← Blog

Consent Mode v2 for UK Websites: What Changed and How to Get It Right

13 July 2026 · 8 min read · by The Tracking People

If your site uses Google Analytics, Google Ads, or any Google marketing product and serves users in the UK or EU, Consent Mode v2 is not optional. It has been a requirement since March 2024 under Google's EU User Consent Policy, and enforcement has been ramping up steadily. If you ignore it, your data degrades, your ad targeting breaks, and your conversion reporting becomes unreliable.

This post explains what Consent Mode v2 actually does, what changed from v1, what breaks when you get it wrong, and how to implement it properly using a CMP or a custom integration with GTM.

What Consent Mode does

At its core, Consent Mode is a signalling layer between your consent management platform (CMP) and Google's tags. Instead of blocking Google tags entirely when a user declines cookies, Consent Mode tells Google what the user has consented to and lets Google's tags adjust their behaviour accordingly. Tags still fire. They just fire with reduced capabilities.

This matters because it means you still get some data even from users who decline cookies. Google calls this "modelling" and it plugs gaps in your reporting that would otherwise be dark holes. No consent? Google models the missing data based on behaviour patterns from users who did consent.

What changed in v2

Consent Mode v1 had two signals: analytics_storage and ad_storage. That was it. Consent Mode v2 adds two more:

  • ad_user_data: controls whether personal data can be sent to Google for advertising purposes. If denied, Google cannot use the data for building audiences or remarketing.
  • ad_personalization: controls whether Google can use the data for personalised advertising. If denied, remarketing and personalised ad targeting are disabled.

These two new signals are the critical ones. Without them properly configured, Google Ads in particular stops working as expected. Conversion measurement degrades. Audiences stop populating. Remarketing lists shrink to nothing.

What happens if you ignore v2

Google's enforcement is gradual but real. The immediate consequences of missing or incomplete Consent Mode v2:

  • Conversion modelling stops. Google cannot fill gaps in your conversion data without the full consent signal set. Your reported conversions drop by 20-40% overnight, not because fewer people converted, but because Google stopped modelling the ones it could not directly observe.
  • Audience lists degrade. Without ad_user_data and ad_personalization signals, Google cannot build or refresh remarketing audiences properly. Your audience sizes shrink, and the ones that remain are less accurate.
  • Google Ads performance suffers. Smart Bidding relies on accurate conversion data. When conversion modelling stops, bidding algorithms lose signal quality. Cost per acquisition drifts upward.
  • Compliance risk. If you are using Google services without proper consent signalling, you are not compliant with Google's own policies. That can lead to account restrictions. Not a theoretical risk. It happens.

Advanced vs Basic Consent Mode

Google offers two implementation approaches, and the difference matters more than most people realise.

Basic Consent Mode blocks Google tags entirely until the user consents. If they decline, no data is sent at all. This is the safer option from a pure privacy perspective, but it means you get zero data from users who decline. No pageviews, no events, no modelling. Your analytics become a subset of reality.

Advanced Consent Mode allows Google tags to fire in a restricted state even when consent is denied. The tags send cookieless pings to Google, which uses them to model conversions and fill reporting gaps. No personal data is collected, no cookies are set, but Google still receives enough signal to make its modelling algorithms work. This is what Google recommends for most implementations.

The practical difference is significant. With Advanced Consent Mode, Google can recover an estimated 50 to 70 percent of the data lost due to consent decline through modelling. With Basic Consent Mode, that data is simply gone. If you run Google Ads campaigns and depend on accurate conversion reporting, Advanced Consent Mode is almost certainly what you want.

To implement Advanced Consent Mode, you need the default consent state set to "denied" before tags load, and the tags must be configured to fire on every page regardless of consent state. The consent signals tell Google what data it can and cannot use. The tags do not set cookies or collect personal data when consent is denied. They operate in a restricted mode automatically.

If you are unsure which mode you are running, check your GTM container. If your Google tags have triggers that wait for a consent update event before firing, you are running Basic mode. If they fire on All Pages and rely on the built-in consent checks, you are running Advanced mode.

Implementing Consent Mode v2 with GTM

There are two ways to implement Consent Mode v2. The easier path is using a CMP that supports it natively (Cookiebot, CookieYes, Usercentrics, Silktide, and most major platforms all do now). The CMP handles the consent collection and fires the consent signals automatically.

If you are doing it manually or building a custom integration, here is the technical outline:

  1. Set default consent state before GTM loads. This is the critical step. The default state must be set to "denied" for all consent types before any tags fire. Place this code above your GTM snippet in the head:
window.dataLayer = window.dataLayer || [];
function gtag() { dataLayer.push(arguments); }
gtag("consent", "default", {
  ad_storage: "denied",
  ad_user_data: "denied",
  ad_personalization: "denied",
  analytics_storage: "denied",
  functionality_storage: "denied",
  personalization_storage: "denied",
  security_storage: "granted",
  wait_for_update: 2000
});
  1. Update consent state when the user makes a choice. When your CMP captures the user's preferences, push an update event:
