Consent Mode v2 without losing your signal

Ship a stricter cookie banner and watch a chunk of your EEA conversions vanish the same week, with no bug to find. Whether that chunk comes back as modeled conversions or stays gone comes down to one setting most teams never chose on purpose. Consent mode v2 is Google's framework for adjusting how its tags behave based on the visitor's consent, carried in four signals: ad_storage, analytics_storage, and the two v2 additions, ad_user_data and ad_personalization. It's required since March 2024 for advertisers running Google's ads features on EEA users. Implemented deliberately, it's also what keeps denied users from becoming a blind spot in your conversion counts.

Most of what you'll read about consent mode ends where the consent platform's job ends: install, comply, done. This guide covers the half that determines what your reports look like afterwards: the signal side. A denied user isn't a lost conversion; it's a modeled one, if your implementation allows modeling at all.

#Is it mandatory? The one-paragraph compliance answer

If you advertise to people in the EEA (plus the UK and Switzerland) and use Google advertising features (remarketing audiences, conversion measurement, personalization), then yes: since March 2024, Google's EU User Consent Policy (its DMA response) requires the v2 signals for those users (About consent mode). Without them, audience building and remarketing for EEA traffic stops, and measurement degrades. If you have zero EEA/UK/CH exposure, nothing forces you, but the modeling machinery below still applies wherever you show a consent banner.

#The four signals and what each actually gates

Consent mode is four boolean signals sent to Google tags before and after the user's consent choice (consent mode concepts). V1 gated storage; v2 added two signals that gate data use, the distinction that matters for compliance:

Note what this implies: a user can consent to measurement but not personalization, and the four signals carry that nuance, which is exactly why "just block all Google tags until consent" throws away more than compliance requires.

#Basic vs advanced: the decision that decides your numbers

This is the fork most implementations fall through without noticing, because a CMP default quietly picks for you.

• Basic consent mode: Google tags don't load at all until consent is granted. Denied users send nothing: no pings, no modeling input. Their conversions simply don't exist to Google.
• Advanced consent mode: tags load before consent but adjust behavior to the signals: when consent is denied they set no cookies and instead send cookieless pings: anonymous, aggregate signals about the visit. Those pings are what makes you eligible for conversion modeling: Google's behavioral modeling estimates the conversions it can't observe from the consented population's patterns (About consent mode).

Our position, stated plainly: choose advanced deliberately unless your legal counsel rules it out. The trade is real: advanced sends cookieless pings pre-consent, and some DPOs read their jurisdiction strictly enough to refuse that. But it should be a decision someone actually made, not a default inherited from a banner install. Basic mode is the right call when counsel says so; it is a strange call when it happens by accident and the marketing team spends the next quarter wondering where EEA conversions went. Simo Ahava's consent mode v2 walkthrough, the canonical practitioner reference on this, makes the same structural point: the tag behavior difference between the modes is the whole game.

#What denial does to your numbers

Before deploying, know what to expect on the other side. With advanced consent mode running on an EEA-exposed account, a share of reported conversions arrives modeled rather than observed, and that share moves with your consent rate: stricter banner UX, higher denial, more modeling. The shape to expect (illustrative numbers; the coupling is what every EEA-exposed account produces): a consent-denial rate around 30% putting the modeled share of reported conversions somewhere in the 10% to 20% band, stepping up visibly the week a stricter banner ships, a number your consent platform's dashboard never shows you.

Two properties of modeled conversions worth internalizing now: they are estimates aggregated into your totals (no user-level rows to audit), and they flow into Smart Bidding as real training input, which is why a basic-mode implementation doesn't just dent your reports, it starves your bidding of an entire consented-out population (Smart Bidding is a signals problem: what the algorithm actually runs on covers what that does to bidding).

#Implementation path 1: through your CMP

The practical path for most teams: a Google-certified CMP (consent management platform) such as Cookiebot, OneTrust, Usercentrics, or CookieYes, which renders the banner, records the choice, and sets the four signals for you. Three things to check rather than trust:

1. Which mode did it default to? Find the basic/advanced setting and make the choice deliberately (see above). This is the single most consequential checkbox in the install.
2. Are defaults set before tags fire? The CMP's snippet must load ahead of every Google tag, setting denied defaults first; a race condition here means tags fire cookied pings pre-consent.
3. Do the v2 signals actually change? Some older CMP configurations set only the v1 pair. Verify all four flip on grant/deny (verification section below).

#Implementation path 2: GTM or gtag directly

Without a CMP, or when you want to own the wiring, consent mode is two calls (setup guide). Defaults first, before any tag loads, denied by default:

gtag('consent', 'default', {
  ad_storage: 'denied',
  analytics_storage: 'denied',
  ad_user_data: 'denied',
  ad_personalization: 'denied',
  wait_for_update: 500
});

