Consent Mode v2 for Developers: Sequencing and Tag Assistant Tests

Consent Mode v2 is Google’s signal layer for telling Analytics and Ads tags what a visitor has actually agreed to. It runs on four signals: ad_storage, analytics_storage, ad_user_data, and ad_personalization. If your site sends data to Google Ads or GA4 from EEA or UK visitors, implementing it properly isn’t optional.

TL;DR:

• Using Consent Mode v2 is mandatory for sites with visitors in the EEA or UK if they process data through Google Ads or GA4, especially for personalization and remarketing features.
• Proper implementation requires declaring all four signals before tags load and updating consent immediately after the visitor’s choice to ensure accurate data collection.
• Failure to wire signals correctly or to test consent updates can cause significant measurement gaps, affecting remarketing, attribution, and conversion tracking.
• Advanced Consent Mode allows tags to load with denied consent and uses statistical modelling to fill reporting gaps, but it only works reliably on high-traffic sites.
• Most common errors include neglecting the ad_user_data and ad_personalization signals, misordering scripts, and not reapplying consent choices for returning visitors.

What is Consent Mode v2 and why does it matter?

Consent Mode v2 isn’t a cookie banner. It’s a messaging protocol that sits between your consent banner and Google’s tags, telling gtag.js and Google Tag Manager how to behave once a visitor makes a choice. You still need a Consent Management Platform (CMP) to actually collect that choice and display the banner. Consent Mode just carries the answer to Google in a format its systems understand.

The reason this matters now rather than at some vague point in the future is enforcement. Since March 2024, Google has required the two newer v2 parameters, ad_user_data and ad_personalization, for any advertiser using personalisation, remarketing, or conversion measurement on EEA, UK, or Swiss traffic. Skip them and Google quietly switches off the advertising features that rely on that data, whatever your CMP says on the front end.

Without correctly wired signals, several things degrade at once:

• Remarketing audiences shrink or stop refreshing altogether.
• Enhanced conversions and offline conversion imports lose accuracy.
• GA4 reporting develops gaps that modelling can only partly fill.
• Attribution across paid channels becomes less reliable, particularly for longer conversion paths.

This sits alongside wider EU policy pressure, including the Digital Markets Act and ongoing IAB Europe work on the Transparency and Consent Framework, both of which push platforms towards stricter, more granular consent handling. Consent Mode v2 is Google’s answer to that pressure, not a separate compliance product.

What do the four Consent Mode v2 signals control?

Each signal governs a distinct slice of what Google’s tags are allowed to do, and getting even one wrong has knock-on effects for measurement.

• ad_storage: controls whether ad-related cookies and cookie-based identifiers can be set or read. Denied means no ad click IDs, no remarketing cookies.
• analytics_storage: controls whether GA4 can set its own cookies and stitch sessions together using client and session identifiers. Denied means each hit arrives without persistent identity.
• ad_user_data: governs whether user data can be sent to Google for advertising purposes, including the raw signals behind enhanced conversions. Denied means that data simply isn’t shared, however good your tagging is elsewhere.
• ad_personalization: governs remarketing and personalised advertising specifically. Denied means a visitor won’t be added to remarketing lists or shown personalised ads, even if ad_storage happens to be granted.

Four total signals is a deliberate expansion from the original two, and it’s where a lot of legacy implementations quietly fail.

Mixed states are common and entirely valid. A visitor might grant analytics_storage but deny both advertising parameters, which is a realistic outcome when a banner offers granular choices rather than a blunt accept-all-or-nothing toggle. In that case GA4 keeps collecting cookie-based analytics data, but Ads receives nothing usable for personalisation or enhanced conversions from that visitor. Your tags need to handle that combination gracefully rather than assuming consent is all-or-nothing.

Should you use Basic or Advanced Consent Mode?

The choice between Basic and Advanced Consent Mode decides what happens the moment a page loads, before anyone has clicked anything on your banner.

