Without consent mode, GA4 measures whichever visitors your consent banner allowed it to measure, and the reports carry no marker saying so. If the banner blocks the Google tag until someone accepts, then users, sessions and key events all describe the consenting subset of your traffic. Consent mode changes what happens to everyone else: in its basic form the tags stay blocked and nothing is transferred at all, and in its advanced form the tags load and send measurements without cookies for as long as consent is denied.
Google's consent mode defines seven consent types, each of which can be granted or denied independently. Analytics measurement is governed by analytics_storage. Advertising is governed by ad_storage, ad_user_data and ad_personalization, the last two of which were added in the November 2023 update that is now called consent mode v2. The remaining three — functionality_storage, personalization_storage and security_storage — cover storage for site features, personalisation and security respectively, and a Google tag will not read them for analytics reporting.
Basic and advanced consent mode differ on one question: whether Google tags are allowed to run before the visitor answers the banner. In basic consent mode the tags do not load until the visitor interacts with the banner, nothing is transmitted to Google before that interaction, and when the visitor declines, no data is transferred at all — not even the consent state. In advanced consent mode the tags load when the page opens, set their default consent states, send measurements without cookies while consent is denied, and update when the visitor answers.
| Setup | What happens when a visitor declines | What reaches GA4 |
|---|---|---|
| No consent mode, banner blocks the tag | The Google tag never loads | Nothing from that visitor |
| No consent mode, tag loads regardless | The tag behaves as though consent were granted | Full measurement with cookies, whatever the visitor chose |
| Basic consent mode | Tags are blocked from firing entirely | Nothing from that visitor, not even the consent state |
| Advanced consent mode | Tags load and send measurements without cookies | Cookieless measurements carrying the consent state |
A signup that starts on your marketing site and finishes in your app is two users in GA4 unless the domains are configured together. Here is what the setting does and what it cannot fix.
Market4 turns one release note into a changelog page, a blog post, a mail-out and a week of social posts — and then tells you which of them brought anyone back.
GA4 numbers collected behind a blocking banner with no consent mode are a lower bound on your traffic, not an estimate of it. Four consequences follow, and all four are easier to handle if you write them down before someone asks why the site's own order count and the property disagree.
Exports inherit all of this. A report pulled through the GA4 Data API describes the same consenting subset as the interface does, because the restriction is at collection time rather than at query time, and no reporting parameter can recover an event that was never sent.
The consent defaults have to run on every page of the site, before any command that sends measurement data. Google's guidance is to call the consent default command ahead of the config and event commands, which means it belongs above the tag rather than beside it. Setting every parameter to denied by default and then updating on the visitor's answer is the shape Google documents, and it is also the shape that survives someone adding a new page that forgets the banner.
Banners that load asynchronously introduce a race: the tag can fire before the consent management platform has had a chance to update anything. Google's documented handling for that is wait_for_update, which takes a value in milliseconds and holds data back for that long so the platform's update can land first. It is a timeout, not a guarantee, so keep the banner's own load path fast.
Not in the sense of adding them to your user count as identified visitors. Advanced consent mode sends measurements without cookies while consent is denied, which gives Google the event and the consent state but no persistent identifier for that browser, so those hits cannot be stitched into a returning user or a full journey. Basic consent mode sends nothing at all when someone declines.
analytics_storage. It enables storage such as cookies or device identifiers related to analytics, which is what GA4 needs to recognise a returning browser and to attribute a session. The advertising types ad_storage, ad_user_data and ad_personalization govern what may be used for advertising, and the last two were added in the November 2023 consent mode update.
It handles consent banners that load asynchronously. If the banner might not run before the Google tags do, wait_for_update takes a value in milliseconds and delays sending for that long, giving the consent management platform time to update the consent state first. Without it, a tag can fire under the page defaults and record a hit that contradicts the choice the visitor is about to make.
Probably not by the amount the chart shows. A banner that blocks measurement until someone accepts removes every declining and every ignoring visitor from the property on the day it ships, which reads exactly like a traffic collapse in every report. Annotate the launch date in GA4, and compare the period after it with itself rather than with the period before.
A server container is a service you now operate: a host, a domain, a deployment and someone to notice when it stops. Here is what that buys, and when it does not buy enough.
Whether GA4 records a click to your docs depends on where the docs live. The built-in outbound click event fires only for links that lead away from the current domain, and configuring cross-domain measurement switches it off again.
