Setting up GA4 so the numbers survive a consent banner
A standard GA4 install ships with no consent values set at all. Four settings decide whether a visitor who declines is counted, and none is in the setup wizard.
On this page
- The default install has nothing to be consent-aware about
- Four settings decide whether a denied visitor is counted
- Scoping the default to a region is the setting that quietly costs you data
- A denied visitor still sends whatever else you put in the ping
- How to verify it rather than assume it
- Which common symptoms trace back to this, and which don't
Short answer: a standard GA4 install is configured for a site with no consent layer, and Google says so in one line of its own developer guide: "By default, no consent mode values are set." Four things decide whether a visitor who declines is counted at all, and none of them appears in the GA4 setup flow — whether your implementation loads tags before the banner or blocks them, whether the consent default fires before the first tag, which reporting identity the property is on, and whether your CMP is running in TCF mode. Fix those four and your numbers get smaller and start being true. Skip them and you get a report that looks healthy and isn't.
Everything below is a property or tag setting. If you're chasing a number that already dropped, the diagnosis is a different job: start with the four causes of a post-banner traffic drop.
The default install has nothing to be consent-aware about
The Google tag adjusts its behaviour according to consent state. That's real, and it's the source of the confusion, because the tag can only adjust to a state that something set.
Google's developer guide is explicit: "By default, no consent mode values are set." So on a site where GA4 was installed first and a banner was added later, the sequence is usually that the tag loads, fires, and writes its cookies, and the banner appears over the top of a page that has already measured the visitor. Nothing is broken. Nothing was configured either.
The same guide is emphatic about ordering, in bold in the original: "If your consent code is called out of order, consent defaults won't work." Its documented sequence is the consent default first, then the Google tag, then the update when the visitor chooses. Tag Assistant reports an outright error for the case where an ad tag has already read or written a cookie before the default was set.
If your banner loads asynchronously — most third-party CMPs do — the guide's answer is wait_for_update with a millisecond value, which holds data back for that long to give the CMP time to call the update. It's a race, and you are choosing how long to wait for it.
Four settings decide whether a denied visitor is counted
None of these lives in the same screen as the others, which is most of why they get missed.
| Setting | Where it lives | What it decides | How to check |
|---|---|---|---|
| Advanced or basic implementation | Your CMP config or your own consent code | Whether denied visitors send cookieless pings at all, and so whether behavioural modelling is even possible | Tag Assistant: do Google tags fire before the banner is answered? |
| Consent default timing | Page head, or the Consent Initialization trigger in GTM | Whether the first hit of the session is unconsented | Tag Assistant: the earliest Consent event, On-page Default column |
| Reporting identity | GA4 Admin → Data display → Reporting identity | Whether modelled data appears in your reports even when the property qualifies | The data-quality icon on a report |
| TCF or non-TCF CMP | Your CMP's own mode | Whether GA4 can model denied traffic at all | Your CMP's settings, and Tag Assistant's Consent tab |
Two of those four need spelling out, because the documentation buries them.
Reporting identity gates the modelled data you already earned. Modelling only shows up under the Blended identity, which Google describes as "By User-ID, device ID, then modeling". On any other setting, the data-quality icon reports "Excluding estimated user data: Your property's reporting identity setting doesn't allow Analytics to estimate data that's missing due to factors such as cookie consent." Google's reporting-identity page lists the three options and doesn't name a default, so check what yours is on rather than assuming. And note what modelling never reaches: audiences, retention reports, predictive metrics, segments with a sequence, and data export — including the BigQuery export, which is observed data only.
A TCF banner turns modelling off entirely. This is the single least-known setting in the list. Google's consent mode help page states that with the IAB Europe Transparency & Consent Framework, "when your users deny consent with a consent solution that uses the TCF, Google Analytics properties aren't able to model data to fill in the missing information." If you run TCF because you sell programmatic inventory, that's a defensible trade — but it is a trade, and the modelling half of your Consent Mode implementation is what you're paying with.
Whether modelling would have helped you anyway is a volume question with published thresholds: at least 1,000 events a day at analytics_storage='denied' for seven days, plus at least 1,000 daily consented users on seven of the previous 28 days, and clearing both is still not a guarantee. Most sites never qualify, which is the argument in what modelling actually recovers.
Scoping the default to a region is the setting that quietly costs you data
Google's own best-practice list says to configure the default state for particular regions rather than for all visitors, and gives the reason directly: applying denied globally when your organisation requires it in one market "avoids losing precise measurement for all other regions". A UK business serving customers in markets with no banner requirement is throwing away observed data if it defaults everyone to denied.
Region defaults use ISO 3166-2 codes, and the more specific region wins — a US default of granted with a US-CA default of denied means a Californian visitor gets denied. The failure Google documents is subtler than getting a code wrong: their troubleshooting page shows an example that sets a regional default for analytics_storage and a global one for ad_storage, and the warning is to check that all four parameters behave as your policy intends. Half-scoped defaults are the normal way this breaks.
A denied visitor still sends whatever else you put in the ping
Here's the line that changes how people configure custom dimensions, and it's in Google's consent mode help page rather than anywhere prominent. When analytics_storage='denied', cookieless pings go to Google, and: "If an advertiser sets other fields, such as user_id and custom dimensions, they will be sent normally."
So denied stops cookies. It does not stop your payload. If you're populating a custom dimension with a CRM identifier, a hashed email or a logged-in account reference, that value leaves the browser for a visitor who declined, because you told the tag to send it. Whether that's lawful is a question about your consent wording, not about Consent Mode — and Consent Mode will not save you from it. The same page notes that user IDs are also the thing that makes cross-device reporting work, so this is a real design tension rather than a bug: see how User-ID behaves in GA4 for the reporting side.
There's a matching surprise on the ads side. With ad_storage='denied', Google still collects the full page URL, "and may include ad-click information in URL parameters (e.g., GCLID / DCLID)", which it says is used only to approximate accurate traffic measurement. If you want those identifiers redacted, that's a separate switch: ads_data_redaction, set to true, which also routes requests through a domain without third-party cookies. Two related settings, two different jobs, and nothing in the interface pairs them.
Reading your own consent implementation from the outside is the only check that matters, because it's the view Google's tags get. Our Consent Mode checker loads your site in a real browser, reads the consent state that was actually set, in what order, and reports whether the four v2 parameters are present before the tags fire.
How to verify it rather than assume it
Google publishes the procedure, and it takes about ten minutes per region.
- Open Tag Assistant and enter your site URL. A new tab opens with your site.
- Answer the banner — accept everything, on the first pass.
- Check the default. In the Summary, select the earliest Consent event and look at the API Call section for all four parameters:
ad_storage,ad_user_data,ad_personalization,analytics_storage. The On-page Default column in your tag's Output shows the same thing. - Check the update. Select the most recent Consent event and confirm the same four parameters changed.
- Check the tags. In the Tags tab, open individual tags and confirm each behaved as the consent state required.
- Repeat with a simulated location for every region you set a default for, using Chrome DevTools' location override.
Two readings tell you something immediately. An empty Consent tab means consent mode is not implemented on the page at all — not misconfigured, absent. And a Tag Assistant error on ordering means a tag beat your default, which is the case that produces a first hit nobody consented to.
Then do the run again choosing reject, which is the pass people skip. What you want to see is Google tags still loading and sending pings with no cookies written. What you'll sometimes see instead is a CMP blocking the container outright, which is basic implementation whatever the CMP's settings screen claims. For the event-level view of the same question, DebugView has three documented ways in and one big blind spot.
Which common symptoms trace back to this, and which don't
Configuration explains fewer reporting complaints than people expect, so it's worth separating them.
Traces back to these settings. A traffic figure that fell when the banner went live, and stayed down. Sessions with no session_start — Google documents this precisely, noting that if a page loads with consent denied and reloads with consent granted, "many sessions with consent could be missing a session_start event", which is why the update command has to run on the page where the visitor chose. User counts that jump when somebody changes the reporting identity, since that's modelled data appearing or disappearing rather than traffic moving. Inflated first_visit and session_start counts in standard reports, because unconsented events aren't tied to a persistent identifier, so the event fires on every page load.
Mostly doesn't. Unassigned traffic is usually campaign-tagging and referral rules rather than consent, though a consent-timing cause does sit in that list and a UTM audit won't find it. Ecommerce numbers that disagree with the shop's own totals are normally an event schema problem. Neither of those improves because you set a consent default.
The reason to keep the two piles apart is cost. Consent settings are a couple of hours of configuration and a verification pass. Attribution and schema problems are weeks. Fixing the cheap pile first also changes what the expensive pile looks like, because you stop diagnosing a data set that was being collected wrongly.
If you'd rather not do the verification pass yourself, that's the work we do — and it's a considerably better conversation to have before somebody presents last quarter's numbers than after.
Sources
- 1.Google — Set up consent mode on websites ('By default, no consent mode values are set'; ordering, regions, URL passthrough, ads_data_redaction) · Checked 2026-09-10
- 2.Google — Troubleshoot consent mode with Tag Assistant (verification procedure and the documented failure cases) · Checked 2026-09-10
- 3.Analytics Help — Consent mode on websites and mobile apps (tag behaviour per consent state; TCF and modelling) · Checked 2026-09-10
- 4.Analytics Help — [GA4] Behavioral modeling for consent mode (eligibility thresholds, reporting-identity requirement, unsupported features) · Checked 2026-09-10
- 5.Analytics Help — Reporting identity (Blended, Observed, Device based) · Checked 2026-09-10