Google Consent Mode, and how to check it is working
Consent Mode looks finished the moment the banner appears. Whether Google ever hears about the visitor's choice is a separate question, and the answer is in the network requests.
What Consent Mode actually does
Google's tags expose an API for consent state. The site calls it to say what the visitor agreed to; Google's tags read that state on every request. It displays nothing and gathers nothing: collecting the choice is the consent management platform's job, and Consent Mode is the wire between CMP and Google.
Two calls do the work, each passing named signals, granted or denied:
- A default call runs before any Google tag loads, declaring the starting position: normally denied for visitors in scope of UK and EU rules.
- An update call runs the moment the visitor accepts or rejects, carrying the new state.
The responding tags are Google's own: the Google tag, GA4, Google Ads conversion tracking and remarketing, and Floodlight. They adjust which cookies are written, whether a persistent identifier is attached, and whether data may be used for personalisation. A rejection produces a signal Google can account for, not a gap.
Non-Google tags ignore the API entirely; a Meta pixel has no idea the call was made. Gating those is a Google Tag Manager job, covered further down.
Basic and advanced mode: the difference that matters
The two implementations are not settings in a menu. They are different architectures, decided by whether Google's tags may load before consent.
Basic mode
Google tags are blocked until the visitor accepts. Nothing is sent while the banner is open. On acceptance the tags load and fire normally, including a delayed page view.
Advanced mode
Google tags load on every page. While consent is denied they send cookieless pings: no cookies read or written, no persistent identifier, and the consent state attached.
A cookieless ping carries the page URL, referrer, timestamp, user agent and consent state. Its client ID is generated per page load and never written to a cookie, so nothing links one ping to the next.
The practical difference is what Google can model from. Advanced mode gives an observed event for every denied visitor; basic mode gives nothing, so modelling works from the consented population alone.
Advanced mode also means the tags run before consent, which is where some legal teams stop and ask questions. That conversation is cheaper before the build.
Is Consent Mode v2 mandatory in the UK and EEA?
Consent Mode v2 is not a legal requirement anywhere. The UK rules are UK GDPR plus PECR, which requires consent for storing or reading anything on a device that is not strictly necessary. Analytics cookies are not necessary; advertising cookies certainly are not.
The EEA equivalent is the ePrivacy Directive per member state, on top of GDPR. None of it mentions Google, tags, or any particular API.
What changed on 6 March 2024 was Google's own EU user consent policy. Advertisers serving the EEA, UK and Switzerland already had to obtain consent. From that date it also had to be communicated back to Google, through Consent Mode v2 or an IAB TCF integration.
The deadline came from the Digital Markets Act, which covers the EU only; Google extended the requirement to UK traffic itself.
The penalty for skipping it is commercial:
- Remarketing and Customer Match audiences stop taking new users from that traffic.
- Conversion modelling is unavailable.
- Google Ads reporting thins out.
A CMP that hard-blocks every non-essential tag and never speaks to Google can be entirely lawful under PECR. It simply loses the features.
The ICO's position is about the banner, not the plumbing: rejecting should be as easy as accepting. A perfectly wired Consent Mode behind a banner with no reject button fixes nothing.
The four signals: ad_storage, analytics_storage, ad_user_data, ad_personalization
Version 1 had two storage signals. Version 2 kept both and added two permission signals; that is the whole of the version bump.
ad_storage
Storage used for advertising. Denied means no advertising cookies are read or written, so no Google Ads click identifier is persisted and no conversion can be tied to a click through a cookie. Since 15 June 2026 it is the only setting governing that collection.
analytics_storage
Storage used for analytics, in practice the GA4 client ID cookie. Denied means each page load looks like a new unidentified visitor, and sessions cannot be stitched together.
ad_user_data
New in v2, and not a storage signal. It states whether user data may be sent to Google for advertising. Denied blocks the transmission itself, so it matters independently of cookies.
ad_personalization
Also new in v2. It states whether data may be used for personalised advertising, and governs remarketing audience membership. Granting ad_user_data while denying this one is valid and fairly common.
Three further types (functionality_storage, personalization_storage, security_storage) exist for other tags to check against. Google's tags accept them without changing behaviour.
Two related parameters get forgotten:
- ads_data_redaction strips ad click identifiers from Google Ads requests while ad_storage is denied and routes them through a cookieless domain.
- url_passthrough carries the click identifier across internal navigations in the URL, so it survives to the conversion page when no cookie is allowed to hold it.
What changed on 15 June 2026, and why ad_storage now carries more weight
Google moved the boundary between Analytics and Ads on 15 June 2026. Before then, whether Analytics could collect Google Ads cookies and identifiers was settled by two controls: a setting in the Analytics admin, and the advertising consent state from the page. Now Analytics defers to Consent Mode alone.
Google Signals after the change
The setting stays in the Analytics admin and API. Its remit is now the association of Analytics data with signed-in user information for behavioural reporting: demographics, interests, cross-device. Advertising identifier collection no longer rests on it.
ad_storage after the change
Whatever value arrives for ad_storage decides whether Ads cookies and identifiers may be collected through Analytics. Nothing on the Analytics side overrides it. A granted default nobody meant to set is now the whole answer.
The properties that feel this kept Google Signals off as a precaution. That switch did two jobs and only one was labelled: with it off, Ads identifiers were held back even where a badly wired banner granted ad_storage.
That second brake has gone. A wrong-but-covered implementation is now simply wrong, and reading gcs on a live request settles which a site has.
Google has flagged a second stage without dating it: the Ads personalisation settings inside Analytics (account, property, Ads link and event level) collapse, leaving ad_personalization in sole control. Dates for that, and for changes to the IP address controls, follow later in the year.
Wiring a consent platform into Google Tag Manager
Ordering decides whether an implementation works. The default call has to complete before the first Google tag fires. If the CMP loads asynchronously and GTM gets there first, the opening page view goes out with no consent state attached, and no later update repairs it.
Two placements achieve it:
- The Consent Initialization - All Pages trigger, which fires ahead of everything else in the container. The default call belongs on it.
- The CMP snippet and default call placed directly in the page head, above the GTM snippet. More reliable, when the site's developers will cooperate.
The wait_for_update parameter buys a slow CMP a short window, in milliseconds, to report a stored decision before tags proceed.
Most CMPs ship a GTM template that handles both calls; Cookiebot, Usercentrics, CookieYes, Iubenda and OneTrust all have one. Publishers on Ad Manager, AdSense or AdMob need a certified CMP. For advertisers the requirement is the signals arriving, whatever produces them.
Region scoping sits on the default call: denied applies to a list of ISO region codes; visitors outside them start granted. GB is not in the EEA list, so an EEA-only region array leaves UK visitors defaulting to granted. That fails PECR.
Google's tags carry built-in consent checks. Everything else needs consent checks configured per tag, or a trigger condition doing the same job. The consent overview in container settings lists which tags have checks and which have none: the fastest way to find the missed ones, and the starting point for consent wiring and CMP setup.
Conversion modelling: what Google fills in, and what it does not
Modelling is the return on implementing Consent Mode properly, and it is narrower than the marketing suggests. Google Ads estimates conversions from unconsented visitors and adds them to the reported figures, using the observed relationship between consented clicks and conversions.
The estimates sit at campaign level. No individual user is identified, and nothing appears in the click-level data.
Volume gates it. Google publishes a minimum around 700 ad clicks over seven days per country and network grouping; below that, no modelling. Plenty of UK accounts sit under the line permanently and get compliance with no recovered numbers.
The GA4 picture is separate. It models users and sessions from the denied pings of advanced mode, with its own thresholds on daily event and user volumes. It applies to standard reports under the blended reporting identity.
The BigQuery export contains observed events only, with nothing modelled. Worth knowing before anyone reconciles the two.
The limits, stated plainly:
- Unconsented visitors are never added to remarketing audiences.
- User-level and path-level data stays missing.
- Nothing equivalent exists for Meta or any non-Google platform, and the CRM is untouched by any of it.
Modelling is no substitute for match quality on consented traffic, which is what enhanced conversions addresses, and which needs ad_user_data granted to run.
How to check Consent Mode is working (Tag Assistant, the consent tab, the network request)
Checking an implementation takes three passes over the same page load, each answering a different question. Do all three in a private window, with the cookie decision cleared each time.
Is a default state arriving before the tags
Connect Tag Assistant and look at the first event in the timeline. The on-page default should already be present, before the container's tags run. A default that only appears after the first page view means the CMP loads too late.
Are all four signals present, and does the update land
Select an event and open the consent tab: on-page default, on-page update, per-tag status. Check that ad_user_data and ad_personalization are listed alongside the two storage types; a page still on v1 shows only two. Accept the banner and confirm an update event appears with the new values.
Does Google actually receive it
Open the network panel, filter for collect, and read gcs on the GA4 request: G1 plus two digits, ad_storage then analytics_storage, 1 granted, 0 denied. G100 before the banner and G111 after is a working advanced setup.
No collect request before the banner means basic mode. No gcs parameter anywhere means Consent Mode is not running on the page; so does G111 with no gcd alongside it.
The gcd parameter on the same request encodes the v2 signals and the default-and-update history. It is easy to misread; the consent tab is the sounder check for the advertising signals.
One further pass is worth the minute. Accept on the landing page, go two pages deep, and read gcs again. A state that reverts on the second page is a common failure.
Five ways it gets set up wrong
The default lands after the first tag
An asynchronously loaded CMP that has not finished when the container initialises. The first page view of every session leaves without a consent state. The fix is an ordering change, not a settings change.
Advanced mode on paper, script blocking underneath
The CMP is set to advanced Consent Mode and also to block the Google tag script until consent. The tag never loads, so no denied pings are sent and no modelling benefit arrives. Both settings look correct in isolation.
Region scoping that misses GB
A denied default applied to an EEA region list, everything else granted. UK visitors get tracked before they have agreed to anything. It survives testing because the tester, usually in the UK, sees data flowing.
Non-Google tags left ungated
Google's tags respect the signals, so the consent tab looks clean, while the Meta pixel and chat widget fire on page load regardless. The legal exposure hides behind an implementation that reports as healthy.
The decision is never replayed
The update fires on the page where the banner was clicked, but the decision is not fed back into the default call, so later pages read denied again. Sessions split across two consent states, and the conversion page ends up denied.
Consent Mode with a server container
Moving collection to a server-side container changes where the vendor requests originate, and nothing about consent. Treating it as a way round consent is the mistake to name first.
Consent state travels inside the incoming request, on the same parameters the browser would have sent to Google. The GA4 client parses them, the event carries a consent state, and server tags take the same consent checks as web tags.
Forwarding is where it goes wrong. A container that drops or rewrites those parameters on the way to Google makes every denied ping look consented, and the modelling is built on bad input.
If a tag is blocked in the browser, nothing reaches the server and there is nothing to forward. Sending the event to the server regardless and fanning it out to Meta from there moves the compliance problem somewhere harder to audit.
Server-set cookies need their own note. A first-party identifier written by the server is still information stored on the device under PECR, and needs consent on the same footing as one written by a script. The longer lifetime is precisely why it matters.
The consent parameters are the first thing I check after any container change on the server containers I run, because nothing downstream complains when they go missing.
Consent is one part of a wider measurement setup, and the rest of it is covered across the other guides.
What people ask about checking an implementation
How do I check if Google Consent Mode is enabled?
Open the site in a private window and read the gcs value on the outbound GA4 request. Tag Assistant's consent tab reports the same state in named form, including the two advertising signals version 1 never had. No default ahead of the first tag means the CMP is arriving too late to be doing its job.
Does Consent Mode replace a cookie banner?
No. It carries a decision that something else has already collected, and it has no interface of its own. A consent platform is still needed to present the choice, store it, and let a visitor change their mind later.
What happens if Consent Mode v2 is not implemented?
Google's advertising features degrade on EEA and UK traffic. Remarketing and Customer Match stop taking new users from it, and modelled conversions are withheld. Measurement carries on for visitors who accepted, so the loss shows up in audience sizes and reported conversion counts before anywhere else.