GA4 Consent Mode v2: Complete Setup and GDPR Guide

What Google Consent Mode v2 Is

Google Consent Mode v2 is a signalling framework that tells Google’s tags (GA4, Google Ads, Floodlight) whether a user has consented to analytics and advertising cookies and adjusts tag behaviour accordingly. Instead of simply firing or not firing, your tags receive a live consent state and react to it. When consent is denied, tags can either stay silent or send cookieless pings, depending on which mode you choose.

Google introduced the two additional signals ad_user_data and ad_personalization for traffic from the EEA, the UK and Switzerland and has required them since March 2024 for ad personalisation, remarketing and Customer Match, as documented in Obtain user consent. The background is Google’s EU user consent policy and the obligations Google took on under the EU Digital Markets Act. Without the signals, Google does not use the data of EEA users for ad personalisation and the EU User Consent Policy audit can lead to suspended audience features and conversion measurement for the account.

This guide explains the two modes, the four consent signals, how to integrate a Consent Management Platform (CMP) like Cookiebot or Usercentrics, what conversion modelling actually recovers and the GDPR trade-offs you need to weigh. It also covers the two 2026 changes that affect every setup: since 15 June 2026 the consent signals alone control the ads data flow from Google Analytics to Google Ads and since 20 August 2026 the Google tag and Tag Manager share one snippet without a gtag config command. This is technical and factual guidance, not legal advice. For the decisions that touch German and EU law, treat the legal sections as professional context and confirm specifics with your data protection counsel.

If you want this wired up and validated end to end, our Consent Mode v2 implementation service covers the full setup and testing cycle.

Consent Mode v2 Basic vs Advanced: The Central Decision

The single most important decision is whether you run Consent Mode in Basic or Advanced mode. They differ in what happens before the user has made a consent choice and after a denial. Google documents both variants in the consent mode overview and in About consent mode.

Basic Mode

In Basic mode, Google tags are blocked from loading until the user grants consent. No pings, no requests, nothing leaves the browser before consent, not even the default consent state. If the user denies, no Google tag fires at all.

• Maximum data minimisation: nothing is sent without consent.
• Simplest to defend from a data protection standpoint, because no data leaves the device before an active opt-in.
• The downside: you collect zero data from users who deny. Google Ads then falls back to its general, less detailed conversion model and behavioural modelling in GA4 is not available.

Advanced Mode

In Advanced mode, Google tags load on every page with all defaults set to denied and their behaviour is governed by the consent state. Before consent and on denial, the tags send cookieless pings. According to Google’s overview, a ping can contain a timestamp, the user agent, the referrer, an indication whether the current or a previous page carried ad-click information in the URL, the consent state as boolean values and a random page-load number, but no cookies and no client identifiers. Once the user consents, full measurement resumes.

• Enables the advertiser-specific conversion model in Google Ads and behavioural modelling in GA4, because Google has a baseline of cookieless pings to model from.
• Recovers a share of the conversions you would otherwise lose to the cookie banner (see the modelling section for what Google documents).
• The downside: cookieless pings are sent before consent, which is contested under GDPR in Germany (covered below).

The trade-off in one sentence: Basic mode favours strict data minimisation, Advanced mode favours data completeness through modelling. There is no universally correct answer. Many DACH practitioners recommend Basic mode where maximum legal defensibility is the priority and reserve Advanced mode for cases where the modelling uplift is documented and the legal position has been reviewed.

The Four Consent Signals (Including ad_user_data and ad_personalization)

Consent Mode v2 extends the original two signals with two advertising-specific ones. All four are passed as either granted or denied.

Signal	Controls
analytics_storage	Analytics cookies and storage (GA4 measurement)
ad_storage	Advertising cookies and storage
ad_user_data	Whether user data may be sent to Google for advertising
ad_personalization	Whether data may be used for personalised advertising / remarketing

Tag Manager also knows three privacy parameters, functionality_storage, personalization_storage and security_storage, listed in the Tag Manager consent mode support page. They do not change the behaviour of Google’s own tags, but most CMPs set them and you can use them for consent checks on your own tags.

