Google Consent Mode v2 Explained

Introduction

Google Consent Mode v2 (GCM v2) is the signal layer that tells Google's tag infrastructure—GA4, Google Ads, Floodlight, and linked measurement products—what personal data can be collected and how it can be used. When a visitor to your site accepts analytics but declines ad personalization, Consent Mode translates that choice into four structured flags that every connected Google service reads automatically. Without a correct implementation, Google's tags either collect without restriction or lose access to conversion modeling that your advertising team depends on.

In March 2024, Google began requiring Consent Mode v2 for EEA advertisers who want to maintain full remarketing, conversion modeling, and audience building through Google Ads. That deadline created urgency, but implementation quality varies enormously. Many teams show Tag Assistant green checks in preview while first-visit analytics cookies still land on EU IP ranges—because preview mode does not clear prior consent cookies and Tag Assistant is not a compliance scanner. Passing Google's platform checks and satisfying GDPR are two different standards that must both be met.

Version 2 extends the original two-signal model—analytics_storage and ad_storage—with two new parameters: ad_user_data and ad_personalization. These additions close a gap where analytics was denied but ad personalization remained enabled. v2 compliance requires setting and updating all four parameters together on every consent event, across every page where Google tags are present, not only the homepage or primary landing page.

This guide explains what Consent Mode v2 is technically, why Google requires it and what that means for your legal obligations, how to choose between Basic and Advanced modes, the most common implementation errors, and how to verify implementation reliably. For context on blocking strategies, read Block Google Analytics before consent. For technical verification steps, see Verify Google Consent Mode. For the cookie banner requirements that frame the broader consent obligation, see Cookie Banner Requirements in 2026.

What Google Consent Mode v2 Is

Consent Mode operates through the gtag consent API. Before any Google tag fires, your page sets default denied flags using gtag('consent', 'default', { analytics_storage: 'denied', ad_storage: 'denied', ad_user_data: 'denied', ad_personalization: 'denied' }). This declaration must arrive before the GTM snippet or any direct Google tag—script order is not optional. Tags that load before the default declaration behave as if no consent information exists, which in practice means they may collect freely on the first page event cycle.

When the user makes a choice—clicking Accept all, Reject all, or adjusting granular category toggles—your CMP or custom banner fires an update call: gtag('consent', 'update', { analytics_storage: 'granted', ad_storage: 'denied', ... }). Tags that were loaded and waiting in denied state immediately read the new signals and adjust their collection behavior. Newly loaded tags on subsequent pages inherit the updated state from the data layer, provided the consent record is persisted in session or local storage and re-applied on each page load.

The four Consent Mode v2 parameters each map to specific Google services and data flows. analytics_storage controls whether GA4 and related products write measurement cookies and associate behavioral data with devices or users. ad_storage controls whether Google Ads products can write cookies for audience building and conversion attribution. ad_user_data controls whether Google may use data sent from your site for advertising purposes, including conversion measurement and modeling. ad_personalization controls whether Google may use that data to show personalized advertisements to the specific individual.

Consent Mode is not a cookie blocker. It changes what happens inside Google tags after they load. If your page does not also prevent non-essential scripts from loading before consent through a blocking mechanism—such as a runtime guard script or CMP pre-consent gating—Google tags can still write first-party or third-party storage before the user decides. For full GDPR alignment, Consent Mode must be paired with actual pre-consent blocking, not substituted for it. The two mechanisms serve different purposes and both are necessary.

• analytics_storage: controls GA4 measurement cookies and behavioral data association with device identifiers.
• ad_storage: controls Google Ads audience-building and conversion-attribution cookies.
• ad_user_data: controls whether data sent from your site may be used by Google for advertising purposes.
• ad_personalization: controls whether Google may use collected data to deliver individualized advertising.

Why Google Requires Consent Mode v2

Google's advertising business depends on measurement quality in an era when many users decline consent. Consent Mode's primary business purpose is enabling statistical modeling: when users deny ad_storage, Google can still observe cookieless signals from consented users and extrapolate estimated conversion volumes for campaigns. This modeling is what Google protects by requiring the v2 parameter set for EEA campaigns. Without structured consent signals, its models cannot distinguish between 'user denied consent' and 'site has no consent implementation,' producing unreliable estimates that reduce advertiser confidence in campaign data.

