Most Consent Mode failures are configuration gaps rather than complex technical problems. They’re easy to create during implementation, hard to detect without deliberate testing, and damaging because they silently corrupt data rather than producing visible errors. These ten failures are ordered roughly by how frequently they appear in the wild and how much damage they cause.
1. Missing Default Consent State
The most common failure. If the consent('default', ...) command doesn’t fire before measurement tags load, tags assume consent is granted. Every event fires as if the user consented, regardless of what the CMP banner shows.
Why it happens: The default command is placed in the wrong GTM trigger (using Initialization - All Pages instead of Consent Initialization - All Pages), or it’s placed after the gtag config call in inline code.
Detection: Check the gcs parameter on initial page load before interacting with the banner. If you see G111 instead of G100, defaults aren’t being set. If gcs is missing entirely, the consent API isn’t loaded.
Damage: You’re technically collecting data without proper consent for EEA/UK users. Google’s compliance checks will eventually catch it, and the data from non-compliant periods is unrecoverable.
2. Only Sending v1 Parameters
Implementations that set ad_storage and analytics_storage but omit ad_user_data and ad_personalization. This typically happens with older CMP configurations created before November 2023.
Why it happens: The CMP template was set up for Consent Mode v1 and hasn’t been updated. The CMP fires a consent update, but only includes two of the four required parameters.
Detection: In the gcd parameter, two positions show q (updated to granted) after the user accepts, but the other two show l (default denied, no update). In Google Tag Assistant, only ad_storage and analytics_storage appear in the Consent Tab.
Damage: Conversion tracking appears to work, which is why this failure persists undetected. But Enhanced Conversions data gets silently dropped (because ad_user_data is denied), and remarketing audiences stop building (because ad_personalization is denied). You discover the problem weeks later in Enhanced Conversions diagnostics or when remarketing audience sizes flatline.
3. Consent Signals Not Reaching Server-Side Containers
The web container encodes consent in gcs and gcd HTTP request parameters. If your server-side setup strips or fails to forward these parameters, server-side tags fire without consent awareness.
Why it happens: Intermediate proxies, CDNs, or load balancers modify the request before it reaches the server container. Or the server container has the wrong Client claiming requests, and consent parameters aren’t being parsed.
Detection: In server-side GTM Preview mode, check the incoming request’s event data for gcs and gcd fields. If they’re missing, consent isn’t reaching the server.
Damage: Google tags will still work (they read the encoded parameters from the GA4 Client), but your compliance posture is broken for non-Google vendors. Meta CAPI, TikTok Events API, and LinkedIn CAPI tags fire without consent checks, potentially sending personal data to third parties against the user’s wishes.
4. Region-Specific Consent Not Configured
Setting consent to denied globally (including for US traffic) or granted globally (including for EEA traffic). Both are wrong.
Why it happens: The implementation uses a single default consent command without the region parameter. Teams either default everything to denied (safe but lossy) or granted (dangerous).
Detection: Check consent state for requests from different regions. If US traffic shows G100 on initial load, defaults are too restrictive. If EEA traffic shows G111 before banner interaction, defaults are too permissive.
Damage: Global denied: you lose 100% of measurement data from non-EEA visitors until they explicitly consent, even though consent isn’t legally required in those regions. Global granted: you violate GDPR for every EEA visitor and face enforcement risk.
Fix: Use region-specific defaults. Denied for EEA/GB, granted for US (with appropriate opt-out mechanisms), and a sensible default for the rest of the world.
5. CMP Loaded Without wait_for_update
Tags evaluate consent state before the CMP has a chance to call consent('update', ...). The race condition is timing-dependent, which makes it intermittent and hard to reproduce.
Why it happens: The wait_for_update parameter is omitted from the default consent command. Most CMPs load asynchronously and need 100-500ms to initialize and check for stored consent preferences.
Detection: Intermittent consent failures where some page loads show correct consent and others don’t. Users with slower connections are more affected. The gcd parameter may show l (no update) on some page loads and q (updated) on others for the same consented user.
Damage: Inconsistent measurement. Some page loads capture full data, others capture only cookieless pings (Advanced mode) or nothing (Basic mode). The inconsistency makes the problem hard to quantify.
6. Cookie Banner Without Consent Mode API Wiring
The banner shows, the user clicks Accept, a cookie stores their preference, but no gtag('consent', 'update', ...) call fires. This is visual compliance without technical compliance.
Why it happens: The CMP was installed for legal checkbox compliance, not for technical integration with Google’s measurement stack. The CMP manages cookies and displays a banner but doesn’t integrate with the Consent Mode API.
Detection: After clicking Accept, the gcd parameter still shows l (default denied, no update received). The consent update never fires, so Google tags continue operating in denied mode permanently.
Damage: You’re collecting no usable data from EEA/UK users (Basic mode) or only cookieless pings (Advanced mode), even after they’ve explicitly granted consent. The banner gives the impression of a working system while measurement is fundamentally broken.
7. Duplicate Tag Implementations
Google tags exist both in the site’s HTML header (hardcoded) and inside GTM. The header tags don’t receive consent signals from GTM’s Consent Mode integration.
Why it happens: A developer added gtag.js directly to the site’s <head> section. Later, a marketing team implemented GTM with Consent Mode. The original inline tags were never removed.
Detection: Multiple /g/collect requests for the same event. One set respects consent (from GTM), the other fires unconditionally (from the inline tag). Check the network tab for duplicate measurement IDs.
Damage: Compliance gap (inline tags ignore consent) plus duplicate data in your GA4 property. The duplicate events inflate session counts, page views, and potentially conversions.
8. Case-Sensitive Trigger Conditions in Server-Side GTM
If you named your GA4 Client ga4 but a trigger condition checks for GA4, nothing fires. Server-side GTM trigger conditions are case-sensitive.
Why it happens: Human error during server container configuration. The Client Name is set in one case, trigger conditions reference a different case.
Detection: Tags don’t fire at all in server-side GTM Preview mode. Events arrive at the server container but no tags respond.
Damage: This breaks your entire server-side setup, not just consent. No server-side tags fire, which means no server-side measurement, no CAPI events, nothing.
9. Enhanced Conversions Without ad_user_data Consent
Enhanced Conversions sends hashed personal data (email, phone, address) to Google for identity matching. Without ad_user_data set to granted, Google drops this data server-side.
Why it happens: Enhanced Conversions was implemented and tested in preview mode, where consent states may not reflect real user behavior. The implementation works in testing because preview mode defaults to full consent.
Detection: Enhanced Conversions diagnostics in Google Ads shows no matched data, or match rates are far below expectations. The gcd parameter shows ad_user_data as l (denied) even after consent is granted, indicating the CMP isn’t sending the v2 parameter update.
Damage: Enhanced Conversions provides 5-15% more attributed conversions through identity matching. With ad_user_data denied, that entire matching pipeline is disabled. Your Google Ads optimization runs on less conversion data, leading to worse bidding performance.
10. Not Testing Across Consent States
Testing only the “consent granted” flow. Everything works when you accept all cookies. The question is what happens when you deny, when you partially consent, and when you revoke previously granted consent.
Why it happens: QA processes focus on happy paths. The consent denied state is treated as an edge case rather than the default experience for a significant portion of users.
What to test:
- Full consent: all four parameters granted
- Full denial: all four parameters denied
- Partial consent: analytics granted, advertising denied
- Consent revocation: user changes from granted to denied mid-session
- Return visit: user returns with previously stored consent preference
Each state should produce the expected behavior in both the web container and server-side container. Verify using network parameters, not CMP interfaces.
Most of these failures produce data that looks plausible — sessions appear in GA4, conversions show up in Google Ads, dashboards look normal. The failures are silent: they suppress signals, drop data, or create compliance gaps without visible errors. Reliable detection requires systematic verification of what the browser actually sends, not what the UI reports.