Can gcs parameter decoded: what g100, g110, g111 mean in ga4 hits be caused by consent timing instead of a tag bug?

Yes. Many consent-related issues come from when the signal arrives, not whether the setting exists in the interface. Browser-level validation matters more than screenshots of the CMP setup.

Should I test this only in GA4 reports?

No. Start in the browser first, then confirm the reporting impact in GA4. Otherwise you may confuse modeled-data shifts with broken implementation.

What is the fastest way to prevent this from happening again?

Create a repeatable QA step for banner changes, region logic, and container releases so consent behavior is validated before it reaches production users.

GCS Parameter Decoded: What G100, G110, G111 Mean in GA4 Hits

What does the GCS parameter mean?

The gcs parameter in GA4 network requests encodes the user's consent state for two of the four Consent Mode signals. Format: G1xy where G1 is constant, x is ad_storage (0=denied, 1=granted), y is analytics_storage (0=denied, 1=granted).

So gcs=G100 means consent set but both denied (only possible in Advanced Consent Mode), gcs=G110 means ad-only granted, gcs=G111 means both granted, gcs=G101 means analytics-only granted. The gcs parameter only covers ad_storage and analytics_storage — the V2-specific signals (ad_user_data, ad_personalization) are encoded in a separate gcd parameter.

This page is the complete reference. Bookmark it.

The full reference table

`gcs` value	`ad_storage`	`analytics_storage`	When you see this
`G100`	Denied	Denied	Advanced Consent Mode, both consents denied (cookieless ping)
`G101`	Denied	Granted	User accepted analytics only, declined ads
`G110`	Granted	Denied	User accepted ads only, declined analytics
`G111`	Granted	Granted	User accepted all (the most common state on healthy properties)
(parameter missing)	n/a	n/a	Consent Mode is not installed at all

The G1 prefix is constant — it indicates this is a Consent Mode parameter. The first 1 doesn't carry consent information by itself; treat G1 as the prefix and the next two digits as the actual signal.

Important: G100 is only possible in Advanced Consent Mode. In Basic mode, no hits fire at all when consent is denied — so gcs=G100 simply never appears. If you see G100 in your network requests, you know two things at once: Consent Mode V1+ is installed AND you're running Advanced mode.

How to find `gcs` in DevTools

Open Chrome DevTools (F12)
Network tab
Filter for collect (catches both GA4 and Google Ads)
Click any request to region1.google-analytics.com/g/collect or similar
Scroll the request URL to find &gcs=G1xy

The parameter appears as a query string component on every collect call when Consent Mode is active. If you can't find it, the implementation isn't running Consent Mode at all — see the diagnostic section below.

What `gcs` does NOT cover

This is the most common point of confusion. gcs covers only ad_storage and analytics_storage. It does NOT encode:

ad_user_data (V2 signal — required for Google Ads measurement in EU/UK since March 2024)
ad_personalization (V2 signal — required for remarketing list eligibility)

Those two V2 signals are encoded in a separate parameter called gcd. If you only check gcs and ignore gcd, you can have a "passing" implementation that's silently broken for Google Ads measurement.

The `gcd` parameter — what it adds

gcd is the V2-specific consent signal. It's present in every hit to Google services, even when Consent Mode isn't fully active. It encodes all four signals plus information about how the consent state was generated.

The format:

Reading this:

Starts with 11 — header constant
One character per signal in order: ad_storage, analytics_storage, ad_user_data, ad_personalization
Each signal separated by 1
Ends with 5 — terminator

Possible values for each signal position (per Simo Ahava's reverse-engineering, still current in 2026):

Value	Meaning
`q`	Denied
`p`	Granted
`r`	Denied default + granted update
`l`	Denied default + denied with explicit signal

So gcd=11p1p1p1p5 means all four granted; gcd=11q1q1q1q5 means all four denied; mixed values (e.g. 11p1p1q1q5) mean ad cookies and analytics granted but ad_user_data and ad_personalization denied — common state for users who accept analytics but decline targeted ads.

Need to validate whether consent timing is distorting your GA4 data?

Audit consent setup

How `gcs` and `gcd` relate

The relationship matters for diagnosing what's broken:

Pattern	Diagnosis
`gcs` present + `gcd` present	Consent Mode V2 working correctly
`gcs` present + `gcd` missing	V1-only implementation — needs upgrade to V2
`gcs` missing + `gcd` present	Unusual; possibly a server-side transformation is stripping `gcs`
Both missing	Consent Mode not implemented at all

The most common audit finding in late 2025 / early 2026 is the second row — properties with gcs working perfectly that haven't upgraded to V2 and are silently losing Google Ads attribution in the EU/UK.

Cookieless pings — what they actually contain

When gcs=G100 (Advanced mode, all denied) and a hit fires anyway, that's a cookieless ping. Stakeholders often ask what's in it. The honest answer:

Cookieless pings contain:

Event name (page_view, purchase, etc.)
Page URL and referrer
Screen resolution
Timestamp
The gcs parameter showing denied state
The gcd parameter showing denied state for all signals

They do NOT contain:

client_id (no GA cookie generated)
user_id
_ga cookie value
Any persistent identifier
IP address (anonymised by GA4 default)

Their purpose: feed Google's conversion modelling pipeline so the consent-denied portion of your traffic can be modelled rather than completely lost. The 1,000 daily ad clicks per domain over 7 days threshold (combined with Advanced mode + Blended reporting identity) activates the modelling.

Where else `gcs` appears

gcs isn't limited to GA4 collect requests. It's also added to:

Google Ads conversion tags (googleads.g.doubleclick.net)
Floodlight tags (DV360)
Google Tag (gtag.js) requests to all Google services
Server-side container outbound requests to Google services (when configured)

This means filtering DevTools for collect only shows you GA4. To see the full picture, filter for gcs= in DevTools' Network tab — that catches every Google service receiving the consent signal.

Region-specific behaviour

gcs and gcd behave the same across regions, but consent enforcement differs:

EEA / UK / Switzerland: Consent Mode V2 required for Google Ads measurement and remarketing since March 2024. gcd must be present and correct.
United States: Not required by Google, but recommended. State laws (CCPA, CPRA, Colorado CPA, Virginia VCDPA) increasingly require opt-out flows that V2's ad_user_data/ad_personalization signals naturally support.
Rest of world: Not required. Most properties still implement V2 for global consistency.

The region parameter in your consent_default command lets you scope different defaults to different regions — e.g., denied-by-default for EEA users, granted-by-default for everywhere else. The gcs and gcd values then reflect the regional default.

What stakeholders need to understand

Translating gcs into business language for non-technical stakeholders:

Most healthy properties run 60–80% G111 (both granted) and 20–40% G100 (both denied), with small percentages of partial states. This is the consent rate distribution from a typical European property.
Sites with strong consent UX run 75–85% G111. Below 50% G111 indicates either a heavy reject-all UX, a privacy-conscious audience, or a banner that's confusing users into rejecting.
Anything above 85% G111 is suspicious — usually indicates either an implementation error (defaults set to granted, violating GDPR), a banner with no real reject option, or a US-only audience.

This distribution becomes the consent KPI for ongoing measurement: track the G111 share monthly, investigate any sustained drop of more than 5 percentage points, and use it as a leading indicator for the conversion-modelling threshold.