Google Consent Mode v2 Explained

Google Consent Mode v2 is the API Google Tags use to ask one question before they do anything: did this visitor agree to be tracked?It doesn't collect consent itself — that's the job of a cookie banner or consent management platform (CMP). It just gives Google's tags a standard way to receive the answer and change their behaviour accordingly.

Why it exists

Before Consent Mode, a tag either fired or it didn't. If a visitor declined analytics cookies, the only correct move was to block Google Analytics entirely — which meant losing all visibility into that visitor's session, including anonymous, aggregate numbers you were legally allowed to keep. Consent Mode fixes this by letting tags run in a cookieless, modelled mode instead of an all-or-nothing one.

From March 2024, Google made Consent Mode a requirement for advertisers using Google Ads or Analytics remarketing/conversion features for EEA traffic. Sites that don't implement it can lose access to features like audience remarketing and conversion modelling for European visitors.

The seven consent signals

Consent Mode v2 works off seven named signals, each set to granted or denied. A cookie banner is responsible for deciding the value of each; Google tags just read them.

The two ad_user_data / ad_personalization signals are what actually make it v2 — v1 only had ad_storage and analytics_storage.

Basic mode vs. advanced mode

This is the part most write-ups skip. There are two ways to implement Consent Mode, and they behave very differently before a visitor makes a choice:

• Basic Consent Mode — Google tags don't load at all until the visitor interacts with the banner. Simple, but you get zero data — not even cookieless pings — for visitors who never respond.
• Advanced Consent Mode — tags load immediately with every signal defaulted to denied, firing cookieless, anonymised pings. Once the visitor responds, Google fires a consent updateand the tag switches behaviour live, without a page reload. This is what almost every production site should use, because it's the only mode that lets Google build modelled conversions for visitors who decline.

What a CMP actually has to do

Consent Mode itself is just an API — it doesn't ship a banner, doesn't store a decision across page loads, and doesn't know anything about GDPR, CCPA, or any other law. Wiring it correctly means:

1. Setting all seven signals to denied before the GTM/gtag snippet loads.
2. Persisting the visitor's decision (cookie or storage) so it survives navigation.
3. Re-mapping banner categories (e.g. “Marketing”, “Analytics”) onto the seven Google-specific signal names.
4. Calling update the moment a decision is made or changed — including revocation.

This is exactly the kind of plumbing an open source CMPlike Consenti is built to own, so you don't have to hand-roll the gtag stub queue and signal mapping yourself. Consenti pushes default on initialisation and update on every consent change automatically, and exposes widget.getGTMConsent() if you want to read the current signal state directly.

import { ConsentiSetup } from '@consenti/ui'

new ConsentiSetup({
  compliance: { type: 'opt-in' },
  utils: {
    gtm: { containerId: 'GTM-XXXXXX' }, // Consenti handles default + update calls
  },
})

For the full configuration options — container ID, URL passthrough, ads data redaction — see the dedicated GTM & Google Consent Mode v2 guide. If you're specifically wiring this up inside the Google Tag Manager console rather than via a JS library, the Google Consent Mode for GTM guide covers that workflow.

Frequently asked questions