The Definitive Guide to Google Consent Mode v2: Requirements and Setup

Google Consent Mode v2 is the critical link between privacy compliance and your ad performance. Essential for EU/EEA traffic, it helps your Google tags respect user consent while supporting accurate attribution data. Failing to implement v2 correctly means losing remarketing and audience features. Learn what’s required, how it works, and how to set it up without breaking your tracking.

Consent Mode v2 sits at the intersection of privacy compliance and campaign performance. Get it right, and your Google tags behave exactly as they should for every user, consenting or not. Get it wrong, and you're flying blind on attribution, with remarketing and audience features quietly switching off for EU/EEA traffic.

This guide covers what Consent Mode v2 requires, how it works, and how to implement and verify it correctly.

What Is Google Consent Mode v2?

Google Consent Mode v2 is Google's framework for managing how its tags behave based on user consent. Depending on what a user agrees to, it adjusts what data gets collected and how it's used. The 2024 update added two new parameters required under the EU Digital Markets Act (DMA) for sites serving users in the EU/EEA.

Think of it as the link between your cookie banner and your Google tags. When a user makes a choice on your banner, Consent Mode translates that into signals each tag understands and acts on. Tags don't just fire and collect whatever they can. They check the consent state first, then behave accordingly.

V1 introduced this with two parameters covering analytics and ad measurement. V2 added ad_user_data and ad_personalization to meet DMA requirements. Without both in place, sites lose access to remarketing and audience features for EU/EEA users.

How Does Google Consent Mode v2 Work?

Consent Mode v2 uses four parameters to control how Google's tags behave based on each user's consent. Each parameter governs a specific type of data activity, and each one can be set to either “granted” or “denied” depending on what the user chooses.

These parameters are set in two stages. 

First, a default state is established when the page loads, before the user has interacted with the consent banner. This default typically sets everything to “denied.” 

Then, once the user makes a choice on the banner, the consent state updates to reflect their decision.

The critical requirement is that the default state is defined before the Google Tag or Tag Manager library loads. This specific sequencing is essential for compliance and is where most implementations go wrong.

The Four Consent Parameters Explained

Here’s a breakdown of the four Google Consent Mode parameters and what they mean:

• analytics_storage (v1): Controls whether Google Analytics can store cookies and collect measurement data. When denied, Analytics operates without cookies. Sessions aren't reliably tracked across pages, and conversion data becomes incomplete.
• ad_storage (v1): Controls whether Google Ads tags can store cookies for ad measurement and attribution. When denied, click-to-conversion tracking breaks and remarketing lists stop being populated.
• ad_user_data (v2): Controls whether personally identifiable user data (like hashed emails) can be sent to Google for advertising. When denied, Google cannot use specific user signals for ad measurement, but it can still receive anonymous signals for aggregate modeling.
• ad_personalization (v2): Controls whether data can be used for personalized advertising, including remarketing. When denied, the user is excluded from audience lists and remarketing campaigns entirely.

Is Google Consent Mode v2 Mandatory?

Yes, using Google Consent Mode v2 is mandatory. Any website using Google Ads or Analytics with EU/EEA traffic that wants to retain audience, remarketing, and conversion features is required to implement Consent Mode v2. Google enforced this as a requirement from March 2024 under its EU user consent policy.

Non-compliant sites don't face direct fines from Google. What they lose is the advertising functionality itself. Remarketing lists stop updating, conversion modeling becomes unavailable, and attribution data degrades over time. For sites still on v1 or running no Consent Mode at all, that degradation is already underway.

Basic Mode vs. Advanced Mode: Which One Should You Use?

The core difference between basic and advanced mode is simple: Basic mode fires no Google tags until the user consents. Advanced mode fires cookieless pings immediately, even when consent is declined.

In Basic mode, non-consenting users are completely invisible to Google. There's no measurement, no modeling, no recovery. For sites with EU/EEA audiences running paid campaigns, that's a permanent gap in attribution that compounds over time.

Advanced mode is the right choice for most advertisers. Because cookieless pings are sent regardless of consent, Google can apply conversion modeling to estimate what non-consenting users did. That estimated data feeds back into Smart Bidding and reporting, preserving measurement accuracy without relying on individual user data.

However, Advanced mode does require the default consent state to be configured correctly before any Google tags fire. This is where manual implementations most often go wrong, and it's not something a visual check of your banner will catch.

→ Add a Before/After tracking impact diagram showing ad data visibility across three states: no Consent Mode, Basic mode, and Advanced mode.

How Conversion Modeling Fills the Data Gap

Even with Consent Mode correctly implemented, visitors who decline cookies create gaps in your analytics. That's unavoidable. Conversion modeling is how Google partially recovers that signal without depending on consent data.

