In March 2024, Google made Consent Mode v2 a hard requirement for any site using Google Ads or remarketing in the EU/EEA. Without it, Google no longer processes Ads data for EU users who decline cookies — your conversion campaigns run blind in one of the world's biggest markets. The deadline passed two years ago. In 2026, this isn't a future concern; it's baseline hygiene for any performance marketer in Europe.
This guide explains what Consent Mode v2 actually does (the modeling part confuses people), how to implement it correctly step by step, how to verify it's working, and what goes wrong when it isn't.
What Consent Mode v2 Actually Does
Consent Mode is a signal layer between your consent banner and your Google tags. When a user declines, the tags don't fire in the normal sense. But instead of losing the visit entirely, Consent Mode passes anonymized, aggregate signals — page path, conversion event type, but no user identity — that Google uses for modeled conversions: statistical estimates of the conversions you're losing to consent decline.
Without Consent Mode v2, Google Ads can't model EU traffic at all. Your campaign reports show a fraction of real conversions. Smart Bidding strategies learn from fewer signals and make worse decisions. Remarketing audiences stop growing. The damage is silent and cumulative.
The two new parameters added in v2
Consent Mode v2 added two parameters that didn't exist in v1:
ad_user_data— controls whether user data can be sent to Google for advertising personalization. When denied, Google won't use any first-party data you collect for ad targeting.ad_personalization— controls remarketing and personalized ad delivery. When denied, the user is excluded from all remarketing lists and personalized ad targeting.
These join the two v1 parameters that you may already have:
analytics_storage— controls whether GA4 can set the_gacookie and identify returning users.ad_storage— controls whether Google Ads can set conversion and remarketing cookies.
All four must be present. An implementation that only sets analytics_storage and ad_storage is v1. It won't satisfy the EU requirement, and it's the most common mistake in implementations that predate the March 2024 deadline.
The required default-denied initialization
Before GTM loads — meaning before any <script src="gtm.js"> tag — you must call gtag('consent', 'default', {...}) with all four parameters set to 'denied'. The order matters. If GTM loads first, the consent defaults arrive too late — Google Ads silently treats the entire session as having no consent signal, which is worse than receiving a denied signal. A denied signal triggers modeling. No signal means nothing.
How to Implement Consent Mode v2 with GTM
Step 1 — Add the consent default before your GTM snippet
In your HTML <head>, place this block before the GTM script tag. This is the most critical ordering requirement in the entire implementation:
<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',
'wait_for_update': 500
});
</script>
<!-- GTM snippet goes here, AFTER the block above -->
<script>(function(w,d,s,l,i){...})(window,document,'script','dataLayer','GTM-XXXX');</script>wait_for_update: 500 gives your banner 500ms to check for a stored preference before tags fire. This prevents the "flash of denied state" on returning visitors — without it, a user who accepted yesterday sees their tags fire as denied until the banner JS reads the cookie and sends the update.
Step 2 — On consent acceptance, push the update
When a user accepts all categories via your banner, push the update immediately:
gtag('consent', 'update', {
'analytics_storage': 'granted',
'ad_storage': 'granted',
'ad_user_data': 'granted',
'ad_personalization': 'granted'
});For partial consent — analytics accepted, ads declined — you grant only what the user agreed to:
gtag('consent', 'update', {
'analytics_storage': 'granted',
'ad_storage': 'denied',
'ad_user_data': 'denied',
'ad_personalization': 'denied'
});On full decline (or on "Reject all"), you don't need to push an update at all — the default-denied state already reflects the user's choice. Some implementations push a denied update explicitly for clarity; that's fine but not required.
Step 3 — Persist the choice
Store the user's decision in a cookie — something like nld_consent=full, analytics, or none — and read it on every subsequent page load. When the cookie exists, pass the stored values to gtag('consent', 'default', ...) instead of always defaulting to denied.
// Read stored consent before GTM loads
const stored = getCookie('nld_consent'); // 'full' | 'analytics' | 'none' | null
gtag('consent', 'default', {
'analytics_storage': stored === 'full' || stored === 'analytics' ? 'granted' : 'denied',
'ad_storage': stored === 'full' ? 'granted' : 'denied',
'ad_user_data': stored === 'full' ? 'granted' : 'denied',
'ad_personalization': stored === 'full' ? 'granted' : 'denied',
'wait_for_update': stored ? 0 : 500 // No wait needed if we have a stored choice
});Without this, every page load starts denied and the wait_for_update window is spent waiting for a banner the user already dismissed three days ago. You show the banner again on every visit, and returning visitors' tags fire in denied mode longer than necessary.
Step 4 — Add the Consent Initialization trigger in GTM
If you're managing the consent initialization inside GTM rather than hardcoding it in your HTML (common with CMP integrations), GTM has a dedicated trigger type for this: Consent Initialization — All Pages. This trigger fires before any other trigger — including the standard Page View — specifically so consent state can be set before tags run.
Create a Custom HTML tag with the default consent block above, set its trigger to "Consent Initialization — All Pages", and ensure it has the highest priority (or fires first in the tag sequence). Your GA4 Config tag and Google Ads GTM tags should fire on standard Page View, not on Consent Initialization, so they inherit the consent state that was just set.
One important note: if you're using a CMP with a native GTM template (Cookiebot, Usercentrics, OneTrust all have them), check whether the template handles the Consent Initialization trigger itself. Many do — adding a duplicate tag will double-set consent state, which is harmless but creates confusion in GTM Preview.
How to Verify It's Working
Check in GA4 DebugView
Enable debug mode (add ?gtm_debug=x to your URL or use Tag Assistant), then open GA4 DebugView. Accept cookies and verify that analytics_storage: granted appears in the event stream. Decline cookies and verify analytics_storage: denied. The consent state is visible in DebugView under each event's parameters when Consent Mode is active.
Check in GTM Preview
The GTM Preview sidebar has a dedicated Consent tab. It shows the current state of all four parameters in real time as you interact with your banner. This is the fastest way to verify that: (1) the default state is denied before banner interaction, (2) accepting updates all four to granted, and (3) partial consent correctly grants some and denies others. If any parameter is missing from the Consent tab entirely, your initialization block isn't running before GTM.
Check in Google Ads
In Google Ads, go to Goals → Conversions → Settings → Consent Signal Status. Your domain should show Eligible, not Limited. "Limited" means Google is receiving consent signals but can't model enough data — often caused by defaults arriving after GTM loads, or by a missing ad_user_data/ad_personalization parameter. It can take 24–48 hours for status to update after fixing an implementation.
What NiceLookingData checks
Our GA4 audit and GTM audit runs a Consent Mode v2 check that verifies:
- A
consentcommand fires before anyconfigtag in the dataLayer sequence - All four v2 parameters are present (
analytics_storage,ad_storage,ad_user_data,ad_personalization) - The default command precedes GTM loading (not set via a GTM tag firing after page load)
- The GTM container itself has Consent Mode enabled in its settings
Implementations that are v1-only, missing the two new v2 parameters, or calling default after GTM all flag as CRITICAL in our audit — because the data loss is immediate and ongoing.
Check your Consent Mode v2 implementation
Run a free GA4 audit to see whether your consent implementation is v2-compliant, whether all four parameters are present, and whether defaults arrive before GTM loads.
Build your Consent Mode v2 snippet →The 4 Most Common Mistakes
These four problems account for the vast majority of broken Consent Mode implementations we see in audits:
1. GTM loads before the consent default. The consent default block is placed after the GTM snippet, or it's implemented as a GTM tag rather than inline HTML. Either way, GTM fires first, Google tags initialize without a consent signal, and the default call arrives too late to matter. Fix: move gtag('consent', 'default', {...}) above the GTM snippet — always in HTML, never as a GTM tag.
2. Missing ad_user_data and ad_personalization. The implementation was built before March 2024 and only sets analytics_storage and ad_storage. This is v1. It doesn't satisfy the requirement, and Google Ads shows "Limited" status. Fix: add the two missing parameters to both your default and update calls.
3. Not persisting consent. The consent choice isn't stored in a cookie, so the banner appears on every page, and returning visitors always start from the default-denied state until the banner JS loads and re-fires the update. Beyond the UX problem, this creates a measurement gap: tags spend the wait_for_update window in denied mode on every page load for a user who consented weeks ago.
4. Using a CMP that doesn't push a Consent Mode update. Many CMPs were not configured for Consent Mode v2 out of the box, especially if installed before 2024. The CMP shows a compliant-looking banner, but its GTM template either doesn't push gtag('consent', 'update', {...}) at all, or only pushes v1 parameters. Check your CMP's GTM template settings and ensure Consent Mode v2 integration is explicitly enabled — most major CMPs have a specific toggle for this.
Frequently Asked Questions
What is Google Consent Mode v2?
Google Consent Mode v2 is an updated version of Google's consent signaling framework, required for EEA advertising from March 2024. It adds two new parameters — ad_user_data and ad_personalization — to the v1 signals. These give Google the granular consent information it needs under GDPR and the Digital Markets Act to determine whether user data can be used for advertising and personalization.
Is Consent Mode v2 required?
Yes, for any site using Google Ads, remarketing, or personalized advertising to target users in the EU/EEA. Google required v2 compliance from March 6, 2024. Without it, Google cannot serve personalized ads or build remarketing audiences for EEA users. Sites using only GA4 for analytics — with no Google Ads connection — are not subject to the same advertising requirement, but implementing Consent Mode correctly is still best practice for GDPR compliance and measurement accuracy.
What are the four Consent Mode v2 parameters?
The four parameters are: analytics_storage (controls whether GA4 can set the _ga cookie and identify returning users), ad_storage (controls Google Ads conversion and remarketing cookies), ad_user_data (controls whether first-party data can be sent to Google for advertising — new in v2), and ad_personalization (controls remarketing and personalized ad delivery — new in v2). All four must appear in both your default and update calls.
How do I implement Consent Mode v2 without a CMP?
You can implement it without a CMP by writing the banner logic yourself: display a consent prompt, capture the user's choice, store it in a cookie, and call gtag('consent', 'update', {...}) with the correct state on acceptance. The consent default block still goes in your HTML before GTM. This is technically viable for simple yes/no consent flows, but a CMP handles the cookie law compliance burden (audit log, consent record, re-consent on policy changes) that a hand-rolled banner doesn't. For any site with meaningful EU traffic, using a CMP is the right choice.
What is modeled conversions in Consent Mode?
Modeled conversions are Google's statistical estimates of the conversions that happened among users who declined consent. When Consent Mode v2 is correctly implemented, tags that fire in denied mode send anonymized, cookieless pings — page path, conversion type, and device category, but no user identity. Google uses these pings as inputs to a machine learning model that estimates how many conversions the consenting population's pattern implies for the non-consenting population. These modeled conversions appear in your Google Ads reports alongside observed conversions, giving a more complete picture of campaign performance. Without Consent Mode v2, Google has no pings to model from, so EU conversions are simply absent from your reports.
How do I check if Consent Mode v2 is working?
Three checks cover it: (1) GTM Preview Mode — open the Consent tab in any tag's details and verify all four parameters appear and update correctly when you interact with your banner. (2) Chrome DevTools Network tab — filter for requests containing "collect", find a GA4 hit, and look for the gcs parameter — its value encodes current consent state and should change as you toggle consent. (3) Google Ads Consent Signal Status (Goals → Conversions → Settings) — your domain should show "Eligible", not "Limited". "Limited" means signals are arriving too late or the v2 parameters are missing.
What is the difference between Consent Mode v1 and v2?
Consent Mode v1 uses two parameters: analytics_storage and ad_storage. These control cookie setting but don't address data sharing for advertising purposes specifically. Consent Mode v2 adds ad_user_data and ad_personalization, which give Google the signals it needs to comply with GDPR's requirements around advertising data use and the Digital Markets Act. A v1 implementation doesn't satisfy the March 2024 EU advertising requirement — Google Ads treats it the same as no Consent Mode at all for the purposes of personalized advertising.
Does Consent Mode v2 affect GA4 data?
Yes, but the effect depends on your implementation level. With Basic Consent Mode (where you block GA4 entirely on denial), you lose all data from non-consenting users — typically 30–60% of EU traffic. With Advanced Consent Mode (where GA4 fires in restricted, cookieless mode on denial), you receive modeled data that fills in some of the gap. GA4 still shows lower session counts for EU users who decline, because it can't set the _ga cookie to identify returning visitors, but conversion modeling gives you a closer picture of real campaign performance. The analytics_storage parameter specifically governs this — declining it doesn't prevent the anonymized ping from firing; it prevents user identification via cookies.
Analytics consultant turned founder. After years running the same GA4 and GTM audits across client engagements, Ludde built the audit into a product — so the pattern-matching takes a minute, not a meeting. More about Ludde →
Run a free GA4 audit.
Connect your Google Analytics 4 property. Our auditor runs 61 checks and gives you an instant health score with a plain-English action plan.