What violations does the scanner check for Google Consent Mode v2?

Analytics Proof checks for 10 specific Google Consent Mode v2 violation types. Here's what each code means and how to fix it:

Violation Codes

GCM_001 — Missing consent default (High)

The gtag('consent', 'default', {...}) command is not present before GTM or GA4 initializes.

Fix: Add this snippet before your GTM container loads:

gtag('consent', 'default', {
  'ad_storage': 'denied',
  'ad_user_data': 'denied',
  'ad_personalization': 'denied',
  'analytics_storage': 'denied'
});

GCM_002 — Tracking cookies before consent (Critical)

Tracking cookies like _ga, _fbp, or _ttp were set before any consent default was established.

Fix: Ensure your GTM/GA4 scripts load only after the consent default is set. The consent default should deny all storage types initially.

GCM_003 — Missing consent update (High)

After the user clicked accept or reject on the consent banner, no consent update command was detected.

Fix: Configure your CMP to call gtag('consent', 'update', {...}) when the user makes a choice. Most CMPs (OneTrust, Cookiebot, etc.) have a Google Consent Mode integration — make sure it's enabled.

GCM_004 — Consent state mismatch (Critical)

The consent update values don't match the user's action. For example, the user clicked "reject" but ad_storage was set to granted.

Fix: Verify your CMP maps the accept button to granted and the reject button to denied for all consent types.

GCM_005 — Tracking cookies after reject (Critical)

New tracking cookies were created after the user rejected consent.

Fix: This usually means a vendor script is ignoring consent state. Check that all tracking tags in GTM have consent checks enabled, or use Advanced Consent Mode.

GCM_006 — Consent persistence failure (Medium)

After reloading the page, the consent state was not restored.

Fix: Ensure your CMP saves the consent choice to a cookie and restores it on subsequent page loads via a new consent default or consent update command.

GCM_007 — Consent mode state inconsistency (Medium)

The internal consent state (google_tag_data.ics.entries) shows inconsistent values between different consent types.

Fix: Review your CMP configuration to ensure all consent types are updated together in a single consent update call.

GCM_008 — GCS parameter mismatch (Medium)

GA4 requests contain a gcs parameter that doesn't match the current consent state. For example, gcs=G111 (all granted) was sent when consent was denied.

Fix: This is usually a timing issue. Ensure consent updates propagate to GA4 before new requests fire.

GCM_009 — Non-compliant vendors before consent (High)

Analytics or advertising vendors made tracking requests before the user interacted with the consent banner, and those requests were not in compliant cookie-less mode.

Note: The following are considered compliant before consent:

• GTM container loader (gtm.js) and gtag.js library
• GA4 requests with gcs=G100 (Advanced Consent Mode / cookie-less)
• Microsoft Clarity running in cookie-less mode

Fix: Enable Advanced Consent Mode for GA4. For other vendors, delay loading until consent is granted.

GCM_010 — Non-compliant vendors after reject (Critical)

Tracking vendors made non-compliant requests after the user explicitly rejected consent.

Fix: Ensure all tracking tags stop firing when consent is denied. In GTM, use built-in consent checks on every tag.