Google Consent Mode v2: When Your Setup Quietly Deletes Data

Consent Mode v2 has two implementations, and the difference is not cosmetic. One of them preserves a modeled signal from visitors who decline; the other silently discards those visitors forever. And even the correct implementation comes with eligibility thresholds that most small and mid-sized properties never meet, which means the "modeling will fill the gaps" promise you may be counting on frequently does not apply to you. None of this errors. Your reports just quietly shrink, and a year later nobody can explain why the trend broke.

The short answer: basic mode deletes, advanced mode models, thresholds decide

Google's consent mode documentation is explicit about the split. A basic implementation blocks Google tags until the visitor consents, which means a declined visitor transmits nothing at all. An advanced implementation loads tags before the consent dialog opens and in all cases, consent or not; declined visitors then send cookieless pings with no persistent identifier, and those pings are what behavioral modeling trains on. Google states plainly that with the basic route "you will not get modeled data in your Google Analytics property to fill in the gaps."

So the first check takes thirty seconds: does your Google tag load before your consent banner fires, on every page, regardless of the visitor's choice? If your consent platform injects the tag only after acceptance, you are on the basic path, and every declined visitor since the banner went live is unrecoverable.

The thresholds nobody reads

Advanced implementation is necessary but not sufficient. Google's behavioral modeling documentation lists the eligibility criteria, and they are volume gates: the property must collect at least 1,000 events per day with analytics_storage='denied' for at least 7 days, and must have at least 1,000 daily users sending consented events for at least 7 of the previous 28 days. Google adds that meeting the thresholds does not guarantee eligibility, and that even additional data may not be sufficient to train the model.

Run the arithmetic against your own traffic. A property doing a few hundred sessions a day does not produce 1,000 denied-storage events daily unless its decline rate is enormous. The practical consequence: for most businesses below roughly a thousand daily users, declined visitors vanish from reports no matter how correctly consent mode is wired. The modeling story you read about at rollout time was written for properties ten times your size.

Even with modeling, your pageview series still breaks

The subtlest trap sits one layer deeper. When a property does qualify, modeling is applied to metrics like users, sessions, and new users. It is not applied to event counts such as page_view, first_visit, and session_start, per the same Google documentation. Pageview counts only ever reflect consented plus cookieless-observed traffic, so the day your banner went live is a permanent step change in every pageview time series, even in the best case.

We learned to respect this one during a website relaunch investigation where a consent banner and an analytics drop arrived in the same week, and consent mode took the blame. It explained the shape of the drop and not the size; the dominant cause turned out to be years of double-fired GA4 tags on the old site. Both lessons generalize. Consent changes and tag changes love to ship together, and untangling them requires diffing both sides of the cutover instead of accepting the first plausible mechanism.

How to check your property this week

1. Load your site in a private window and watch the network panel before touching the banner. If no Google tag request fires until you accept, you are on the basic implementation.
2. Decline consent and look at the hits that do fire. Advanced-mode pings carry a consent state parameter (gcs) showing denied storage. No hits at all means declined visitors are simply gone.
3. Compare your daily event volume against the modeling thresholds above and be honest about whether you qualify. If you do not, treat every consent-era number as consented-traffic-only and label it that way in reports.
4. Annotate the banner launch date in GA4 as a permanent series break, the same way you would for a tagging fix. Never compare pageviews across it without saying so.
5. If your consent rate matters commercially, measure it directly: consented sessions divided by server-side or CDN request counts for the same period, which no consent state can distort.

What to do about it

If you are on basic mode, the fix is configuration, not code: your consent platform almost certainly supports the advanced pattern, where tags load in all cases and fire according to consent state. Google's guidance also notes that a denied-by-default state can be applied only to visitors from regions that require it, which preserves full measurement everywhere else; that is a policy decision for you and your counsel, but it is worth knowing the option exists. And if your property is below the modeling thresholds, move the KPIs that matter to sources consent cannot bend: Search Console clicks, server-side conversion counts, orders.

If your numbers changed and nobody knows why

A consent rollout is one of the three or four events that permanently rewrite what your analytics baseline means, and it rarely arrives alone. We run fixed-scope tie-out audits that separate consent effects from tagging effects from real demand changes, with the evidence attached. The step change in your charts has a mechanical explanation; the expensive mistake is guessing which one.