admin 
Most Smart Bidding problems get blamed on the wrong thing. People switch strategies, lower targets, and argue about primary versus secondary conversions, when the real problem might be more upstream: the conversions feeding the algorithm are not real. Not which conversions you optimize for, but whether the ones you count actually matched a real user. When the pipeline breaks, the conversion still shows in your reports and the campaign still looks fine. The algorithm is just training on a signal that is degraded, skewed, or partly missing.
1. PII That Is Hashed Or Normalized Wrong
Enhanced conversions work by taking Personally Identifiable Information (PII) first-party data you collect, an email or phone number, hashing it, and matching it against signed-in Google users. The match recovers conversions cookies miss. But the hash only works if the input is normalized first.
Email needs to be lowercased and trimmed of whitespace before hashing. Phone numbers need E.164 format, with country code and no punctuation. Send a raw string with a stray space, a mixed-case address, or a local phone format, and the hash is technically valid and completely useless. The hash of ” John@Example.com ” is not the hash of “john@example.com,” so it never matches.
Nothing errors. The conversion still records through your normal tracking. What you lose is the enhanced match, while your match rate sits far lower than it should and everything looks fine on the surface.
How To Catch It
Check the match rate in your conversion action diagnostics. If it is well below what Google reports as typical, assume a normalization problem first. Send a known test conversion with a known signed-in address and confirm it matches.
2. Consent Mode Not Configured For The Match
In the EEA, the UK, and Switzerland, enhanced conversions data flows through Consent Mode, and the common failure is not that the tag fails to fire. It is that ad_user_data and ad_personalization were never mapped to granted on acceptance, so the signals that authorize the match are missing even when the user consented. The Google tag checks that in real time and withholds the match key without it. Basic consent mode is a separate and smaller problem, because it still measures a consenting user in full. What basic costs you is the decliners, plus modeling quality.
Worth flagging before you rush to switch it on: Advanced consent mode is the right call for data recovery, but it sits in a genuinely contested spot on privacy. Under it, a non-consented hit still fires. No cookies are stored, but the ping still carries browser type, device type, country, page URL, and any fields you set yourself, including order ID and conversion value, and that feeds aggregated modeling you only see once you clear Google’s data thresholds. Whether a payload like that is clean anonymization or data you are still sending without consent is exactly the argument practitioners are having, and as the data controller you carry the accountability for Google’s processing either way. I am not giving legal advice, and this is a call to make with whoever owns privacy at your client, not something to flip on because it lifts your match rate.
There is a subtler version that catches people even when consent mode is configured correctly. The consent status does not always update the moment the user clicks accept. On some setups it only updates on the next page load, so the conversion firing on the current page, the purchase or lead the user just completed, still goes out under the pre-consent state. The banner recorded the accept, but the one conversion you most wanted to match went out before the granted signal caught up.
One lever sits above all of this. Every fix here assumes the user consented in the first place, and consent rate is not fixed. Banner layout, wording, and how the accept and reject options are presented move acceptance rates significantly, and in the EU that rate is often the single biggest cap on how much data reaches Smart Bidding at all. A technically flawless setup on a banner that 40% of users reject is still only working with 60% of your traffic. Improving the banner is usually a bigger lever than any of the tuning above, and it is the one people treat as fixed because legal signed off on it once.
How To Catch It
Confirm what version of consent mode you are running: Advanced consent mode or basic, and that the consent signals update to granted on acceptance. Then test the timing specifically: Accept consent and complete a conversion in the same page session, and confirm the granted signal is in place before the conversion fires rather than only after the next navigation. That timing gap is the part that survives an otherwise correct setup.
3. Conversion Value That Does Not Match What Transacted
This one is specific to Target ROAS, and it is the most financially direct of the seven. If the value passed with the conversion does not reflect what the customer actually paid, Target ROAS optimizes against a fiction. Common causes are a static value hardcoded when transactions are variable, or currency sent inconsistently so mixed denominations land in one column.
For ecommerce, the biggest version is the gross-versus-net question, and whether shipping is inside the number. These sound like reporting preferences. They are not. They change which customers Smart Bidding decides are valuable.
Say two orders both show €200. One is a full-price sale. The other is mostly discounted items that will partly get returned. Gross value treats them as identical, so the algorithm chases more customers like the second one. Shipping does the same thing: an order with €15 of shipping folded into the value outbids an identical free-shipping order, even though that €15 is a cost to you, not margin. Feed either in and Smart Bidding optimizes toward whatever looks valuable before you subtract what you actually keep.
The truest signal is net revenue with shipping excluded, because it is closest to the margin the business keeps. You can run gross and include shipping, and Smart Bidding still optimizes toward a consistent number. But then every downstream calculation, your real ROAS, your break-even target, your channel comparisons, has to be recomputed to strip out what you baked in. Most teams never do, so reported performance drifts from the money in the bank without anyone deciding it should.
There is a time dimension to this too. The value that was correct at checkout stops being correct when the customer returns two of the three items, or cancels entirely. If you never send that back, Smart Bidding keeps treating a €200 order that became €140 as a €200 win, and keeps chasing customers who look like a return you already ate. Conversion adjustments are how you close that loop. Restate the value down on a partial return, retract it entirely on a cancellation. For any business with meaningful return rates, an unadjusted account is systematically training the algorithm toward its own worst customers.
Once the value is net and correct, the next step up is profit. Conversions with cart data passes what actually sold per order, and a cost-of-goods-sold feed in Merchant Center lets Smart Bidding optimize on margin rather than revenue. One caution: Google will let you approximate COGS; its own guidance suggests estimating it at 80% of price, and Smart Bidding will chase that estimate as confidently as a real figure. Profit-shaped reporting built on a guessed margin is a cleaner-looking fiction, not profit.
Target CPA campaigns survive this because they do not read value. Any Target ROAS account does not.
How To Catch It
Reconcile a day of reported value against actual net revenue from your backend, and be explicit about whether shipping is in or out on both sides. They will not match perfectly because of attribution windows, but they should be close. A gap that looks exactly like your average shipping charge or your gross-to-net ratio tells you which mistake you made.
4. A Tag Or CMS Change That Silently Drops A Parameter
This is the failure that does the most damage over time, because it is not a setup error at all. It is a setup that was correct and then broke.
A developer ships a site change. A GTM container gets reorganized. A CMS update alters how a variable populates on the confirmation page. Any of these can drop the field enhanced conversions depends on: The email variable stops populating, or the value parameter starts returning empty. The conversion still fires, and base tracking still works. The enhanced layer just stops receiving what it needs.
Because nothing throws an error and the conversion count looks normal, this runs for weeks. Match rate decays slowly rather than dropping off a cliff, so it never triggers the alarm a total tracking failure would. By the time anyone notices bidding has drifted, the model has trained on degraded data for a month.
How To Catch It
The fix is to stop relying on anyone noticing. The distinctive tell is coverage falling while conversion count holds steady. Coverage is the percentage of eligible conversion events that arrived with user data attached; it is charted over time in the diagnostics report, and it is the number that moves when a variable stops populating. Alert on that divergence directly.
5. Enhanced Conversions For Leads Keyed To Data That Changes
This is the one almost nobody writes about, because it crosses from the ad platform into the CRM, and most coverage stops at the website.
Enhanced conversions for leads captures hashed user data at the moment of the lead, then matches it later when you upload the offline conversion from your CRM: the closed deal, the qualified lead, the booked revenue. The match key is the data captured at form submission, and the failure is that this key changes between the click and the close. A user submits a form with their personal email, then the deal progresses under their work email. Someone fixes a typo in the phone number during qualification. The CRM stores a normalized version of a field captured raw on the site. In each case, the offline conversion uploads, tries to match on a key that no longer agrees with what was captured, and fails silently. The revenue event, your single most valuable signal, never reaches Smart Bidding.
For lead-gen accounts, this is the difference between Smart Bidding optimizing toward form fills and optimizing toward revenue. If the offline match fails, the algorithm trains on the lead, not the sale, no matter how clean your primary conversion architecture is.
This is the same problem from the other direction as keeping fraudulent leads out of the signal in the first place: both decide whether the data Smart Bidding learns from reflects real revenue.
How To Catch It
Check your offline import match rate separately from your online match rate. They are different numbers that fail for different reasons. A low offline rate almost always points to a key-consistency problem between capture and upload, and the fix is standardizing which field is the match key and normalizing it identically in both places.
6. Match Data Captured On One Domain, Conversion Fired On Another
Enhanced conversions need the user data and the conversion event to end up associated with each other. On a lot of real sites, they live on different domains, and that is where the match falls apart.
The common shape is a checkout that hands off to a payment processor on its own domain, or a booking flow that completes on a subdomain the main tag does not fully cover. The user enters their details on your site, then the purchase confirms elsewhere. If the conversion fires on the confirmation page but the user data was only available before the handoff, the payload goes out without its match key. The conversion records. The match does not happen.
It is easy to miss because it only affects traffic running through the cross-domain path. A single-domain test purchase matches perfectly, so the setup looks correct, while a meaningful slice of real transactions takes the broken route and never matches.
How To Catch It
Map where the user data is available against where the conversion tag fires. If those are on different domains, confirm the data is carried across explicitly rather than assumed to persist. Test through the actual cross-domain path, because the simplified single-domain test is exactly the one that hides this.
7. Duplicate Or Missing Transaction IDs
Enhanced conversions use the transaction or order ID to deduplicate. Get that ID wrong and the match layer either double-counts or collides, both hard to see from the reporting surface.
Duplicate IDs happen when a reloadable confirmation page fires the same order ID more than once, or a test and a live transaction share an ID, so one purchase matches as several. Missing IDs happen when the field is empty or inconsistent, so deduplication cannot run, and the system drops matches or fails to reconcile the online event with the offline upload.
There is a known Shopify version worth watching for specifically. Shopify generates an abandoned-cart ID that looks similar to a transaction ID, and with a sloppy offline conversion import setup, those abandoned carts sometimes get counted as purchases. It is easy to spot once you know the tell: the abandoned-cart ID is much longer than a normal transaction ID. But it still has to be monitored, because nothing flags it and the extra “purchases” inflate both your conversion count and, on Target ROAS, your value.
For Target ROAS, the damage compounds, because a double-counted transaction doubles both the conversion and its value. Smart Bidding then sees a customer pattern tied to inflated returns and chases more users like them, confidently, on a number that was never real.
How To Catch It
Pull a sample of order IDs and check them against your backend for uniqueness and completeness. Every real transaction should carry exactly one ID, present and unique. Reloadable confirmation pages are the usual source of duplicates; empty fields usually trace back to a variable that does not populate reliably when the tag fires. On Shopify specifically, check ID length, since the abandoned-cart IDs stand out as noticeably longer than real transaction IDs.
Why This Sits Underneath The Bidding Conversation
The conversion architecture argument is right that you should decide carefully what Smart Bidding learns from. This is the layer below that. Not which conversions you select, but whether the ones you select are real, complete, and correctly valued before the selection happens. You can have a flawless primary and secondary setup and still feed the model a signal missing a third of its matches, skewed away from a region, or valued against the wrong number. The architecture decides what the algorithm trains on. Data integrity decides whether that training data is true.
This matters more, not less, as bidding gets more automated. An agent allocating budget on a corrupted signal does not hesitate the way a person might. It commits, quickly, to a pattern built on data that was wrong before anyone chose to trust it. The case for connecting automation to live, trustworthy data only holds if the data underneath is clean first.
So, before you test another bid strategy, and before you audit which conversions are primary, confirm the conversions are real. Check your match rate. It is the cheapest audit in Google Ads, and the one most people never run.
More Resources:
Featured Image: Collagery/Shutterstock
