Google Consent Mode v2

Since 6 March 2024, version 2 has effectively been a prerequisite for using Google Ads and Google Analytics with their full range of functions in the European Economic Area.

The most important sentence first, because it is the one most often misunderstood in practice: consent mode does not make tracking lawful. It ensures that a decision already made is passed on technically. Anyone without an effective banner has a legal problem even with perfectly configured consent mode. When consent is needed is explained in the practical guide consent mode and Section 25 TDDDG.

Why Consent Mode v2 exists: the DMA, not the TDDDG

The trigger for version 2 was not the German Telecommunications and Digital Services Data Protection Act, nor directly the GDPR, but the Digital Markets Act. The DMA obliges designated gatekeepers to be able to demonstrate separate consent for combining and cross-using personal data across services. Google passed this requirement on to its own advertising products: anyone in the EEA who wants to use Google Ads with personalisation, remarketing audiences or conversion measurement must supply the corresponding consent signals.

This origin explains the two parameters that distinguish version 2 from version 1. It was not about cookies in the narrower sense but about whether user data may be transmitted to Google and used for personalisation.

The parameters at a glance

The first four are relevant for working with Google Ads and Analytics. The other three have existed since version 1 and are rarely set in a differentiated way in practice.

Default and update: the order is decisive

Technically, consent mode consists of two commands. The default command sets the state before the user has clicked anything; in the EEA, this typically means all relevant parameters set to denied. The update command overwrites this state as soon as a decision has been made.

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

// after the decision in the banner:
gtag('consent', 'update', {
  'ad_storage': 'granted',
  'ad_user_data': 'granted',
  'ad_personalization': 'granted',
  'analytics_storage': 'granted'
});

The most common implementation mistake lies right here: the default command must run before any Google tag fires. If it is set too late or forgotten altogether, tags assume a default state that is not permitted in the EEA. The update command, in turn, should follow immediately after the user's decision; if the page first loads with consent denied and then reloads with consent granted, Google loses decisive data points according to its own documentation.

Basic mode and advanced mode

Both variants meet the formal requirement. They differ in what happens before consent has been given.

• Basic mode: the Google tags are only loaded once the user has consented. If they decline, nothing happens: no request is sent to Google. From a data protection point of view, this is the conservative variant and the one that is easiest to explain to a supervisory authority.
• Advanced mode: the tags load immediately and, even if consent is declined, send so-called cookieless pings containing the consent status. These pings are the data basis for Google's conversion modelling, which estimates missing conversions statistically.

The decision between the two is not a technical detail but a trade-off. Advanced mode delivers more complete reports but also transmits data to Google when consent is declined, and data protection experts give different answers to the question of whether this ping is permissible without consent. Anyone in doubt is safer with basic mode and accepts gaps in measurement in return.

A sober note on modelling: it only kicks in above certain data volumes. Smaller shops often see no modelled conversions at all and therefore gain little from advanced mode, while bearing its full legal risk.

Real-world example: the consolidation in Google Analytics 4

Google is gradually restructuring the controls so that only the consent mode signals count. On 15 June 2026, Google Signals was switched over: instead of dual control via the Google Signals setting in Analytics and consent mode, consent mode alone within Google Ads now decides whether Google Ads cookies and IDs are collected. The same step has been announced for ads personalisation later in 2026; then ad_personalization alone will control whether data is used for personalised advertising. Google documents the details in its developer documentation on consent mode.

The practical consequence: property settings in Analytics that were set years ago and not touched since lose their effect. Anyone who uses audiences or conversion imports in Ads and has relied on these old switches should check the consent signals that their CMP actually sends, not the ones configured in the CMP's admin area.

Consent mode, CMP and banner: who does what

The division of labour is simple but is regularly mixed up:

1. The banner asks the question and must meet the legal requirements in doing so: informed, voluntary, granular and with a reject option that is just as easy to reach as consent.
2. The consent management platform documents the decision, manages withdrawal and makes it available technically.
3. Consent mode translates it into the four parameters and passes it on to the Google tags.

