On 21 July 2025, Google began disabling conversion tracking, remarketing audiences, and ad personalisation for advertisers who had not implemented Consent Mode V2. There was no prominent announcement. No countdown timer. Accounts that had been running Google Ads campaigns for years woke up to find their conversion data had dropped by 90% or more. The data lost during those non-compliant months is permanently gone; Google does not backfill.
The requirement had been in force since March 2024. Google's EU User Consent Policy explicitly covers the European Economic Area, the United Kingdom, and Switzerland. UK businesses were included from day one. Yet a Cookie Information study in April 2024 found that only 26% of UK websites had implemented Consent Mode V2, and 84% were setting cookies before obtaining consent.
If your business runs Google Ads or uses GA4, this is not optional. And getting it wrong is arguably worse than not implementing it at all, because a misconfigured setup can leave you both non-compliant with UK privacy law and unable to track the data Google requires for its advertising features to function.
This guide explains what Consent Mode V2 actually does at a technical level, why it matters under UK law, how to implement it correctly, and where the most damaging mistakes occur.
What Consent Mode V2 actually does
Consent Mode is a JavaScript API that communicates your visitors' consent choices to Google tags. It tells Google Analytics 4, Google Ads, Floodlight, and the Conversion Linker how to behave based on whether a user has accepted or declined cookies through your consent banner.
The mechanism is built on two commands that fire through the dataLayer.
The first is the default command, which sets the initial consent state before the user interacts with your banner. For UK businesses, every parameter should default to denied:
gtag('consent', 'default', {
'ad_storage': 'denied',
'ad_user_data': 'denied',
'ad_personalization': 'denied',
'analytics_storage': 'denied',
'wait_for_update': 500
});
The second is the update command, which fires when the user makes a choice. If they accept, the relevant parameters switch to granted:
gtag('consent', 'update', {
'ad_storage': 'granted',
'ad_user_data': 'granted',
'ad_personalization': 'granted',
'analytics_storage': 'granted'
});
That is the entire mechanism. Everything else is configuration.
The four parameters
Version 2, released in November 2023, added two parameters to the original two. Understanding what each controls is essential to getting the implementation right.
ad_storage and analytics_storage are what Simo Ahava calls "upstream" qualifiers. They control whether Google tags can read and write cookies on the user's device. When ad_storage is denied, no advertising cookies are set. When analytics_storage is denied, no first-party analytics cookies (_ga, _gid) are written. These parameters directly alter how tag code behaves on the page.
ad_user_data and ad_personalization are the V2 additions, and they work differently. Ahava describes them as "downstream" instructions. They do not change how tags behave on your website. Instead, they are flags sent to Google's servers telling them how to process the data once it arrives. ad_user_data controls whether personal data can be used for advertising measurement, including Enhanced Conversions. ad_personalization controls whether data can be used for remarketing and personalised advertising.
This distinction matters. A user might grant ad_user_data (allowing Google to measure conversions against their data) while denying ad_personalization (declining to be added to remarketing lists). Consent Mode V2 supports this granularity, and a properly configured consent banner should offer it.
Three additional parameters exist: functionality_storage, personalization_storage, and security_storage. These are available for third-party tags in Google Tag Manager (GTM) but are not checked by Google's own tags and are not part of the V2 enforcement requirement.
What Consent Mode does not do
Consent Mode does not store or manage consent choices. It does not present a consent banner. It does not decide what is "strictly necessary." It is one component in a broader consent architecture: the signalling layer between your consent management platform (CMP) and Google's tags. The CMP handles the user-facing consent interaction and persists the choice across sessions; Consent Mode communicates that choice to Google.
This is the first place implementations go wrong: treating Consent Mode as a compliance tool rather than a technical bridge. Having it configured does not make your tracking compliant. It means Google's tags know what the user chose. Whether that choice was obtained lawfully is your responsibility.
Why UK businesses need this now
The timeline matters because it determines how much data you may have already lost.
Google designated Consent Mode V2 as mandatory for all advertisers targeting EEA and UK audiences from 6 March 2024. This aligned with the Digital Markets Act compliance deadline in the EU. Enforcement was phased: warning emails were sent to non-compliant accounts through late 2024 and early 2025. Then, on 21 July 2025, Google began actively turning off features.
For non-compliant accounts, the consequences are specific and measurable. Remarketing audiences stop building: no new users are added to any list, which means lookalike audiences degrade and campaign reach shrinks. Conversion tracking breaks: Google Ads cannot attribute clicks to purchases or enquiries, which means Smart Bidding loses its feedback loop and cost-per-acquisition rises. Enhanced Conversions are blocked: even server-side hashed data is rejected without the ad_user_data consent signal. Demographic and interest reporting goes dark. GA4 audience sharing to Google Ads stops functioning.
If your business spent the period between March 2024 and July 2025 without Consent Mode V2, the data from that period is permanently lost. Google does not reconstruct it retrospectively.
The UK legal landscape
Consent Mode V2 exists because of privacy law, and UK businesses face a regulatory framework that has tightened considerably since the requirement was introduced.
PECR: the law that governs cookies
The Privacy and Electronic Communications Regulations 2003, Regulation 6, is the primary UK law governing cookies and similar technologies. It states that a person shall not store or gain access to information on a user's device unless clear information is provided and consent is given. The only exceptions are for transmission of a communication or where access is strictly necessary for a service the user has requested.
PECR's scope is broader than most marketing teams realise. It covers any technology that stores or accesses information on a user's device, not just cookies. The ICO has confirmed this extends to fingerprinting techniques. For Consent Mode V2, this means the question of whether data is "accessed" from a user's device applies regardless of whether a cookie is set.
The Data (Use and Access) Act 2025
The DUAA received Royal Assent on 19 June 2025, with key provisions commencing on 5 February 2026. It is the most significant change to UK privacy regulation since the adoption of the UK GDPR.
For cookie consent, the Act introduces five new exemptions to PECR Regulation 6. The one that matters most for marketing teams is the statistical/analytics exception: cookies used solely for collecting aggregate statistics no longer require prior consent, provided clear information and a simple free opt-out are offered. This is a genuine shift from opt-in to opt-out for qualifying analytics.
The critical limitation: the ICO has stressed that this exception does not cover advertising-related analytics. Any cookie used for behavioural profiling, audience building, or targeted advertising still requires explicit consent. For the analytics exception to apply, the data must not be shared with or repurposed by third-party providers for their own commercial purposes.
This creates an immediate problem for standard GA4 implementations. Google processes GA4 data on its own infrastructure and uses it for purposes beyond the individual site owner's aggregate statistics. Whether GA4 qualifies for the DUAA analytics exception is, at minimum, questionable. The ICO has not published definitive guidance on this interaction, and organisations should not assume the exception applies to GA4 without legal advice.
The DUAA also aligned PECR penalties with UK GDPR levels. Cookie and tracking violations can now result in fines of up to £17.5 million or 4% of global annual turnover, whichever is higher. The previous cap was £500,000. The Act also introduced "instigator" liability: if a third-party agency or technology provider instigates a non-compliant cookie placement on your website, both you and the instigator can be held directly liable.
ICO enforcement trajectory
The ICO has made cookie compliance an explicit priority. In January 2025, it announced a review of the UK's top 1,000 websites. By December 2025, 95% of those sites met the ICO's compliance checks, but only after 564 improved following initial failures, and 17 were issued preliminary enforcement notices. The three things the ICO assessed: whether non-essential cookies were set before the user made a choice, whether rejecting was as easy as accepting, and whether cookies were placed after the user refused.
In 2024, the ICO reprimanded Sky Betting and Gaming for unlawfully processing data via advertising cookies without consent, the first major public enforcement action specifically on cookie consent mechanisms. NOYB was approved as a qualified entity in December 2024, meaning it can now bring collective redress actions in the UK for cookie consent violations. And the ICO published its 2025 Online Tracking Strategy, with four focus areas: deceptive or absent choice, uninformed choice, undermined choice, and irrevocable choice.
The ICO has proposed relaxing enforcement for certain "low-risk" advertising cookies and planned to publish a statement on this in early 2026. As of February 2026, that statement has not appeared. Businesses should not adjust their compliance posture based on a regulatory statement that has not yet been issued.
Basic vs. Advanced: the decision that matters most
Every Consent Mode V2 implementation requires choosing between Basic and Advanced mode. This is not a technical detail; it is a compliance and commercial decision with significant consequences either way.
Basic mode
In Basic mode, Google tags are completely blocked from loading until the user interacts with your consent banner. No data is transmitted to Google before consent: not cookies, not pings, not even the consent state itself. If the user grants consent, tags load and send full measurement data. If the user denies consent, nothing is sent. Nothing at all.
The compliance position is straightforward: no data flows to Google without explicit consent. PECR Regulation 6 is satisfied.
The data cost is severe. With UK consent rates for "accept all" typically running at 25–30% on properly configured banners, you lose visibility into 70–75% of your traffic with no recovery mechanism. Google's behavioural modelling in GA4 is not available in Basic mode. Conversion modelling is available but uses a general model, less accurate and not specific to your site's traffic patterns.
Advanced mode
In Advanced mode, Google tags load immediately when the page opens, regardless of consent. They set a default denied state and send "cookieless pings" to Google's servers. These pings contain no persistent identifiers and no cookies, but they do include timestamps, user agent strings, referrer URLs, ad-click indicators, and a random number generated per page load. When a user grants consent, full measurement data flows normally. Google uses the cookieless pings from non-consenting users, combined with full data from consenting users, to build advertiser-specific models that estimate the behaviour and conversions of the invisible audience.
Google states this approach recovers "more than 70% of ad-click-to-conversion journeys lost due to user cookie consent choices." This is a marketing claim from Google. It should be treated as such: useful directional information, not an independently verified statistic.
The legal controversy
Advanced mode is where the implementation decision meets the law. The question is whether sending cookieless pings from a user who has not yet consented (or who has denied consent) constitutes "gaining access to information stored in the terminal equipment of a subscriber or user" under PECR Regulation 6.
No ICO ruling, UK court, or EU data protection authority has directly adjudicated this question. The legal position remains formally untested.
The weight of independent expert opinion, however, leans in one direction. Simo Ahava, the most authoritative independent technical analyst of Google's tracking infrastructure, advises that Advanced mode's use "needs to be extremely carefully deliberated with your legal team. Remember that you are collecting data from users who might not have opted into such a thing." Brian Clifton, formerly Google's own Head of Web Analytics for EMEA, stated more bluntly that "an explicit no means no, yet Google's consent mode is extremely flawed in this regard." Multiple CMP providers, including Vera and Consentmo, have stated publicly that they consider Advanced mode non-compliant.
Google's counter-position is that cookieless pings contain no persistent identifiers, do not store cookies, and are used solely for aggregate statistical modelling. The data, Google argues, is not personal data.
The argument against that position: PECR Regulation 6 covers "information stored or accessed," not just cookies or personal data. User agent strings, referrer URLs, and timestamps are accessed from the user's device. The ICO has confirmed PECR covers fingerprinting techniques and similar technologies. The European Data Protection Board's Guidelines 2/2023 broadened the interpretation of what constitutes accessing information on terminal equipment under the equivalent EU provision.
There is a further complication that is poorly understood. Brian Clifton flagged in 2022 that cookieless pings still carry user_id and transaction_id fields if those are collected elsewhere on the page. Google's own documentation confirms that "any fields set by the advertiser (e.g., user_id, custom dimensions) continue to be sent normally" when analytics_storage is denied. If your implementation sends user identifiers alongside cookieless pings, the "no personal data" argument becomes considerably harder to sustain.
Making the decision
For businesses with a low risk tolerance, particularly regulated firms, firms in financial services, or firms that process sensitive data, Basic mode is the defensible choice. The data cost is real, but it is a known, quantifiable cost.
For businesses that depend heavily on Google Ads performance and need the modelling to maintain campaign optimisation, Advanced mode may be commercially necessary. But it should be implemented with three conditions: your legal team has reviewed the PECR implications, your privacy notice explicitly discloses that cookieless pings are sent before consent, and you have confirmed that no user-level identifiers are transmitted in the cookieless pings.
For small businesses with fewer than 1,000 daily users, the calculation shifts again. Google's behavioural modelling requires a minimum of 1,000 daily events with analytics_storage denied for seven consecutive days, and 1,000 daily consenting users for seven of the previous 28 days. If your site does not meet these thresholds, modelling will not activate regardless of which mode you choose. The practical difference between Basic and Advanced for a low-traffic site is minimal, and the compliance risk of Advanced is not justified by a modelling benefit you will never receive.
Implementation: GTM and CMP
The most common implementation path uses Google Tag Manager with a Google-certified consent management platform. The CMP handles the user-facing banner and consent storage; GTM handles the communication of consent state to Google tags.
Step 1: Enable consent overview in GTM
In your GTM container, navigate to Admin → Container Settings → Additional Settings and enable "Enable consent overview." This adds a shield icon to each tag showing its consent configuration.
Step 2: Install your CMP tag
In GTM, create a new tag using your CMP's community template from the Template Gallery. Major CMPs with native GTM templates include Cookiebot, CookieYes, Termly, Civic Cookie Control, iubenda, and Complianz. The CMP tag must be set to fire on the Consent Initialization – All Pages trigger. This trigger fires before all other triggers in the container, ensuring consent defaults are set before any measurement tags execute.
Step 3: Configure default consent state
Your CMP template should set all four core parameters to denied by default. If your CMP does not handle this automatically, you will need to configure it. For UK businesses, the default must be denied for ad_storage, analytics_storage, ad_user_data, and ad_personalization. No exceptions; no region-specific overrides that default UK traffic to granted.
Set the wait_for_update parameter to 500 milliseconds. This tells Google tags to wait for a consent update from the CMP before processing their initial requests. If the CMP loads slowly, this prevents tags from firing with an undefined consent state.
Step 4: Map CMP categories to Consent Mode parameters
Your CMP will present users with cookie categories: typically "Necessary," "Analytics," "Marketing," and sometimes "Functional" or "Personalisation." These must map correctly to Consent Mode parameters. The mapping varies by CMP. CookieYes, for example, maps seven Google consent types into four categories. Miscategorisation is one of the most common implementation errors; it leads to marketing cookies being served under "functional" consent, or analytics data being blocked when the user has accepted analytics.
Verify the mapping in your CMP's documentation and test it in isolation before deploying.
Step 5: Configure tag consent settings
For Basic mode, open each Google tag in GTM, go to Advanced Settings → Consent Settings, and check "Require additional consent for tag to fire", then add the required consent types (e.g., ad_storage for Google Ads tags, analytics_storage for GA4). The tag will not fire until those consent types are granted.
For Advanced mode, check "No additional consent required". Google tags will fire normally and automatically adjust their behaviour based on the consent state, sending cookieless pings when consent is denied and full data when granted.
A known GTM bug affects Basic mode: if a tag has "Once per page" firing frequency combined with Additional Consent Checks, GTM considers the tag "fired" during the Consent Initialization phase (when consent is denied) and will not fire it again after consent is granted. The workaround is to use trigger-based logic instead of Additional Consent Checks.
Step 6: Test
Testing is not optional, and it requires more than loading the page and clicking "Accept."
Tag Assistant (tagassistant.google.com) is Google's preferred debugging tool. Enter your site URL, navigate through the consent flow, and inspect the "Consent" tab for each event. A warning that "a tag read consent before a default was set" is a red flag indicating a race condition: your tags are firing before the CMP sets defaults.
Browser Network tab: Filter requests for google-analytics.com/g/collect or googleads.g.doubleclick.net. Inspect the gcs and gcd parameters on each request.
The gcs parameter uses a G1xy format, where x is ad_storage status (1=granted, 0=denied) and y is analytics_storage status. Before consent: G100 in Advanced mode means both denied (correct). G111 before consent means both are defaulting to granted (misconfigured). No gcs parameter at all means Consent Mode is not integrated.
The gcd parameter encodes all four V2 parameters with letter codes showing how each was set. The letter r (denied by default, then granted after update) is the indicator of a correct implementation: defaults were set to denied, the user granted consent, and the update command fired successfully.
Test in incognito mode. Existing consent cookies in a normal browser session will mask first-visit behaviour. Test on both desktop and mobile; CMP rendering and consent flows often differ between devices. Allow up to 48 hours for GA4 to process changes; consent diagnostics are not real-time.
What happens to your data
The commercial impact of Consent Mode V2 depends on three variables: your consent rate, your traffic volume, and which mode you implement.
Consent rates: the numbers that matter
Industry data is consistent on the broad picture. When a properly configured consent banner offers equally prominent "Accept All" and "Reject All" options, acceptance rates typically run between 25% and 40% in the UK. When researchers analysed 26 academic studies, they found that 50–67% of users reject tracking when given a genuine, unbiased choice. The ICO's own experience is instructive: after implementing best practices on ico.org.uk, visible analytics traffic dropped by 90.8%, from 119,417 to 10,967 users per day.
These figures mean that for a compliant UK website, 60–75% of visitors are invisible to Google Analytics and Google Ads without modelling.
Modelling: what it recovers and what it does not
In Advanced mode, Google uses machine learning to estimate the behaviour of non-consenting users based on patterns observed in consenting users. GA4 calls this "behavioural modelling"; Google Ads calls it "conversion modelling."
The modelling is not available to everyone. GA4 requires at least 1,000 daily events with analytics_storage denied for seven consecutive days, and at least 1,000 daily consenting users for seven of the previous 28 days. Google Ads conversion modelling requires at least 700 ad clicks per day over a seven-day period, per country and domain grouping. Many small and medium UK businesses will never meet these thresholds, meaning modelling will never activate regardless of how well Consent Mode V2 is implemented.
What modelling estimates: daily active users, sessions, new users, key event rates, geographic breakdowns, device breakdowns. What it does not estimate: individual event counts in standard reports, raw data exported to BigQuery for non-consenting users. The modelled figures are statistical reconstruction, not recovered data. They are useful for trend analysis and campaign optimisation, but they are not a replacement for observed measurement.
Google claims modelling recovers "over 70% of ad-click-to-conversion journeys." This is a figure from Google's own marketing materials. Independent verification does not exist. Google does not publish its modelling methodology or accuracy benchmarks.
Impact on Google Ads
For advertisers, the cascade of effects from non-compliance is specific. Remarketing audiences stop populating for non-consented users, which degrades audience quality over time. Smart Bidding strategies (Target CPA, Target ROAS, Maximise Conversions) lose signal data, causing performance to drift. Enhanced Conversions, which match hashed first-party data to Google accounts for attribution, are blocked entirely if ad_user_data is denied. GA4 audience sharing to Google Ads stops for users who have not consented to both ad_user_data and ad_personalization.
The firms hardest hit are those running performance-driven campaigns where bidding algorithms depend on a consistent feedback loop. When 70% of conversions disappear from the data, bidding algorithms optimise against an incomplete picture, and costs rise.
The mistakes that cause the most damage
After implementing Consent Mode V2 across multiple client sites, these are the errors I see most frequently, ranked by the damage they cause.
1. No default consent state
If the default consent command does not fire before Google tags load, Consent Mode is undefined. Google tags treat this as consent granted, meaning every parameter defaults to granted and full data is collected before the user makes any choice. Your site is now both non-compliant with PECR and sending false consent signals to Google. Tag Assistant will show gcs=G1-- (no consent mode active) or, worse, G111 (full consent) on the first page load. Fix: ensure your CMP tag fires on the Consent Initialization trigger before all other tags.
2. CMP category mapping errors
A marketing cookie classified as "functional" in your CMP means it fires when the user accepts "functional" cookies but denies "marketing." The user believes they have declined marketing tracking; your site is setting marketing cookies under a different label. This is both a PECR compliance failure and a Consent Mode misconfiguration, because the consent signals sent to Google will not match the cookies actually deployed. Fix: audit your CMP's category-to-parameter mapping against the cookies each tag actually sets.
3. Missing V2 parameters
Older CMP templates, particularly those installed before November 2023, may not include ad_user_data and ad_personalization. If these parameters are absent, Google treats them as not set. Enhanced Conversions will be blocked, and remarketing will be limited. Tag Assistant will show these parameters as "not set" rather than "denied" or "granted." Fix: update your CMP template to the latest version and verify all four parameters appear in the consent state.
4. Advanced mode without understanding the data it sends
Implementing Advanced mode because an agency recommended it, without confirming what data the cookieless pings contain in your specific setup, is a compliance risk. If your GA4 implementation sends user_id or custom dimensions containing personal data, that data will be included in cookieless pings even when analytics_storage is denied. Google's documentation is explicit on this point. Fix: audit what fields your GA4 implementation sends and confirm none contain personal data when consent is denied. If they do, either remove them from the denied state or switch to Basic mode.
5. Not enabling blended reporting in GA4
Even with a correct Consent Mode V2 implementation, if GA4's reporting identity is set to "Observed" rather than "Blended," modelled data from non-consenting users is excluded from reports. Your team sees only the consenting minority and makes decisions based on an unrepresentative sample. Fix: go to Admin → Property Settings → Data Display → Reporting Identity and select "Blended."
6. Testing only on desktop
CMP rendering, tag loading order, and consent flows frequently differ between desktop and mobile. A site that tests correctly on desktop Chrome may have race conditions on mobile Safari where the CMP loads after Google tags have already fired. Fix: test the full consent flow on at least three device/browser combinations, including mobile Safari and mobile Chrome.
7. Treating Consent Mode as "done"
CMP templates update. Google changes its tag behaviour. New scripts added to the site by other teams drop cookies outside the CMP's control. A third-party chat widget or embedded video player introduces tracking that your consent architecture does not cover. Consent Mode is infrastructure that requires monitoring, not a one-time installation. Fix: run a monthly audit. Check the gcs and gcd parameters in live traffic. Scan for undeclared cookies. Verify the CMP still covers every script on the site.
The broader picture
Consent Mode V2 is a Google-specific mechanism, but the underlying consent requirements apply across the advertising ecosystem. Meta has its own Conversions API and consent framework. Microsoft Advertising introduced its own Consent Mode, mandatory for EEA/UK traffic from May 2025. If your site runs multiple advertising platforms, each needs its own consent signal integration; Consent Mode V2 only covers Google's tags.
For businesses questioning whether the complexity is worth it, the answer depends on what you use Google for. If you depend on Google Ads for lead generation or sales, Consent Mode V2 is non-negotiable: without it, your campaigns are optimising blind. If you use GA4 for traffic analytics but do not run Google Ads, the DUAA analytics exception may reduce the consent burden for basic analytics, but only if your implementation genuinely qualifies under the exception's strict conditions, and that question has not been definitively answered for GA4.
If your business does not use Google Ads or GA4, Consent Mode V2 is not relevant to you. But PECR still is. Every tracking technology on your site that stores or accesses information on a user's device requires consent unless a specific exception applies. The tools differ; the legal obligation does not.
What to do now
If you have not implemented Consent Mode V2, you are losing data every day that will never be recovered. Start here:
Audit your current state. Open Tag Assistant and load your site. Check whether consent defaults are set before any Google tags fire. Inspect the gcs parameter in the Network tab. If you see G111 before any user interaction, your implementation is broken.
Choose your mode. If your business has low risk tolerance or fewer than 1,000 daily users, use Basic mode. If you depend on Google Ads performance and can satisfy your legal team that cookieless pings are defensible under PECR, use Advanced mode with documented legal reasoning.
Choose your CMP. Use a Google-certified CMP with a native GTM template. For UK businesses, Cookiebot, CookieYes, and Civic Cookie Control are established options with proven V2 support. Install it on the Consent Initialization trigger.
Implement, test, and monitor. Follow the GTM workflow above. Test in incognito across devices. Set up a monthly audit cadence to catch drift.
Talk to your legal team. Consent Mode V2 is a technical implementation of a legal obligation. The technical setup is within reach for any competent marketing or development team. The legal judgment about which mode to use, how to disclose cookieless pings in your privacy notice, and whether the DUAA analytics exception applies to your GA4 setup requires legal advice specific to your business.
This is the kind of implementation work I do at Penby every week: configuring consent architectures that satisfy both Google's technical requirements and UK privacy law. The technical setup is rarely where projects fail; it is the gap between what the technology does and what the law requires where most businesses get stuck. That gap, between marketing technology and data protection, is where Penby works.