For advertisers, the practical impact of missing v2 signals is loss of EEA remarketing audiences, degraded conversion modeling accuracy, reduced Smart Bidding signal quality, and in some cases unavailability of certain Ads features entirely. Teams that skip v2 or set all parameters to 'granted' as a shortcut may see metrics continue in the Ads dashboard—because modeling fills gaps—but they are accumulating both legal and platform policy risk simultaneously. A future Google Ads policy enforcement action could remove features retroactively for non-compliant accounts.

Regulators and enforcement bodies including the French CNIL, German DSK, and Irish DPC have explicitly noted that Consent Mode does not fulfill GDPR requirements on its own. GDPR requires valid consent before collecting personal data for analytics or advertising. Consent Mode is a signal format—it communicates a consent state to Google's infrastructure. The law requires that the consent underlying those signals is freely given, specific, informed, and documented. These are separate obligations that interact but cannot substitute for each other.

Basic vs Advanced Consent Mode

Google Consent Mode operates in two modes: Basic and Advanced. In Basic Consent Mode, Google tags are blocked entirely until the user accepts the relevant consent categories. No data collection, no cookieless pings, no requests to Google domains. Google modifies its attribution and conversion models using signals only from users who consented. Basic mode is straightforward to explain to regulators and auditors: if the user declines, no Google tag activity occurs on that session.

In Advanced Consent Mode, Google tags load immediately even when consent is denied. They operate in a restricted state: no first-party cookies, no identifiers persisted to storage, but cookieless pings are sent to Google when the tag fires. These pings may carry URL data, referrer information, and browser signals that Google uses internally for conversion modeling. Advanced mode provides statistically richer models for advertisers but introduces legal complexity: your legal team must assess whether cookieless pings constitute personal data transmission under your specific circumstances and document that assessment.

Most GDPR-conscious implementations start with Basic mode or a hybrid approach: block tags at the network level with a runtime guard script, then load them only after consent is granted. This provides clean Reject behavior—no requests to Google at all on denial—while still using Consent Mode signals to differentiate analytics from advertising purposes for consented users. The compliance scanner can confirm which mode your site effectively runs by checking whether Google requests appear on pre-consent page loads before any user action.

The choice between Basic and Advanced should involve your legal counsel, not just the analytics or marketing lead. Advanced mode's cookieless pings to google-analytics.com before consent have been noted in informal enforcement guidance as a potential unlawful transfer concern, particularly for sites serving French or German users whose national DPAs have taken strict positions. Basic mode gives a cleaner compliance narrative: nothing leaves the browser until the user affirms consent. For most small-to-mid-size businesses serving EU traffic, Basic mode or hard blocking combined with Consent Mode updates represents the lower-risk path.

• Basic mode: tags blocked entirely until consent granted; no cookieless pings; simpler compliance story.
• Advanced mode: tags load with denied defaults; cookieless pings sent immediately; richer modeling; legal assessment required.
• Hybrid approach: block at network level with guard script (Basic-equivalent behavior) plus Consent Mode update on user action.
• For EEA sites with strict DPA environments (France, Germany, Netherlands), Basic mode is the safer default choice.
• Advanced mode is appropriate when your legal team has assessed cookieless pings and documented the analysis.
• Either mode requires all four v2 parameters set in both default and update calls.

Common Consent Mode v2 Implementation Errors

Consent Mode v2 errors fall into three categories: ordering errors where defaults arrive too late, mapping errors where parameters are set incorrectly for the chosen categories, and scope errors where implementation covers only some pages or tag containers. Each category produces a site that looks correct in Tag Assistant during a live preview session but fails on first-visit EU traffic when tested by a compliance scanner or manually with a fresh browser profile.

Ordering errors are the most critical and hardest to detect without explicit source-order inspection. If GTM loads before the default declaration, tags may run a full collection cycle before seeing denied defaults. Tag Assistant does not reliably catch this because it often operates after cookies already exist in the browser profile from prior visits. Checking page source for script order—guard script first, then Consent Mode defaults, then GTM—is a required verification step, not optional. See Verify Google Consent Mode for the complete verification process.