The two v2 additions, ad_user_data and ad_personalization, are the reason the update was mandatory. Without them set to granted, Google will not build remarketing audiences or run personalised measurement for that user, even if ad_storage is granted.

Google’s consent API reference states that no consent mode values are set by default, so you have to set the defaults yourself before any tag fires and update them when the user interacts with your banner. A correct default state looks like this in Tag Manager via a Consent Initialization trigger or directly through gtag:

gtag('consent', 'default', {
  ad_storage: 'denied',
  ad_user_data: 'denied',
  ad_personalization: 'denied',
  analytics_storage: 'denied',
  wait_for_update: 500
});

Everything is denied until the user decides. wait_for_update tells the tags to wait up to 500 milliseconds for a consent update, which gives the CMP time to read a stored choice of a returning visitor before any tag acts. If you need different defaults per country, the same command accepts a region array with ISO codes and the most specific region wins.

When the user accepts, the CMP fires an update:

gtag('consent', 'update', {
  ad_storage: 'granted',
  ad_user_data: 'granted',
  ad_personalization: 'granted',
  analytics_storage: 'granted'
});

Google is explicit that the default command must run on every page before any command that sends measurement data and that consent defaults do not work if the code runs out of order. Setting the default too late is one of the most common misconfigurations and silently breaks the whole model.

Tag Manager Since August 2026: One Snippet, Consent Initialization and the Tag Gateway

On 20 August 2026 Google unified the Google tag and Tag Manager. Google tags are being upgraded to fully capable Tag Manager containers, all new deployment snippets are identical and they no longer contain a gtag config command. Google recommends configuring initialisation through the Initialization trigger, which can also wait for a legacy config command if you want to preserve an older setup. Existing snippets keep working and the container optimisation Google offers is optional.

For consent this changes nothing about the order of operations, but it removes the place where many older setups hid their consent default: the inline gtag config block. Put the consent default and your CMP tag on the Consent Initialization trigger. Google’s trigger documentation states that it fires before all other triggers, including the Initialization trigger and that it is meant for tags that set or update consent state. A consent default on a page view trigger runs too late.

Google’s own tags (GA4, Google Ads, Floodlight, Conversion Linker) carry built-in consent checks and adjust their behaviour to the consent state without extra configuration. Every tag additionally has an additional consent checks setting with the options not set, no additional consent required and require additional consent for the tag to fire. The Consent Overview in the container settings shows these settings for all tags at once. In practice: Advanced mode relies on the built-in checks alone, Basic mode adds a required consent type or a consent-based trigger so that the tag does not fire before the update.

The Google tag gateway for advertisers lets you load the Google tag and send measurement events through your own domain via Cloudflare, a CDN or a load balancer, described in Google’s announcement. It changes the transport path, not the consent logic: defaults, updates and the four signals apply unchanged and data from users who denied consent may not be forwarded just because the request now passes through your domain.

CMP Integration: Cookiebot, Usercentrics and Default States in Tag Manager

Google runs a CMP partner programme whose members, among them Cookiebot and Usercentrics, ship Tag Manager templates for consent mode and the same page states that you can also build your own consent banner. A Google-certified CMP with IAB TCF integration is mandatory only for publishers who serve ads through AdSense, Ad Manager or AdMob, as documented in the publisher requirements. For advertisers a partner CMP is the practical route because the template handles default and update, but the integration details still matter.

The Standard Tag Manager Integration Flow

1. Set defaults first. Fire the CMP template or your consent tag on the Consent Initialization trigger and set all four signals to denied. This must run before everything else.
2. Load the CMP. The CMP banner loads and either reads a stored choice or waits for the user.
3. Update on interaction. When the user accepts or rejects categories, the CMP issues the consent update with the matching granted/denied values.
4. Tags respect the state. Your GA4 and Google Ads tags read the live consent state and fire, send cookieless pings or stay silent accordingly.

Cookiebot

According to the Cookiebot implementation guide, the Cookiebot script sends the consent update automatically and maps both ad_user_data and ad_personalization to its marketing category. What you have to do yourself is set the default state: in Tag Manager, enable consent mode in the Cookiebot tag and define denied for each parameter, use the WordPress plugin or place the inline default script before the Tag Manager snippet. Keep the template on the newest version. The typical Cookiebot error is not a missing mapping but a missing or late default, which shows up in Tag Assistant as an update without a preceding default.

