Smart Bidding gets blamed for a lot of things it did not cause. Teams argue about which conversion should be primary, tighten a target CPA, or switch strategies entirely, while the actual problem sits one layer below all of that: the conversions feeding the algorithm are not real. Not which conversions you count, but whether the ones you count actually matched a genuine user action. A broken pipeline does not throw an error. The conversion still shows up in your reports, the campaign still looks fine, and the algorithm keeps training on a signal that is quietly degraded, skewed, or missing pieces.
Here are the seven places that pipeline most often breaks, and how to catch each one before it costs you a quarter of bad bidding.
1. Hashing or normalizing PII incorrectly
Enhanced conversions work by taking first-party data you already collect — an email address or phone number — hashing it, and matching that hash against signed-in Google users. It recovers conversions that cookies miss. But the hash is only useful if the input was normalized first.
Email addresses need to be lowercased and trimmed of whitespace before hashing. Phone numbers need E.164 format: country code, no punctuation. Send a raw string with a stray space or mixed case, 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 will never match.
Nothing errors when this happens. The conversion still records normally through standard tracking. What quietly disappears is the enhanced match, and your match rate sits far below where it should be while everything on the surface looks fine.
How to catch it: Check the match rate in your conversion action diagnostics against what Google reports as typical for your setup. If it’s well below that, assume a normalization issue first, then send a known test conversion from a known signed-in address and confirm it matches.
2. Consent Mode signals that never reach the match
In the EEA, the UK, and Switzerland, enhanced conversions data flows through Consent Mode, and the common failure isn’t a tag that fails to fire — it’s that ad_user_data and ad_personalization were never mapped to “granted” on acceptance. The signals that authorize the match are simply missing, even from users who consented. The Google tag checks this in real time and withholds the match key without it.
There’s a subtler version that catches teams even when Consent Mode is configured correctly: consent status doesn’t always update the instant a 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 — goes out under the pre-consent state. The banner recorded the acceptance; the one conversion you most wanted to match went out before the granted signal caught up.
Worth flagging separately: Advanced Consent Mode recovers more data than the basic version, but it sits in genuinely contested territory on privacy. Under it, a non-consented hit still fires — no cookies stored, but the ping still carries browser type, device type, country, page URL, and any custom fields you set, including order ID and value. Whether that counts as clean anonymization or data sent without real consent is exactly the argument privacy practitioners are having right now, and as the data controller, the accountability for how Google processes that signal sits with you either way. That’s a decision for whoever owns privacy on the account, not something to flip on because it lifts your match rate.
There’s also a lever above all of this that’s easy to treat as fixed once legal signs off on it: consent rate itself. Banner layout, wording, and how accept/reject are presented move acceptance rates significantly, and in the EU that rate is often the single biggest cap on how much data ever reaches Smart Bidding. A technically flawless setup running against a banner that 40% of users reject is still only working with 60% of your traffic.
How to catch it: Confirm which version of Consent Mode is running and that the consent signals actually 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.
3. Conversion value that doesn’t match what actually transacted
This one is specific to Target ROAS, and it’s the most financially direct failure on this list. If the value passed with a conversion doesn’t reflect what the customer actually paid, Target ROAS optimizes against a fiction. Common causes: a static value hardcoded when transactions are variable, or currency sent inconsistently so mixed denominations land in one column.
For ecommerce, the bigger issue is usually gross-versus-net, and whether shipping sits inside the number. These sound like reporting preferences. They aren’t — they change which customers Smart Bidding decides are worth chasing.
Two orders both showing €200: one is a full-price sale, the other is mostly discounted items likely to be partly returned. Gross value treats them as identical, so the algorithm goes after more customers who look 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, not margin. Feed either version in, and Smart Bidding optimizes toward whatever looks valuable before you subtract what you actually keep.
Net revenue with shipping excluded is the truest signal, since it sits closest to the margin the business actually keeps. You can run gross value with shipping included and still get consistent optimization from Smart Bidding, but then every downstream number — real ROAS, break-even target, channel comparisons — has to be recomputed to strip that out. Most teams never do, and reported performance quietly drifts from the money actually landing in the bank.
There’s a time dimension too. A value correct at checkout stops being correct once a customer returns two of three items or cancels entirely. Skip that correction and Smart Bidding keeps treating a €200 order that became a €140 order as a full win, chasing more customers who resemble a return you already absorbed. Conversion adjustments close that loop — restate value down on a partial return, retract it entirely on a cancellation. For any business with meaningful return volume, an unadjusted account is systematically training the algorithm toward its own worst customers.
Once value is net and accurate, the next step up is profit: passing cart-level data on what actually sold, plus a cost-of-goods-sold feed in Merchant Center, lets Smart Bidding optimize on margin instead of revenue. One caution — Google will let advertisers approximate COGS, and its own guidance suggests estimating it at around 80% of price. Smart Bidding will chase that estimate as confidently as a real figure, which means profit-shaped reporting built on a guessed margin is a cleaner-looking fiction, not actual profit. Target CPA campaigns are immune to this whole category of error, because they never read value at all.
How to catch it: Reconcile a day of reported value against actual net revenue from your backend, being explicit about whether shipping is in or out on both sides. They won’t match perfectly because of attribution windows, but they should land close. A gap that resembles your average shipping charge or your gross-to-net ratio tells you exactly which mistake happened.
4. A tag or CMS change that silently drops a parameter
This is the failure that does the most cumulative damage, because it isn’t a setup mistake at all — it’s 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, base tracking still works, and the enhanced layer just quietly stops receiving what it needs.
Because nothing throws an error and the conversion count looks normal, this can run 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: Stop relying on someone noticing. The distinctive tell is coverage falling while conversion count holds steady — coverage being the percentage of eligible conversion events that arrived with user data attached, charted over time in the diagnostics report. Alert on that divergence directly rather than waiting to spot it manually.
5. Lead match keys that change between click and close
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 the offline conversion — the closed deal, the qualified lead, the booked revenue — gets uploaded from the CRM. 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 a personal email, then the deal progresses under their work email. Someone corrects a typo in the phone number during qualification. The CRM stores a normalized version of a field that was captured raw on the site. In every case, the offline conversion uploads, tries to match on a key that no longer agrees with what was originally captured, and fails silently. The revenue event — the single most valuable signal in the account — never reaches Smart Bidding.
For lead-gen accounts, this is the difference between Smart Bidding optimizing toward form fills and optimizing toward actual revenue. If the offline match fails, the algorithm trains on the lead, not the sale, no matter how clean the primary conversion architecture looks. It’s the mirror image of 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 the offline import match rate separately from the online match rate — they’re different numbers that fail for different reasons. A low offline rate almost always points to a key-consistency problem between capture and upload; 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 plenty of real sites, they live on different domains, and that’s where the match falls apart. The common shape: 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 doesn’t 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 that handoff, the payload goes out without its match key. The conversion records; the match never happens.
It’s 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 at all.
How to catch it: Map where the user data is available against where the conversion tag actually fires. If those sit on different domains, confirm the data is carried across explicitly rather than assumed to persist — and test through the actual cross-domain path, since 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, and both are hard to spot 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 can’t run at all.
There’s a known Shopify-specific version of this worth watching for. Shopify generates an abandoned-cart ID that looks similar to a real transaction ID, and with a sloppy offline conversion import setup, those abandoned carts can get counted as purchases. The tell is length — the abandoned-cart ID runs noticeably longer than a normal transaction ID — but it still has to be actively monitored, because nothing flags it automatically, and the extra “purchases” inflate both conversion count and, on Target ROAS, value. For Target ROAS specifically, the damage compounds: a double-counted transaction doubles both the conversion and its value, and Smart Bidding then chases more customers who look like that pattern, 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 doesn’t populate reliably when the tag fires. On Shopify specifically, check ID length, since abandoned-cart IDs stand out clearly against real ones.
Why this sits underneath the bidding conversation
The debate over which conversions should be primary versus secondary is worth having, but it assumes the conversions on the table are trustworthy to begin with. This is the layer underneath that decision: not which conversions you select, but whether the ones you select are real, complete, and correctly valued before the selection ever happens. An account can have a flawless primary-and-secondary architecture and still feed the model a signal missing a third of its matches, skewed away from a region, or valued against the wrong number entirely.
This matters more, not less, as bidding gets more automated. When Google adjusted how Smart Bidding responds to signals earlier this year, it was a reminder that these systems commit to a pattern quickly and without the hesitation a person might apply — an agent allocating budget on a corrupted signal doesn’t pause to sanity-check it. That is the same underlying risk raised more broadly around AI systems moving faster than the humans overseeing them, a concern Google’s own leadership has acknowledged in public. The case for connecting automated bidding to live data only holds if that data is clean first.
So before testing another bid strategy, and before auditing which conversions are primary, confirm the conversions are real. Checking match rate is one of the cheapest audits available in Google Ads, and it’s the one most accounts never run.
Frequently asked questions
What’s the fastest way to tell if my Smart Bidding data is degraded?
Start with the match rate in your conversion action diagnostics. If it sits well below what Google reports as typical for your setup, that’s the first sign of a normalization, consent, or tag issue upstream — not a bidding strategy problem.
Does this affect Target CPA campaigns the same way it affects Target ROAS?
Not equally. Target CPA doesn’t read conversion value, so value errors (gross versus net, shipping inclusion, unadjusted returns) don’t distort it the way they distort Target ROAS. Match rate and tagging issues still affect both.
How often should match rate be checked?
Treat it like an ongoing monitor, not a one-time audit. Coverage decay from a dropped tag parameter is gradual, so a monthly check on the diagnostics report catches problems long before they’ve trained a quarter of bad bidding data.
Is Advanced Consent Mode always the right choice for recovering match rate?
Not automatically. It recovers more data, but the privacy tradeoffs it involves are genuinely contested, and the accountability for how that data gets processed sits with the advertiser as data controller. That’s a decision for whoever owns privacy on the account, not a default setting.