Consent Mode v2: A Technical Guide to Getting It Right

Since March 2024, Google requires Consent Mode v2 for advertisers who reach users in the European Economic Area. Without it, remarketing audiences and some conversion features in Google Ads stop working for EEA traffic.

Most websites now have a cookie banner. Far fewer pass the visitor’s choice to Google correctly. This guide covers what Consent Mode does and where setups usually go wrong.

What Consent Mode does

Consent Mode is the way your website tells Google tags what the visitor agreed to. The banner (CMP) collects the choice, and Consent Mode passes it to GA4, Google Ads and Floodlight tags, which then adjust their behaviour.

Version 2 uses four parameters:

  • ad_storage: can advertising cookies be stored
  • analytics_storage: can analytics cookies be stored
  • ad_user_data: can user data be sent to Google for advertising
  • ad_personalization: can the data be used for personalised ads and remarketing

The last two are new in v2. A setup that still sends only ad_storage and analytics_storage is not complete.

Default and update

Consent Mode works in two steps.

  1. Default: before any tag runs, the page sets the default state, in the EEA normally “denied” for all four parameters.
  2. Update: when the visitor makes a choice in the banner, the CMP sends an update with the new values.

The order matters. If a tag runs before the default is set, it behaves as if consent was given. This is one of the most common errors we find: the CMP sends only the update, and there is no default at all.

Basic and advanced mode

In basic mode, Google tags do not load until the visitor accepts. If they decline, Google receives nothing.

In advanced mode, the tags load straight away with the default “denied” state and send cookieless pings without identifiers. Google uses these pings for conversion modelling in Google Ads and for behavioural modelling in GA4.

Modelling in GA4 has thresholds. The property needs at least 1,000 events per day with analytics consent denied for at least 7 days, and at least 1,000 daily users who accepted for at least 7 of the previous 28 days. Smaller websites often do not reach this, so modelled data will not appear even with a correct setup.

Which mode to use is a legal decision as much as a technical one. Advanced mode sends cookieless requests before consent, and some companies prefer not to do that.

Mistakes we see most often

  • No default state, only the update from the banner.
  • The default is set after GTM has already loaded, so the first page view is sent without consent information.
  • Only the two original parameters are set, without ad_user_data and ad_personalization.
  • The Meta pixel or other non-Google tags fire before consent. Consent Mode only controls Google tags; other tags need their own consent triggers in GTM.
  • The banner shows “Reject”, but the tags behave the same whichever button the visitor clicks.

How to check your own setup

Open the website in a private window, open the Tag Assistant preview and look at the Consent tab for the first event. You should see the default state before any tag fires, and an update after you click a button in the banner. Then reject all cookies and check in the Network tab that no Meta, TikTok or LinkedIn requests are sent.

Consent Mode and server-side tracking

Consent Mode also works with server-side GTM. The consent state is passed with each request to the tagging server, and the server tags respect it. On the server you can also drop or anonymise data for visitors who declined, before it reaches any platform.

Not sure your setup passes the visitor’s choice correctly? A tracking audit checks the default, the update, all four parameters and every non-Google tag on the site.