Back to Blog
August 24, 2026

Consent Mode v2: the setup guide advertisers can't skip

Master Consent Mode v2 setup to ensure compliant data tracking. Learn the essential steps to protect your audience data and avoid risks.

Consent Mode v2: the setup guide advertisers can’t skip

Flat-lay of creative office tools with glowing bulb

Consent Mode v2 is Google’s signalling layer. It tells every Google tag on your site which consent choices a visitor actually made, before any data collection happens. The single most important technical priority is this: set your default consent state to “denied” in the page head, before any Google tag fires, and make sure your consent management platform maps its banner categories to all four signals correctly.

Get that sequencing wrong and the consequences aren’t abstract. Sites serving EEA, UK, or Swiss traffic that haven’t implemented the four required signals risk losing remarketing lists, audience segments, and conversion measurement for that traffic. Google doesn’t send a warning first. It simply stops populating the features that depend on consent signalling.

Here’s what needs to happen before anything else:

  • Declare default consent state (all four signals) in the <head>, ahead of Google Tag Manager or gtag.js.
  • Map every CMP banner category to ad_storage, analytics_storage, ad_user_data, and ad_personalization.
  • Fire the update command the instant a user makes a choice, not on page reload.

Consent Mode v2 became a functional requirement, not an optional upgrade, once Google tied it to continued access to ad and measurement features for EEA/UK/Swiss traffic. Miss the setup and you don’t get a compliance warning. You get quietly degraded data.

Key Takeaways

Consent Mode v2 works because the default consent state is declared before any Google tag fires, and the CMP reliably maps its categories to all four signals.

Point Details
Default-first is non-negotiable Declare denied defaults in the page head before GTM or gtag.js loads.
Four signals, not two Map ad_storage, analytics_storage, ad_user_data, and ad_personalization correctly via your CMP.
Choose mode by traffic and capability Basic mode suits smaller sites; Advanced mode suits higher-traffic sites with technical resource for modelling.
Verify, don’t assume Use Tag Assistant, GA4 DebugView, and network tab checks on gcd/gcs parameters after every change.
It’s a product requirement, not a legal shield GDPR, ePrivacy, and PECR still govern your actual legal obligations.

If your tag setup spans multiple domains or serves mixed-jurisdiction traffic, a dedicated audit of your existing implementation before launch tends to catch sequencing errors far earlier than discovering them through a reporting gap. Radka Advertising’s full range of services covers exactly this kind of technical implementation work alongside the broader marketing and analytics support many teams need once Consent Mode is live and reporting needs re-calibrating against modelled data.

Table of Contents

Consent Mode v2 runs on four signals instead of the two that defined the original version. ad_storage and analytics_storage are the originals: they control whether Google can write and read cookies or similar identifiers for advertising and analytics purposes respectively. Deny them and the browser storage simply doesn’t happen.

The two new signals are where v2 earns its name. ad_user_data governs whether user data can be sent to Google for advertising purposes at all. ad_personalization governs whether that data can be used to build remarketing lists and personalised ad targeting. Google added these because the EU’s Digital Markets Act required more granular control over how personal data flows to advertising systems, not just whether a cookie gets dropped.

The distinction that trips up most implementers is upstream versus downstream. ad_storage and analytics_storage act as upstream qualifiers: they control what happens at the point of collection, on the browser. ad_user_data and ad_personalization, by contrast, are downstream instructions telling Google’s own systems what they’re permitted to do with information once it arrives, a framing that Simo Ahava has written about in detail. Get your CMP mapping wrong on this point and you can end up blocking storage correctly while still failing the processing requirement, or vice versa.

A few things Consent Mode v2 is not:

  • It is not a consent management platform. It’s a protocol that a CMP feeds instructions into.
  • It does not obtain consent. Your banner does that; Consent Mode just relays the outcome.
  • It does not replace your legal basis for processing under GDPR or PECR.

Consent Mode v2 requires you to set a default consent state before any Google tag fires and to issue an update command the moment a visitor responds. Everything else in this guide is really just detail on getting that one sequence right.

Basic mode versus advanced mode: practical trade-offs

Choosing between Basic and Advanced mode is the first real decision you’ll make, and it shapes what your reporting looks like for every visitor who declines consent.

