Consent Mode v2 for UK Websites: What Changed and How to Get It Right
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 critical parameters:
- 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_dataandad_personalizationsignals, 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.
Strict Load Order Required: The default consent command MUST execute before GTM or any Google tags load in your HTML header. If tags fire even a microsecond before default consent is defined, unconsented hits will be dispatched.
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.
| Capability / Feature | Basic Consent Mode | Advanced Consent Mode |
|---|---|---|
| Tag Execution on Decline | Completely blocked by CMP / trigger | Fires in restricted cookieless mode |
| Conversion Modelling | Disabled (100% data loss for declined users) | Active (Recovers 50–70% of lost conversion data) |
| Cookie Placement | None on decline | No cookies written/read when denied |
| GTM Setup Complexity | Requires custom blocking triggers | Uses built-in GTM consent settings |
| Recommended For | Strict zero-ping compliance regimes | Performance-focused eCommerce & B2B Ads |
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.
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, follow these three sequential steps:
Step 1: Set Default Consent State
The default state must be set to "denied" for all consent types before GTM or any tracking script loads. Place this code snippet at the very top of your <head> section:
window.dataLayer = window.dataLayer || [];
function gtag() { dataLayer.push(arguments); }
// Establish initial baseline: Deny by default
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
});
Step 2: Dispatch Consent Updates on User Action
When the user selects their cookie preferences via your CMP banner, push an update event reflecting their exact choices:
// Broadcast updated user consent states
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"
});
Step 3: Configure Tag-Level Consent in GTM
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 simply because code was deployed. Verify each scenario systematically:
- Incognito Baseline Check: Open your site in an incognito window with GTM Preview mode. Ensure the Consent tab reports
"denied"across all types prior to banner interaction. - Accept All Verification: Click 'Accept All' and confirm that all six consent types update to
"granted"in real time. - Reject Non-Essential: Ensure analytics and advertising remain
"denied"while security remains"granted". - GA4 DebugView Inspection: Look for the
consent_updateevent in GA4 DebugView and inspect parameter values. - Network Header Payload Audit: Inspect requests to
google-analytics.com/g/collect. Thegcsquery parameter encodes consent:G100indicates denied, whileG111indicates full grant.
Decode the GCS String: In Chrome DevTools Network tab, filter by collect?v=2. Look at the gcs parameter: G1[ad_storage][analytics_storage] where 1 = granted and 0 = denied. For v2, also inspect gcd which encodes all four Google signals.
Common mistakes
- Default set to "granted": The most common and hazardous error. If default state is granted before user input, you are collecting data unlawfully. Default must always be "denied".
- Missing ad_user_data & ad_personalization: Failing to include the two new v2 signals causes Google Ads conversion modelling and audience generation to silently fail.
- wait_for_update timeout too low: If set below 2000ms, Google tags may time out and fire with denied state before the CMP finishes initializing.
- CMP loading after GTM: Asynchronous CMP scripts must never delay default consent initialization.
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. For UK and EU compliance, ensure your chosen vendor (Cookiebot, CookieYes, Usercentrics, OneTrust, Silktide) fires all six consent keys natively.
We audit and implement Consent Mode v2 for agencies and high-traffic brands. We'll inspect your GTM container, CMP signalling, and GA4/Google Ads payloads to ensure 100% compliance and zero data loss. No sales pitch. Just a clear technical report.
Request a Consent Audit