Skip to main content
Cookie Gate
Commerce Security logo, "All 12 PCI DSS Requirements in Plain English," "Get it now for free," "Complete Survival Guide" and a button toclick to get it
Category: Google Consent Mode

gcd Parameter

Also known as: gcd, Google Consent Data parameter
Simply put

The gcd parameter is a piece of data that Google's tags attach to the network requests they send to Google services, such as Google Analytics and Google Ads. It carries information about a user's consent choices as expressed through Google Consent Mode. Unlike some other signals, it is generally included in every hit to Google services, whether or not consent mode is active.

Formal definition

The gcd parameter is a query parameter appended to hits sent to Google services (for example Google Analytics 4 and Google Ads) when Google Consent Mode is in use. According to vendor and practitioner documentation, it encodes the statuses of all four Consent Mode v2 signals (typically ad_storage, analytics_storage, ad_user_data, and ad_personalization), whereas the related gcs parameter reflects only ad_storage and analytics_storage. Sources indicate that gcd is included in all hits to Google services regardless of whether consent mode is active, and its encoded values can be inspected using tools that decode gcs and gcd from network requests. This entry describes the parameter's reported technical role only; it does not establish that transmitting these signals satisfies consent obligations under the ePrivacy rules governing storage of and access to information on a device, or under the GDPR governing subsequent processing of personal data, which require separate legal assessment. The precise encoding scheme and its interpretation may evolve as Google updates its tagging and Consent Mode implementations.

Why it matters

The gcd parameter is one of the practical signals through which a website's consent decisions are actually communicated to Google's services. When privacy teams configure Google Consent Mode to reflect a user's choices, the gcd parameter is what carries the encoded statuses of the underlying Consent Mode v2 signals on hits to services such as Google Analytics 4 and Google Ads. For compliance and analytics professionals, this makes gcd an important verification point: inspecting the parameter helps confirm whether the consent states surfaced in the browser are being transmitted to Google as intended, rather than assuming the configuration works simply because a consent banner is present.

Because gcd is reportedly included in all hits to Google services regardless of whether consent mode is active, it can appear on requests even in scenarios where practitioners might not expect it. This is significant when auditing an implementation, because the mere presence of the parameter does not by itself indicate that valid consent was obtained or that any storage or processing is lawful. Under the ePrivacy rules governing the placing of and access to information on a device, and under the GDPR governing the subsequent processing of any personal data, the legal question of whether a given tag may fire, and on what basis, remains a separate assessment from whatever the gcd parameter reports.

Misreading this distinction is a common source of risk. Teams may treat the transmission of consent signals as evidence of compliance, when in fact the parameter only reflects what Google's tagging was told about the user's choices. Verifying that gcd accurately mirrors the consent recorded by the consent management platform is a useful technical control, but it does not replace legal review of consent quality, geographic scope, and record-keeping obligations, which differ across the EU, the UK, and individual US state regimes.

Who it's relevant to

Web developers and tag managers
Those responsible for implementing Google Tag Manager, GA4, or Google Ads tagging use the gcd parameter as a verification point to confirm that configured Consent Mode v2 signals are actually being transmitted on hits to Google services. Inspecting decoded gcd values helps identify misconfigurations between the consent management platform and Google's tags.
Privacy officers and data protection professionals
Practitioners auditing a Google Consent Mode deployment can reference gcd to check whether the consent states recorded in the browser match what is sent to Google. They should keep in mind that the presence or content of the parameter does not by itself demonstrate that consent is valid or that storage and processing are lawful under the ePrivacy rules or the GDPR, which require separate assessment.
Analytics and marketing compliance teams
Teams relying on Google Analytics and Google Ads data need to understand how consent signals flow through parameters such as gcd, because those signals influence how Google processes hits. This supports troubleshooting of measurement behavior while keeping the technical signal distinct from the underlying legal basis.
Legal counsel reviewing consent implementations
Counsel assessing a site's compliance posture may encounter gcd during technical reviews. It offers evidence of what consent state was communicated to Google, but interpretation must account for differing obligations across the EU, the UK, and US state regimes, and the fact that transmitting a signal does not resolve questions of consent quality or record-keeping.

Inside gcd Parameter

Purpose within Google Consent Mode
The gcd parameter is associated with Google's Consent Mode, where it conveys the encoded state of a user's consent choices for various consent types to Google tags and services. It is one of several signals used to communicate whether particular processing may occur based on the consent status captured through a CMP or consent banner.
Encoded consent-type signals
The parameter typically packages the status of multiple Consent Mode consent categories (such as those relating to analytics storage and advertising storage) into a compact encoded form. The exact structure is defined by Google's implementation and may change; practitioners should treat the precise encoding as an implementation detail controlled by Google rather than a stable published standard.
Relationship to the underlying legal basis
The gcd parameter reflects a consent state that is expected to originate from a valid consent interaction under the applicable regime. Under EU rules, the placing of and access to information on a device is governed by the ePrivacy Directive as implemented nationally, while any resulting processing of personal data is governed by the GDPR. The parameter itself is a technical transport of a signal and does not by itself establish that valid consent was obtained.
Interaction with a CMP
In common deployments, a consent management platform captures the user's choices and those choices are translated into Consent Mode states, which may then be represented in signals such as gcd. The CMP and tag configuration are responsible for ensuring the signal accurately mirrors the user's actual choices.

Common questions

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

