The most reliable way to verify a Consent Mode implementation is to inspect the network parameters the browser sends to Google, rather than relying on the CMP’s admin interface. CMP dashboards report what the CMP believes it is doing; network parameters show what is actually sent. When these diverge, the network parameters are the source of truth.
Finding the Requests
Open your browser’s Developer Tools, go to the Network tab, and filter for requests to:
/g/collect(GA4 measurement protocol)google-analytics.com/g/collectgoogleads.g.doubleclick.net(Google Ads)
Each request carries consent state as query parameters. Look for &gcs= and &gcd= in the URL or request payload.
The gcs Parameter (v1 Consent State)
The gcs parameter encodes the original two consent parameters in a compact format: G1xy
| Value | ad_storage | analytics_storage | Meaning |
|---|---|---|---|
G111 | granted | granted | Full consent |
G110 | granted | denied | Ad cookies allowed, analytics blocked |
G101 | denied | granted | Analytics only |
G100 | denied | denied | Everything denied |
A gcs=G100 request can only appear in Advanced mode. In Basic mode, no request would fire at all when both parameters are denied. If you see G100 in your network requests, you’re running Advanced mode and the user has declined consent.
If you don’t see the gcs parameter at all, the consent default command isn’t firing before the measurement request. Tags are operating without consent awareness — the most dangerous failure state because it looks like everything is working.
The gcd Parameter (v2 Consent Detail)
This is the v2-specific parameter that encodes all four consent signals along with information about the consent journey. The gcd parameter is a string with positional characters, each representing a consent parameter’s state and how it got there.
Each position’s letter indicates the consent trajectory:
| Letter | Meaning |
|---|---|
l | Default denied, no update received |
q | Default denied, then updated to granted |
t | Default granted, no update received |
p | Default granted, then updated (various states) |
r | Other intermediate states |
Reading the Parameter
The gcd parameter encodes the four consent signals in a structured string. Each signal gets a position with its journey letter. The exact format uses numbered positions separated by characters:
For a correctly configured Advanced mode page load before the user interacts with the banner, you should see l values (default denied, no update). This means defaults are set and the user hasn’t responded yet.
After the user accepts all consent, the values should change to q (default denied, then updated to granted). This confirms the full consent flow: default denied -> CMP update -> granted.
What the Letters Tell You
Seeing t (default granted, no update) means one of two things:
- Your defaults aren’t set to
deniedfor that user’s region. The parameter was never denied, so granting it is the default state. - You don’t have a consent default command firing at all, and the parameter was never explicitly set.
Either way, t for EEA/UK traffic is a red flag. It means consent wasn’t properly obtained before measurement began.
Seeing l (default denied, no update) after the user has clicked Accept means your CMP isn’t firing the consent update call. The default denied state was set, but the CMP’s accept action didn’t trigger gtag('consent', 'update', ...). This is the “visual compliance without technical compliance” failure: the banner works, the cookie is stored, but Google tags never learn consent was granted.
Seeing q (default denied, then updated to granted) is the correct state after a user accepts consent in a properly configured implementation. It confirms: defaults were set to denied, the CMP fired an update, and consent is now granted.
Verification Workflow
A systematic verification covers four consent states:
1. Initial page load (before banner interaction)
- Filter network requests, find a
/g/collectping - Confirm
gcs=G100(both denied in Advanced mode, or no request in Basic mode) - Confirm
gcdshowslvalues for all four parameters - If
gcsis missing or showsG111, defaults aren’t set correctly
2. After accepting all consent
- Click Accept on the banner
- Find the next
/g/collectrequest - Confirm
gcs=G111(both granted) - Confirm
gcdshowsqvalues (denied then updated to granted) - If
gcdshowsqfor only two parameters, the CMP is sending v1 updates only
3. After declining consent
- Clear cookies, reload, click Reject
- In Advanced mode: confirm requests fire with
gcs=G100 - In Basic mode: confirm no requests fire at all
- Check
gcdshowslvalues (denied, no update — the “deny” action shouldn’t trigger an update to granted)
4. After partial consent
- If your CMP supports granular choices, grant analytics but deny advertising
- Confirm
gcs=G101(ad_storage denied, analytics_storage granted) - Confirm
gcdshowsqfor analytics parameters andlfor advertising parameters
Tools
Consent Mode Inspector Chrome extension — Provides a real-time overlay showing consent state and history without digging through network requests. Particularly useful for verifying state transitions: you can see the timeline of default -> update calls and confirm all four v2 parameters are present.
Google Tag Assistant Preview mode — The Consent Tab shows consent state for each event in the GTM container. Verify that ad_user_data and ad_personalization are listed as separate parameters. If only ad_storage and analytics_storage appear, your implementation is still running v1 regardless of what your CMP claims.
Browser Developer Tools — The manual approach described above. More work, but also the most trustworthy: you’re looking at raw HTTP requests, not an abstraction layer’s interpretation of them.
Common Debugging Patterns
All parameters show t for EEA traffic: Your consent default command isn’t firing, or it’s firing after tags have already evaluated consent. Check the trigger ordering — the default must be in Consent Initialization, not Initialization or All Pages.
Two parameters show q, two show l after accepting: Your CMP is sending v1 updates only. Update the CMP configuration to include ad_user_data and ad_personalization in the consent update call.
No gcs or gcd parameters at all: The gtag consent API isn’t loaded, or your tag implementation bypasses it entirely. This often happens with duplicate tag implementations where tags exist both in GTM and in the site’s HTML header.
Values change on navigation but reset on refresh: The CMP is setting consent state on the current page but not persisting it. The stored consent cookie is either not being set or not being read on subsequent page loads. Check CMP cookie configuration and domain settings.