Mapping errors are common when CMPs or custom banners do not explicitly wire all four v2 parameters to their corresponding consent category toggles. Many early v1 implementations mapped only analytics_storage and ad_storage. When v2 shipped, teams added the new parameters to the Consent Initialization tag but did not update the update call. The result: on Accept all, all four are granted correctly, but on Reject all or partial accept, ad_user_data and ad_personalization remain at their initialized (often granted) default. The banner looks like it works; network inspection shows ad parameters still granted after rejection.

• Setting all four consent parameters to 'granted' in Consent Initialization to avoid modeling gaps.
• Loading GTM or the gtag snippet before the Consent Mode default declaration in the page template.
• Mapping only analytics_storage and ad_storage on consent updates, omitting ad_user_data and ad_personalization.
• Implementing Consent Mode only on the homepage while landing pages from Google Ads campaigns bypass the CMP entirely.
• Using Tag Assistant with an existing consent cookie in the browser to verify—which skips the first-visit denied state.
• Configuring defaults correctly in GTM preview but publishing without the same Consent Initialization tag settings.
• Hard-coding 'granted' for admin or test users in a way that contaminates production site metrics.
• Running Consent Mode v2 alongside a legacy v1 implementation that overwrites parameter states.
• Assuming server-side GTM inherits client-side consent state without explicit server-side propagation logic.
• Failing to update Consent Mode signals when users change preferences after their initial choice.
• Trusting GTM Consent Overview as a compliance confirmation rather than a debugging aid.
• Not re-verifying after agency or marketing team container updates that add new conversion tags.

Testing Consent Mode Correctly

Testing Consent Mode requires a clean environment on every run. Browser profiles that carry existing Google consent cookies cannot accurately represent a first-visit EU user. Open a new private or incognito window for every test scenario and clear all storage before loading your URL. For server-rendered sites, remember that Google tags loaded through server-side rendering or inlined scripts may fire before client-side JavaScript runs—including before your CMP mounts and sets defaults.

The Reject scenario is the most important and most neglected test. After loading the page and dismissing or rejecting consent, inspect the Network tab filtered to requests containing google-analytics.com, googletagmanager.com, doubleclick.net, and google.com. In Basic mode, none of these should appear. In Advanced mode, a limited cookieless ping may be acceptable if your legal assessment permits it. Any response that sets _ga, _gid, _gcl_*, or IDE cookies after rejection is a clear failure. Navigate to two or three internal pages after rejecting and confirm no new tracking requests appear.