Does setting the gcd parameter correctly mean my cookie consent setup is compliant?
No. The gcd parameter is a technical signal used to communicate consent-related information within certain tag or vendor ecosystems, but a correctly configured parameter does not by itself establish valid consent. Compliance depends on whether consent was actually obtained in line with applicable law, for example, being freely given, specific, informed, and unambiguous under the GDPR in EU jurisdictions, or on an opt-out basis under some US state frameworks. The parameter reflects a consent state; it does not create or validate one. Legal judgment about how consent is collected, recorded, and honored remains necessary, and the parameter alone cannot substitute for that assessment.
Is the gcd parameter a substitute for a consent management platform or consent record-keeping?
No. The gcd parameter is a mechanism for passing consent status alongside requests within a particular ecosystem, whereas a consent management platform (CMP) is responsible for presenting choices to users, capturing their decisions, and typically maintaining logs of those decisions. Consent logging and record-keeping obligations, where they apply, are generally satisfied by the CMP or equivalent systems rather than by a transient parameter carried with a request. The parameter and the CMP address different layers: one communicates a state downstream, the other manages and documents how that state was established. They are complementary rather than interchangeable.
How does the gcd parameter get populated when a user makes a consent choice?
The parameter is typically populated based on the consent state captured by the consent mechanism on the site, for example, the choices a user makes through a consent banner or CMP. That state is then encoded into the parameter and passed with the relevant requests. The specific encoding and the categories it reflects depend on the ecosystem and configuration in use. Implementers should confirm how their particular tagging setup maps user choices to the parameter values, and verify that the mapping accurately reflects the categories of processing the user did or did not consent to. Details beyond a given implementation are out of scope here.
Should the gcd parameter be sent before a user has interacted with the consent banner?
In most EU jurisdictions, non-essential cookies and similar technologies generally require prior consent before they are set or accessed, so any signal reflecting a default or pre-interaction state should be handled carefully to avoid implying consent that was not given. Where the parameter reflects a state before the user has made a choice, it should represent the absence of consent rather than a presumed acceptance, since pre-ticked boxes and implied consent from continued browsing are widely considered non-compliant in the EU. Requirements differ under US state opt-out frameworks. Implementers should confirm the exact behavior of their setup against applicable requirements rather than assuming a default.
How can I verify that the gcd parameter reflects the user's actual choices?
Verification generally involves inspecting the requests generated after making different consent choices and confirming that the parameter values change in line with those choices, for example, that declining a category is reflected accurately. Testing across the relevant consent scenarios (acceptance, rejection, and granular selections where offered) helps confirm the mapping between the user interface and the parameter. Because the parameter is only one part of a larger flow, verification should also consider whether the downstream behavior matches the signaled state. This entry does not cover the specific tooling or debugging methods for any particular ecosystem.
What should I do if the gcd parameter conflicts with other consent signals such as Global Privacy Control?
Conflicts can arise where multiple signals coexist, such as a browser-level Global Privacy Control signal alongside consent captured through a banner. As a general matter, implementers should ensure their setup honors user-expressed preferences consistently and does not process data in ways the user has objected to. Where signals appear to conflict, resolving them typically requires deciding, based on applicable law and guidance, which expression of the user's wishes should govern. Because regulatory positions on how such signals interact continue to evolve and depend on jurisdiction and facts, this is an area where legal input is advisable, and the correct resolution is not something the parameter alone can determine.

Common misconceptions

The presence of a gcd parameter proves that valid consent was collected.
The parameter is only a technical transport of a consent state. Valid consent under the GDPR must be freely given, specific, informed, and unambiguous through a clear affirmative action, and in most EU jurisdictions pre-ticked boxes, implied consent from continued browsing, and cookie walls are widely considered non-compliant. Whether the signal reflects genuinely valid consent depends on how the consent was actually obtained, not on the existence of the parameter.
Because it is a Google technical mechanism, gcd applies the same way in every jurisdiction.
Consent obligations differ across the EU, the UK, and individual US states such as under the CCPA and CPRA in California, and EU-style opt-in requirements differ from opt-out models common in US state laws. A single signal cannot capture these differing legal requirements on its own; its meaning and adequacy depend on the applicable regime and how the surrounding configuration is set up.
Configuring Consent Mode and passing gcd correctly makes an implementation compliant.
Tools and signals such as Consent Mode and the gcd parameter support compliance but do not replace legal judgment. Compliance depends on the validity of the consent interaction, accurate categorization of cookies and similar technologies, honoring user choices, and meeting record-keeping and other obligations that vary by jurisdiction and evolve with regulatory guidance.

Best practices

Treat the gcd parameter as a downstream reflection of consent choices rather than a source of consent; ensure the underlying consent interaction meets the applicable standard, which in most EU jurisdictions requires a clear affirmative action before non-essential cookies or similar technologies are used.
Verify that the signal accurately mirrors the user's actual choices captured by your CMP, and test that changes to consent (including withdrawal) are reflected in the values passed to Google services.
Do not rely on Consent Mode signals alone to satisfy legal obligations; document the legal basis, keep records of consent where required, and confirm that essential versus non-essential technologies are correctly categorized.
Account for jurisdictional differences by confirming that your configuration reflects opt-in requirements where they apply (such as in the EU and UK) and opt-out or signal-based mechanisms where those govern (such as under certain US state laws), rather than assuming one approach applies everywhere.
Because Google's encoding and implementation of parameters such as gcd may change, avoid building compliance conclusions on a specific internal structure of the value and monitor for updates to Google's documentation and applicable regulatory guidance.
Involve legal or data protection expertise when interpreting whether a given Consent Mode configuration meets the requirements of the relevant regime, since tooling supports but does not replace legal judgment.
Application Security Isn’t Optional Anymore.