Using behavioral patterns from consenting users, Google's models estimate what non-consenting users likely did: which pages they visited, whether they converted, and which campaigns brought them there. That estimated data feeds into Smart Bidding and campaign reporting, helping maintain measurement accuracy without relying on individual-level consent.

The quality of the model depends directly on the number of users who consent. For example, a site with a 40 percent consent rate gives Google considerably less to work with than one with a 70 percent consent rate. That's why consent banner design and consent UX are performance decisions, not just compliance ones.

How to Set Up Google Consent Mode v2

There are two ways of setting up Google Consent Mode v2: through a certified Consent Management Platform (CMP), which is Google's recommended approach, or manually via Google Tag Manager or gtag.js.

Option 1: Set Up Via a Certified CMP 

A certified CMP handles the most error-prone part of the implementation automatically: setting the correct default consent state before any Google tags fire. It also keeps pace with changes to Google's requirements without needing developer involvement each time.

Here's how to set it up with Cookiebot CMP:

1. Sign up for Cookiebot CMP and connect your domain.
2. In your dashboard, navigate to Integrations and enable the Google Consent Mode v2 toggle.
3. Add Cookiebot™ to your site via the GTM template or the WordPress plugin.
4. Configure geotargeting so the consent banner shows to EU/EEA visitors.
5. Publish and verify using GTM Tag Assistant. The validation steps are in the section below.

Option 2: Manual Implementation via GTM or gtag.js

For developers or technical website managers who prefer direct control, manual implementation is possible via GTM or by adding the Consent Mode snippet directly to the site's <head>.

Here are the steps:

1. Load the Consent Mode initialization snippet in the <head>, before any Google tags.
2. Set default consent states for all four parameters using a Consent Initialization trigger in GTM.
3. Update the consent state via the dataLayer when the user interacts with the banner.
4. For direct script implementation without GTM, the same sequencing logic applies. See Google's developer documentation for the full gtag.js code.

TCF v2.3 Is Now Mandatory

The IAB’s TCF v2.3 became mandatory in February 28, 2026. For sites using a TCF-compliant CMP, Google reads the IAB TC String automatically, and no additional Consent Mode configuration is required on top of a compliant TCF setup.

How to Verify Your Implementation Is Working

A working consent banner doesn't guarantee consent signals are firing in the correct order. Incorrect sequencing is the most common implementation failure, and it's not visible to the end user.

Using GTM Tag Assistant to Validate Consent Mode

The most common way to verify your implementation is to use GTM. To do this, open GTM Tag Assistant and trigger a page load. In the event sequence, the Consent Initialization trigger must appear before any other Google tag triggers. If it appears after a GA4 or Google Ads tag, the implementation isn't working correctly, regardless of how the banner looks on screen.

If this is the case, check the consent state values in Tag Assistant. All four parameters should show either granted or denied, never “not set.” A "not set" value means the default consent configuration wasn't in place before tags fired. It's the single most common error in manual implementations.

Common GTM Errors and How to Fix Them

There are a few other common GTM errors. 

The most frequent issue is consent signals firing after Google tags already have. This usually means the initialization tag is using the wrong trigger type. Switching it to Consent Initialization - All Pages ensures it runs before anything else on the page.

Additionally, if ad_user_data and ad_personalization aren't showing up in Tag Assistant at all, the implementation was likely built for v1 and never updated. Both parameters need to be added to the default consent state and to any consent update calls triggered by banner interactions.

If you notice that the consent state isn't updating after a user accepts or declines on the banner, the culprit is almost always a mismatch between the CMP's dataLayer push event name and the GTM trigger that's supposed to listen for it. Check that both use exactly the same event name.

Finally, if the banner fires but consent state values still show as "not set", the default consent state was never configured. Only an update call exists, with no default to update from. A gtag ('consent', 'default', {...}) call needs to run on every page load, before any Google tags fire.

Here’s an overview of the most common mistakes and how to fix them.

Does Google Consent Mode v2 Make You GDPR-Compliant?

No, and this is one of the most common misconceptions about Consent Mode. Implementing it correctly doesn't make your site compliant with General Data Protection Regulation (GDPR) requirements on its own.

Consent Mode signals user consent to Google's tags and adjusts how they behave. It doesn't collect consent itself. GDPR consent must be prior, informed, freely given, and specific. Meeting those standards requires a properly configured CMP with a compliant banner that gives users a genuine choice before any tracking occurs.

Consent Mode handles what Google requires: the signal. A CMP handles what the GDPR requires: the collection and auditable record of consent. You need both working together to address requirements on either front.

Don't Let Consent Mode v2 Cost You Your Ad Data

Consent Mode v2 is a baseline requirement for EU/EEA advertisers, and the data loss from non-compliance compounds the longer it's left. Getting it right means pairing Consent Mode with a Google-certified CMP that handles consent collection correctly and passes signals to Google in the right sequence, automatically.