Skip to main content
Cookie Gate
Promotional banner ad for the Penetration Testing Report Kit
Category: Google Consent Mode

gcs Parameter

Also known as: Google Consent Status parameter, gcs signal
Simply put

The gcs parameter is a value that Google adds to tracking requests sent to Google Analytics 4 and other Google tags when Google Consent Mode is in use. It communicates whether the user has consented to certain types of storage, such as for advertising and analytics, allowing Google's tags to adjust their behavior accordingly. It is one signal within a broader consent setup and does not by itself establish that consent was validly obtained under applicable law.

Formal definition

The gcs parameter is an encoded value appended by Google Consent Mode to collect/measurement API requests sent to Google services (for example, GA4). It transmits the consent state specifically for the ad_storage and analytics_storage consent types, using encoded values such as G100 (denied), G101, and similar codes to represent the combination of consent states. The parameter is set automatically by Consent Mode based on the configured consent signals and is interpreted by Google's tags to determine whether cookies/identifiers may be stored or whether cookieless/modeled measurement applies. Per Google's documentation and practitioner analysis, gcs reflects only ad_storage and analytics_storage; the additional consent signals introduced with Consent Mode v2 (such as ad_user_data and ad_personalization) are conveyed through other parameters rather than gcs. As a technical transport of consent state, gcs supports Consent Mode operation but is distinct from, and does not substitute for, meeting the legal standards for valid consent under the ePrivacy Directive's national implementations or the GDPR. The precise mapping of every gcs code and interactions with server-side or advanced Consent Mode implementations may vary and are not fully covered by this definition.

Why it matters

The gcs parameter provides a practical, observable signal that consent state is actually being transmitted to Google's tags. For compliance teams verifying a Google Consent Mode deployment, inspecting the gcs value in outgoing collect requests is one of the more concrete ways to confirm that a consent management platform's decisions are reaching Google Analytics 4 and other Google tags. When the parameter reflects a denied state (for example, an encoded value such as G100), it indicates that Consent Mode is instructing Google's tags to fall back to cookieless or modeled measurement rather than storing identifiers.

At the same time, the presence of a correctly populated gcs parameter should not be mistaken for proof of lawful consent. The gcs value only conveys the consent state that Consent Mode was configured to send; it does not demonstrate that consent was freely given, specific, informed, and unambiguous as required under the GDPR, nor that the ePrivacy Directive's national implementations governing storage on the user's device were satisfied. A gcs value can just as easily reflect a misconfigured banner, a default state, or consent obtained through non-compliant means. Relying on the parameter as evidence of compliance without examining how the underlying consent was collected is a common source of misplaced confidence.

The parameter is also limited in scope. As noted in Google's documentation and practitioner analysis, gcs reflects only the ad_storage and analytics_storage consent types. The additional signals introduced with Consent Mode v2, such as ad_user_data and ad_personalization, are conveyed through other parameters. Teams auditing a v2 implementation should therefore not treat gcs as a complete picture of the consent signals being transmitted, and should be cautious about drawing conclusions from it alone.

Who it's relevant to

Web developers and analytics implementers
Developers configuring Google Consent Mode with GA4 or other Google tags use the gcs parameter as a diagnostic checkpoint. Inspecting the value in outgoing collect requests helps confirm that the consent management platform's decisions are being translated into the signals Google's tags expect, and helps identify misconfigurations before they affect measurement behavior.
Privacy officers and compliance auditors
Those reviewing a Consent Mode deployment can use the gcs parameter to verify that consent state is being transmitted, but should treat it as supporting evidence only. The parameter does not establish that consent met the legal standards under the GDPR or the ePrivacy Directive's national implementations, so auditors still need to examine how consent was collected and recorded.
Consent management platform integrators
Teams connecting a CMP to Google Consent Mode need to understand that gcs reflects only the ad_storage and analytics_storage consent types. For Consent Mode v2, additional signals such as ad_user_data and ad_personalization are conveyed through other parameters, so integrators should validate the full set of signals rather than relying on gcs alone.

Inside gcs Parameter

GCS String Format
The gcs parameter carries a Google Consent Signal expressed as a short numeric string (for example, beginning with G1 followed by digits) that Google tags and pixels append to outgoing requests to communicate the user's consent state for measurement and advertising purposes.
Consent State Digits
The digits following the version prefix encode the granted or denied status for the relevant consent types, allowing Google's services to interpret whether the user has permitted certain processing. The exact digit-by-digit meaning depends on Google's own documentation and may change over time.
Relationship to Google Consent Mode
The gcs parameter is generated as part of Google Consent Mode, the mechanism through which a website communicates a user's consent choices to Google tags. Its value typically reflects the consent state that a consent management platform (CMP) or the site's own logic has passed to Consent Mode.
Scope of Signal
The parameter conveys a snapshot of consent status for Google's advertising and analytics functions. It is a signal about consent, not itself the legal record of consent, and does not by itself establish that valid consent was obtained under any applicable law.

Common questions

Answers to the questions practitioners most commonly ask about gcs Parameter.

