Google Consent Mode, and how to check it is working
Consent Mode is one of those things that looks finished the moment the banner appears. The banner is the visible part. Whether Google ever hears about the choice a visitor made 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. A site calls it to say what the visitor has agreed to, and Google's tags read that state on every request and behave accordingly. It displays nothing and it gathers nothing. Collecting the choice is the consent management platform's job; Consent Mode is the wire between the CMP and Google.
Two calls do the work. A default call runs before any Google tag loads and declares 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. Each call passes a set of named signals, each one granted or denied.
The tags that respond to those signals are Google's own: the Google tag, GA4, Google Ads conversion tracking and remarketing, and Floodlight. They adjust which cookies get written, whether a persistent identifier is attached to a hit, and whether the data may be used for personalisation. The practical effect is that a rejection produces a signal Google can account for, not a gap in the data.
Non-Google tags ignore the API entirely. A Meta pixel or a LinkedIn insight tag 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 two different architectures, and which one a site is running is decided by whether Google's tags are allowed to load before consent.
Basic mode
Google tags are blocked from loading until the visitor accepts. Nothing at all 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 is thinner than it sounds and less empty than people assume. It carries the page URL, the referrer, a timestamp, user agent information and the consent state. The client ID on those pings is generated for that page load and never written to a cookie, so nothing links one ping to the next.
The practical difference is what Google has to model from. Advanced mode gives it an observed event for every denied visitor, which is a far better basis for estimating what was lost. Basic mode gives it nothing from those visitors and leaves modelling to work from the consented population alone. Advanced mode also means the tags run before consent, which is the point some legal teams stop and ask questions. That conversation is cheaper before the build than after it.
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 alongside PECR, and PECR is the part that governs storing or reading information on a device. It requires consent for anything not strictly necessary to provide the service the visitor asked for, which analytics cookies are not and advertising cookies certainly are not. The EEA equivalent is the ePrivacy Directive as implemented in each member state, sitting on top of GDPR. None of that legislation mentions Google, tags, or any particular API.
What changed on 6 March 2024 was Google's own policy. The EU user consent policy already obliged advertisers to obtain consent from users in the EEA, the UK and Switzerland. From that date Google additionally required the consent to be communicated back to it, through Consent Mode v2 or through an IAB TCF integration. The deadline was set by the Digital Markets Act, which covers the EU and not the UK; Google extended the requirement to UK traffic under its own policy.
The penalty for skipping it is commercial. Remarketing and Customer Match audiences stop taking new users from that traffic, conversion modelling is unavailable, and Google Ads reporting thins out. A site running 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 requirement is Google's own, and the enforcement is commercial.
The ICO's own position is about the banner, not the plumbing: rejecting should be as easy as accepting. A perfectly wired Consent Mode sitting 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, which is the whole of what the version bump means.
ad_storage
Governs 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 back to a click through a cookie. Since 15 June 2026 it is the only setting that governs that collection, which the next section sets out.
analytics_storage
Governs storage used for analytics, in practice the GA4 client ID cookie. Denied means each page load looks like a new unidentified visitor to the collection endpoint, and sessions cannot be stitched together.
ad_user_data
New in v2, and not a storage signal at all. It states whether user data may be sent to Google for advertising purposes. Denied blocks the transmission itself, which is why it matters independently of cookies.
ad_personalization
Also new in v2. It states whether the data may be used for personalised advertising, which is the signal that governs remarketing audience membership. Granting ad_user_data while denying this one is a valid and fairly common combination.
Three further types exist in the API — functionality_storage, personalization_storage and security_storage — and Google's tags accept them without changing their behaviour. They are there for other tags to check against, and setting them has no effect on GA4 or Google Ads.
Two related parameters sit next to the signals and get forgotten. Setting ads_data_redaction strips ad click identifiers from Google Ads requests while ad_storage is denied and routes them through a cookieless domain. Setting 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 that date, whether the Google Analytics tag and SDK could collect Google Ads cookies and identifiers was settled by two controls at once: a setting held in the Analytics admin, and the advertising consent state arriving from the page. From that date Analytics defers to Consent Mode alone.
Google Signals after the change
The setting stays in the Analytics admin and in its API, and its remit is now the association of Analytics-sourced data with signed-in user information for behavioural reporting. Demographics, interests and cross-device reporting rest on it. Advertising identifier collection no longer does.
ad_storage after the change
Whatever value arrives for ad_storage decides whether Ads cookies and identifiers may be collected through Analytics, and nothing on the Analytics side overrides it. A granted default that nobody meant to set is now the whole of the answer.
The properties that feel this are the ones that kept Google Signals switched off as a precaution. That switch was doing two jobs and only one of them was labelled: with it off, Ads identifiers were held back even where a badly wired banner was granting ad_storage. The second brake has gone. An implementation that was wrong but covered is now simply wrong, and reading gcs on a live request is what settles which of the two a site has.
Google has flagged a second stage without dating it. Ads personalisation is presently governed by a layer of settings at account, property, Ads link and event level inside Analytics, and those are due to collapse so that ad_personalization exclusively controls whether the data is used for personalisation in the Ads account. Google has said the exact dates for that, and for changes to the IP address controls, will follow later in the year.
Wiring a consent platform into Google Tag Manager
The single constraint that decides whether an implementation works is ordering. 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.
GTM has a dedicated trigger for this. Consent Initialization - All Pages fires ahead of everything else in the container, including All Pages, and the default call belongs on it. The alternative is to place the CMP snippet and the default call directly in the page head above the GTM snippet, which is the more reliable of the two when the site's developers will cooperate. The wait_for_update parameter buys a short window in milliseconds for a slow CMP 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. Google requires a certified CMP for publishers using Ad Manager, AdSense or AdMob; for advertisers the requirement is the signals arriving, whatever produces them.
Region scoping is set on the default call. A default of denied can be applied to a list of ISO region codes so that visitors outside them start granted. GB is not inside the EEA list, so a region array built from EEA member states alone leaves UK visitors defaulting to granted, which does not meet the PECR requirement.
Google's tags carry built-in consent checks and adjust themselves. Everything else in the container needs the additional consent checks configured on each tag, or a trigger condition doing the same job. Turning on the consent overview in container settings gives a single screen listing which tags have checks and which have none, and it is the fastest way to find the ones that were missed. That screen is also the sensible 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 around it suggests. Google Ads estimates the conversions that came from unconsented visitors and adds them into the reported conversion figures, using the observed relationship between consented clicks and conversions. Those conversions are estimates at the campaign level. No individual user is identified, and nothing appears in the click-level data.
Volume gates it. Google publishes a minimum on the order of 700 ad clicks over seven days for a given country and network grouping, below which no modelling happens at all. Plenty of UK accounts sit under that line permanently, and for them Consent Mode delivers compliance and no recovered numbers.
The Google Analytics Consent Mode picture is separate. GA4 runs behavioural modelling on the denied pings from advanced mode to estimate users and sessions, with its own published thresholds on daily event and user volumes across a training window. It applies to standard reports under the blended reporting identity, and it does not reach the BigQuery export. The export contains observed events only, which is worth knowing before anyone reconciles the two and reports a discrepancy.
The limits are worth stating 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 also no substitute for match quality on the consented traffic, which is what enhanced conversions addresses, and which needs ad_user_data granted before it can 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, and they answer different questions. 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 to the site and look at the first event in the timeline. The on-page default should already be present there, before the container's tags run. A default that only appears after the first page view means the CMP is loading too late and the ordering needs fixing.
Are all four signals present, and does the update land
Select an event and open the consent tab. It shows the on-page default, the on-page update, and per-tag consent status. Check that ad_user_data and ad_personalization are listed alongside the two storage types; a page still on v1 shows only two. Then accept the banner and confirm an update event appears with the new values.
Does Google actually receive it
Open the browser network panel, filter for collect, and read the gcs parameter on the GA4 request. It is a G1 prefix followed by two digits: the first is ad_storage, the second analytics_storage, 1 for granted and 0 for denied. G100 before the banner and G111 after it is a working advanced setup. No collect request before the banner at all means basic mode. No gcs parameter anywhere means Consent Mode is not running on the page. A gcs of G111 with no gcd alongside it means the same thing.
The gcd parameter on the same request encodes the v2 signals and the default-and-update history in a compact form. It is readable with effort and easy to misread, so the consent tab remains the sounder check for the two advertising signals.
One further pass is worth the minute it costs. Accept on the landing page, navigate 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 by the time the container initialises. The first page view of every session leaves without a consent state, and Google treats the page as unconfigured. Fixing it is an ordering change, not a settings change.
Advanced mode on paper, script blocking underneath
The CMP is configured for advanced Consent Mode and is also set to block the Google tag script until consent. The tag never loads, so no denied pings are sent, and the account gets neither the compliance benefit of blocking nor the modelling benefit of advanced mode. Both settings look correct in isolation.
Region scoping that misses GB
A denied default applied to an EEA region list, with everything else defaulting to granted. UK visitors fall into the granted branch and get tracked before they have agreed to anything. This survives testing because the tester is usually in the UK and 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 the chat widget fire on page load regardless. The exposure here is the legal one, and it hides behind a Consent Mode implementation that reports as healthy.
The decision is never replayed
The update fires on the page where the banner was clicked, and subsequent pages read the denied default again because the stored decision is not fed back into the default call. Sessions come out split across two consent states, and the conversion page is the one that ends up denied.
Consent Mode with a server container
Moving collection to a server-side container changes where the vendor requests originate. It changes nothing about consent, and treating it as a way round consent is the mistake to name first.
The mechanics are straightforward. Consent state travels to the server inside the incoming request, on the same parameters the browser would have sent to Google. The GA4 client in the server container parses them, the event data carries a consent state, and server tags can be given the same consent checks as web tags. The forwarding step is where it goes wrong: a server container that drops or rewrites those parameters on the way to Google makes every denied ping look consented, and the modelling is then built on incorrect input.
If a tag is blocked in the browser, no request reaches the server and there is nothing to forward. If the event is sent to the server regardless and fanned out to Meta and the rest from there, the compliance problem has only moved, and it has moved somewhere harder to audit from the outside.
Server-set cookies deserve their own note. A first-party identifier written by the server is still information stored on the visitor's device under PECR, and it needs consent on the same footing as a cookie 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.
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 that version 1 never had. Where no default appears ahead of the first tag, 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.