Usercentrics

According to the Usercentrics step-by-step guide, consent mode is active by default and the toggle sits under Configuration and CMP Settings. Usercentrics does not map categories but Google services from its database: Google Analytics 4 drives analytics_storage, Google Ads, Google Ads Conversion Tracking, Google Ads Remarketing and Conversion Linker drive ad_storage and ad_user_data and ad_personalization follow the value of ad_storage. At least one matching service must exist in your configuration for each parameter, otherwise the update event omits it. Usercentrics does not handle the default event natively: set it in the Default Consent State section of the Tag Manager template, optionally per region or with a manual script.

TCF 2.2

If you operate in programmatic advertising, your CMP may also emit an IAB TCF 2.2 transparency and consent string. Consent Mode and TCF are separate but related: the TC string carries the legal consent record for vendors, while Consent Mode carries the operational signal to Google’s tags. With enableAdvertiserConsentMode in the TC data, Google can infer the advertising signals from the TC string, but Cookiebot still recommends setting the consent defaults explicitly so that no Google tag can fire before the string is available.

Conversion Modelling: What You Realistically Recover

Conversion modelling is the practical payoff of Advanced mode. When a user denies consent, Google has no cookie to attribute their conversion, so the path is lost. Modelling uses the cookieless pings plus aggregated behavioural patterns from consenting users to statistically reconstruct those missing conversions.

The often quoted figure comes from a Google blog post from April 2021: on average, conversion modelling through consent mode recovers more than 70% of ad-click-to-conversion journeys lost due to user cookie consent choices. Google adds in the same post that results for each advertiser may vary widely, depending primarily on consent rates and the setup. Treat it as a vendor figure from 2021, not as a forecast for your account.

The thresholds are documented. For Google Ads, consent mode modelling requires 700 ad clicks over a 7 day period per country and domain grouping and without cookieless pings Google cannot calculate advertiser-specific calibration factors, which is the difference between the general model in Basic mode and the advertiser-specific model in Advanced mode. For GA4, behavioural modelling requires an advanced implementation, at least 1,000 events per day with analytics_storage set to denied for at least 7 days and at least 1,000 daily users sending events with analytics_storage set to granted on at least 7 of the previous 28 days. Google notes that meeting the thresholds does not guarantee eligibility. Low-traffic accounts may see little or no modelled data.

How much you lose without modelling depends on your own consent rate, which your CMP reports. Modelling does not give you raw user-level data back, it gives you a statistically estimated count, which is useful for bidding and reporting but is not the same as observed conversions.

Consent Signals and the Data Flow to Google Ads Since 15 June 2026

Google has started to consolidate the data controls between Google Analytics and Google Ads. Until June 2026 the collection of Google Ads cookies and IDs by the Google Analytics tag was controlled by both the Google Signals setting in Analytics and the consent mode ads settings. Since 15 June 2026 consent mode is the single control: the users’ choices transmitted through the ads consent signals exclusively govern how that data is collected and used, while the Google Signals setting only controls whether Analytics data is associated with signed-in user information for behavioural reporting inside Analytics.

Google has announced two further steps for later in 2026: for linked properties, the ad_personalization signal will exclusively control whether Analytics data is used for personalisation in the Ads account and IP addresses collected by the Google tag will be encrypted and flow to the linked Google Ads account, where Ads settings govern them. Exact dates are still to be announced.

Three practical consequences:

• Switching off Google Signals no longer prevents ads-related data from flowing to Google Ads. Only a denied ad_storage and ad_user_data does.
• A default of denied for all four signals is now the mechanism that enforces the user’s choice for the Ads data flow. If your setup relied on the Google Signals toggle as a safety net, verify the defaults now.
• Audience and personalisation controls in the Analytics admin are on their way out. Document the consent mapping, not the toggle, as your control.

GDPR, TDDDG and Data Transfers: Technical Context, Not Legal Advice

This section is professional context, not legal advice. The legality of Advanced mode in Germany is genuinely contested and you should confirm your position with qualified counsel.

