Consent Mode V2 Attribution Gaps and Modeling Accuracy

Consent Mode V2 didn't just change a checkbox in Google's settings. It changed what Google is legally allowed to see, and that creates real holes in your data, not small dents. Understanding how Google's modeling tries to patch those holes, and where it can't, tells you what your reporting actually reflects versus what it's guessing at.

A quick timeline helps. Google shipped the first version of Consent Mode back in September 2020. Version 2 landed in November 2023 and became mandatory for advertisers in the EEA and UK by March 2024, largely because of Google's obligations under the EU's Digital Markets Act. V2 added two new parameters, ad_user_data and ad_personalization, on top of the original ad_storage and analytics_storage. Then, starting July 21, 2025, Google began actively shutting off remarketing, conversion tracking, and demographic reporting for EEA and UK traffic on accounts that weren't sending proper consent signals.

Those four parameters are the whole ballgame. When a user withholds consent on any of them, the related data doesn't get fuzzy or degraded. When a user withholds consent on any of them, the related data doesn't get fuzzy or degraded, it disappears. And this isn't a niche problem affecting a handful of privacy-conscious users. Global research from Cookie Script (cited by Dataslayer) puts average cookie acceptance at just 31%, and EU numbers usually run lower than that. Add in ad blockers, which run on roughly 29.5% of internet connections worldwide according to GWI and Backlinko, and you've got a huge chunk of traffic where GA4's tag never even fires, consent or no consent.

Modeling is Google's answer to that gap. It's not a patch bolted on after the fact, it's a built-in feature of how the system now works. But it only works under specific conditions, and it comes with real limits and a fair amount of opacity. The rest of this piece walks through what modeling can actually recover, where it falls apart, and which setup choices decide the outcome.

How Basic and Advanced mode determine whether modeling is available at all

Nothing matters more to modeling accuracy than this one setting. It's the fork in the road that everything else downstream depends on.

Basic Mode is the stricter of the two. Tags simply don't load until a user says yes. Say no, and nothing gets sent, not even an anonymous ping. GA4 has zero behavioral modeling to work with in this setup. Over in Google Ads, conversion modeling falls back to generic industry benchmarks instead of anything built from actual site behavior; Bounteous reports this.

Advanced Mode works differently. Tags load right away with consent defaulted to denied, and when a user actually declines, Google still gets a "cookieless ping": an anonymized, cookieless signal that carries behavioral information but no user ID and no way to stitch it to a session. Those pings are the raw material Google's machine learning uses to estimate what non-consenting users probably did.

The gap between the two isn't just "more data versus less." A model trained on your own site's patterns and one borrowed from an industry average that has nothing to do with your business produce a meaningful accuracy gap, not a rounding error. That's a meaningful accuracy gap, not a rounding error.

Some teams stick with Basic Mode anyway, and there are real reasons for it. Legal counsel at some companies won't sign off on cookieless pings. Regulators in France, Italy, the Netherlands, and Austria have raised questions about GA4 compliance that make some teams cautious. Low-traffic sites often won't hit the volume thresholds for modeling regardless of mode, so Advanced buys them nothing. And building Advanced Mode correctly takes engineering time some teams don't have.

If an advertiser is on Basic Mode and staring at flat modeling numbers wondering what's wrong, they're asking the wrong question. Modeling was never switched on for them.

Even Advanced Mode doesn't turn modeling on automatically, though. There's a volume bar to clear first.

The traffic thresholds that determine whether Google's models ever activate

Google won't model data below certain minimums. Fall short, and non-consenting users aren't estimated at all, they just vanish from every report.

Fresh Egg's research finds that for GA4 behavioral modeling, a property needs at least 1,000 daily users with analytics_storage set to granted, for a minimum of 7 out of the previous 28 days, the consented group the model learns from. That's the consented group the model learns from. It also needs at least 1,000 events per day with analytics_storage set to denied, for at least 7 days, which is the group the model is trying to fill in for. Do the math on a 50% consent rate and a site needs 2,000 total daily visitors just to be in the running. Plenty of smaller sites never get there.

Google Ads runs its own separate threshold for conversion modeling: 700 ad clicks over a 7-day window, broken out by country and domain grouping; both Fresh Egg and Dataslayer report this.

