Consent Mode v2: What It Actually Changes About Your GA4 Data

Consent Mode v2 changes how Google Analytics 4 (GA4) counts and models users based on the consent signals your site sends. When a visitor denies analytics or ad consent, GA4 doesn't simply drop that visit — it uses modeling to estimate what likely happened, which changes your numbers in ways many teams don't expect.

Key takeaways

• Consent Mode v2 is a required signal framework, not a cookie banner — it works alongside your existing consent management platform (CMP), it doesn't replace it.
• Two new consent parameters, ad_user_data and ad_personalization, are required for Google Ads features like remarketing and conversion import in the EEA.
• When consent is denied, GA4 doesn't stop counting entirely — it uses conversion modeling to fill gaps, provided you meet Google's minimum data thresholds.
• Your "users" and "sessions" metrics can shift after implementation, not because traffic changed, but because measurement methodology changed.
• Sites that ship Consent Mode incorrectly (e.g., default state set wrong) can see conversions disappear entirely rather than get modeled.

What is Consent Mode v2, exactly?

Consent Mode v2 is Google's updated framework for passing user consent status to Google tags (GA4, Google Ads, Floodlight) before they fire. It's an evolution of the original Consent Mode, adding two parameters required for advertising measurement in the European Economic Area (EEA): ad_user_data and ad_personalization.

Consent Mode itself is not a consent banner. It's a signal layer — your CMP (OneTrust, Cookiebot, CookieYes, or a custom banner) tells Google tags what the user has agreed to, and the tags adjust their behavior accordingly. Google announced this update in late 2023 as a requirement for advertisers serving ads to users in the EEA, with enforcement tied to continued access to certain Google Ads and Analytics features.

There are four consent types in play: ad_storage, analytics_storage, ad_user_data, and ad_personalization. Each can be set to granted or denied, and each affects what a Google tag is allowed to do.

Why do my GA4 numbers change after implementing Consent Mode v2?

Your GA4 numbers change because denied-consent visits no longer generate the cookie-based hits they used to, so GA4 fills the gap using conversion modeling — a statistical estimate based on observed, consented traffic with similar characteristics. This is a methodology shift, not necessarily a traffic change.

Before Consent Mode, a visitor who rejected cookies typically generated little or no GA4 data at all. After Consent Mode v2, that same visitor generates a "cookieless ping" — a limited signal with no persistent identifier — which GA4 uses as an input to its modeling, rather than counting them as a full standard session.

The practical effect: your conversion counts may become more complete (because modeled conversions attempt to account for consent-denied users), while your user and session counts may look different because they're now built from a blend of observed and modeled data rather than observed data alone.

Does GA4 modeling replace real data with guesses?

No — modeling only activates in aggregate reporting once you clear Google's minimum data thresholds, and it never fabricates individual user records. It estimates behavioral patterns for denied-consent traffic based on patterns from consented traffic with similar characteristics, then applies that only at the aggregate level.

Modeling is a statistical technique that estimates conversion behavior for users whose consent was denied, based on observed behavior from similar consented users. Google requires a minimum volume of daily consent-denied traffic and daily observed conversions before conversion modeling activates for a property, per Google's documentation. Below that threshold, denied-consent conversions may simply not appear anywhere.

This matters most for mid-sized sites with meaningful EEA traffic but modest overall volume — they can fall below the modeling threshold and see a visible drop in reported conversions with no modeling to soften it.

How is this different from basic Consent Mode?

Basic Consent Mode only controlled ad_storage and analytics_storage, affecting whether cookies could be set at all. Consent Mode v2 adds ad_user_data and ad_personalization, which govern whether user data can be sent to Google for advertising purposes — a distinct and more granular permission layer.

User visits site

CMP loads before GTM

Consent choice recorded

granted or denied per signal

Default vs update signal sent

gtag consent commands

GA4 tag behavior adjusts

full hit, cookieless ping, or blocked

Reporting reflects observed + modeled data

thresholds apply

What breaks most often in Consent Mode v2 implementations?

The most common failure is an incorrect default consent state — set before the CMP loads — which either blocks tags that should fire or grants consent that was never actually given. Both cause silent data loss or compliance risk, and neither typically throws an error.

If you're seeing gaps like these, a structured audit is the fastest way to isolate whether the issue is consent configuration, tag firing order, or something unrelated like broken triggers — our free instant audit checks exactly these points. If the underlying issue turns out to be a tagging gap rather than consent, our guide on GA4 not tracking form submissions covers the next most common cause.

Should you move to server-side tagging because of this?

Server-side tagging doesn't remove your consent obligations, but it gives you a single, auditable point to enforce consent decisions and can reduce reliance on browser-based cookie limitations. It's worth considering if you're already troubleshooting complex consent logic across many client-side tags.

Server-side Google Tag Manager (sGTM) is a tagging architecture where tags run on a server you control rather than in the user's browser, giving you more control over what data is sent, when, and under what consent state. It doesn't bypass consent requirements — you still need to pass consent signals into your server container — but it centralizes enforcement. See our guide on server-side GTM setup for GA4 for the tradeoffs.

Frequently asked questions

Is Consent Mode v2 legally required?

Consent Mode v2 became a requirement from Google for advertisers using certain Google Ads and Analytics features with EEA traffic, effective March 2024, per Google's own communications. Legal consent requirements themselves are set by regulations like GDPR, not by Google — Consent Mode is the technical mechanism for complying with those rules within Google's tools.

Will my GA4 conversion numbers go up or down after implementing it?

It depends on your prior setup and traffic volume. Sites with significant EEA consent-denied traffic often see conversion counts partially recover through modeling versus having no data at all pre-implementation, but sites below the modeling threshold may see reported conversions drop with nothing to fill the gap.

Do I need Consent Mode v2 if I have no EEA traffic?

If you have zero users subject to GDPR or similar regulations, the Google-imposed requirement doesn't strictly apply, but implementing it anyway is low-risk and future-proofs your setup as regulations expand elsewhere. Many teams implement it globally rather than maintaining region-specific tagging logic.

Does Consent Mode v2 fix GA4 and Google Ads discrepancies?

It addresses one specific cause — consent-driven data gaps — but it won't fix discrepancies caused by attribution model differences, tag firing order issues, or lookback window mismatches. If your numbers still don't reconcile after a correct Consent Mode implementation, the cause is likely elsewhere in your tagging setup.

How do I know if my Consent Mode v2 setup is actually working?

Test both consent states directly using GTM's Preview mode and Google's Tag Assistant, checking that the correct tags fire, block, or send cookieless pings under each state. A configuration audit, like our free instant audit, is the fastest way to confirm this without manual trial and error across every page template.