Basic mode blocks Google tags entirely until a user grants consent. Nothing fires, nothing pings, nothing gets sent to Google in any form for that visitor until they click accept. It’s the simpler build: fewer moving parts, less risk of a misconfigured tag leaking data early, and a shorter list of things that can go wrong during a technical audit. The cost is a hard data gap. Visitors who decline, or who never interact with the banner, generate zero signal. No modelling, no partial data, nothing.

Advanced mode takes a different approach. Tags still load, but with denied defaults set, and they send cookieless pings, small, anonymous signals that carry no identifiers. These pings feed Google’s modelling systems, which can estimate conversion behaviour for non-consenting users if enough volume passes through them, filling in some of the gap Basic mode leaves wide open.

  1. Basic mode suits smaller sites, low-complexity tag setups, or teams without in-house development resource to manage denied-state tag behaviour.
  2. Advanced mode suits sites with meaningful EEA/UK traffic volume and a technical team capable of testing tags properly in a denied state.
  3. Either mode requires the same default-first sequencing. Advanced mode just adds the layer of cookieless pings on top.
Factor Basic mode Advanced mode
Tags before consent Fully blocked Load with denied defaults
Cookieless pings None Sent for modelling
Data on non-consenting users None Partial, modelled
Implementation complexity Lower Higher
Best fit Small sites, limited dev resource High-traffic sites, technical teams

Modelling only kicks in above certain traffic thresholds, and Google doesn’t publish an exact universal figure, so treat any recovered data as a reasonable estimate rather than a like-for-like replacement for consented, deterministic tracking. Sites with modest EEA traffic volumes often see negligible modelling benefit and add complexity for little return. That’s worth weighing honestly before defaulting to Advanced mode because it sounds more sophisticated.

Sequencing is everything here. Get the order wrong and the rest of the configuration barely matters, because tags will have already fired with the wrong assumptions baked in.

The order of operations

  1. Declare default consent state first, in the page <head>, before Google Tag Manager’s container snippet or gtag.js loads. This is non-negotiable. If GTM initialises before the default command runs, tags can inherit an implicit granted state, which defeats the entire point of the setup.
  2. Load your CMP banner, which presents the categories to the user and captures their choice.
  3. Fire the consent update command the instant the user responds, whether that’s accept, reject, or a partial selection across categories.
  4. Persist that choice so it survives page navigation and return visits, and replay it consistently rather than re-prompting every session.

gtag.js implementation pattern

If you’re running gtag.js directly rather than through a tag manager, the pattern is a two-step command sequence. First, a default consent declaration sets all four signals to “denied” (or “granted” for any category you’ve decided doesn’t require consent, such as strictly necessary storage) before any other Google tag command runs. Second, once the CMP captures a response, an update command overwrites those defaults with the user’s actual choices. The critical detail is timing: the default command has to execute synchronously, inline in the head, not deferred, not loaded asynchronously after other scripts.

GTM implementation

Inside Google Tag Manager, the mechanism is the Consent Initialisation trigger, a trigger type specifically built to fire before the regular container initialisation, guaranteeing your default consent tag runs first. Pair it with the wait_for_update parameter, which tells tags to hold briefly for a consent signal before firing, rather than assuming denial or granting indefinitely.

The trade-off with wait_for_update is real: set it too high (several seconds) and you introduce a noticeable delay in tag firing that can affect page performance and even cause tags to fire before the CMP has actually responded if the CMP itself is slow to initialise. Set it too low or skip it and you risk tags firing before the CMP has had a chance to load at all. Most CMP vendors publish a recommended wait_for_update value for their specific integration, and it’s worth using their community-built GTM templates where available rather than building the consent tags from scratch.

Pro Tip: Check whether your CMP has a purpose-built GTM template in the Community Template Gallery before writing custom consent tags. Most certified CMPs publish one, and it saves you from manually wiring up default and update commands that are easy to get subtly wrong.

CMP integration and category mapping

Your consent banner almost certainly groups cookies into categories like “necessary,” “analytics,” “marketing,” and sometimes “personalisation” or “functional.” None of those map automatically to Google’s four signals. Someone has to do that mapping deliberately:

  • Marketing/advertising categories typically map to ad_storage and ad_user_data.
  • Personalisation or targeted advertising categories map to ad_personalization.
  • Analytics categories map to analytics_storage.
  • Necessary/functional categories rarely touch any of the four signals at all.

