Google Consent Mode v2: Set It Up Correctly

Olamide Sule, founder of Dolphin Analytics: a digital analytics expert based in London delivering solutions for agency and in-house clients.

Consent Mode v2 is the piece that decides whether a cookie banner quietly guts your GA4 numbers or barely dents them. Set up correctly, it keeps you compliant and still recovers most of the traffic a banner would otherwise hide. Set up wrong, it either fires tags before people have answered, which is a compliance problem, or it stays dark on every decline, which is a data problem. We set Consent Mode up for clients most weeks, and the misconfigurations below are the ones we actually find. Here is what each part does and how to wire it so it does neither.

This is the implementation guide. If your GA4 sessions already dropped after a banner went live and you want to work out how much you lost first, start with cookie consent blocking Google Analytics, then come back here to fix the configuration underneath it.

What is Google Consent Mode v2?

Google Consent Mode v2 is a signalling layer that tells Google how each visitor answered your cookie banner, so GA4 and Google Ads tags change what they collect instead of firing blind. It sits between your Consent Management Platform (CMP, the tool that shows the banner) and your Google tags, passing the visitor’s choice through as consent states. Google documents the whole model in its Consent Mode developer guide.

The “v2” part matters because it changed what the signal has to carry. In the v2 update Google required from March 2024, two advertising parameters became mandatory for any advertiser running remarketing or audiences in the European Economic Area. Miss them and Google Ads stops building audiences from your traffic, so v2 is not only a GA4 concern; it is what keeps paid campaigns fed under a consent banner.

Consent Mode is a signalling layer, not a cookie banner and not a CMP. It does not ask anyone for consent. Your CMP does that; Consent Mode carries the answer to Google’s tags. Teams often think installing a banner means Consent Mode is handled, and it is not: the banner and the signalling are two separate jobs that have to be wired together.

What are the four Consent Mode v2 parameters?

Consent Mode v2 controls four consent parameters, each a switch Google reads before a tag decides what to do. Two govern measurement and two govern advertising, and every one of them defaults to denied until your banner says otherwise.

Parameter	Controls	Owned by
analytics_storage	GA4 measurement cookies (the _ga cookie and session counting)	GA4
ad_storage	Advertising cookies used for conversion tracking and remarketing	Google Ads
ad_user_data	Whether user data may be sent to Google for advertising	Google Ads (v2)
ad_personalization	Whether that data may drive personalised remarketing	Google Ads (v2)

The first two existed in the original Consent Mode. Google added ad_user_data and ad_personalization in v2 so advertisers in the European Economic Area can keep running Google Ads audiences under a banner, provided the visitor agreed. Set the two advertising parameters to denied and Google Ads still measures conversions in aggregate through modelling, but it will not add those users to remarketing lists.

Basic vs advanced Consent Mode: which should you use?

Advanced Consent Mode recovers far more data than basic, so it is the right default unless a strict internal data policy rules out sending any signal from a declined visit. The two differ in what happens the moment a visitor declines, and that single difference decides how much of your reporting survives a consent banner.

	Basic Consent Mode	Advanced Consent Mode
On a decline	Tag never loads, nothing sent	Tag loads restricted, sends a cookieless ping
Data on declined visits	None	Modelled from anonymous pings
Recovery in GA4	No modelling possible	Behavioural modelling estimates the gap
Compliance	Compliant	Compliant (pings carry no cookies or identifiers)
Best for	Teams that cannot send anything on a decline	Almost everyone else

The recovery in advanced mode comes from modelling. When declined visits send anonymous, cookieless pings, GA4 uses consent mode modelling to estimate the sessions, users and conversions those visitors would have produced, then folds the estimates into your reports. The modelling needs a consistent volume of daily traffic and consented data to train on, so it switches on faster for busier properties than quiet ones. It never fully replaces observed data, but it closes most of the hole a raw banner leaves.

Basic mode is genuinely simpler to deploy and it is fully compliant. What it cannot do is recover anything, because a tag that never loads sends no signal to model from. Choose it only when a data policy forbids any transmission from a non-consented visit, and accept that the gap stays open.

How to set up Google Consent Mode v2 in Google Tag Manager

Setting up Consent Mode v2 in Google Tag Manager (GTM) means loading a denied default before anything fires, then letting your CMP flip the signals to granted when a visitor accepts. Work through it in order, because the order is where most setups go wrong.

1. Load a denied default on the Consent Initialisation trigger. GTM has a dedicated Consent Initialisation trigger that runs before every other trigger. The tag on it must set all four signals to denied. Most CMP templates do this for you (step 3); if yours does not, add a Custom HTML tag on that trigger with:

   <script>
     window.dataLayer = window.dataLayer || [];
     function gtag(){dataLayer.push(arguments);}
     gtag('consent', 'default', {
       analytics_storage: 'denied',
       ad_storage: 'denied',
       ad_user_data: 'denied',
       ad_personalization: 'denied',
       wait_for_update: 500
     });
   </script>

   The wait_for_update gives the CMP half a second to load a returning visitor’s stored choice before tags read the state.

