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 privacy-preserving, cookieless signals depending on which mode you choose.

Consent Mode v2 became effectively mandatory on 6 March 2024 for any advertiser in the European Economic Area (EEA) who wants to keep using Google Ads personalisation, remarketing and audience features. The change was driven by the EU Digital Markets Act (DMA), which requires Google to obtain documented consent before using personal data for advertising. Without correctly wired v2 signals, Google stops populating remarketing lists and audience targeting for EEA traffic.

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. 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.

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. 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, and you lose the conversion modelling benefit.

Advanced Mode

In Advanced mode, Google tags load on every page, but their behaviour is governed by the consent state. Before consent and on denial, the tags send cookieless pings: small, aggregated, non-identifying signals that contain no cookies and no client identifiers. Once the user consents, full measurement resumes.

• Enables conversion modelling, because Google has a baseline of cookieless pings to model from.
• Recovers a meaningful share of the conversions you would otherwise lose to the cookie banner.
• 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 new 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

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.

You set defaults before any tag fires, then update them when the user interacts with your banner. A correct default state looks like this in Google Tag Manager via a Consent Initialization trigger, or directly through gtag:

// Default state: everything denied until the user decides.
// wait_for_update gives the CMP time to read a stored choice.
gtag('consent', 'default', {
  ad_storage: 'denied',
  ad_user_data: 'denied',
  ad_personalization: 'denied',
  analytics_storage: 'denied',
  wait_for_update: 500
});

When the user accepts, the CMP fires an update:

// Called by your CMP after the user grants consent.
gtag('consent', 'update', {
  ad_storage: 'granted',
  ad_user_data: 'granted',
  ad_personalization: 'granted',
  analytics_storage: 'granted'
});

The default state must be set as early as possible in the page lifecycle, before any Google tag has a chance to run. Setting it too late is one of the most common misconfigurations and silently breaks the whole model.

CMP Integration: Cookiebot, Usercentrics and Default States in GTM

Google requires a Google-certified CMP for Consent Mode v2 to function correctly with the Ads ecosystem. Cookiebot and Usercentrics are the two most widely deployed certified platforms in the DACH market. Both can drive the consent signals automatically, but the integration details matter.

The Standard GTM Integration Flow

1. Set defaults first. Use a Consent Initialization - All Pages trigger in GTM that sets 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

Cookiebot has a built-in Consent Mode integration. In template-based GTM setups, the Cookiebot CMP template can map its consent categories (statistics, marketing) directly onto the four Google signals. Verify that the marketing category maps to both ad_storage and the two new advertising signals, not just ad_storage. A common mistake is leaving ad_user_data and ad_personalization unmapped, which silently disables remarketing.

Usercentrics

Usercentrics offers a dedicated Consent Mode v2 setting and a GTM template. Enable the v2 signals explicitly in the Usercentrics admin, then confirm the data layer events carry all four signals. Usercentrics can run in either Basic or Advanced mode depending on configuration, so check that the selected mode matches your documented decision.

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. A certified CMP keeps them consistent, but you should not assume one implies the other is correctly configured.

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.

According to Google, conversion modelling can recover over 70% of the conversion paths lost to cookie rejection in Advanced mode. Treat this as a vendor-published figure: it is Google’s own number, the real uplift varies by traffic volume, conversion rate and consent rate, and modelling requires a minimum data threshold before it kicks in. Low-traffic accounts may see little or no modelled data.

The scale of the problem makes modelling relevant. In Germany, realistically around 40% of users reject cookies, which means without a recovery mechanism you can be missing roughly 30 to 50% of your conversion data. 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.

GDPR, TDDDG and Schrems II: The Legal Context

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.

The German Cookie Law

Cookie and device-access consent in Germany is governed by the TDDDG (the renamed TTDSG), the relevant German law since 13 May 2024. It requires active consent before storing or reading information on a user’s device. Violations can be fined up to 300,000 EUR. This is the legal basis for why you must 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 some information (page context, timestamp, an aggregated signal) 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.

Schrems II and the Data Privacy Framework

Data sent to Google involves transfer to a US company. The EU-US Data Privacy Framework (adequacy decision, July 2023) currently makes these transfers permissible again after Schrems II invalidated Privacy Shield. However, the framework is widely regarded as unstable: the privacy group noyb has signalled it will challenge it, and a potential “Schrems III” ruling could change the picture. Build with this residual risk in mind rather than assuming permanence.

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

Consent Mode is a client-side signalling layer. Server-side tracking (server-side GTM) 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.

// Conceptual server-side guard: only forward when consent is present.
// The consent state is read from the incoming event, not assumed.
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.
• 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 category mismatch. The CMP’s marketing category maps to only some of the advertising signals, so consent is partially lost.
• 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.
• 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 GTM Preview / Tag Assistant. Confirm the default state sets all four signals to denied before any tag fires.
2. Check the consent update on accept. Click accept on your banner and verify all four signals flip to granted.
3. Inspect network requests. In Advanced mode, before consent you should see cookieless pings (requests with gcs parameters reflecting the denied state). After consent, full requests.
4. Read the gcs parameter. The Google consent signal string (for example G100, G111) encodes the consent state on each request, a fast way to confirm the signal is travelling.
5. Validate in GA4 DebugView. Confirm events arrive with the expected consent state and that denied-consent traffic behaves as your chosen mode dictates.

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. Advanced mode loads tags on every page and sends cookieless pings before and after a denial, which enables conversion modelling. Basic favours strict data minimisation, Advanced favours data completeness.

Is Google Consent Mode v2 mandatory?

For advertisers in the EEA using Google Ads personalisation, remarketing or audience features, yes, effectively since 6 March 2024. Without correctly configured v2 signals, Google stops populating those features for EEA traffic. The DMA is the underlying driver.

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?

A Google-certified CMP. Cookiebot and Usercentrics are the most common in DACH. Both can drive all four consent signals, but the category-to-signal mapping must be verified, particularly that the marketing category maps to ad_user_data and ad_personalization.

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.

How many conversions does modelling recover?

Google states conversion modelling can recover over 70% of paths lost to cookie rejection in Advanced mode. That is a vendor figure, actual uplift depends on traffic volume, consent rate and a minimum data threshold. 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 before any Google tag
• Add wait_for_update for returning-visitor stability
• Wire a Google-certified CMP (Cookiebot or Usercentrics)
• Verify the marketing category maps to ad_user_data and ad_personalization
• Confirm the consent update fires all four signals on accept
• Validate cookieless pings (Advanced) via the gcs parameter
• If using server-side, enforce consent at the server and never forward denied data
• Test the full flow in GTM Preview and GA4 DebugView

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.