A certified CMP partner handles this mapping out of the box and keeps it updated as Google’s requirements shift, which matters more than it sounds given how often the underlying specification has been revised since launch. Building this mapping manually is possible, but it puts the burden of staying current entirely on your team.

Persistence across pages and visits

Consent Mode itself stores nothing. Your CMP is responsible for writing the user’s choice to a cookie or localStorage and re-reading it on every subsequent page load, re-emitting the same consent state without prompting again. Skip this and users see the banner repeatedly, defaults reset to denied on every page, and your measured conversion volume can drop sharply for reasons that have nothing to do with actual consent rates. This is one of the most common and most damaging implementation gaps, and it’s rarely caught until someone compares raw traffic against reported conversions and finds a gap that doesn’t match.

Hands arranging branded workspace with lightbulb

Testing, verification and common implementation mistakes

An implementation that looks correct in code review can still fail in the browser. Verification means watching what actually happens on a live page load, not trusting that the configuration is right because it matches a checklist.

Three tools do most of the work here. Tag Assistant, Google’s own debugging extension, shows you exactly which tags fired and what consent state they read at the time. GA4 DebugView lets you trace individual hits and confirm whether analytics storage was denied or granted at collection. And a straight network tab inspection of outgoing requests reveals the gcd and gcs parameters, Google’s shorthand encoding of consent state attached to every tag call, which is the closest thing to ground truth you’ll get.

Run through this checklist before calling an implementation finished:

  • No advertising cookies are set on first load, before any consent interaction.
  • The update command fires immediately on accept, visible in the network tab within the same page load.
  • Consent state persists correctly on a second page view without re-prompting.
  • In Advanced mode, cookieless pings appear in denied state rather than being suppressed entirely.

The mistakes that cause most failures are depressingly consistent. The default command runs too late, often because someone added it after the GTM snippet rather than before, letting tags inherit granted consent by default. The CMP fails to persist state, so every new page resets to denied and inflates your apparent decline rate. And wait_for_update is either missing entirely or set high enough to create a visible delay without actually fixing the underlying sequencing problem.

Pro Tip: If your reported decline rate looks unusually high compared to your CMP’s own analytics dashboard, check persistence first. A CMP that isn’t writing its consent cookie correctly will make every visit look like a fresh, non-consenting session, even for repeat visitors who already said yes.

Fixing any of these is largely a matter of re-checking script order in the page source, confirming the CMP’s cookie actually exists in browser storage after a choice is made, and re-running Tag Assistant on a fresh, cleared-cookie session to see the default state as a first-time visitor would.

Consent Mode v2 is a Google product requirement, not a law. Google requires it to keep specific ad and measurement features functioning for traffic from the EEA, UK, and Switzerland: remarketing, conversion modelling, and various audience-building tools depend on it directly. Miss the setup and those features degrade for that traffic regardless of whether your business is otherwise fully compliant with data protection law.

That’s a separate question from legal compliance. GDPR, the ePrivacy Directive, and the UK’s PECR set the actual legal bar for obtaining consent, and none of them are satisfied simply by installing Consent Mode. Some European data protection authorities have raised concerns about cookieless pings, querying whether they constitute personal data processing even in modelled form. Consent Mode is the technical plumbing; your legal basis for processing still rests on the CMP obtaining valid consent and your organisation keeping proper records of it.

Practical implications:

  • Treat Consent Mode v2 as necessary for Google functionality, not as a substitute for legal advice.
  • Use a certified CMP and keep consent records, because regulators will ask for evidence, not just a working banner.
  • Many sites implement v2 globally rather than only for EEA/UK visitors, since maintaining two separate tagging setups by region adds complexity most teams don’t need.

Most consent mode failures we see during audits come down to sequencing, not strategy. Teams pick the right mode, brief the right CMP vendor, and still lose data because nobody checked what fires first in the actual page source.

Our audit process, whether it’s a standalone review or part of a broader implementation project, runs through the same core checks every time:

  • Tag inventory: every Google tag and third-party pixel currently live on the site, mapped against what actually needs consent.
  • CMP category mapping: confirming banner categories translate correctly to all four signals, not just the two legacy ones.
  • GTM trigger review: verifying the Consent Initialisation trigger exists and fires before container initialisation, not after.
  • Default-first placement check: reading the actual page source to confirm the default command sits ahead of any Google script.
  • Persistence verification: testing across sessions to confirm consent choices survive page reloads and repeat visits.
  • Test plan sign-off: a documented Tag Assistant and DebugView pass before the implementation is considered live.

