How to debug Google Consent Mode v2

Why is Google Consent Mode v2 so hard to see in DevTools?

Because none of it is visible where you would look for it. The consent commands never appear as plain objects in the dataLayer, and the state Google tags actually received is compressed into two cryptic request parameters.

Google Consent Mode v2 is invisible plumbing. The default and update commands are pushed into the dataLayer as internal arguments you cannot see by typing dataLayer in the console (gtag pushes them as arguments objects, not plain objects), and the state Google tags actually received is encoded in cryptic request parameters like gcs=G101 and the even denser gcd string. Worse, the CMP and Consent Mode are two separate systems: your CMP can say analytics is granted while the Google-side signal still says denied, and GA4 quietly degrades to cookieless pings. Debugging that with plain DevTools means decoding parameters by hand and guessing at ordering.

Event Watcher captures the default and update pushes as first-class events, decodes gcs/gcd on every Google request, and cross-checks Consent Mode against what your CMP reports, flagging mismatches per event.

What do you need before you start?

Event Watcher installed, DevTools open on the Event Watcher panel, and a session where the banner still appears, because Consent Mode's whole point is the transition from default to update and you want to observe both.

Use a fresh incognito window or clear cookies so the consent banner reappears. Stay in Stream view. The Consent filter chip should be on Auto; you will switch it to Only when you want to isolate consent traffic.

How do you debug Consent Mode v2, step by step?

Watch three things in order: that a consent default push lands before any Google tag traffic, that a consent update follows the banner choice, and that the gcs value on post-update hits matches what the visitor actually granted. The six steps below walk through each check.

1. Load the page without answering the banner. In the stream, look for consent default. It appears as a consent signal event with a teal shield badge. Click it to see the initial state per category: ad_storage, analytics_storage, ad_user_data, ad_personalization.

2. Check ordering. The default command must appear before the first request from GA4, Google Ads, or the gtag / GTM container does any work. If a Google request precedes it, tags ran with no consent instruction at all, a classic implementation bug.
3. Click a pre-consent GA4 request and read the decoded parameters. gcs=G100 means both storage signals denied; G101 analytics only; G111 both granted. The gcd parameter carries the richer v2 signal set, decoded for you.

4. Accept the banner. A consent update push should follow within moments. Click it and confirm every category flipped to granted that the visitor actually granted.
5. Now open any Google request fired after the update and check the detail view's Consent section. It shows the CMP's state and the Google Consent Mode columns side by side, with the required category row in bold and disagreements highlighted. This is where CMP-vs-Consent-Mode wiring bugs surface: the Consent Mode integration in the CMP either fired late, mapped categories wrong, or never fired.
6. Watch for the yellow Consent Mode mismatch badge. It appears when the CMP says a category is granted but the default/update state disagrees at event time. Event Watcher shows it only on requests from Google products that actually read Consent Mode (GA4, Google Ads, Floodlight, GTM) and suppresses it for vendors like Meta or TikTok that ignore Consent Mode entirely, so a mismatch flag is always meaningful.

What does a correct Consent Mode setup look like, and what does a broken one look like?

Correct means exactly one default before any Google traffic and one update right after the banner choice, with the CMP and Consent Mode agreeing on every category afterwards. Broken usually means a missing command, or an ordering problem that leaves tags running on unset consent.

Good: exactly one consent default push, before any Google tag traffic, defaulting everything to denied. One consent update immediately after the banner choice, matching what the visitor selected. Post-update GA4 hits carry gcs=G111 (on full acceptance), and the Consent section shows CMP and Consent Mode agreeing on every category. No yellow mismatch badges.

Bad: no default push at all (tags run with unset consent); Google requests firing before the default; an update that never arrives after acceptance, leaving GA4 on cookieless pings with gcs=G100 while the CMP shows granted (you will see the mismatch badge on every subsequent Google request); or ad_user_data / ad_personalization missing from the update, which breaks Google Ads features even when ad_storage is granted. If GA4 also fires before any choice is made, follow up with the pre-consent GA4 guide.