Seven Signals, Two Jobs

Google Consent Mode uses seven named parameters, and people conflate them constantly. Four of them make up "Consent Mode v2" as most guides describe it; the other three predate v2 and cover non-advertising storage. Get clear on what each one controls and you'll debug a broken setup faster, and you'll be able to tell a legal team exactly what your site is and isn't allowed to do per user choice.

This is a reference, not an install guide. For the implementation decision, see advanced vs basic Consent Mode; for behaviour under denied consent, see what Google Ads does when consent is denied.

The Key Distinction: Storage vs Data Use

Before the definitions, hold one idea in mind. Two of the signals are upstream storage permissions: they decide whether cookies and identifiers can be written and read at all. Two are downstream data-use instructions: they tell Google's servers how it may process data it already received. Google's own docs frame it this way, and it's why you can send a conversion ping while still forbidding Google from using that data to build a remarketing audience.

The Four Consent Mode v2 Parameters

ad_storage (upstream storage). Enables storage related to advertising, such as advertising cookies and device identifiers. Denied means Google Ads can't read its advertising cookie and falls back to click identifiers in the URL.
analytics_storage (upstream storage). Enables storage related to analytics, for example cookies used to measure visit duration. Denied means GA4 collects via cookieless pings rather than a persistent client ID.
ad_user_data (downstream data use). Whether the user consents to their personal data being sent to Google for advertising purposes. This is the gate on enhanced conversions.
ad_personalization (downstream data use). Whether the user consents to their data being used for personalized advertising, meaning remarketing. Denied means the user is not added to remarketing or Customer Match audiences.

The two ad_user_data and ad_personalization signals are what turned Consent Mode into "v2" in 2024; they were added to satisfy the EU Digital Markets Act.

The Three Storage Parameters

These three existed before v2 and cover storage that isn't advertising or analytics:

functionality_storage. Enables storage that supports the functionality of the site or app, such as language settings.
personalization_storage. Enables storage related to personalization, such as video recommendations.
security_storage. Enables storage related to security, such as authentication, fraud prevention, and other user protection.

In most compliant setups, security_storage maps to strictly necessary functions and is typically defaulted to granted, since blocking it would break authentication and fraud protection. functionality_storage and personalization_storage should track whatever consent category you've assigned them; don't grant them by reflex if they power non-essential features.

Which Google Product Needs Which Signal

When something "stops working" after a consent change, it's almost always because one specific signal is denied. This mapping is the fastest triage:

GA4 measurement depends on analytics_storage (with modeling filling gaps when it's denied).
Google Ads conversion tracking depends on ad_storage.
Enhanced conversions depend on ad_user_data; deny it and no hashed data is sent.
Remarketing and Customer Match depend on ad_personalization; deny it and the user isn't added to lists.

Because these stack independently, a user can grant analytics but deny advertising, and each product responds to only its own signal.

How the Signals Travel: gcs and gcd

When a Google tag fires, it encodes the consent state into the request so Google's servers know how to handle it. Two request parameters matter for debugging:

gcs (Google Consent Status) encodes the state of ad_storage and analytics_storage. A value like G100 means both denied; G111 means both granted.
gcd encodes the fuller v2 picture, including ad_user_data and ad_personalization.

You'll see these in the network tab when inspecting a tag's outgoing request, which is how you confirm the browser actually sent the state you configured rather than what you assumed. The step-by-step method is in how to debug Consent Mode v2.

Common Mistakes With These Parameters

Treating v2 as "just two more signals to grant." ad_user_data and ad_personalization aren't formalities. One gates enhanced conversions, the other gates remarketing. Defaulting them to granted for EEA users when the visitor hasn't consented is a compliance failure, not a convenience.
Confusing storage with data use. Granting ad_storage but denying ad_personalization is a valid, common state: Google may store the ad cookie but must not build a remarketing audience. If you assume the four signals move together, you'll misread your own data.
Forgetting security_storage. Because it maps to strictly necessary functions like authentication, denying it can break logins and fraud protection. It's usually the one signal you default to granted.
Never verifying gcs/gcd. The configured state and the transmitted state can differ if a tag fires before your default. Only the request parameters prove what actually left the browser.

Setting Them Correctly

Every parameter you use should be given an explicit default before any Google tag fires, and that default should be denied for anything requiring consent (with security_storage, and often functionality_storage, as the sensible exceptions). Your consent banner then issues an update when the user chooses, flipping the relevant signals to granted. If a default is missing, Google assumes a value, and the assumption may not be the one your compliance stance requires. For wiring this through a tag manager, see the complete GTM and consent setup guide.

The Consent Mode v2 Parameters: A Plain-English Reference