How Does TrueVault Implement Google Consent Mode V2?
TrueVault's Google Tag Manager (GTM) template implements Google Consent Mode V2, the framework Google requires for tags that serve personalized advertising or analytics to users in the EEA, UK, and Switzerland. This page explains what Consent Mode V2 is, which signals our CMP sets, and how the template behaves at page load and after a consumer interacts with the banner.
What Is Consent Mode V2?
Consent Mode V2 is a Google API that lets a Consent Management Platform (CMP) communicate a user's consent choices to Google tags (Google Ads, Google Analytics 4, Floodlight, etc.) by setting named consent signals to either granted or denied. Google tags then adapt their behavior based on those signals — for example, GA4 will send cookieless "pings" instead of full hits when analytics_storage is denied, and Google Ads will fall back to modeled conversions when ad_storage is denied.
Consent Mode V2 introduced two additional signals on top of the original Consent Mode:
ad_user_data— whether user data may be sent to Google for advertising purposesad_personalization— whether the user's data may be used for personalized advertising (remarketing)
Both are required for any site that sends EEA traffic to Google's advertising products.
Signals TrueVault Sets
The TrueVault Polaris CMP GTM template manages the full set of Consent Mode V2 signals plus one TrueVault-specific signal used by our US & Canada opt-out flow:
| Signal | Source in the CMP |
|---|---|
ad_storage | Advertising consent toggle |
ad_user_data | Advertising consent toggle |
ad_personalization | Advertising consent toggle |
analytics_storage | Analytics consent toggle |
functionality_storage | Functionality consent toggle |
personalization_storage | Personalization consent toggle |
security_storage | Functionality consent toggle |
tv_not_opted_out | US/Canada opt-out state |
The advertising toggle drives all three Consent Mode V2 advertising signals (ad_storage, ad_user_data, ad_personalization) so a single user-facing choice updates every advertising-related tag consistently.
How the Template Loads Consent State
The template runs in three phases on every page load. The order matters because Google requires that default consent state be set before any Google tag fires.
1. Set Regional Defaults (EEA / UK / CH)
First, the template calls setDefaultConsentState with values derived from the Default Consent State checkboxes you configured in the GTM template, scoped to the EEA, UK, and Switzerland country codes. This implements Google's required "deny by default in regulated regions" pattern. Each default also sets wait_for_update: 500, which tells Google tags to delay firing for up to 500ms while the CMP determines whether the user has a stored consent choice.
2. Set Implicit Defaults Everywhere Else
Next, the template calls setDefaultConsentState again — this time with no region scope and every signal set to granted. This is the "implicit consent" model used in regions like the United States, where consent is assumed unless the user later opts out. The wait_for_update: 500 delay still applies so that any opt-out cookie set on a previous visit can be honored before tags fire.
3. Apply the Stored Consent Cookie
The template then reads the Polaris consent cookie. If a cookie is present, it converts the stored permissions into Consent Mode signals and calls updateConsentState, overriding the defaults from steps 1 and 2 with the user's actual choices. See this article for details on the cookie format.
If no cookie exists, the defaults from the previous two steps remain in effect until the consumer interacts with the banner.
Reacting to Consent Changes
After the initial load, the template registers an addConsentListener callback with Polaris. Whenever the consumer accepts, declines, or updates their preferences in the banner, Polaris invokes the callback and the template calls updateConsentState with the new signal values. Google tags loaded on the page receive the update immediately and adjust their behavior without requiring a page reload.
Ads Data Redaction
In addition to the Consent Mode signals, the template sets the ads_data_redaction flag from the Ads Data Redaction field in the GTM template configuration. When enabled and ad_storage is denied, Google Ads tags will fully redact ad-click identifiers from network requests, providing an extra layer of privacy on top of the standard Consent Mode behavior.
Verifying Your Implementation
To confirm Consent Mode V2 is working on your site:
- Open your site in an incognito window with the browser devtools Network tab open.
- Filter for requests to
google-analytics.comorgoogletagmanager.com. - Before interacting with the banner, look for the
gcs(Google Consent State) andgcd(Google Consent Default) parameters on outgoing requests — these encode the current Consent Mode signal state. - Decline consent in the banner and confirm the
gcsparameter changes accordingly on subsequent requests.
The gcs parameter is a four-character code in the format G1[ad_storage][analytics_storage], where each position is 1 for granted and 0 for denied:
gcs Value | ad_storage | analytics_storage | Typical Scenario |
|---|---|---|---|
G111 | granted | granted | User accepted all, or implicit consent in non-regulated regions |
G110 | granted | denied | User accepted advertising only |
G101 | denied | granted | User accepted analytics only |
G100 | denied | denied | User declined all in a regulated region |
These values reflect our current understanding of Google's gcs parameter. Google has stopped officially documenting these values, but we have consistently observed them in our testing.
Note that gcs only encodes ad_storage and analytics_storage. The other Consent Mode V2 signals (ad_user_data, ad_personalization, etc.) are reported separately in the gcd parameter, which is a longer encoded string covering every signal and its default-vs-updated state.
You will observe that the Google Analytics tags still do communicate in a limited fashion (with corresponding gcs value) even when ad_storage or analytics_storage are denied, which is expected behavior under Consent Mode V2. If you'd like to block all communication entirely, you can add these signals (or the tv_not_opted_out signal) as additional consent requirements to your GA4 tags. Reference our Cookie Consent and US & Canada opt-outs documentation as needed.