Paste your GTM / consent code snippet
Detailed Findings
Audit Checklist Summary
What Is Google Consent Mode?
Google Consent Mode is a framework that lets websites adjust how Google tags behave based on the consent status of their visitors. Introduced in 2020, it acts as a bridge between your Consent Management Platform (CMP) and Google services like Google Analytics 4, Google Ads, and Floodlight tags. Rather than blocking tags entirely when consent is denied, Consent Mode sends cookieless pings that allow Google to model conversions and behavior without storing personally identifiable information.
How Consent Mode Works with GTM
When implemented through Google Tag Manager, Consent Mode operates on a two-step process. First, you set default consent states before the GTM container loads. This tells Google tags how to behave before a user interacts with the consent banner. Second, when the user grants or denies consent, your CMP calls gtag('consent', 'update', {...}) to adjust tag behavior in real-time.
The critical detail most implementations miss: the default consent state must be set before the GTM container script loads. If the container fires first, tags execute with implied consent for a brief window, which violates GDPR requirements. This is the single most common compliance issue we detect in audits.
Consent Mode v1 vs. v2
The original Consent Mode (v1) managed two consent types: ad_storage and analytics_storage. In November 2023, Google introduced Consent Mode v2, adding two new signals: ad_user_data and ad_personalization. These map directly to the EU Digital Markets Act (DMA) requirements that came into force in March 2024.
If you are running Google Ads campaigns targeting EU users, Consent Mode v2 is now mandatory. Without it, Google cannot use your conversion data for audience building, remarketing, or measurement optimization. For a complete walkthrough, see our privacy-compliant analytics guide.
Consent Mode v2: What Changed
Google’s Consent Mode v2 was not a minor update. It fundamentally changed how Google processes user signals for advertising purposes in the European Economic Area (EEA), United Kingdom, and Switzerland. The changes align with the EU Digital Markets Act (DMA), which requires gatekeepers like Google to obtain explicit consent before combining user data across services.
The Two New Parameters
ad_user_data controls whether user data can be sent to Google for advertising purposes. When denied, Google will not associate conversion events with a Google user account. ad_personalization controls whether personalized advertising (remarketing, Similar Audiences) is permitted. When denied, Google will not use the data for ad targeting.
These parameters exist because the DMA requires granular consent. Simply blocking all cookies with ad_storage: denied was not sufficient. Google needed to distinguish between “user allows cookies” and “user allows their data to be used for ads” as separate consent actions.
Google’s March 2024 Deadline
Starting March 6, 2024, Google began enforcing Consent Mode v2 for all EEA traffic. Advertisers who did not upgrade lost access to audience features, remarketing, and conversion modeling for EU users. This means if your GTM container still uses v1 consent parameters, you are losing valuable advertising data every day.
The impact is measurable. Advertisers who upgraded to v2 with a properly configured CMP recovered an average of 65% of conversion data that would otherwise be lost when users deny consent. This is because Google’s behavioral and conversion modeling relies on the cookieless pings that Consent Mode sends even when consent is denied. For more on how this affects your GDPR compliance, see our GDPR web analytics guide.
| Parameter | Version | Controls | Default for EU |
|---|---|---|---|
ad_storage | v1+ | Advertising cookies (e.g., _gcl_*) | denied |
analytics_storage | v1+ | Analytics cookies (e.g., _ga, _gid) | denied |
ad_user_data | v2 | Sending user data to Google for ads | denied |
ad_personalization | v2 | Personalized advertising / remarketing | denied |
functionality_storage | v1+ | Functional cookies (preferences, language) | granted |
personalization_storage | v1+ | Personalization cookies (recommendations) | denied |
security_storage | v1+ | Security-related cookies (authentication) | granted |
For a deep-dive into auditing your existing GA4 setup against these requirements, see our GA4 privacy audit guide.
Common Consent Mode Mistakes
After auditing hundreds of GTM implementations, we see the same consent configuration mistakes appearing repeatedly. Each one either creates a compliance risk or degrades your data quality. Here are the most critical ones to watch for.
1. Missing Default State
The GTM container loads without any gtag('consent', 'default', ...) call. Tags fire with full access for the first few hundred milliseconds until the CMP initializes. This is technically a GDPR violation since data was collected without consent.
2. Default Set After GTM Container
The consent default script appears after the GTM container snippet in the HTML. Even if it’s present, tags in the container execute before the default is applied, creating a consent gap that regulators consider non-compliant.
3. All Consent Granted by Default
Setting all consent types to 'granted' in the default state defeats the entire purpose. This means tags behave as if full consent was given before the user ever sees a banner. Several DPAs have specifically called out this pattern as a violation.
4. Missing v2 Parameters
Using only ad_storage and analytics_storage without the new ad_user_data and ad_personalization parameters. Since March 2024, this means losing all EU remarketing and audience data in Google Ads.
5. No wait_for_update
Without wait_for_update, Google tags fire immediately with the default (denied) state and do not wait for the CMP to load. If a returning user has previously granted consent, their preference is ignored until the CMP catches up, losing data.
6. Missing Region Parameter
Applying denied defaults globally when they should only apply to EU/EEA regions. This unnecessarily reduces data collection for non-EU users who don’t require consent banners, degrading analytics quality for no compliance benefit.
7. No URL Passthrough
Failing to enable url_passthrough means losing all cross-domain attribution when consent is denied. With passthrough enabled, Google appends gclid and dclid to URLs instead of cookies, preserving campaign attribution.
8. No Ads Data Redaction
When ads_data_redaction is not set to true, ad click identifiers may still be sent in requests even when ad_storage is denied. Enabling redaction ensures no ad-related identifiers leak when consent is not given.
For a practical guide on getting cookie consent right, see our analytics cookie consent guide. If you’re considering dropping consent complexity entirely, our migration guide from Google Analytics walks through the process step by step. Our Consent Impact Dashboard can help you quantify how much analytics data your consent setup is costing you.
The Privacy-First Alternative
Here’s a perspective that the Consent Mode documentation won’t tell you: the entire consent initialization problem disappears when you use cookieless analytics. Tools like Plausible, Fathom, and Simple Analytics don’t set cookies, don’t use persistent identifiers, and don’t require consent banners in most jurisdictions.
Why Consent Mode Exists in the First Place
Consent Mode is fundamentally a workaround. Google Analytics uses cookies to track users across sessions, which requires consent under GDPR, ePrivacy Directive, and now the Digital Markets Act. Rather than remove the cookies, Google created a layer of complexity that lets their tags operate in a “reduced functionality” mode when consent is denied. You then need a CMP to manage consent states, a properly configured GTM container, and ongoing auditing to ensure nothing breaks.
Privacy-first analytics tools took a different approach: they designed their tracking to not require consent in the first place. No cookies means no consent banner, no Consent Mode initialization, no CMP integration, no wait_for_update timing issues, and no risk of firing tags before consent is obtained.
What You Actually Gain
By switching to a cookieless analytics tool, you eliminate an entire category of compliance risk. There is no consent initialization code to audit, no GTM container timing to debug, and no region-specific consent defaults to maintain. Your analytics script loads and works the same way for every visitor, everywhere. The data you collect is inherently privacy-compliant because it never contained personal data to begin with.
This doesn’t mean you lose analytical depth. Modern cookieless tools provide campaign attribution (via cookieless attribution models and UTM parameters), conversion tracking, funnel analysis, and real-time dashboards. What you lose is cross-session user tracking, which is increasingly unreliable anyway due to browser restrictions on third-party cookies, ITP, and ad blockers.
For a detailed feature comparison, see our Plausible vs. Fathom vs. Matomo comparison. If you’re evaluating alternatives, our Google Analytics alternatives guide covers the full landscape of privacy-respecting options, including self-hosted solutions for teams that need to keep data on their own infrastructure.
You can also explore privacy-enhancing technologies that go beyond analytics to protect user data across your entire stack.
Frequently Asked Questions
region parameter, you can apply denied defaults only to regulated regions while keeping granted defaults elsewhere, maximizing data collection while staying compliant.dataLayer. The key is ensuring your CMP fires gtag('consent', 'update', ...) with all v2 parameters when the user makes a choice.dataLayer to inspect consent events. Google’s Tag Assistant (tagassistant.google.com) shows consent state changes in real-time. Also check the Network tab: when consent is denied, Google requests should include gcs=G100 (all denied) rather than gcs=G111 (all granted). Our GA4 privacy audit guide has a complete testing checklist.wait_for_update parameter introduces a brief delay (typically 500ms) before tags fire, waiting for the CMP to load. In practice, this delay is negligible because the CMP itself needs time to render the consent banner. The bigger performance concern is the CMP itself, which often adds 50-150KB of JavaScript. Privacy-first analytics tools like Plausible (under 1KB) eliminate this overhead entirely.denied and never update them, which means Google tags only send cookieless pings. You get behavioral modeling but no actual user-level data. More practically, you could build a custom consent banner that calls gtag('consent', 'update', ...) on user interaction. However, regulatory requirements for consent banners are complex (clear language, equal prominence for accept/reject, record-keeping), so using a certified CMP is strongly recommended.url_passthrough preserves ad click information (gclid, dclid) by appending them to URLs when navigating between pages, instead of storing them in cookies. This maintains campaign attribution even when ad_storage is denied. ads_data_redaction goes further: when enabled and ad_storage is denied, it removes ad click identifiers from all Google tag requests entirely. They serve different purposes: passthrough preserves attribution data, while redaction ensures no ad identifiers leak when consent is not given.Ready to simplify your analytics compliance?
Learn how privacy-first analytics eliminates the need for consent mode entirely.
Read Our Privacy Analytics Guide →Related resources