Google Consent Mode v2: the signals, the modes, and how to verify yours.
Consent Mode is easy to install and easy to get subtly wrong, because almost every failure is silent. This covers what the four signals actually control, how to read the consent state straight off the network request, and the threshold your account has to clear before modelling gives you anything back.
Consent Mode v2 is an API that communicates a visitor's consent choices to Google tags. It adds ad_user_data and ad_personalization to the original ad_storage and analytics_storage. The first two are gates — they control whether cookies may be read or written. The second two are not gates: they travel with the request and instruct Google on what it may do with the data once it arrives. Since March 2024 you need all four to keep conversion tracking and remarketing working for EEA and UK traffic.
Two of the signals gate collection. Two do not.
This is the distinction most implementations miss. ad_storage and analytics_storage are upstream: they decide whether a tag may use cookie storage at all. ad_user_data and ad_personalization are downstream instructions — they do not stop the tag firing, they tell Google whether the data it just received may be used for advertising and for personalisation. A setup that sets the storage pair correctly and leaves the v2 pair unset looks healthy in Tag Assistant and still silently starves your remarketing audiences, because the signal Google needs to populate them never arrives.
Reading consent off the wire: gcs and gcd
Every Google request carries these. gcs is the v1 parameter in the form G1xy, where x is ad_storage and y is analytics_storage, 1 for granted and 0 for denied — so G111 is both granted and G100 is neither. gcd is the v2 parameter and encodes all four signals using letters for the transition, not just the end state: l means the signal was never set, p means denied by default and never updated, t means granted by default and never updated, r means denied by default then granted after the user chose, and u means granted by default then denied. That distinction is the useful part. An r or a u proves your update call fired. A p or a t on a visitor who clicked the banner proves it did not.
Basic versus advanced is a data decision, not a compliance one
Both are compliant. In basic mode, tags are blocked entirely until consent is granted, so a visitor who declines contributes nothing at all. In advanced mode the tags still load and send cookieless pings carrying random, ephemeral identifiers rather than cookie-based ones, and Google uses those to model the conversions it cannot observe. Advanced recovers materially more reported conversions. It also means requests leave the browser for people who declined, which is the first thing a DPO will want to discuss. Pick deliberately and write down the reasoning, because you will be asked.
Modelling has a threshold, and most accounts do not clear it
Conversion modelling is not automatic. Google requires roughly 700 ad clicks over a seven-day period per country and domain grouping before models activate, and there is a training period after that before modelled conversions appear in reporting. Below that threshold, advanced mode still sends the pings but you get no modelled conversions back — you have taken on the privacy conversation without collecting the benefit. Check your click volume per country before choosing advanced on the strength of the modelling argument.
Ordering, defaults and the ones people forget
The default command must run before any measurement tag, which in GTM means firing it on the Consent Initialization trigger rather than All Pages. wait_for_update gives an asynchronous banner a stated number of milliseconds to answer before tags proceed. Defaults can be scoped by region using ISO 3166-2 codes, and the more specific region wins, so US-CA overrides US. Two settings get skipped almost universally: ads_data_redaction, which strips ad click identifiers from requests while ad_storage is denied, and url_passthrough, which carries gclid and dclid through in the URL so attribution survives a navigation when cookies are not available.
Where server-side changes the shape of the problem
Client-side, consent is advisory. The browser asks each tag to behave and each vendor tag decides for itself, which means your compliance position is only as good as the least careful template in your container. In a server container the consent state arrives with the event and is evaluated once against a policy per destination, so a denied signal means the outbound request is never constructed rather than constructed and flagged. That is materially easier to evidence, and in practice it is cleaner data too, because the events you are permitted to send stop being dropped alongside the ones you are not.
- 01 Open the Network tab, filter for gcd, and confirm the parameter is present on your Google requests at all
- 02 Accept the banner and check the gcd letters change to r or u — that is proof the update call fired, not just the default
- 03 Confirm the default command runs on Consent Initialization, not All Pages
- 04 Decline, and verify ad_user_data and ad_personalization both read denied rather than unset
- 05 Check whether ads_data_redaction and url_passthrough are configured; they usually are not
- 06 Count ad clicks per country over seven days against the ~700 threshold before relying on modelling
- 07 In Google Ads, open the conversion diagnostics panel and look for consent mode warnings
Is Google Consent Mode v2 mandatory? +
Not universally. It is required to keep conversion tracking, remarketing and audience features working in Google Ads for traffic from the EEA and the UK. Outside those regions nothing breaks without it, though the signals remain useful.
What is the difference between Consent Mode v1 and v2? +
v1 carried ad_storage and analytics_storage, both of which gate cookie access. v2 adds ad_user_data and ad_personalization, which do not gate anything — they instruct Google on whether the data may be used for advertising and for personalisation once received.
How do I check whether Consent Mode is actually working? +
Look at the gcd parameter on any outbound Google request. If it is absent, Consent Mode is not running. If the letters stay at p or t after a visitor interacts with your banner, the default fired but the update did not — which is the most common fault there is.
Do I still need a cookie banner? +
Yes. Consent Mode is the transport, not the consent. A CMP collects and stores the choice; Consent Mode is how that choice reaches Google's tags.
Does server-side tagging let me skip consent? +
No, and anyone telling you otherwise is selling you a liability. Moving collection server-side changes where processing happens, not whether you need a legal basis for it.
Want someone to just do this properly?
Consent enforcement in the container, wired to your CMP, with an audit trail — part of every build we ship.