Google Consent Mode V2: what it is, how it works, and how to set it up
Mariusz Brucki | 2 June 2026 | Last updated: Google updated its Consent Mode framework in early 2024, adding 2 new consent types and making the whole thing mandatory for anyone using Google Ads in Europe. Most teams updated their CMP tag in GTM and moved on. What many didn't catch is that the Basic vs. Advanced choice, and how consent signals travel through a server container, has a direct impact on how much conversion data reaches your ad platforms.
The framework, the tradeoffs, the server-side nuances, and the setup steps are covered in this article.
What is Google Consent Mode V2?
Consent Mode is a set of signals that your cookie banner sends to Google's tags. When a user accepts or declines cookies, those signals tell Google's products what they're allowed to do: set cookies, collect user data, run personalised ads, or model conversions.
The CMP handles the user interaction, the upstream side. Google's tags then adjust their behaviour based on whatever the user chose. Consent Mode sits between the two and carries the decision from one to the other.
The 4 consent types
V1 used two consent types. V2 added two more:
| Consent Type | Controls | Added in | DMA Required |
| ad_storage | Advertising cookies | V1 | No |
| analytics_storage | Analytics cookies | V1 | No |
| ad_user_data | Sending user data to Google for advertising purposes | V2 | Yes |
| ad_personalization | Personalised ads and remarketing | V2 | Yes |
The last two matter specifically for the EU's Digital Markets Act. Google needs explicit consent not just for storing cookies, but for using your visitors' data inside its ad systems. Without ad_user_data and ad_personalization properly configured, remarketing audiences and conversion tracking are incomplete regardless of what your CMP says.
Basic vs. advanced Consent Mode: which should you use?
There are two ways to implement Consent Mode, and the difference shows up in your advertising performance.
Basic Consent Mode: Tags only fire after the user explicitly consents. Non-consenting visitors generate no data at all.
Advanced Consent Mode: Tags load with default states (denied in the EU). When a non-consenting user visits, the tag still sends cookieless pings to Google, a minimal signal without identifying data. When they accept, full data flows.
Here's how the 3 states compare in practice:
| No Consent Mode | Basic | Advanced | |
| Non-consenting users | Uncontrolled (compliance risk) | No signal sent | Cookieless ping sent |
| Conversion modeling available | No | No | Yes (after threshold) |
| Modeling threshold | - | - | 700 ad clicks / 7 days / country |
| EU site at ~40% consent rate | Compliance risk | 54% of signals gone, no alert | 54% partially recoverable |
Google Ads needs at least 700 ad clicks over 7 days per country before it starts modeling conversions. Under that threshold, even Advanced mode sends cookieless pings from non-consenting users, but the modeling never kicks in.
According to SearchLab’s Privacy & GDPR’s Statistics, for EU sites where consent rates typically sit around 46%, Basic mode means 54% of your conversion signal disappears from Google's view. Campaigns keep running, bidding algorithms adjust to whatever's left, and there's no warning that the data is thin.
Advanced is the better choice for most sites. The requirement is that your CMP tag fires before any other tag, during the consent initialisation trigger, so default states are set before any data is collected. If there's a delay, you risk sending data before consent is initialised.
How does Consent Mode V2 work with Server-side Tracking?
Most server-side setups have a gap here: consent states are not forwarded to the server container automatically. What happens instead depends entirely on which tags you're running.
Google products: handled automatically
For GA4 and Google Ads, the web container packages the current consent state into a gcs parameter on every outgoing request. That request hits the server container, and the Google tags there read the parameter and handle consent enforcement on their own. No additional configuration needed in the server container for these tags.
Non-Google tags: you need to pass consent manually
Meta Conversions API, LinkedIn Insight Tag server-side, TikTok Events API, and similar platforms don't read the gcs parameter. They need consent states passed explicitly as event parameters. Without that, the tag has no way to know what the user agreed to.
Setup for non-Google tags
- Download and import the GitHub Consent State Template into your GTM web container
- Create a Consent State variable for each relevant type: ad_storage, analytics_storage, ad_user_data, ad_personalization
- Add all four variables to a Google Tag Event Settings variable as event parameters
- Attach that Event Settings variable to your main Google Tag
- In the server container, create Event Data variables for each consent state, using the consent type name as the Key Path (e.g., ad_personalization)
- Use these variables as trigger conditions to gate non-Google tags, so they only fire when the relevant consent type is granted
Without this, a server-side Meta or TikTok tag fires on every event, regardless of what the user chose.
How to set up Consent Mode V2 in GTM: step by step
1. Enable Consent Overview
Go to Admin → Container Settings in your GTM web container. Under Additional Settings, enable Consent Overview and save. This makes consent behaviour visible in Preview mode, which you need for verification.
2. Add your CMP tag
Go to Tags → New and find your CMP in the Community Template Gallery. Set the trigger to Consent Initialisation - All Pages. This fires before everything else on the page and sets the default consent states.
3. Map CMP categories to consent types
Different CMPs use different internal category names. Standard mapping for EU sites:
- Marketing → ad_storage, ad_user_data, ad_personalization
- Statistics → analytics_storage
- Preferences → functionality_storage, personalization_storage
Check your CMP's documentation to confirm its exact category names. Mismatched mapping is one of the more common Consent Mode problems and not obvious to spot from the outside.
4. Set defaults to denied for EU visitors
All four consent types should default to "denied" before any user interaction. Your CMP tag should handle this, but verify it in GTM Preview by checking the Consent tab on a fresh page load before interacting with the banner.
5. Configure the server container for non-Google tags
Follow the steps from the previous section: Consent State Template, Event Settings variable, server-side Event Data variables, consent-based trigger conditions. For GA4 and Google Ads in the server container, nothing extra is needed.
6. Verify with Tag Assistant
Open GTM Preview in a fresh browser session. Load your site and open the Consent tab. All four types should show "denied." Accept the banner and confirm that they update to "granted." Then check the Tags tab to verify tags fire or hold back according to the consent state.
For the full configuration reference, the TAGGRS Consent Mode documentation walks through each step in detail.
CMP-specific notes
Cookieconfirm
Cookieconfirm uses a dedicated tag in the Community Template Gallery. Install it with a Consent Initialisation trigger, and the server container picks up the GCS parameter for all Google tags automatically. For non-Google tags, create custom blocking triggers using the ED | x-ga-gcs Event Data variable. The value gcs=G101 means ad_storage is denied; gcs=G10 at the start indicates ad_storage denial in the GCS string format.
Axeptio
Axeptio works differently. Rather than the standard GCS parameter, Axeptio tracks consent through vendor names stored in axeptio_authorized_vendors and pushes an axeptio_update event to the dataLayer when consent changes. On the server side, create an Event Data variable for axeptio_consent_state and condition each tag on whether the relevant vendor name (e.g., google_analytics) is present in that variable. The category-to-signal mapping for Consent Mode V2 is configured inside the Axeptio platform itself.
How to check whether Consent Mode V2 Is working?
Three methods are used in combination.
GTM Preview - Consent tab
Open a private browser session, start Preview mode, and load your site. Before touching the banner, open the Consent tab. All four consent types should read "denied." Accept the banner and watch the values update. If they don't change, the CMP tag isn't firing or its categories aren't mapped to the right consent types.
Network tab - gcs parameter
In Chrome DevTools, filter network requests for collect. Each GA4 hit includes a gcs parameter that encodes the current consent state. G111 means all four types are granted. G101 means ad_storage is denied, analytics_storage is granted. The parameter value is what actually got sent to Google, not what the banner claimed to set.
TAGGRS dashboard
In your TAGGRS server container, incoming events carry the consent state parameters passed from the web container. Check an event from a consenting session and confirm that ad_storage, analytics_storage, ad_user_data, and ad_personalization appear as event parameters with the expected values. If they're missing, the Event Settings variable isn't connected, or the Consent State Template wasn't imported.
Where TAGGRS fits
Server-side tracking and Consent Mode V2 work well together, but they need to be wired up correctly for the combination to hold. The automatic GCS handling in Google's tags covers GA4 and Google Ads without extra work on the server side. For everything else, Meta, LinkedIn, TikTok, or any custom server-side integration, consent has to be passed deliberately through the event payload.
TAGGRS provides the server container infrastructure and publishes the Consent State Template that handles how consent parameters travel from the web container to the server. For teams on Axeptio or Cookieconfirm, the CMP-specific guides above cover the exact configuration steps for each platform.
FAQ
What is the difference between Consent Mode V1 and V2?
V1 used two consent types: ad_storage and analytics_storage. V2 added ad_user_data, which controls whether user data is sent to Google for advertising, and ad_personalization, which controls remarketing and personalised ads. Both new types are required for DMA compliance. Sites still on V1 will see incomplete remarketing audiences and gaps in conversion tracking.
Does Consent Mode V2 replace Server-side Tracking?
No. They serve different purposes. Consent Mode governs what data Google is allowed to process based on user choices. Server-side tracking changes where data collection happens, moving it from the browser to your own server. The two work together: server-side tracking improves first-party cookie lifespans and data quality, but consent decisions still need to travel with the data to stay compliant.
How do I check if Consent Mode V2 is set up correctly?
Three checks: the GTM Preview Consent tab (verify defaults are "denied" before interaction and update after); the gcs parameter on GA4 network requests (G111 = all granted); and your TAGGRS server container dashboard to confirm consent state parameters are arriving on server-side events.
What is the conversion modeling threshold for Consent Mode?
Google Ads needs 700 ad clicks over 7 days per country and domain before conversion modeling activates. Below that, Advanced Consent Mode sends cookieless pings from non-consenting users but Google can't yet model conversions from them. Basic Consent Mode never reaches this threshold for non-consenting users because no signal is sent at all.