Basic Consent Mode blocks Google tags from firing at all until consent is granted. Nothing loads, nothing pings, and visitors who decline get zero data recorded against them. It’s the simpler build and the more conservative choice, but it produces no data whatsoever for non-consenting users, which on a site with a high decline rate can leave real gaps in reporting.

Advanced Consent Mode takes a different route. Tags load immediately with denied defaults, and Google collects cookieless “pings”, stripped-down signals with no persistent identifiers attached. Google then uses statistical modelling to estimate conversions and behaviour for the users who declined, filling in some of what Basic mode simply loses.

Advanced mode tends to suit any site running meaningful ad spend, since the modelled conversions genuinely help close reporting gaps. That said, modelling only becomes statistically reliable once there’s enough event volume to work with, so a low-traffic site may see little practical benefit despite the extra build effort.

How do you set default and update consent states with gtag.js?

Sequencing is the single most important thing to get right here. Every default consent state must be declared before any Google tag has the chance to load, or the tag will fire under whatever default the browser happens to assume, usually the wrong one.

1. Load the consent default before gtag.js. Place the default call at the very top of your <head>, ahead of the Google Analytics or Google Ads tag snippet.
2. Declare all four v2 signals explicitly. Don’t rely on Google to infer a value you haven’t set.
3. Set wait_for_update so tags briefly hold before firing, giving your CMP time to respond with the visitor’s real choice.
4. Fire the update call the moment your CMP records a decision, whether that’s an explicit accept, a reject, or a partial, granular choice.
5. Persist the choice in your CMP’s own storage and reapply it via the default call on every subsequent page load, not just the first.

A typical default declaration looks like this:

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

That wait_for_update value, commonly set somewhere in the 300 to 500 millisecond range, gives your CMP a short window to respond before Google’s tags proceed on the default state regardless. Once the visitor makes a choice, the update call looks like this:

gtag('consent', 'update', {
  'ad_storage': 'granted',
  'analytics_storage': 'granted',
  'ad_user_data': 'granted',
  'ad_personalization': 'granted'
});

Two extra parameters are worth knowing about, even though they’re secondary to the four core signals. ads_data_redaction strips identifying information from ad clicks when consent is denied but you still want some redacted signal to reach Google. url_passthrough preserves click identifiers in the URL when cookies aren’t available, which helps recover some conversion data on denied sessions without breaching the consent choice itself.

Pro Tip: Never hard-code a default of “granted” anywhere in your codebase, even temporarily during testing. It’s an easy mistake to leave in production, and it silently defeats the entire point of consent mode for every visitor who hasn’t yet made a choice.

How do you implement Consent Mode v2 in Google Tag Manager?

Most sites run their tags through GTM rather than hand-coding gtag.js, and the wiring there follows a similar logic with different mechanics.

1. Use the Consent Initialization trigger on your default consent tag, firing on all pages. This trigger runs earlier than a normal Page View trigger, which matters because a Custom HTML tag tied to a standard trigger fires too late to catch tags that load immediately.
2. Build a separate update tag triggered by the custom event your CMP pushes to the dataLayer once a visitor makes a choice.
3. Map each of the four signals to a Data Layer Variable (DLV) pulled from your CMP’s event payload, rather than hard-coding values into the tag itself.
4. Check GTM’s Consent Overview panel for any tags running without a consent check attached. This surfaces tags that will fire regardless of what the visitor decided, which is a common oversight when new tags get added later without anyone revisiting consent settings.
5. If you run a server-side container, confirm that consent state is forwarded correctly from the client container. A common gap is a server container that receives events but drops the consent parameters somewhere in the pipeline, meaning GA4 or Ads never see the real state.

Pro Tip: Don’t assume a green tick in GTM’s preview mode means consent is actually reaching Google. A tag can fire successfully and still carry the wrong consent state if the CMP event was pushed before the default tag initialised.

Testing and debugging your consent mode setup

Getting the code right isn’t the same as confirming it works. Test each of these scenarios separately, since they often fail in different ways:

1. Fresh session, no interaction yet: open the site in an incognito window and confirm all four signals report as denied before any banner interaction.
2. Reject all: click decline and confirm tags either stop firing (Basic) or switch to cookieless pings (Advanced).
3. Accept all: confirm every signal flips to granted and full-fidelity data starts flowing.
4. Change consent later: revisit consent settings after initially accepting or declining, and confirm the update call fires again rather than being ignored.

Tag Assistant’s Consent tab is the fastest way to check this without digging through raw network traffic. It shows the consent state Google’s tags believe is active at each point, which is often the quickest way to spot a timing problem.

For a more granular check, open your browser’s network tab and inspect the requests going to Google. Two parameters tell you what was actually received: gcs encodes ad_storage and analytics_storage, while gcd encodes the two newer v2 signals. If either parameter shows a value that doesn’t match what your banner just recorded, the fault sits somewhere in the wiring between your CMP and Google’s tags, not in Google’s interpretation of consent.

Most timing issues trace back to one of two causes: a missing wait_for_update, or a CMP event that never gets pushed again after the container reloads. Both are worth checking first before assuming something more complicated has gone wrong. Testing across all four scenarios above, rather than just checking that the banner appears correctly, catches the ordering and wiring problems that a visual check alone will miss.

Common Consent Mode v2 mistakes worth fixing now

Most broken implementations share a small handful of root causes, and each is quick to fix once identified:

• Only the original two signals are declared. Sites migrated from v1 often forget to add ad_user_data and ad_personalization, which quietly degrades audiences and enhanced conversions without throwing any visible error.
• The default call loads after the Google tag. Even a few milliseconds of delay means the tag has already assumed a default consent state before your code has a chance to set the real one.
• The CMP’s dataLayer event never fires on repeat visits. A returning visitor with a stored choice needs that choice reapplied via the default call on every page load, not just remembered silently by the CMP.
• Tags added later in GTM bypass consent checks entirely. New tags don’t automatically inherit consent settings from existing ones, so each addition needs its own review.

MB Web’s audit checklist for fixing a broken consent mode setup

When we’re brought in to fix a Consent Mode v2 problem, we start with an inventory: every Google tag firing on the site, how the CMP is wired into the dataLayer, and whether the default call actually sits ahead of everything else in the page’s load order. From there we run Tag Assistant diagnostics and check the gcs/gcd parameters on live network requests, comparing what the CMP recorded against what Google actually received.

Most fixes turn out to be small once we’ve found the fault: reordering a script tag, tightening or loosening wait_for_update, or adding a missing consent check to a tag that someone added to GTM six months ago and never revisited. We’ve seen sites with a fully functional-looking banner where the consent signal never reached Google at all, purely down to event ordering.

After an audit, clients get a written summary of what we found, what we changed, and a screenshot record of the before-and-after network requests, so there’s a clear paper trail if a regulator or ad platform ever asks questions.

Consider hiring a specialist agency for technical implementation and audits

If you’d rather have someone check the wiring than trace gcs parameters yourself, specialists can perform this work, including GTM and gtag.js implementation, CMP integration, and testing to confirm signals are genuinely reaching Google rather than just looking right on the surface.

This suits marketers and website owners who know their consent setup needs attention but don’t have the time to work through sequencing and debug logs line by line. We also cover the wider technical health of a site alongside consent fixes, since a broken script order is often a symptom of deeper structural issues worth addressing at the same time. If measurement gaps have started affecting your paid campaigns, it’s also worth reviewing your SEO and PPC setup alongside the consent audit, since the two are more connected than they first appear.

Get in touch through our web design and development services page and we’ll take an honest look at what’s actually happening on your site before recommending anything.

Sources

• Set up consent mode on websites | Tag Platform
• Consent mode behaviour (Google support)
• Google Consent Mode v2: The Complete Implementation | CookieChimp

FAQ

Recommended

• Step by step web development: a beginner’s guide