Multi-domain setups and cross-country traffic are where this gets genuinely complicated, more so than most single-site guides admit. A business running separate domains for different markets, or serving mixed EEA and non-EEA traffic through one property, needs consent state handled consistently across all of them, which is exactly the kind of technical coordination that benefits from a dedicated audit before launch rather than after a data gap shows up in reporting.

Detailed troubleshooting tips for common implementation issues beyond race conditions

Race conditions get most of the attention in Consent Mode troubleshooting guides, but they’re not the only failure mode. A handful of quieter issues cause just as much damage and get diagnosed far less often.

Server-side tagging mismatches are one. If you’re running Google Tag Manager server-side alongside a client-side container, consent signals set in the browser need to be forwarded correctly to the server container. Miss that link and the server side can process data as though full consent was granted, even when the client correctly denied it.

Cross-domain consent gaps show up when a site spans subdomains, say a main site and a checkout hosted on a separate subdomain, and the CMP’s cookie is scoped too narrowly to be read across both. The user consents once but appears to have never consented at all on the second domain.

Third-party tag conflicts happen when non-Google tags, loaded through the same container, don’t respect the consent signals at all because they were never built to read them. These tags need their own conditional triggers based on consent state, layered on top of whatever Consent Mode handles natively for Google’s own tags.

Stale CMP configurations cause slow drift rather than sudden failure. A banner category gets renamed or a new tracking tool gets added to the site, and nobody updates the mapping, so consent data quietly stops matching reality over a period of months.

The fix for all four is the same discipline: re-run your test plan, including Tag Assistant and a network tab check, every time the tag setup or CMP configuration changes, not just at initial launch.

Consent Mode v2 changes what “accurate” reporting even means. Once significant portions of your EEA or UK traffic decline consent, Google Analytics and Google Ads stop reporting raw, deterministic numbers for that segment and start reporting modelled estimates instead, filled in from the patterns of users who did consent.

Creative workspace with unlit devices and bulb

In Google Analytics 4, this shows up as gaps in user-level reporting and a growing reliance on conversion modelling to estimate what non-consenting sessions were likely doing. Session counts, engagement metrics, and audience sizes can all shift once modelling is switched on, sometimes in ways that don’t match intuition if you’re used to raw, unmodelled numbers from years ago.

In Google Ads, conversion modelling affects bidding directly. Smart Bidding strategies rely on conversion signals to optimise spend, and a thinner signal set, even with modelling filling gaps, tends to produce noisier optimisation than a fully consented dataset would.

None of this is a reason to avoid proper implementation. The alternative, running without Consent Mode v2 at all, means losing these features outright rather than getting a modelled approximation of them. Modelled data is imperfect, but it’s a meaningfully better position than the feature simply not functioning. Teams evaluating unusual traffic patterns or unexplained reporting shifts often find it useful to cross-check GA4 signal changes against known causes like consent-driven modelling before assuming something else broke.

A business serving both EEA and non-EEA visitors faces a genuine design choice: region-aware defaults, or one global default applied everywhere.

Region-aware defaults set denied as the baseline only for visitors in jurisdictions that legally require it, and grant by default elsewhere. This preserves more data volume from regions with lighter consent requirements, but it requires reliable geolocation at the point the default command runs, before any tag fires, which adds a technical dependency most teams underestimate.

Global defaults apply the same denied baseline everywhere, regardless of visitor location. It’s simpler to build and audit, and it sidesteps the geolocation dependency entirely. Many sites choose this route specifically because maintaining two parallel consent logic branches, one regional and one global, multiplies the surface area for the sequencing errors already covered above.

Multi-domain setups add a further layer. If your CMP’s consent cookie is scoped to a single domain, a user who consents on your main site and later reaches a separate subdomain or a fully distinct domain (a checkout platform, a booking system, a regional storefront) may appear to be a fresh, non-consenting visitor there. The fix is configuring your CMP’s cookie scope deliberately across every domain and subdomain in the estate, and testing that specific handoff explicitly rather than assuming it works because it works on the main domain.