Does the gcs parameter itself set or store cookies, or otherwise satisfy consent obligations?
No. The gcs parameter is a status indicator appended to outgoing requests that communicates the consent state Google's tags observed at the time of the request; it does not itself place or access information on a user's device, and it does not constitute or replace valid consent. Under the ePrivacy Directive and its national implementations, the lawfulness of placing or reading cookies depends on obtaining prior consent (where required), and under the GDPR any resulting personal data processing needs its own valid basis. The gcs value merely reflects a consent decision that must have been made elsewhere through a compliant consent mechanism; it is not evidence that such a mechanism was lawful.
Does a gcs value showing consent granted prove that valid, compliant consent was collected?
Not on its own. The gcs parameter reports the consent state passed to Google's tags, but it does not verify how that state was obtained. Valid consent in most EU jurisdictions must be freely given, specific, informed, and unambiguous through a clear affirmative action, and a gcs value cannot demonstrate that those standards were met. It also does not serve as your consent record for accountability purposes. Treat the parameter as a technical reflection of an upstream decision rather than as proof of compliance, and rely on your consent management platform's logs and your own records for evidence.
Where can I actually see the gcs parameter to check what value is being sent?
The gcs value can generally be observed in the network requests sent to Google endpoints, which you can inspect using your browser's developer tools (the network tab) or a tag debugging or proxy tool. You would typically look at outgoing hits from Google tags and locate the gcs parameter in the request URL or payload. Keep in mind that what you see reflects the consent state at the moment of that specific request, so testing should cover different consent scenarios. The exact structure and encoding of the value is defined by Google and may change, so treat any observed format as subject to updates.
How does the gcs parameter relate to Google Consent Mode settings?
The gcs value is generally derived from the consent states configured through Google Consent Mode, which is the mechanism by which consent signals (such as those for analytics and advertising storage) are passed to Google tags. In practice, the consent signals your CMP communicates to Consent Mode are what determine the gcs value transmitted with requests. Because of this dependency, misconfiguration of your CMP-to-Consent-Mode integration can produce gcs values that do not accurately reflect the user's actual choices. The precise mapping between consent parameters and the encoded gcs value is defined by Google and may evolve, so verify behaviour against current Google documentation.
What should I do if the gcs value does not match the consent choice a user made?
A mismatch typically points to an integration issue between your consent management platform and the way consent signals are passed to Google's tags, rather than a problem with the parameter itself. You would generally review the timing of when consent signals are set relative to when tags fire, confirm that your CMP is correctly updating consent states, and check for default consent settings that may apply before a user interacts. Because an inaccurate gcs value can mean tags behave inconsistently with the user's actual choice, resolving such discrepancies is important for aligning technical behaviour with the consent you rely on. This is a technical diagnostic exercise and does not by itself resolve the separate legal question of whether your consent collection is compliant.
Is monitoring the gcs parameter enough to demonstrate accountability for cookie consent?
No. Observing gcs values can help you verify that consent signals are being transmitted as expected, which is a useful part of technical testing, but it is not a substitute for the consent records and logging that accountability obligations under the GDPR generally require. The parameter reflects a state at a point in time and is not designed to serve as an auditable record of who consented, to what, and when. For record-keeping you should rely on your consent management platform's logging and your own documentation, and you should not treat the presence of gcs values as evidence that your overall approach meets legal requirements, which depends on facts beyond the scope of this parameter.

Common misconceptions

The presence of a gcs parameter proves that valid consent was collected.
The gcs parameter merely transmits a consent state that upstream logic supplied; it does not demonstrate that consent met the standard of being freely given, specific, informed, and unambiguous required under the GDPR in the EU, nor that it satisfies opt-out expectations under US state laws. The parameter is a signal, not a consent record, and it does not replace the CMP's own consent logs or your legal assessment.
Configuring Google Consent Mode and sending gcs signals makes a site compliant.
Consent Mode and the gcs parameter are technical measures that help align Google tags with a user's choices, but they do not by themselves ensure compliance. Compliance still depends on obtaining valid consent where required (generally prior, opt-in consent in most EU jurisdictions before non-essential cookies or similar technologies are used) and on meeting the separate obligations of the ePrivacy rules governing device storage and access and the GDPR governing any resulting processing of personal data.
The gcs parameter reflects the complete legal consent picture for all trackers on a page.
The gcs parameter relates specifically to Google's consent signaling for its own tags and services. It does not govern or evidence consent for third-party pixels, SDKs, local storage, or fingerprinting from other vendors, which are subject to the same consent rules but are handled through their own mechanisms.

Best practices

Treat the gcs parameter as a diagnostic signal rather than a compliance record, and rely on your CMP's dedicated consent logging to demonstrate that consent was obtained where required.
Verify that the consent state passed to Google Consent Mode accurately mirrors the choices captured by your CMP, so the gcs value does not misrepresent the user's actual selection.
Confirm that non-essential Google tags do not fire, or fire only in a suitably restricted mode, before consent is given in jurisdictions such as the EU and UK where prior consent is generally required for non-essential cookies and similar technologies.
Consult Google's current documentation for the meaning of the gcs string values rather than assuming a fixed interpretation, since the encoding may evolve.
Assess consent obligations separately for the ePrivacy dimension (placing or accessing information on the device) and the GDPR dimension (processing personal data), and do not treat a populated gcs parameter as satisfying either.
Extend your consent governance beyond Google's signals to cover other vendors' pixels, SDKs, local storage, and fingerprinting, which fall under the same rules but are not represented by the gcs parameter.
Promotional banner for the Pentest Readiness checklist download