Google Consent Mode v2 tells your Google tags what they may do with a visitor’s data, based on the choice made in your cookie banner. It has four signals: ad_storage, analytics_storage, ad_user_data and ad_personalization. Set all four to denied before any tag loads, then update them when the visitor chooses. It does not replace a banner.
Tracking only helps if it is both accurate and allowed. That is why our tracking and website ecosystem service treats consent as part of the build, not a patch added later.
What is Consent Mode?
Consent Mode is a set of signals your site sends to Google tags. Tag Manager is one container that holds all your tracking tags, so each tool is added, changed and tested in one place. Consent Mode sits on top of it. A tag reads the signals and adjusts: it either stores cookies and sends full data, or it holds back.
It is not a cookie banner. A banner (a consent management platform, or CMP) asks the visitor. Consent Mode passes the answer to Google’s tags. You need both.
What do the four signals control?
Google’s consent mode overview defines them like this:
| Signal | What it controls |
|---|---|
| ad_storage | Storage, such as cookies, related to advertising |
| analytics_storage | Storage related to analytics, for example visit duration |
| ad_user_data | Sending user data to Google for advertising, including conversion measurement |
| ad_personalization | Personalised advertising, such as remarketing |
The last two were added in version 2. Google says ad_user_data and ad_personalization both need to be granted for personalised advertising to work.
What happens when a signal is denied?
Google’s documentation describes the effects:
- ad_storage denied: no new advertising cookies are written, and existing ones are not read.
- analytics_storage denied: tags do not read or write analytics cookies. Instead, cookieless pings are sent to Google Analytics.
- ad_personalization denied: personalised advertising, including remarketing, is switched off.
- ad_user_data denied: personal data is not used for online advertising, and conversion data tied to ad clicks becomes limited.
So a “no” from the visitor does not mean your reports go blank. It means they carry less detail.
How do you set it up in GTM?
Google’s guide to setting up consent mode on websites uses two calls. The default goes first, and the update goes after the visitor chooses.
- Set the default before any tag loads. All four signals start as denied:
gtag('consent', 'default', { ad_storage: 'denied', ad_user_data: 'denied', ad_personalization: 'denied', analytics_storage: 'denied' }). Google advises that CMPs set defaults for all four, and warns against setting them asynchronously. - Update when the visitor chooses. When they click Accept, send
gtag('consent', 'update', {...})with the signals they agreed to. A Reject sends nothing new, so the defaults stay denied. - Remember the choice. On the next page, read the stored choice and send the update again before the tags run. We also set a short wait so a stored choice is read first.
- Gate tags that do not read Consent Mode. Google’s own tags honour the signals. Others, such as a Bing or Meta tag, may need their own consent setting inside GTM, so check each one.
How do you check it works?
Use Tag Assistant. Google’s debugging guide says its Consent tab shows the API calls, so you can confirm all four signals were set and in the right order. Test three cases: first visit with no choice, after Accept, and after Reject. Then look at the cookies in your browser. If a cookie appears before a choice, a tag is not gated.
A common failure is order. If the default arrives after a tag has fired, the tag has already acted. Another is a banner whose Reject button does less than its Accept button. On the UK side, the regulator expects refusing to be as easy as accepting. We cover that in what changed in UK cookie rules.
Questions people ask
Do we still need a cookie banner? Yes. Consent Mode passes the visitor’s choice to Google tags. It does not collect the choice.
Does server-side tracking bypass consent? No. Moving a tag to a server changes where it runs, not whether you need permission.
Can we see how this is set up on a real site? Ours follows this pattern. The cookie policy lists what runs and when, and our free tracking check reads the public setup of your own site.
Not sure your banner and tags agree? Send the brief and we will look.
