Your Consent Mode v2 Setup Is Probably Broken — Here's How to Verify It

What Consent Mode v2 Is Supposed to Do

Google Consent Mode v2 sends two parameters with every Google tag request: ad_storage and analytics_storage. Each can be granted or denied. When denied, Google tags adjust their behaviour: GA4 sends cookieless pings, Google Ads does not write conversion cookies, Floodlight does not set audience pixels. The tag still fires, but operates in a privacy-safe mode.

Since March 2024, Consent Mode v2 added two additional parameters: ad_user_data and ad_personalization. These are required for sending user data to Google for advertising purposes in the EEA. Without these signals, your Google Ads remarketing audiences in Europe stop populating.

The theory is clean. The implementation is where it breaks.

Five Consent Mode Failures That Create GDPR Liability

1. Tags Firing Before Consent Is Initialised

This is the most common failure. The GTM container loads and fires tags immediately. The CMP loads asynchronously and updates consent state 200–500ms later. In that window, tags have already fired with the default consent state. If your default is granted (which it is unless you explicitly set it to denied), you just tracked a user without consent.

The fix requires setting the default consent state to denied before any tags fire, using a consent initialization trigger type in GTM. But 60% of implementations we audit have the default set incorrectly or not set at all. The gtag('consent', 'default', ...) call must execute before the GA4 config tag. If it does not, the config tag fires with implicit consent.

// This must run BEFORE any Google tags
gtag('consent', 'default', {
  'ad_storage': 'denied',
  'ad_user_data': 'denied',
  'ad_personalization': 'denied',
  'analytics_storage': 'denied',
  'wait_for_update': 500
});

2. Non-Google Tags Ignoring Consent Mode Entirely

Consent Mode is a Google-specific protocol. Meta Pixel, TikTok Pixel, LinkedIn Insight Tag, Hotjar, Intercom, and every other non-Google tag do not understand ad_storage: denied. They fire regardless. Your CMP is supposed to block these tags entirely when consent is denied, using GTM trigger exceptions or tag sequencing. In practice, most CMPs only configure consent groups for Google tags and leave non-Google tags unmanaged.

We audit 20+ containers per month. In 35% of them, the Meta Pixel fires on every page load regardless of consent state. The pixel does not check consent parameters. It fires because no GTM trigger exception blocks it.

3. Consent State Not Persisting Across Pages

A user grants consent on page 1. The CMP writes the consent state to a cookie. On page 2, the cookie is read and consent state is restored. But if the cookie domain is misconfigured (set to www.example.com instead of .example.com), the cookie is not readable on subdomains. The user navigates to shop.example.com and consent resets to the default denied state. Tags fire in cookieless mode even though the user already consented.

The opposite is also common: the consent cookie expires before the session ends, or a server-side redirect strips cookies, causing consent state to reset mid-journey.

4. CMP Banner Dismissed Without Explicit Choice

Many CMPs allow users to dismiss the banner by scrolling or clicking elsewhere on the page. Some CMPs interpret this as implicit consent. Under GDPR, consent must be “freely given, specific, informed and unambiguous” — a scroll is none of those things. If your CMP treats a banner dismissal as consent and fires tracking tags, you have a compliance violation on every session where the user did not click an explicit accept or reject button.

5. Consent Mode Update Calls Firing at the Wrong Time

When a user clicks “Accept All,” the CMP should call gtag('consent', 'update', { ... }) to change consent state from denied to granted. Google tags then re-fire with full tracking enabled. But if the update call fires after the page’s event tags have already completed, those events are lost. The page view was cookieless. The user is now cookied. But the original page view event was already sent without cookies and cannot be retroactively enriched.

This is especially problematic for single-page applications where the consent update fires once but the user navigates through multiple virtual page views. Only the first page view after consent is properly tracked.

How to Verify Your Implementation

Open Chrome DevTools, go to the Network tab, and filter for requests to google-analytics.com/g/collect. Look at the gcs parameter in the request URL. This encodes the consent state:

• gcs=G100 — analytics_storage denied, ad_storage denied
• gcs=G110 — analytics_storage granted, ad_storage denied
• gcs=G111 — both granted

If you see G111 on the first request before the user has interacted with the CMP banner, your default consent state is wrong. You are tracking without consent.

For non-Google tags, check the Network tab for outbound requests to facebook.com/tr, analytics.tiktok.com, or any other third-party endpoint. If these fire before consent, those tags are unmanaged.

Continuous Consent Verification

Manual verification checks one session, one time. Consent failures are intermittent — they depend on CMP load timing, network conditions, cookie state, and user behaviour. You need automated, continuous verification that monitors consent state on every session and alerts when tags fire outside their consent boundaries.