Consent for Storing and Reading on the Device

In Germany, section 25 TDDDG requires consent before information is stored on or read from the user’s device unless that is strictly necessary for a service the user requested. Cookies and comparable identifiers set by Google tags fall under this. That is the technical reason why you set all consent defaults to denied and only update on an explicit opt-in.

Why Advanced Mode Is Contested

Advanced mode sends cookieless pings before consent. The contested question is whether those pings constitute processing of personal data without a legal basis. They contain no cookies and no client identifiers, but they do transmit the information listed above (page context, timestamp, user agent, consent state) to Google before the user has opted in. Several DACH data protection experts argue that for maximum legal defensibility, Basic mode is the safer choice because nothing leaves the device before consent. Others consider the pings sufficiently anonymised. Present this to your stakeholders as a documented trade-off, not a settled verdict.

Data Transfers to the US

Data sent to Google involves transfer to a US company. The EU-US Data Privacy Framework, adopted by the European Commission in July 2023 after Schrems II had invalidated Privacy Shield, is the current basis for these transfers. The framework is being challenged in court, so check its status with your counsel and build with this residual risk in mind rather than assuming permanence. The Google tag gateway does not change where the data ends up.

Server-Side Tracking Plus Consent Mode: Enforcing Consent at the Server

Consent Mode is a client-side signalling layer. Server-side tracking (server-side Tag Manager) sits behind it and gives you a second enforcement point. When you combine them, the consent state travels with the event into your server container, where you can decide, per consent state, whether to forward data onward to Google, Meta or any other destination.

This matters because it lets you enforce consent decisions on infrastructure you control, rather than trusting only the browser. It also improves data quality and resilience against ad blockers and Safari’s tracking prevention. Our GDPR-aware conversion tracking service builds exactly this combination on German infrastructure.

One critical clarification: server-side tracking is not a consent bypass. If a user denies consent, your server-side container must not forward their data to Google, Meta or TikTok, not even in anonymised form, without a valid legal basis. Server-side tracking improves data quality and control, but it does not replace the requirement for consent. Anyone selling it as a way to “track everyone regardless of the banner” is misrepresenting the law.

The following conceptual guard reads the consent state from the incoming event instead of assuming it and forwards only when both advertising signals are granted:

function shouldForward(event) {
  const consent = event.consent || {};
  return consent.ad_user_data === 'granted'
      && consent.ad_personalization === 'granted';
}

Common Consent Mode v2 Misconfigurations

These are the recurring errors we find when auditing existing setups.

• Defaults set too late. The consent default call must run before any Google tag. If it loads after GA4, the model never engages.
• Default on the wrong trigger. A consent default on a page view or DOM Ready trigger instead of Consent Initialization runs after the Google tag has already initialised.
• Missing the two v2 signals. Setups migrated from the original Consent Mode often update ad_storage and analytics_storage but never wire ad_user_data and ad_personalization, silently killing remarketing.
• CMP mapping incomplete. With Usercentrics, a missing Google service in the configuration means the update omits that parameter; with Cookiebot, an outdated template means the default is missing.
• Advanced mode chosen without a legal review. Teams enable Advanced mode for the modelling uplift without documenting the GDPR trade-off.
• No wait_for_update. Without it, tags can fire before the CMP has read a returning user’s stored choice, producing inconsistent states.
• Relying on the Google Signals toggle. Since 15 June 2026 it no longer controls the ads data flow, only the consent signals do.
• Assuming server-side equals compliant. Forwarding denied-consent data server-side because “it is anonymised” is a misreading of the law.

A structured review catches these quickly. If you are not sure which of these applies to you, a free initial consultation is the place to work it out together.

How to Test Whether Your Consent Mode v2 Works