Mistakes at level one cannot be repaired at level three. A banner without an equivalent reject button remains open to challenge even if the signals are set cleanly from a technical point of view. Conversely, an exemplary banner is of little use if the signals never reach Google; then audiences and conversions are missing without anyone noticing why.

Typical implementation mistakes

• Advanced mode as an excuse. "We track anyway" is not a permissible interpretation. The cookieless ping does not replace consent.
• Only v1 parameters set. Anyone who does not transmit ad_user_data and ad_personalization loses remarketing audiences and personalisation in the EEA, usually unnoticed until a campaign fails to deliver.
• The tag manager loads before the default. Check the order; do not assume it.
• Withdrawal without effect. When the user withdraws their consent, an update with denied must follow. A tick that merely flips in the CMP interface is not enough.
• No evidence. The accountability obligation requires that you can document the state of the banner and the consents. Dated screenshots of the configuration are the minimum.

Server-side tagging does not change consent

A variant that is regularly sold as a workaround: you move tag processing to your own server, and that supposedly settles the consent question. That is wrong. Section 25 TDDDG is tied to access to information on the end device, not to which server subsequently receives the data. If an ID is set or read in the browser, consent remains necessary, regardless of whether the request goes to Google or to your own subdomain.

Server-side tagging makes sense for other reasons: better control over which fields go to third parties at all, lower load in the browser and more robust measurement. Consent mode continues to run; the signals are simply passed to the server container. Anyone who does not pass consent through cleanly in this architecture has invested the effort and still has a gap.

How to check the implementation

A consent mode configuration cannot be judged from a screenshot of the CMP interface, only from what the browser actually sends. Three checks are enough for a reliable statement:

1. The state before the decision. Open the page in a fresh profile without touching the banner. In the developer tools, check whether any requests go out to Google domains at all and which consent status they carry. In basic mode, nothing should go to Google here.
2. The transition. Decline, then consent in a second run. In both cases, an update call should follow, including when consent is declined. If it is missing there, the refusal is invisible to Google.
3. Withdrawal. Grant consent, use the page, then withdraw it via the withdrawal link. After that, the parameters must be back on denied and the corresponding cookies deleted. This step is skipped most often in practice and is the first thing noticed in an audit.

Google Tag Assistant shows the consent status for each tag and makes visible whether a tag fired with granted or denied. For ongoing monitoring, it is worth repeating these three runs after every major release: a deployment that shifts the loading order in the tag manager silently pushes the default command back, and nobody gets an error message about it.

Anyone who wants to document this records the date, the URL checked, the browser and the result of the three runs. This is not bureaucracy for its own sake: the accountability obligation under Article 5(2) GDPR requires that compliance can be demonstrated, and a log of these checks is the simplest evidence that a marketing team can keep without legal support.

Frequently asked questions about Google Consent Mode v2

Is Consent Mode v2 mandatory?

It is not a legal obligation but a Google requirement. Without the signals, central functions of Google Ads and Google Analytics are not available, or only to a limited extent, in the EEA. The legal obligation to obtain consent arises independently of this from Section 25 TDDDG and the GDPR.

What is the difference between v1 and v2?

Version 2 adds the two parameters ad_user_data and ad_personalization. They separate the transmission of user data to Google and its use for personalised advertising from the pure cookie question.

Basic or advanced: which is right?

Both can be implemented lawfully. Basic mode is the more data-economical variant and easier to defend; advanced mode delivers modelled data but sends pings even without consent. With small data volumes, advanced mode often brings no measurable advantage.

Does consent mode replace my consent management platform?

No. The CMP obtains consent and documents it; consent mode merely transmits the result to Google tags.

Does consent mode also work for other providers?

The parameters are a Google specification and are evaluated by Google tags. Other providers need their own connections to the CMP. A well-configured consent set-up therefore always controls more than just Google.