If Google Analytics or Google Ads has warned you about missing ad_user_data or ad_personalization consent, this guide is for you. It covers what Consent Mode v2 is, how to set it up and how to check it.
What Consent Mode is, and what it is not
Consent Mode is a way for your website to tell Google’s tags what a visitor agreed to. Google’s tags read that signal and change how they behave: for example, not writing advertising cookies when consent for advertising storage is denied.
Consent Mode is not a cookie banner. It does not ask the visitor anything. Something else, usually a consent management platform, has to ask and send the result to Google.
It is also not blocking. Consent Mode only changes the behaviour of tags that read it, mainly Google’s own. A Meta pixel, a chat widget or a video embed does not read Google’s signal.
The four core v2 signals
Version 2 added two signals to the core set. Google describes them like this:
| Signal | What it controls (Google’s wording, shortened) |
|---|---|
ad_storage | Storage, such as cookies, related to advertising |
analytics_storage | Storage, such as cookies, related to analytics, for example visit duration |
ad_user_data | Consent for sending user data to Google for online advertising |
ad_personalization | Consent for personalised advertising |
If your banner sends only the first two, Google Analytics may warn that ad_user_data or ad_personalization consent is missing for traffic from the European Economic Area (EEA).
Consent Mode also has three further storage signals: functionality_storage, personalization_storage and security_storage.
Default first, then update
The order of events matters:
- Default. As the page loads, before any Google tag runs, the site sets a default state for each signal.
- Update. When the visitor makes a choice, the site sends an update, and Google’s tags adjust straight away.
If Google’s tags start before the default is set, they may act as if consent was granted. This is the most common Consent Mode mistake, usually caused by script order.
How Cookie Compliance sends the signals
Cookie Compliance sets the default and sends the update for you:
- Before a choice, the banner sends a consent default with every mapped signal set to denied. While it is holding tags back, the default also tells Google’s tags to wait for an update.
- When a click changes one or more mapped values, the banner sends an update. A click that leaves every mapped value the same sends none.
- For a returning visitor, the default already carries the choice they saved earlier.
- Which signals are granted depends on your category mapping. Each Google signal is mapped to one of the banner’s purpose categories, and a signal is granted when the visitor accepts that category. Unless you change it, the mapping is:
| Google signal | Banner category |
|---|---|
ad_storage, ad_user_data, ad_personalization | 4 Ad Personalisation |
analytics_storage | 3 Site Optimisation |
functionality_storage, personalization_storage, security_storage | 2 Content Personalisation |
Blocking also holds Google’s loaders (Google Tag Manager and gtag.js) until the visitor accepts. The browser may still request those files, but their code does not run before consent.
How to set it up with Cookie Compliance
Google Consent Mode is on both the Free and Professional plans. It is off for a new app, so turn it on.
1. Turn it on
- Dashboard: go to Configuration → Consent Signals, switch on Google Consent, then click Publish Now.
- WordPress plugin: go to the Cookie Consent tab → Laws, languages & signals → Consent signals → Google Consent Mode v2.
2. Put Google’s tags below the banner
The Cookie Compliance snippet must be the first script in <head>. Leave your Google tag (gtag.js) or Google Tag Manager container below it. You do not need to edit Google’s snippet.
3. If you use Google Tag Manager
- Do not install the banner as a tag inside GTM. It must sit in the page
<head>above the container. See Cookie consent with Google Tag Manager. - Do not set a consent default anywhere inside GTM, for example with
gtag('consent', 'default', …)in a Custom HTML tag. Cookie Compliance already sets the default, and a second one can conflict.
What to expect when it is on
Switching Consent Mode on does not change blocking. Google’s loaders belong to the Content Personalisation category and are held until the visitor accepts it, either way. Tags GTM then fires are held if they match a tracker pattern. Tags that match none run, so check them with the test guide.
How to check that it works
In Tag Assistant
Google’s own steps, in short. Start in a fresh private window or with saved consent cleared; a returning visitor’s default already carries their choice. Cookie Compliance holds the container until the visitor accepts, so Tag Assistant usually connects only after step 2. The default is still recorded first.
- Open Tag Assistant and enter your site’s address. Your site opens in a new tab. If Tag Assistant says it could not connect, Google notes that your container may be blocked from loading.
- On your site, accept all in the banner. If the container was held, Tag Assistant should now connect.
- In Tag Assistant’s Summary, select the earliest Consent event. Under API Call, check every signal you mapped: each should be set and start as denied. That may be all seven, not just the core four.
- Select the most recent Consent event and check that the mapped signals were updated to match your choice.
- Under Tags, click a tag to see whether it behaved according to the consent state.
In the browser
In a private window, before clicking anything in the banner:
- Application → Cookies should show no Google Analytics or Ads cookies, such as
_gaor_gcl_au. - Network should show no data requests such as
google-analytics.com/g/collect. The GTM or gtag.js file itself may be requested, because browsers fetch script files early. A held file’s code does not run.
After you accept the relevant purposes, visit a page or take an action where your tags fire. Their cookies may then appear. GA4 warnings about missing v2 signals do not clear instantly; give Google time to process new traffic.
Consent Mode does not replace blocking
Blocking stops non-essential scripts from running before a choice. Consent Mode tells Google’s tags what the visitor chose when they do run. Cookie Compliance supports both, within its limits. On the Free plan, each page view where the banner loads counts as a visit. Once a site passes the Free plan’s visit limit (see Pricing) for the current 30-day cycle, blocking stops and consent records are no longer saved to our server. The visitor’s choice is still stored in their browser, and if Consent Mode is on and signals are mapped, Consent Mode signals continue. Signals for Microsoft and Meta tags are Professional-plan features. See pricing and Cookie auto-blocking.
FAQ
Is Consent Mode v2 required?
Three things get mixed up here:
- The law decides when you need consent, depending on where your visitors are.
- Google’s EU user consent policy requires sites using certain Google products to get legally valid consent from users in the EEA, the UK and Switzerland where it is required.
- Consent Mode is how Google’s tags learn the result. It does not collect consent.
Whether you need Consent Mode depends on the Google products and features you use. Check Google’s requirements for them.
Why does googletagmanager.com appear in the Network tab before anyone has consented?
The browser may request the file before the banner holds it. A held file’s code does not run. Check that there are no Google cookies and no data requests such as collect. If there are, see the test guide.
Does Google Consent Mode cost extra with Cookie Compliance?
No. It is included on both the Free and Professional plans.