gtag("consent", "update", {
  ad_storage: userConsentedMarketing ? "granted" : "denied",
  ad_user_data: userConsentedMarketing ? "granted" : "denied",
  ad_personalization: userConsentedMarketing ? "granted" : "denied",
  analytics_storage: userConsentedAnalytics ? "granted" : "denied",
  functionality_storage: userConsentedPreferences ? "granted" : "denied",
  personalization_storage: userConsentedPreferences ? "granted" : "denied"
});
  1. Configure your GTM tags to respect consent. In GTM, every tag that fires Google services (GA4, Google Ads, Floodlight) needs the built-in Consent Overview settings checked. Go to the tag, expand Advanced Settings → Consent Settings, and ensure "Require additional consent for tag to fire" is set correctly for the consent types the tag needs.

Testing your setup

Do not trust that it works because the code is deployed. Test it:

  • Open your site in an incognito window. Open GTM Preview mode. Check that the Consent section shows "denied" for all types on the initial page load (before any consent interaction).
  • Accept all cookies. Verify that the Consent section updates to "granted" and that your GA4 and Google Ads tags fire with full capabilities.
  • Reject non-essential cookies. Verify that analytics and marketing consent types remain "denied" but the tags still fire (they just fire in consent-restricted mode).
  • Check GA4 DebugView. You should see consent state events arriving with the correct values. Navigate to Admin, then DebugView, and look for the consent_update event. Expand it to verify each consent type shows the expected state. If you do not see consent_update events, your CMP is not pushing the consent state correctly.
  • Check the Network tab. Open DevTools, filter by "collect" requests to google-analytics.com, and look at the request parameters. The gcs parameter encodes consent state. A value of G100 means analytics is denied. G111 means everything is granted. If these values do not change when you update your consent preferences, the integration is broken.
  • Test across browsers. Safari and Firefox handle cookies differently, and some CMPs behave inconsistently across browsers. Test in at least Chrome, Firefox, and Safari.

Common mistakes

  • Default set to "granted". This is the most common error. If your default consent state grants everything and the user never interacts with the banner, you are collecting data without consent. That is a GDPR violation and a Google policy violation. Default must be "denied" for non-essential consent types.
  • Missing ad_user_data and ad_personalization. If your consent implementation only sets analytics_storage and ad_storage like v1 did, you are not compliant with v2. Google will treat this as no consent for the missing signals.
  • wait_for_update too short. If your CMP takes 3 seconds to load but your wait_for_update is set to 500ms, Google tags will fire before the user's consent choice is known. Set it to at least 2000ms.
  • CMP loads after GTM. The default consent state must be set before GTM loads. If your CMP loads asynchronously and sets consent after GTM fires, your initial pageview will be sent without proper consent signals. Fix the load order.

Choosing a CMP for UK sites

Your CMP is the front end of your consent implementation. It handles the banner, the preferences, and the consent update signals that Consent Mode relies on. The CMP you choose matters because a poorly integrated CMP will break your entire consent pipeline regardless of how well your GTM setup is configured.

For UK and EU compliance, your CMP must support Consent Mode v2 natively. That means it must fire all six consent types in the gtag consent update call, not just the legacy two. Most major CMPs now support this: Cookiebot, CookieYes, Usercentrics, OneTrust, Silktide, and Termly all have Consent Mode v2 integrations. But "supports" and "works out of the box" are not the same thing. We have seen CMPs that claim v2 support but only fire analytics_storage and ad_storage in their default configuration, missing ad_user_data and ad_personalization entirely.

When evaluating a CMP, verify the following:

  • It fires a gtag consent update call with all six consent types when the user makes a choice.
  • It sets the default consent state to "denied" before any Google tags load.
  • It respects the wait_for_update timeout so Google tags do not fire before the user's choice is known.
  • It works with your GTM implementation without requiring custom JavaScript workarounds.
  • It stores consent preferences so returning visitors do not see the banner again on every visit.

If you are using a free CMP, test it thoroughly. Free tiers often lack full Consent Mode v2 support or have limitations on the number of consent types they can handle. The cost of a proper CMP (typically 10 to 50 pounds per month for small sites) is trivial compared to the cost of broken consent that degrades your entire measurement stack.

Need help getting Consent Mode v2 right?

We audit and implement Consent Mode v2 for agencies and their clients. If your setup is not working, or you are not sure whether it is compliant, get in touch. We will review your implementation and tell you exactly what needs fixing. No pitch. No retainer. Just a clear report.

A NORTH //{DIGITAL} COMPANY LinkedIn Privacy Policy