Clearing the threshold makes a property eligible, not modeled overnight. Training takes time after eligibility first kicks in. And eligibility isn't a one-time badge, either: the thresholds must be maintained, and Google doesn't go back and fill in any gap retroactively.

One setup detail trips up a lot of implementations: Fresh Egg notes that GA4's Reporting Identity has to be set to "Blended" for modeled data to even show up in reports. If that step is skipped, modeling might run in the background while the reports show nothing for it.

There's an uncomfortable irony baked into all this. The sites that need modeling the most, the smaller ones with lower traffic and lower consent rates, are exactly the ones least likely to qualify for it. The system, structurally, favors bigger properties.

For the sites that do clear the bar, the next question is how much of the missing data modeling actually gives back.

What recovery figures mean and how widely they vary

The numbers floating around out there span a wide range, and none of them should be treated as a guarantee for any specific site. They're directional at best.

Advanced Mode recovery, on a clean implementation, has been cited at 10–30% of lost conversion data. Dataslayer's figure for Advanced Consent Mode modeling specifically is a 15-25% uplift in reported conversions. Fresh Egg, drawing from its own client base, has seen recovery above 70% in some cases. Google's own illustrative example describes an advertiser with a 50% consent rate seeing only a 19% drop in conversions, 12 out of 62, with modeling adding an 18% uplift. And in one real-world case detailed by ppc.land (the Harvest Digital case, discussed by Mike Teasdale), roughly 40% of attribution data came back through behavioral modeling after a broken consent banner got fixed. The other 60% was gone for good.

That spread comes down to a handful of variables: consent rate, traffic volume, industry, what kind of conversion is being tracked, and whether the account has layered on extras like Enhanced Conversions or server-side tagging.

Three things stack together to push recovery toward the higher end of that range:

Advanced Consent Mode modeling gets the 15-25% uplift mentioned above. Enhanced Conversions, which match hashed first-party data like email or phone numbers to logged-in Google users, adds another 5-25%, and it matters even more given that Safari and Firefox cap third-party cookie life at 1 to 7 days. Server-side tagging, which moves data collection off the browser and around most ad blockers, adds 10-30% in accuracy, and typically costs a modest monthly sum to run on something like Google Cloud Run.

The 40% figure from the Harvest Digital case deserves more attention than the others, since it reflects a measured outcome after the fix went in, not a projection. And it comes with a hard ceiling: even a correctly built implementation can't pull back data that was never captured during the broken period. It's just gone, because even a correctly built implementation can't pull back data that was never captured during the broken period.

Google's own Ads documentation notes that consented users convert at 2 to 5 times the rate of non-consenting users. That means the model is estimating behavior for a group that acts differently, by a wide margin, from the group it's learning from. None of the recovery percentages above fully account for that mismatch.

Recovery rates describe the aggregate picture. What happens inside the actual reporting tools is a different, messier story.

Where modeled data misleads: the reporting gaps practitioners hit in practice

GA4's standard reports don't separate modeled conversions from measured ones. The dashboard shows one blended number, no asterisk, no flag telling you what share of it is a Google estimate.

That creates a specific headache for anyone pulling data into BigQuery. Modeled numbers stay locked inside the GA4 reporting interface and never make it into the BigQuery export. So anyone building reports off raw BigQuery data will always see a lower conversion count than what's showing on the GA4 dashboard. The architecture works that way by design.

If GA4 shows more conversions than the CRM or backend order system for the same stretch of time, and Consent Mode is active, the gap is probably modeled conversions that never turned into real orders, and that inflation risk needs watching closely. If GA4 shows more conversions than the CRM or backend order system for the same stretch of time, and Consent Mode is active, the gap is probably modeled conversions that never turned into real orders. Because the model is estimating behavior for users who never consented, it can't confirm whether an unconsented conversion had an ad interaction behind it, which means some real conversions may go uncounted even as others are over-estimated. The bias doesn't always run in the same direction. Still, properties running low consent rates without ever validating their setup tend to show inflated numbers that make certain channels look better than they are, which nudges budget toward the wrong place.

Smart Bidding takes a hit from this too. It depends on clean conversion signals, and when those signals are thin or heavily modeled, the algorithm can pull back on bids, shrink impression share, or shift spend toward channels with cleaner attribution, which just deepens the original measurement problem. In smaller accounts, modeled conversions can make up a large chunk of the total signal Smart Bidding is working from, which makes bid optimization jumpy. A common pattern in accounts with active Consent Mode is conversion tracking issues severe enough to corrupt Smart Bidding outright, often from double-counted conversions caused by running GA4 imports and native Ads tags side by side.