Then an update when the visitor chooses:

gtag('consent', 'update', {
  ad_storage: 'granted',
  analytics_storage: 'granted',
  ad_user_data: 'granted',
  ad_personalization: 'granted'
});

Region-scope the defaults with the region parameter if you only gate EEA traffic (e.g. denied defaults for EEA country codes, granted elsewhere). Gating the whole world to solve a European requirement is a self-inflicted signal loss. In GTM, the same wiring runs through the consent initialization trigger and each tag's built-in consent checks; the concepts are identical, the calls are just configured instead of written.

#Verify it's working

Consent mode fails silently in both directions, over-blocking (signal loss) and under-blocking (compliance risk), so verification is not optional:

1. Tag Assistant (or GTM preview): open the consent tab and watch the four signal states: default denied on load, flipping correctly on grant and deny. All four, not just the v1 pair.
2. Network tab: pre-consent, Google requests should carry the denied-state consent parameter (the gcs/gcd parameters) and set no cookies; post-grant, cookies appear.
3. In Ads and GA4, after ~a week: EEA conversions still flowing, GA4 acknowledging consent signals in its data-quality indicators, no cliff-edge drop dated to the deploy.

#Reading your reports afterwards

Post-deploy, your numbers have a new ingredient, and reading them takes one mental adjustment: totals now include estimates. Google Ads folds modeled conversions into the conversions column; GA4 applies behavioral modeling to its reporting when eligible. Neither labels each row: modeling shows up as aggregate lift, not as flagged conversions.

Two predictable consequences. First, small-segment precision drops: modeled conversions are distributed statistically, so campaign-level EEA numbers carry wider error bars than the total suggests. Second, Ads and GA4 diverge more: they model independently, on different eligibility rules and different consented populations, so consent is now a standing line item in any reconciliation. When the gap gets uncomfortable, Why your GA4 and Google Ads conversions don't match triages it, and the consent gap is one of its named failure modes for a reason.

#What consent mode does NOT do

Boundaries, so nobody files this in the wrong drawer. Consent mode is not a CMP: it doesn't render banners or record proof of consent; it consumes what your banner decides. It is not a legal basis: it transmits consent, it doesn't create it, and it doesn't make an uncompliant banner compliant. It does not recover deterministic tracking: modeling estimates aggregates, and the user-level match for denied users is gone, which is the honest cost. And it does nothing about the other signal-loss front: shrinking cookie lifetimes hit consented users too, which is Tracking after third-party cookies: what actually still works's territory. For recovering match quality on consented traffic, Enhanced conversions: what they fix, what they leak, how to turn them on is the adjacent upgrade.

The mental shift consent mode forces is bigger than one checkbox: your conversion count stops being a pure tally and becomes part observed, part estimated, and that split only grows as more of the stack leans on modeling. The job is no longer "capture every conversion" but "know which of your numbers are real counts and which are informed guesses." The one figure that tells you, your modeled-versus-observed share, moves every time you touch the banner, and no consent platform dashboard surfaces it. Buron does: it shows that split and flags when consent losses start moving your totals, so "our EEA conversions dropped 20%" arrives as a finding with a cause attached, not a quarterly mystery.

Frequently asked questions

Is consent mode v2 mandatory?

Yes, if you advertise to users in the EEA (plus the UK and Switzerland) and use Google's advertising features (audiences, remarketing, conversion measurement). Since March 2024, Google requires the two v2 signals (ad_user_data, ad_personalization) under its EU User Consent Policy; without them, ads personalization and remarketing for EEA users stop working.

What is the difference between consent mode v1 and v2?

V1 had two signals: ad_storage and analytics_storage, gating cookie access for ads and analytics. V2 adds two more: ad_user_data (may user data be sent to Google for advertising) and ad_personalization (may it be used for remarketing). V2 signals gate data use, not just cookie storage.

How do I enable consent mode v2?

Easiest path: a Google-certified CMP (consent management platform), which sets the four signals from your banner automatically. Manual path: set default consent states to denied before any Google tag loads, then update states from your banner's choice via gtag('consent', 'update', ...) or GTM's consent APIs. Verify with Tag Assistant.

What is Google consent mode v2 cookie information?

Consent mode v2 doesn't set its own tracking cookies; it's a signaling framework that tells Google tags which storage and data uses the visitor consented to. The four signals (ad_storage, analytics_storage, ad_user_data, ad_personalization) determine whether tags may read or write cookies and how the data may be used.

Related

• Tracking after third-party cookies: what actually still works
• Why your GA4 and Google Ads conversions don't match
• Enhanced conversions: what they fix, what they leak, how to turn them on
• Smart Bidding is a signals problem: what the algorithm actually runs on