What Consent Mode v2 actually changes
Consent Mode is a signalling layer, not a consent tool. It tells Google's tags what a user has agreed to, using four parameters — ad_storage, analytics_storage, and the two added in v2, ad_user_data and ad_personalization. Your CMP still collects the consent; Consent Mode is how that decision reaches the tags.
The v2 parameters are the ones that catch teams out. A site that implemented Consent Mode in 2022 and never revisited it is signalling only half of what Google now expects, which affects audience and remarketing features in the EEA regardless of whether the banner itself is fine.
The other thing worth being precise about: Consent Mode does not make non-compliant tracking compliant. If a tag writes to storage before a decision exists, adding a consent signal on top does not fix that. Consent Mode is what you do after the gating is correct, not instead of it.
- ad_storage, analytics_storage, ad_user_data and ad_personalization — all four set, not just the original two
- A default state that denies before any user decision, declared before any Google tag loads
- An update call fired the moment the CMP resolves, including for returning visitors with a stored choice
- Region-scoped defaults where your obligations differ by jurisdiction
Basic or advanced — a decision, not a default
Basic mode blocks Google tags entirely until consent is granted. Nothing is sent for users who decline. It is the conservative reading and the easier one to defend, and it costs you all measurement signal from non-consenting users.
Advanced mode loads the tags in a restricted state, sending cookieless pings that carry no identifiers. Those pings feed conversion modelling, which recovers a meaningful portion of the reporting you would otherwise lose. It is also the option that requires you to be comfortable explaining what those pings contain, because a cookieless ping is still a transmission.
Which is right depends on your risk posture and your regulator, not on which produces better numbers. We will lay out the trade-off with the specifics of your setup rather than defaulting to advanced because it looks better in reporting. Where teams choose advanced, we make sure the restricted state is genuinely restricted and that the modelling thresholds are realistic for your traffic volume — below a certain volume, modelling simply does not engage and you have taken the risk for no benefit.
The Tag Manager work
Most Consent Mode failures are Tag Manager failures. The default state is set in a tag that fires on All Pages instead of on Consent Initialization, so it lands after the first Google tag. Or the CMP's update call fires on a DOM event that a single-page app never emits on route change. Or a custom HTML tag bypasses consent checks entirely because someone needed it live on a Friday.
We work through the container systematically: consent initialisation ordering, built-in consent checks on every Google tag, additional consent checks on the tags that need them, and data layer events that survive client-side routing. Custom HTML tags get particular attention because they are where consent gating is most often quietly absent.
Where you are running server-side tagging, the consent state has to survive the hop to the container. That is a different piece of work and a common source of drift — a client that gates correctly feeding a server container that forwards everything regardless.
- Consent Initialization trigger ordering, verified against actual tag fire sequence
- CMP-to-Consent-Mode integration, including returning visitors and single-page app route changes
- Built-in and additional consent checks configured per tag, custom HTML included
- Server-side container consent propagation where you run one
- Microsoft UET consent mode and Clarity consent API alongside Google, where those are in your stack
Validation, because 'it looks fine' is not evidence
The last stage is the one most often skipped. We validate with Tag Assistant and the browser network panel, checking the actual gcs parameter on outgoing requests for each consent permutation: no decision, accept all, reject all, and granular partial consent. Those four states produce four different expected signals, and a setup that handles three of them correctly is still broken.
We check the returning-visitor path separately, because it uses a different code path — the CMP reads a stored decision rather than showing a banner, and the update call timing is different. This is the single most common place where a setup that tests clean on a fresh browser fails in production.
You get the validation evidence as part of handover: the permutations tested, what was expected, what was observed. It is the document that answers 'can you show me it works' without anyone having to reproduce the testing.
Background reading
The detail behind this work is written up in our Knowledge Hub. These are the guides we hand to clients before a kick-off call.
Frequently asked questions
- What is the difference between basic and advanced Consent Mode?
- Basic mode blocks Google tags entirely until consent is granted, so nothing is sent for users who decline. Advanced mode loads tags in a restricted state that sends cookieless pings carrying no identifiers, which feed conversion modelling and recover part of the lost reporting. Advanced gives you more data; basic is easier to defend. The right choice depends on your risk posture and your traffic volume, since modelling does not engage below a certain threshold.
- Do we still need a cookie banner if we implement Consent Mode?
- Yes. Consent Mode is a signalling layer that tells Google's tags what a user decided — it does not collect consent and it does not make non-compliant tracking compliant. You need a CMP to collect the decision and correct tag gating so nothing fires before that decision exists. Consent Mode sits on top of both.
- We implemented Consent Mode in 2022. Do we need to do anything?
- Almost certainly. Version 2 added ad_user_data and ad_personalization. A setup that only sets ad_storage and analytics_storage is signalling half of what Google now expects, which affects audience and remarketing features for EEA traffic even if your banner is otherwise fine.
- How do you verify Consent Mode is working?
- We check the actual gcs parameter on outgoing requests across four permutations — no decision yet, accept all, reject all, and granular partial consent — using Tag Assistant and the browser network panel. We test the returning-visitor path separately, because it uses different timing and is where most setups that look clean on a fresh browser actually fail.
- Does this work with single-page applications?
- It works, but it needs deliberate handling. Client-side route changes do not fire the DOM events that many default CMP integrations listen for, so the consent update can silently stop propagating after the first page view. We wire the integration to the router rather than to page load events.
- Can you handle Microsoft UET and Clarity too?
- Yes. Microsoft UET has its own consent mode and Clarity has a consent API, both with their own defaults and failure modes. If they are in your stack we implement them alongside Google rather than leaving them ungated, which is the usual state of affairs when only the Google side has had attention.
Related services
Cookie Consent Implementation
Banner, preference centre and category mapping built to survive an audit and a redesign.
OneTrust Implementation
Configuration, UCPM, migrations and rescue work from OneTrust implementation specialists.
CCPA, GPC & US State Banners
Opt-out mechanics, Global Privacy Control handling and multi-state banner logic.
See the full range on our services overview, including audits, privacy notice management and internal team training.
Talk to someone who has done this before
Tell us what you are running today and what is failing. We will tell you what it takes to fix it — scope, sequence and effort — before you commit to anything.