There's a timing issue layered on top. The default GA4-imported key event can lag behind the Google Ads native tag by several hours. Unless an account has specifically overridden that default, Smart Bidding is optimizing against yesterday's behavior, not today's.

Attribution models don't always agree with each other, either. GA4 runs its own property-level model, Data-Driven Attribution by default, and Google Ads applies its own attribution model to that same imported conversion. Discrepancies that look like broken tracking are often just two different models disagreeing about credit.

The most useful check here is simple: line up GA4's total conversions against actual CRM or backend order counts for the same period. Whatever excess appears in GA4 when compared against CRM or backend order counts is likely modeled conversions that didn't correspond to real orders, and it shouldn't get counted as real campaign performance.

How silent implementation failures create data loss that looks like market weakness

The Harvest Digital case, shared by Mike Teasdale on LinkedIn and reported by ppc.land, is the clearest illustration of how bad this can get without anyone noticing.

Conversions for the client dropped 90% overnight in August 2025. Campaigns were still live, clicks were still coming in, nothing in the account had been touched. The cause turned out to be the consent banner itself: it looked fine, it was legally compliant on its face, but it wasn't passing consent signals through to Google's tag layer. From Google's side, no signal means no consent, full stop.

The trigger for the collapse was Google's July 2025 enforcement policy, the same one mentioned earlier, which started cutting off personalization, remarketing, and conversion tracking for accounts without properly wired-up Consent Mode V2 signals on UK and EEA traffic. After the team found and fixed the issue, behavioral modeling recovered around 40% of the lost attribution data. The remaining 60% was gone permanently, with no way to get it back.

This is what makes these failures so dangerous: everything looks fine on the surface. The banner shows up, the tag fires, the dashboard looks healthy, and the consent signal still never reaches Google. Google's own documentation says detection latency for consent signal issues runs 48 to 72 hours, so a broken setup can quietly bleed data for up to three days before any diagnostic tool even flags it.

Performance decline across the accounts Teasdale looked at showed up gradually, and advertisers kept blaming the market, seasonality, competition. "Their numbers have been soft for months. They assume it's the market. It's their data infrastructure."

Legal compliance and technical compliance are two separate things, and that gap is the cause underlying these problems: a banner can satisfy GDPR from a user's point of view while remaining invisible to Google's systems. A banner can check every box GDPR requires from a user's point of view, and still be completely invisible to Google's systems. Regulators are watching both sides of that line, too. CNIL fined Google €325 million in September 2025 over consent violations, and the California Privacy Protection Agency fined Honda $632,500 in March 2025 for CCPA violations that included making it harder to decline tracking than to accept it.

The implementation mistakes that produce silent data loss in practice

Most Consent Mode V2 failures don't appear in a dashboard right away. By the time someone notices, the damage has usually been piling up for weeks.

A common one, flagged by both Bounteous and Darwin Apps, is getting the Google Tag Manager firing order wrong. If consent defaults are set to fire on a Page View trigger instead of the Consent Initialization trigger, tags can execute before any consent state has even been established. That means data gets collected before the user has made a choice at all, which creates compliance exposure and corrupts the very consent signal the system depends on.

That kind of sequencing error tends to surface downstream in a different form. Missing session_start and page_view events, caused by this exact problem, show up in GA4 as a wave of "(not set)" traffic sources across acquisition reports. Teams often chase that as a tagging bug when the real cause is upstream, in how consent gets initialized.

Darwin Apps identifies third-party scripts embedded straight into page HTML as another common culprit. If a script sits outside the tag container, it fires the moment the page loads, regardless of what the consent management platform is configured to do. By the time the banner even renders, the data's already been collected. No banner fix after the fact can undo that.

Regional consent defaults get mishandled too. Darwin Apps reports that a single global default applied across every market either over-collects in the EEA or under-collects everywhere else. And there's a legal wrinkle that adds pressure here: a ruling from the Verwaltungsgericht Hannover found that Google Tag Manager itself was sending device data, including IP addresses, to US servers before any consent interaction had even happened, which has pushed some teams to rethink how much they trust default GTM behavior before a user has said anything.