Google Consent Mode v2: What It Is and How to Implement It

What Consent Mode v2 actually does

Consent Mode is a framework that lets you pass consent signals to Google's tags (GA4, Google Ads, Floodlight) so they can adjust their behavior based on what a visitor has and hasn't agreed to. When a visitor declines analytics cookies, Consent Mode tells GA4 to operate without setting persistent identifiers — no _ga cookie, no user identification. Google can still receive a "ping" that a page was viewed, but without any data that could identify the individual.

Version 2, which Google required for all advertisers in the EU by March 2024, added two new consent types: ad_user_data (whether the user consents to their data being used for advertising) and ad_personalization (whether the user consents to personalized ads). Without these signals, Google Ads can't run remarketing campaigns to EU users.

The four consent signals you need to set

Consent Mode v2 works with six consent types in total, though four are the most important for most sites:

analytics_storage — Controls whether GA4 can store cookies and collect analytics data. Deny this and GA4 stops setting the _ga cookie.
ad_storage — Controls whether Google Ads cookies can be set. Required for conversion tracking and remarketing.
ad_user_data — New in v2. Controls whether user data can be sent to Google for advertising purposes.
ad_personalization — New in v2. Controls whether data can be used for personalized ad targeting.

The other two — functionality_storage and security_storage — cover functional cookies (language preferences, login state) and security cookies. security_storage is typically granted by default since it covers things like CSRF protection.

The critical timing issue

This is where most implementations go wrong. Consent Mode defaults must be set before Google's tags load — not after. If you configure consent defaults inside a GTM Custom HTML tag that fires on page load, you've already missed the window. GA4 will have already initialized with its default behavior, potentially setting cookies before the consent signal arrives.

The correct implementation places the consent default settings in an inline script in the HTML <head>, before the GTM snippet:

<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments);}
  gtag("consent", "default", {
    "analytics_storage": "denied",
    "ad_storage": "denied",
    "ad_user_data": "denied",
    "ad_personalization": "denied",
    "functionality_storage": "denied",
    "security_storage": "granted",
    "wait_for_update": 500
  });
</script>
<!-- GTM snippet goes here, AFTER the consent defaults -->

The wait_for_update: 500 parameter tells GA4 to wait up to 500 milliseconds for a consent update before sending any data. This gives the CMP (consent management platform) time to check for a stored consent preference and update the signals before GA4 makes any network calls.

Consent updates: when the user accepts

When a visitor accepts cookies — either when first shown the banner or later via your cookie settings — your consent management platform (CookieYes, Cookiebot, OneTrust, etc.) needs to push a consent update to the data layer. In GTM, you then need a trigger listening for that update event and a tag that fires gtag("consent", "update", {...}) with the granted signals.

In CookieYes specifically, the data layer event that fires on consent update is cookie_consent_update (underscores, not hyphens — this matters). Your GTM trigger should listen for a Custom Event with that exact name.

The consent update tag sends the updated signals to GA4 and Google Ads. Only after this fires will those tags begin operating in full mode — setting cookies, sending full event data, and enabling remarketing.

Google's behavioral modeling

One of the key benefits of Consent Mode is that Google uses machine learning to model the behavior of non-consenting users — estimating conversion rates and traffic patterns based on the consenting population. This means your reports aren't showing a 40% gap where EU visitors used to be; instead, Google fills in estimated aggregate data.

This modeling only works if you have Consent Mode properly implemented. Without it, you either lose all visibility into non-consenting users, or you're collecting data you're not allowed to collect. Neither is acceptable.

How to verify your implementation

Use GTM's preview mode and GA4's DebugView to verify consent mode is working correctly:

Open your site in GTM preview mode. Before accepting the cookie banner, check the data layer — you should see the consent defaults have been pushed with all signals denied.
Accept the cookie banner. Check the data layer again — you should see a cookie_consent_update event, and your consent update tag should fire in GTM preview.
In GA4 DebugView, events should only appear after banner acceptance, not before.
Check your browser DevTools (Application → Cookies) — the _ga cookie should not be present before consent is given.

Consent Mode and your CMP

Most reputable CMPs — CookieYes, Cookiebot, OneTrust, TrustArc — support Consent Mode v2 natively. They handle the consent update push to the data layer. Your job is to configure GTM to listen for it and respond correctly.

What they don't handle automatically is the inline consent defaults in your HTML. That inline script is your responsibility, and it needs to be on every page of your site — not just the homepage.

Need Consent Mode v2 implemented correctly?

I handle the full consent stack — CMP setup, GTM consent configuration, inline defaults, and DebugView verification — so you're compliant and not leaking data.

Get a quote