Google Consent Mode v2 Explained: Signals & Modeling

Google Consent Mode v2 is the mechanism by which Google’s tags (Google Analytics, Google Ads, Floodlight) adjust their behavior based on what a visitor consented to. Your consent banner or CMP collects the choice; consent mode communicates it to the tags; the tags then decide what they may store on the device and what they may send to Google. The mechanics are specified in Google’s consent mode documentation.

The “v2” matters because of enforcement: Google requires the two v2 signals from advertisers with EEA and UK audiences — since March 2024 — for ad personalization and remarketing features to keep working (the requirement is laid out in Google’s consent mode help for Ads). In practice, if you advertise to Europeans through Google, consent mode stopped being optional.

One scoping note before the details, because it prevents the most common confusion: consent mode is Google’s consent plumbing for Google’s tags. It is not a consent banner, not a legal basis, and not a framework governing your non-Google analytics — we return to each of those boundaries below.

Consent mode communicates consent state per consent type. Four carry the weight:

The v1 pair governs storage on the device; the v2 pair governs data use by Google — that’s why v2 exists: EU enforcement increasingly cares not just whether a cookie is set, but whether personal data flows into ad targeting. Google’s spec also defines functionality_storage, personalization_storage and security_storage for non-Google-ads purposes; your CMP will handle them, but the four above are the ones with product consequences.

In code, consent mode is two calls: a default set before any tag loads (what applies before the visitor chooses) and an update when they choose. A typical EU-safe default:

// Before any Google tag loads: deny by default for EU visitors
gtag("consent", "default", {
  ad_storage: "denied",
  analytics_storage: "denied",
  ad_user_data: "denied",
  ad_personalization: "denied",
  region: ["EEA-country-codes..."],
  wait_for_update: 500
});

// After the visitor accepts in your banner/CMP:
gtag("consent", "update", {
  ad_storage: "granted",
  analytics_storage: "granted",
  ad_user_data: "granted",
  ad_personalization: "granted"
});

Most teams never write this by hand — Google-certified CMPs emit it — but knowing what the calls do is how you audit that your banner and your tags actually agree.

There are two implementation styles, and the choice is a real privacy-vs-data tradeoff, not a version difference:

In basic mode, a visitor who declines is simply invisible to Google’s tags. In advanced mode, declined visitors still generate cookieless pings — no advertising identifiers, but event-level signals Google uses to model conversions more accurately. Google’s documentation is explicit that advanced mode enables the more detailed modeling; whether sending any pings without consent is acceptable in your jurisdiction is a question for your counsel, not your tag manager — several EU regulators read ePrivacy strictly (see the ICO’s cookie guidance for the UK reading).

The pitch for consent mode is that modeling fills the gaps: when visitors deny consent, Google estimates the conversions and behavior you couldn’t observe, so reported totals stay decision-useful. For Google Ads bidding this genuinely matters — conversion modeling feeds the bidding algorithms, and an advertiser without it simply loses the declined segment from optimization. GA4 behavioral modeling similarly estimates metrics for unconsented traffic, as described in Google’s consent mode help for Analytics.

The honest caveats:

• Modeled numbers are estimates. They’re Google’s inference of what declined visitors probably did, not observations. Directionally useful; not audit-grade.
• Modeling has entry requirements. GA4’s behavioral modeling activates only above minimum traffic and event-volume thresholds — smaller sites never qualify, and get gaps rather than estimates.
• You can’t inspect it. There’s no per-visitor record behind a modeled aggregate — nothing to drill into, reconcile with your CRM, or hand to finance.
• It only patches Google’s view. Modeling reconstructs Google’s reporting; it does nothing for your other analytics, your CRM journeys, or person-level questions.

That last point deserves emphasis: under UK and EU guidance, declining must be as easy as accepting — the ICO has been explicit about “reject all” prominence. Optimizing consent rates is legitimate UX work (clarity, timing, trust), but dark patterns that juice the rate create the same legal exposure the banner was meant to prevent.

Here’s the structural point that gets lost in consent-mode content: consent mode is scoped to Google’s tags. The measurement problem it mitigates — losing visibility of visitors who decline ad-tracking cookies — doesn’t apply uniformly to every architecture. An analytics layer that sets no advertising cookies, does no cross-site tracking, and serves first-party sits on a different legal and technical footing than the ad stack consent mode exists to manage.

That’s the design we run: first-party, cookieless analytics measures traffic without advertising identifiers, so baseline measurement doesn’t hinge on the banner outcome — while Google Ads tags, where you run them, still get consent mode and its modeling for the advertising layer. The two coexist: consent mode for Google’s ad ecosystem, first-party measurement for your own ground truth. The server-side tracking guide covers the adjacent architecture questions.

The legal fine print of that posture — which lawful basis covers cookieless analytics, when ePrivacy still bites, what changes for EU person-level identification, and where a consent gate remains the right call — is deliberately not re-litigated here: our visitor identification GDPR guide is the canonical treatment, including the honest caveat that some regulators read device-storage rules to cover localStorage identifiers too. Short version: cookieless first-party is a strong posture with real paperwork attached, not a magic exemption.

1. 1If you advertise to EEA/UK audiences with Google: implement consent mode v2 (all four signals) via a Google-certified CMP — this is the keep-remarketing-working requirement.
2. 2Choose basic vs advanced deliberately, with counsel: advanced recovers more modeled data; basic is the conservative reading of ePrivacy.
3. 3Set region-scoped defaults: denied-by-default where consent is required; granted elsewhere if that matches your legal analysis.
4. 4Verify end-to-end: decline in your own banner, then confirm in the browser’s network tab which pings still fire — trusting the CMP’s dashboard is how mismatches survive for months.
5. 5Track your consent rate as a first-class metric, and improve it with clarity and trust — not dark patterns.
6. 6Keep a measurement layer whose baseline doesn’t depend on the banner, so your channel and revenue ground truth survives whatever the accept rate does.

Consent mode is best understood as damage control for a cookie-dependent advertising stack — well-engineered damage control, worth implementing properly if you run Google ads in Europe. Just don’t mistake it for a measurement strategy: the strategy is deciding which of your data needs consent-gated advertising identifiers at all.