The Accept scenario confirms the positive path: after accepting, all four Consent Mode parameters should update to granted (or to the specific subset matching the user's category choices), and tags should fire normally. GA4 measurement cookies should appear in the browser cookies panel after this action only. Check the GTM Consent tab in Tag Assistant against the actual network requests—the two should agree. When they disagree, there is usually a Consent Initialization tag that is overriding the CMP update, or the CMP is firing an incomplete update call.

Granular preference testing covers the middle path: analytics accepted, marketing declined. Set your banner to analytics enabled and marketing disabled. Network inspection should show GA4 cookies appearing and ad storage parameters remaining denied. If ad cookies appear despite marketing being toggled off, your update call wires ad_storage to analytics_storage instead of to a separate marketing toggle. These wiring bugs are common in semi-custom CMP setups and in configurations copied from v1 tutorials that predate the v2 parameter set.

1. Open a fresh incognito browser window with no existing cookies or prior consent signals.
2. Navigate to your site and immediately pause before clicking the banner to inspect the console and network tab.
3. Confirm default denial: run dataLayer.filter(e => e['0'] === 'consent') in the console or check Tag Assistant Consent panel shows all four parameters as denied.
4. Inspect network requests on page load before any user action—in Basic mode, no google-analytics.com, googletagmanager.com, or doubleclick.net hits should appear.
5. Click Reject all and verify no cookies are written; check the Application > Cookies panel for _ga, _gid, _gac_, _gcl_*, or IDE cookies.
6. Navigate to a second internal page without changing the prior Reject choice and confirm consent state persists with no new tracking requests.
7. Open a new incognito window, click Accept all, and confirm all four Consent Mode parameters update to 'granted' in the data layer.
8. Open a new incognito window, enable analytics only in the preferences panel, and confirm ad_* parameters remain denied while analytics_storage is granted.
9. View page source to confirm script order: runtime guard loads before GTM or gtag snippet—check that no Google tag appears before the consent default declaration.
10. Run a compliance scanner on the same URL from a clean crawl context to obtain an independent second opinion that does not share your test environment cookies.

What Compliance Scanners Check

Independent compliance scanners approach your site as EU users and enforcement tools do: no prior consent cookies, no relationship with your CMP's test flows, no Tag Assistant context. They load your pages, observe network traffic, and flag requests to tracking endpoints that appear before the user has interacted with the banner. This is the test that matters legally, because it reproduces what a data protection authority or NGO scanner would observe.

When scanning for Consent Mode compliance specifically, look for three categories of flags: pre-consent requests to Google domains, consent parameter misconfiguration detected through early page signals, and missing Consent Mode signals entirely. A page that passes UI review may fail all three scanner checks if the Consent Initialization fires after GTM or if the CMP does not send an update on Reject. See Cookie Banner Requirements in 2026 for how scanner results connect to broader banner obligations.

Scanners cannot confirm that Consent Mode parameters map correctly to your specific category toggles—that requires documentation and manual verification as described in the previous section. But they can confirm that no Google cookies or identifiers are written during the pre-consent window, that consent requests do not appear before banner interaction completes, and that post-rejection navigation remains clean. Combined with manual verification logs, scanner evidence becomes the strongest available form of compliance documentation for GDPR Article 5(2) accountability.

• Pre-consent google-analytics.com collection requests before any banner interaction.
• _ga, _gid, or _gac_ cookies appearing in the first page load without prior user consent.
• googletagmanager.com loading before a runtime guard script in page source inspection.
• Consent Initialization tag absent from GTM container review or present with granted defaults.
• All four v2 parameters not present in consent update calls detected through data layer inspection.
• Post-reject navigation pages showing fresh Google cookie writes on subsequent internal loads.
• Landing pages from advertising campaigns loading without the banner or with auto-granted consent bypassing the CMP.
• Third-party scripts loading on first paint that set identifiers used for cross-site tracking.

Consent Mode v2 checklist worth citing

If you need a compact reference for a blog post, implementation ticket, vendor questionnaire, or agency handoff, use this checklist. It focuses on observable behavior rather than marketing claims: denied defaults, script order, Reject behavior, category mapping, and evidence after changes.

How GDPRChecker Helps

GDPRChecker integrates Consent Mode v2 signals into its banner platform. When users accept analytics categories, analytics_storage updates to granted. When users accept marketing or advertising categories, ad_storage, ad_user_data, and ad_personalization all update together. Category-to-parameter mapping is configured under Consent → categories (Google Consent Mode v2) and published with your CMP config. GDPRChecker supports Consent Mode v2 integration and diagnostics, but is not currently a Google Certified CMP or IAB TCF CMP.

The runtime guard script (runtime-guard.js) loads synchronously in your page template before GTM and any Google tag snippets. This preserves denied defaults until the banner records a user choice, regardless of how quickly GTM containers load in production. Ordering verification is available in the setup dashboard, which checks whether guard placement is correct on the live URL—not only in the GTM preview environment. This catches the ordering errors that cause the most invisible compliance failures.

The compliance scanner runs against your production URL from a clean crawl context, providing an independent check that shares none of your test environment cookies. Scanner reports document pre-consent behavior, post-reject clean-up, and Consent Mode signal presence—creating a compliance artifact that both marketing and legal teams can act on. Scheduled scans alert teams when production behavior changes after a GTM container publish, plugin update, or template modification, turning compliance into an ongoing monitored state rather than a one-time deployment milestone.

For teams managing multiple sites, the GDPRChecker dashboard shows Consent Mode health across all registered URLs. Runtime heartbeat monitoring detects when a site stops sending protection signals—indicating a banner has been removed, a script tag reordered, or a plugin update has overridden consent gating. This prevents the gap between 'we implemented it six months ago' and 'it is still working today,' which is the most common reason for compliance drift on sites that were initially set up correctly.

• Free GDPR Compliance Scanner
• GDPRChecker pricing
• Cookie banner product overview
• Cookie consent management
• Privacy policy generator
• Cookie policy generator