Denial isn’t a dead end. It’s a different operating mode that needs its own deliberate handling rather than being treated as a gap you simply accept.

Contextual and non-personalised advertising remains available even when a user declines ad_personalization. Google Ads can still serve contextually relevant, non-targeted ads based on page content rather than user history, preserving some monetisation without needing the declined signal.

First-party data strategies, built from newsletter sign-ups, account creation, or direct purchase history collected with its own explicit consent, give you a data channel that doesn’t depend on the same advertising cookies at all.

Aggregated and modelled reporting, available specifically in Advanced mode through cookieless pings, fills some of the analytical gap for non-consenting users without ever identifying them individually.

Server-side, consent-aware measurement for critical business events, like purchase confirmations, can sometimes be built to log business-critical outcomes (order completed, value processed) in a way that respects declined consent while still giving finance and operations teams the numbers they need, separate from marketing attribution entirely.

None of these fully replace consented tracking. They’re mitigations, not equivalents, and treating them as a full substitute is how teams end up overstating what their reporting actually shows for declined traffic.

Consent Mode v2 isn’t a configure-once system. Google has already revised the specification more than once since its introduction, and both EU and UK privacy regulation continue to shift, which means an implementation that was correct at launch can quietly become outdated.

A sensible maintenance rhythm includes a quarterly tag audit, checking for any new marketing or analytics tags added to the site since the last review that haven’t been mapped into the consent framework. It also means re-testing after every CMP vendor update, since banner category structures and default behaviours can change with a vendor’s own product updates, sometimes without much notice to customers.

Watching for Google’s own specification changes matters just as much. Google has adjusted default behaviours and threshold requirements before, and a setup built against an older version of the guidance can drift out of alignment without any error message telling you so.

Finally, re-running the full verification pass, Tag Assistant, GA4 DebugView, and a network tab check, after any significant site redesign or CMS migration catches the single most common cause of implementations breaking silently: someone rebuilds the page head and the default consent command simply doesn’t make it into the new template.

Authoritative docs and guides to consult next

For exact command syntax and parameter names, Google’s own developer documentation is the primary reference. For implementation nuance beyond the official docs, Simo Ahava’s technical breakdown of the four signals and SetupAnalytics’s practical guide both cover ground the official documentation glosses over. Before choosing a CMP vendor, check its certified partner status directly rather than relying on marketing claims alone.

What actually matters once the setup is live

Most Consent Mode v2 guidance treats it as a policy question, something to be debated in terms of what’s fair to users or how aggressively to interpret Google’s requirements. That framing misses the point. Once you’ve decided on your consent categories, the entire remaining challenge is technical sequencing, and sequencing either works or it doesn’t.

The conventional advice undersells persistence. Plenty of guides focus heavily on the default and update commands and treat persistence as a footnote, when in practice it’s the single most common cause of implementations that look correct in testing but bleed data in production. A consent choice that doesn’t survive a page reload is functionally the same as no consent system at all, just with extra code.

If there’s one thing to prioritise above everything else in this guide, it’s testing after every change, not just at launch. Tag setups drift. CMP vendors update their scripts. Site rebuilds move the page head around without anyone checking what depended on its exact order. Consent Mode v2 isn’t hard to get right once. It’s hard to keep right, and that’s where most of the real failures happen.

Sources

FAQ

It’s mandatory in the sense that Google requires it to keep specific ad and measurement features functioning for EEA, UK, and Swiss traffic. It is not a general legal requirement under GDPR or PECR, though those laws still govern your actual consent obligations.

Declare a default consent state for all four signals in the page head before any Google tag loads, connect your CMP so it maps its banner categories correctly, and fire the consent update command the instant a user responds.

Activation happens through your default and update commands, either coded directly via gtag.js or configured through Google Tag Manager using the Consent Initialisation trigger and a properly set wait_for_update value.

In GTM, Consent Mode governs whether tags are allowed to fire and what data they can collect, based on the consent state read from your default settings and any update fired by the CMP after a user’s choice.

What’s the difference between Basic and Advanced mode?

Basic mode blocks tags entirely until consent is granted, with no data from non-consenting users. Advanced mode loads tags with denied defaults and sends cookieless pings that can support modelled estimates for non-consenting traffic.

More Articles