2. Set region defaults if you serve mixed traffic. You can scope the denied default to EEA and UK regions and leave other regions granted, using the region field on the default command. Do this deliberately: defaulting the wrong region to granted is a compliance risk, and defaulting everyone to denied without modelling costs you data.

3. Connect a certified CMP template. Cookiebot, OneTrust, Cookie Script, Complianz and the rest publish Google-certified CMP templates that pass the banner’s answer to Consent Mode. In GTM go to Tags > New > Tag Configuration > Discover more tag types in the Community Template Gallery, search the CMP’s name, and add its template. In the template’s settings map each banner category to its signal: a Statistics or Analytics category updates analytics_storage; a Marketing or Advertising category updates ad_storage, ad_user_data and ad_personalization. Fire it on the same Consent Initialisation trigger. If the template sets its own denied defaults, use those and skip the manual tag from step 1; running both is how double defaults happen.

4. Choose advanced mode in the CMP settings. Advanced versus basic is usually a toggle inside the CMP template, not a separate build. Turn on advanced (sometimes labelled “send cookieless pings” or similar) so declined visits still signal.

5. Confirm your GA4 and Ads tags respect consent. Google tags read the consent state automatically, but check that your GA4 configuration tag and any Google Ads tags are not set to fire on a plain page-view trigger that ignores consent. The tag should wait for the consent state, not race it.

6. Publish, then verify every state. Do not trust the container preview alone; test the live behaviour across accept, reject and ignore before you call it done. The verification section below covers exactly what to look for.

Most of this is CMP configuration and trigger order, not custom JavaScript. When conversions rather than sessions are the thing that stopped, the fault often sits next to consent rather than in it, which our guide on GA4 not tracking conversions walks through separately.

The misconfigurations that quietly break Consent Mode

Most broken Consent Mode setups pass a glance and still lose or leak data, because the failure is in timing and mapping, not in whether the banner appears. These are the ones we see most often when we open a property.

• Defaults set to granted. If the default command grants consent before the banner is answered, tags fire on every visitor regardless of choice. That recovers sessions on paper and creates real GDPR and PECR exposure, which is a worse problem than an incomplete report.
• The update fires after the tags. Consent has to default to denied before your Google tags load, then update to granted on accept. If the update command runs after the tags have already fired, the first hit goes out in the wrong state and the numbers drift.
• The CMP is installed but not mapped. A banner can look compliant on screen while none of its categories are wired to the consent parameters. The visitor clicks accept, nothing updates, and the tags stay stuck in the denied default. This is the most common “it looks fine but the data is gone” fault.
• Basic mode left on by accident. Many CMP templates ship in basic mode. If nobody switched it to advanced, you are compliant and losing every declined visit with no modelling to recover it.
• Region defaults inverted. Scoping the denied default to the wrong regions, or forgetting to scope it at all, either over-collects where consent is required or over-restricts where it is not.

How do you verify Consent Mode v2 is working?

Verify Consent Mode v2 by loading your own site and testing all three answers a visitor can give: accept, reject and ignore. Use GA4 DebugView, Google Tag Assistant or the GTM preview pane, and watch the consent state on each tag as you go. The banner passing visually is not proof; the consent signal reaching the tag is.

Check each state:

• On accept: every parameter you granted should read granted, and the GA4 tag should fire a full hit with cookies set.
• On reject: with advanced mode configured, the GA4 tag should still fire a cookieless ping with analytics_storage at denied. No cookie, no identifier, but a signal Google can model from.
• On ignore (no answer): the tag should behave as a decline, sending the cookieless ping under the denied default, never a full hit.

If the tag stays completely silent on a decline, you are running basic mode or the pings are not configured, and you are losing that traffic. If the tag fires fully before you answer the banner, your defaults are granted or the update is racing the tags, and you have a compliance gap. Either way, the test tells you which fault you have before it costs you a quarter of reporting or a regulator’s attention.

For a wider sweep of the same before-and-after checks across a whole GA4 property, our GA4 audit checklist runs the same diagnosis end to end.

Getting consent right is one job, not a trade-off

Compliant and accurate are the same setup done properly, not two settings you balance against each other. The instinct after a data drop is to loosen the banner or default consent to granted, and every version of that trades a real legal risk for a cosmetic recovery. Advanced Consent Mode exists precisely so you do not have to make that trade: the pings stay anonymous and cookieless, so they are compliant, and they still give GA4 enough to model the gap.

The stakes are real on both sides. We do this consent and tracking work for clients most weeks, and on one engagement it helped a client avoid exposure to a potential GDPR fine of up to €20M. The same setup that removes that exposure is the one that stops the data loss.

If you want to see what consent setup a site is currently exposing before you touch anything, Sonar scans a URL from the outside and reports the tags, pixels and consent configuration it can prove from the scan, no account access needed. When the configuration needs real work, reworking the CMP, the GTM tags and Consent Mode together is a scoped project rather than a toggle: see how we approach tracking and consent, or talk to us first and tell us what dropped and when. We will come back with what we think broke and what the fix would involve.

This page is general information about analytics configuration, not legal advice. GDPR and PECR obligations depend on your own circumstances, so confirm your position with a data protection specialist before acting on it.