
How to read the gcd parameter in Google Consent Mode v2
You open your browser's developer tools, filter by g/collect and spot a long
parameter: gcd=11r1r1r1r5. It doesn't look like the gcs=G111 you already know.
It's the gcd parameter — the most complete diagnostic tool Consent Mode v2
offers, and the one that has replaced gcs as the primary reference since 2025.
What is the gcd parameter
gcd stands for Google Consent Data. Unlike gcs (which only encodes two
permissions in 4 characters), gcd encodes all four Consent Mode v2
permissions along with how each state was reached: the default value, the
user's update, or both.
The gcd is sent with every request to Google, whether Consent Mode is
active or not. This makes it the most reliable signal for understanding what's
happening with consent on your site.
The gcd format: what each position means
The gcd value is a string with a fixed format:
11{signal1}1{signal2}1{signal3}1{signal4}5
The 11 at the start and 1 between each signal are fixed separators (they
don't change). The 5 at the end is a closing value. What matters are the
letters in the 4 signal positions:
| Position | Signal | What it controls |
|---|---|---|
| 1 | ad_storage | Advertising cookies (conversions, remarketing) |
| 2 | analytics_storage | Analytics cookies (GA4) |
| 3 | ad_user_data | Permission to send user data to Google |
| 4 | ad_personalization | Permission for personalization and remarketing |
Each letter encodes the full trajectory of consent for that signal: what was declared by default and what the user decided afterward.
The 9 letter codes: the alphabet of consent
The letters aren't random. They follow an alphabetical pattern across two dimensions: what was declared by default (column) and what the user did afterward (row).
Group 1: l, m, n — No default recorded
| Letter | Default | Update | Meaning |
|---|---|---|---|
l | (none) | (none) | Consent Mode didn't set a default or update. |
m | (none) | Denied | No default, user explicitly denied. |
n | (none) | Granted | No default, user explicitly granted. |
Group 2: p, q, r — Default denied (most common)
| Letter | Default | Update | Meaning |
|---|---|---|---|
p | Denied | (none) | Default denied, user hasn't decided yet. |
q | Denied | Denied | Default denied, user confirmed denial. |
r | Denied | Granted | Default denied, user granted afterward. ✅ |
Group 3: t, u, v — Default granted
| Letter | Default | Update | Meaning |
|---|---|---|---|
t | Granted | (none) | Default granted, no user update. |
u | Granted | Denied | Default granted, user denied afterward. |
v | Granted | Granted | Default granted, user confirmed grant. |
Memory trick: within each group of 3 letters, the first is "no update", the second is "update to denied", the third is "update to granted".
Practical examples: how to read a gcd
Before the user interacts (advanced mode)
gcd=11p1p1p1p5
All 4 letters are p: default denied, no update. This is correct in advanced
mode — tags load with a denied default state and send cookieless pings until
the user decides.
User accepts everything
gcd=11r1r1r1r5
All 4 letters are r: default denied → update granted. This is the ideal flow
when the user accepts all categories. Each signal went from denied to granted
via the banner update.
User rejects everything
gcd=11q1q1q1q5
All 4 letters are q: default denied → update denied. The user explicitly
rejected. Cookieless pings still travel (advanced mode), but without cookies.
Partial selection: analytics yes, advertising no
gcd=11q1r1q1r5
Position 1 (ad_storage): q — denied → denied.
Position 2 (analytics_storage): r — denied → granted.
Position 3 (ad_user_data): q — denied → denied.
Position 4 (ad_personalization): r — denied → granted.
This means the user accepted analytics and data, but rejected advertising and personalization.
Default granted without update (incorrect configuration)
gcd=11t1t1t1t5
All 4 letters are t: default granted, no update. This indicates the default
was declared as granted instead of denied — an implementation error. Advanced
mode requires the default to be denied.
gcs vs gcd: why gcd is better
| Aspect | gcs | gcd |
|---|---|---|
| Permissions | 2 (ad_storage, analytics_storage) | 4 (all Consent Mode v2 signals) |
| Detail | Final state only (granted/denied) | Full trajectory (default + update) |
| Sent | Only with Consent Mode active | Always, with or without Consent Mode |
| Debugging | Basic | Complete |
| Format | G1xy (3-4 chars) | 11l1l1l1l5 (9 chars) |
gcs is still useful for a quick read (G111 = everything granted), but when
you need to debug why something isn't working, gcd tells you the full
story: what was declared, what the user decided, and in what order.
How to verify in Chrome DevTools
- Open Developer Tools (F12 or Cmd+Opt+I).
- Go to the Network tab.
- Filter by
g/collect(GA4 requests) ordoubleclick(Google Ads requests). - Click any request and look for the
gcdparameter in the query string. - Decode the 4 letters using the table above.
What to look for
| State | Expected gcd | What to verify |
|---|---|---|
| Page loaded, no decision yet | 11p1p1p1p5 | Defaults correct (denied) |
| Accepted everything | 11r1r1r1r5 | All 4 signals changed to granted |
| Rejected everything | 11q1q1q1q5 | All 4 signals stayed denied |
| Only accepted analytics | 11q1r1q1r5 | Mix of q and r per choice |
Default set to granted | 11t1t1t1t5 | ⚠️ Error: default must be denied |
Missing 1 separators | Unexpected format | ⚠️ Possible incorrect implementation |
Common errors the gcd reveals
Default set to granted (t, u, v)
If you see letters from the t/u/v group, your Consent Mode snippet declares
granted as the default value. This violates advanced mode: Google expects the
default to be denied and the user to change it to granted via the banner.
Missing ad_user_data or ad_personalization
If positions 3 and 4 show l (no default recorded) while positions 1 and 2 show
p or r, your CMP isn't declaring the mandatory permissions since March 2024.
Google Ads disables ad personalization even if the user accepted.
Update never arrives (p persists after banner)
If after the user accepts the banner the letters remain p (default denied, no
update), your CMP isn't firing gtag('consent', 'update', …). The banner shows
it worked, but the signal never reaches Google.
Inconsistent letter mix
If you see a combination like r1p1r1p5 (some r, some p), it means some
signals were updated and others weren't. This usually happens when the CMP maps
banner categories to Consent Mode parameters incorrectly.
Why it matters
The gcd isn't just a technical detail — it's the proof that your
implementation works:
- Compliance: demonstrates that the default is
deniedand that consent is only granted after an explicit choice, as required by the GDPR. - Modeling: Google needs correct signals in all 4 positions to activate conversion modeling in GA4 and Google Ads.
- Diagnostics: instead of guessing why the numbers don't add up, you read directly what's happening in each request.
- Audit: a privacy officer or auditor can verify compliance by inspecting
the
gcdin network requests.
How Conma solves it
Conma declares all 4 permissions as denied by default, synchronously, before
any Google tag runs. When the user decides, it updates the state in under 500 ms.
The result in the Network tab:
gcd=11r1r1r1r5
All 4 signals show r (denied → granted): the complete, correct flow, ready for
audit. If you need an implementation that always arrives in the right order, read
our guide to comply with Google Consent Mode v2.