1. Use Tag Assistant. Open Tag Manager preview or tagassistant.google.com, select the earliest Consent event in the summary and check in the API Call section or the Consent tab under On-page Default that all four signals are denied. Google’s consent debugging guide walks through exactly this.
2. Check the consent update on accept. Click accept on your banner, select the most recent Consent event and verify under On-page Update that all four signals are granted.
3. Inspect network requests. According to the consent mode overview, the gcs parameter transmits ad_storage and analytics_storage and the gcd parameter carries the state of all consent signals. In Advanced mode you should see requests with a denied state before consent, in Basic mode no Google requests at all.
4. Validate in GA4 DebugView. Enable debug mode via Tag Assistant preview or the debug_mode parameter and open Admin, Data display, DebugView, as described in Monitor events in DebugView. Confirm events arrive with the expected consent state and that denied-consent traffic behaves as your chosen mode dictates.
5. Check the status in Google Ads. After a correct implementation Google Ads shows “Consent mode is implemented” or “Consent mode is implemented and modeling is active”. According to the verification page the status can take 48 hours to appear and up to two weeks in some cases.

Frequently Asked Questions

What is the difference between Consent Mode v2 Basic and Advanced?

Basic mode blocks Google tags from loading until the user consents, so nothing is sent on denial, not even the default consent state. Advanced mode loads tags on every page with denied defaults and sends cookieless pings before and after a denial, which enables the advertiser-specific conversion model and behavioural modelling. Basic favours strict data minimisation, Advanced favours data completeness.

Is Google Consent Mode v2 mandatory?

For advertisers with traffic from the EEA, the UK and Switzerland who use Google Ads personalisation, remarketing or Customer Match, yes, since March 2024. Without the ad_user_data and ad_personalization signals Google does not use those users’ data for personalisation and a failed EU User Consent Policy audit can lead to suspended audience features and conversion measurement.

Is Advanced mode GDPR-compliant in Germany?

It is contested. Advanced mode sends cookieless pings before consent and DACH experts disagree on whether that constitutes processing without a legal basis. Many recommend Basic mode for maximum legal defensibility. This is professional context, not legal advice, so confirm with your data protection counsel.

Which CMP do I need for Consent Mode v2?

Any CMP that sets the default and sends the update for all four signals. Google’s CMP partner programme includes Cookiebot and Usercentrics and Google states that you can also build your own banner. A certified CMP with TCF integration is only mandatory for publishers serving ads through AdSense, Ad Manager or AdMob. Whatever you use, verify the mapping, particularly that ad_user_data and ad_personalization are part of the update.

What are ad_user_data and ad_personalization?

They are the two signals new to v2. ad_user_data controls whether user data may be sent to Google for advertising. ad_personalization controls whether data may be used for personalised advertising and remarketing. Both must be granted for remarketing to work and since June 2026 they are the only control for the ads data flow from Google Analytics.

How many conversions does modelling recover?

Google’s 2021 figure is more than 70% of lost ad-click-to-conversion journeys on average, with the caveat that results vary widely. Google Ads modelling requires 700 ad clicks over 7 days per country and domain grouping, GA4 behavioural modelling requires an advanced implementation and at least 1,000 daily events with denied and 1,000 daily users with granted analytics storage over the documented periods. Low-traffic accounts may see little modelled data.

Do I need server-side tracking in addition to Consent Mode?

Not strictly, but combining them lets you enforce consent on infrastructure you control and improves data quality against ad blockers and Safari. Server-side tracking is not a consent bypass: denied-consent data must not be forwarded without a legal basis.

Summary: Consent Mode v2 Setup Checklist

• Decide Basic vs Advanced and document the GDPR trade-off
• Set all four consent defaults to denied on the Consent Initialization trigger, before any Google tag
• Add wait_for_update for returning-visitor stability
• Wire a CMP from Google’s partner programme (Cookiebot or Usercentrics) or your own banner
• Verify the update carries ad_user_data and ad_personalization, not only ad_storage
• Confirm the consent update fires all four signals on accept
• Validate the consent state on requests via the gcs and gcd parameters
• Stop relying on the Google Signals toggle for the Ads data flow and verify the defaults instead
• If using server-side, enforce consent at the server and never forward denied data
• Test the full flow in Tag Assistant and GA4 DebugView and check the consent mode status in Google Ads

Consent Mode v2 is not a one-time toggle. It is a signalling layer that has to be correctly wired, legally reasoned and continuously validated. If you want certainty that yours is recovering the data it should while staying GDPR-aware, our Consent Mode v2 implementation and conversion tracking compliance work cover exactly that.