Debugging Consent Mode V2: gcs, gcd and the violations nobody catches

Consent Mode V2 is easy to install and hard to verify. The banner says one thing, the tags do another, and the only honest source of truth is the traffic leaving the browser. Here is how to read it.

The gcs parameter

Every Google hit carries gcs, a four-character code such as G111. The first two characters are a version marker. The third is ad_storage, the fourth is analytics_storage, each either 1 for granted or 0 for denied.

• G111 — both granted.
• G100 — both denied.
• G101 — ads denied, analytics granted. Common after a "reject marketing only" choice.
• G1-- — consent mode is not initialised at all. If you see this on a site with a banner, the banner and the tags are not talking to each other.

The gcd parameter

gcs only covers two signals; V2 has four. gcd covers all of them — ad_storage, analytics_storage, ad_user_data and ad_personalization — and, crucially, encodes how each state was reached. A letter says both the value and whether it came from your default configuration or from a user action.

That distinction is the one that matters in an audit. A granted state that was never updated by the user is not consent; it is a default that happens to be permissive. If every signal in gcd shows granted with no update recorded, your implementation is very likely defaulting to granted before anyone clicks anything — which is exactly what regulators look for.

The blind spot: everyone who is not Google

Consent Mode is a Google mechanism. Meta, TikTok, LinkedIn, Criteo, Adform and the rest do not read gcs; they fire when their own script is loaded. So the failure mode almost nobody tests for is simple and very common:

The user rejects marketing cookies, Google respectfully degrades to cookieless pings — and the Meta pixel sends a full Purchase event anyway, because the CMP blocked the Google tags but not that one script.

This is the check Tag Master automates. It reads the current ad consent state, watches which vendors keep sending, and produces a plain list: these platforms fired while ad_storage was denied. It is not legal advice, but it is the fastest way to find the tag your CMP forgot.

A practical audit routine

1. Open the site in a fresh profile or incognito window so no prior consent is stored.
2. Open the panel, reload, and look at hits fired before you touch the banner. Anything with real event data here is firing pre-consent.
3. Reject everything. Check the consent panel: all four signals should read denied.
4. Browse, add to cart, complete a test purchase. Now check the violation list — any vendor named there ignored the rejection.
5. Accept everything and confirm the signals flip to granted and hits resume normally. If they do not, your update call is not reaching the tags.

Common causes when something is wrong

• Tags loaded outside GTM. A pixel hardcoded in the theme never sees your consent triggers.
• Wrong consent category in the CMP. A vendor classified as "functional" fires before the marketing decision.
• No wait-for-update. Tags fire in the milliseconds before the banner initialises.
• Server-side relaying. The browser respects consent, then the server sends the event anyway, because the consent signal was not forwarded.

Doing this in the panel →

The rest of this group: Consent and blocking

• Testing tracking without polluting production analytics

More in Consent and blocking