Google Consent Mode v1 vs v2: What Changed and Why It Matters for Your Website

A Brief History of Google Consent Mode

Google released the original Consent Mode in September 2020, roughly two years after GDPR enforcement began. The idea was straightforward: let website owners adjust how Google tags behave depending on whether a visitor accepts or refuses cookies. When someone declined, Google tags would stop writing cookies but could still send anonymous, cookieless pings back to Google's servers. Google then used those pings to model the conversions it could no longer directly measure.

That original version - now referred to as Consent Mode v1 - worked with just two parameters: ad_storage and analytics_storage. One controlled cookie access for advertising purposes, the other for analytics. Simple, binary, and limited.

Then the EU's Digital Markets Act changed the equation. The DMA, which began enforcement in March 2024, designated Google (alongside Apple, Meta, Amazon, ByteDance, and Microsoft) as a gatekeeper. Under Article 5(2) of the DMA, gatekeepers cannot combine personal data from different services for advertising unless the user gives explicit consent. Google needed a mechanism to prove that advertisers were passing proper consent signals - and Consent Mode v1 was not granular enough to do the job.

What Consent Mode v1 Actually Did

Consent Mode v1 gave website owners a way to signal two things to Google: whether the visitor consented to advertising cookies (ad_storage) and whether they consented to analytics cookies (analytics_storage). Each parameter could be set to granted or denied.

When both were denied, Google tags stopped using browser storage entirely. No _ga cookie, no _gcl_au cookie, no persistent identifiers at all. Tags could still fire in what was informally called "cookieless mode", sending anonymous pings that included basic information like timestamp, user agent, and referrer - but nothing that could identify an individual across sessions.

The limitation was that v1 treated advertising consent as a single block. A visitor either consented to all advertising data uses or none. There was no way to say "yes, you can measure my conversions" while also saying "no, you cannot use my data for personalised remarketing ads." Privacy-conscious users had no middle ground.

V1 also lacked a formal distinction between Basic and Advanced implementation modes. In practice, some sites blocked Google tags entirely until consent was granted (what would later be called Basic mode), while others let tags load and adjust their behaviour dynamically (Advanced mode). But these were not official categories with documented differences in modelling capabilities.

The Two New Parameters in Consent Mode v2

Google announced Consent Mode v2 in November 2023 and set a compliance deadline of 6 March 2024 - the same date the DMA required gatekeepers to meet their obligations. V2 kept the original ad_storage and analytics_storage parameters and added two new ones:

• ad_user_data - controls whether the visitor's personal data can be sent to Google for advertising purposes. This covers things like hashed email addresses used in Enhanced Conversions, customer match lists, and conversion data uploads.
• ad_personalization - controls whether the visitor's data can be used for personalised advertising, including remarketing lists and audience targeting.

These two parameters operate independently. A visitor might grant ad_user_data (allowing conversion measurement) while denying ad_personalization (blocking remarketing). This granularity is a direct response to GDPR's requirement for specific, informed consent - Article 6(1)(a) requires that consent be given for each distinct processing purpose, not bundled into a single yes/no.

The technical behaviour matters here. Unlike ad_storage and analytics_storage, which directly control whether tags can read and write cookies, the new parameters function as metadata flags. As Simo Ahava documented in his technical analysis, ad_user_data and ad_personalization are appended as URL parameters to requests sent to Google's servers. The GA4 tag itself does not change how it fires based on these signals - it is Google's backend that reads them and decides whether to process the data for advertising purposes.

Side-by-Side Comparison: v1 vs v2

Basic Mode vs Advanced Mode: A v2 Distinction

Consent Mode v2 formalised two implementation approaches with significantly different consequences for data collection and modelling accuracy.

Basic Consent Mode

Google tags do not load at all until the visitor interacts with the consent banner and grants permission. If consent is denied, no data reaches Google - not even anonymous pings or the consent state itself. Google can still model conversions, but it uses a general model based on aggregate patterns across all advertisers, not your specific traffic data. The result is less accurate modelling, but the approach is simpler to implement and carries lower legal risk because no data whatsoever leaves the browser without consent.

Advanced Consent Mode

Google tags load immediately, before the visitor makes a consent choice, with all consent parameters defaulting to denied. While consent is denied, tags send cookieless pings - stripped of personal identifiers but containing anonymised signals like conversion type, country, and device category. When consent is later granted on the same page, previously collected pings get retroactively reprocessed with the granted status.

The payoff is better modelling. Google builds an advertiser-specific conversion model from your cookieless ping data, which tends to be more accurate than the generic model used in Basic mode. Google's own data suggests that Advanced Consent Mode with conversion modelling recovers around 65-70% of conversion journeys that would otherwise be lost to consent refusals.

The trade-off is legal exposure. Sending any data to Google's servers before a visitor consents - even cookieless pings without personal identifiers - is a grey area under Article 5(3) of the ePrivacy Directive, which requires consent for accessing or storing information on a user's device. Whether cookieless pings constitute "accessing information" is debated, and no DPA has issued definitive guidance. If your legal team is cautious, Basic mode is the safer choice.

Why Google Forced the Upgrade

The timing of Consent Mode v2 was not coincidental. The EU's Digital Markets Act required designated gatekeepers to comply with its obligations by 6 March 2024. Under the DMA, Google cannot combine personal data across its services for advertising without explicit user consent. Consent Mode v2 is Google's mechanism for receiving and respecting those consent signals from advertisers.

Google's enforcement rolled out in stages. From January 2024, publishers using Google AdSense, Ad Manager, or AdMob were required to use a Google-certified CMP that supports the IAB Transparency and Consent Framework (TCF) v2.2. From March 2024, advertisers using Google Ads or GA4 audience features needed Consent Mode v2 implemented to continue building audiences and tracking conversions for EEA users.

The real teeth came in July 2025. Google began automatically disabling conversion tracking, remarketing, and demographic reporting for accounts that had not implemented Consent Mode v2 for EEA and UK traffic. There was no grace period and no manual review. Some advertisers reported overnight drops of 90-95% in their conversion metrics. Data lost during periods of non-compliance is permanent - Google offers no backfill or retroactive modelling.

What Happens If You Do Not Upgrade

Running Google Ads or GA4 without Consent Mode v2 in 2026 means operating blind in European markets. The specific consequences stack up quickly:

• No new EEA audiences - GA4 stops adding EEA visitors to audience lists, which means your remarketing pools shrink with every passing day.
• Broken conversion tracking - Google Ads cannot attribute conversions from EEA traffic, so Smart Bidding strategies like Target ROAS and Target CPA optimise on incomplete data.
• No Enhanced Conversions - Without ad_user_data consent signals, hashed first-party data like email addresses will not be processed for conversion matching.
• No personalised ads - Without ad_personalization signals, Google will not serve remarketing or personalised display ads to those users.
• Performance Max suffers - PMax campaigns depend heavily on audience signals and conversion data. Strip those away for EEA traffic, and the algorithm has far less to work with.

Research by CookieScript found that only about 31% of users globally accept tracking cookies. If your European traffic represents a significant share of revenue, losing visibility into 70% of those visitors is not a minor inconvenience - it is a structural problem for campaign optimisation.

How to Implement Consent Mode v2

The implementation path depends on whether you use a consent management platform (CMP) or maintain your own consent solution.

Using a Google-Certified CMP

The simplest route. Google-certified CMPs like Kukie.io handle the consent signal plumbing automatically. When a visitor interacts with your cookie banner, the CMP sends the appropriate granted or denied values for all four parameters to Google tags. Most certified CMPs updated their integrations to support v2 parameters automatically, so if you are already using one, check with your provider to confirm v2 signals are active.

You can verify your implementation using Google Tag Assistant. Navigate to your site, observe the consent initialisation showing default states (all four parameters should appear as denied for EEA visitors before interaction), make a consent choice through your banner, and confirm that Tag Assistant shows the updated consent states with correct values for ad_storage, analytics_storage, ad_user_data, and ad_personalization.

Using Google Tag Manager

If you manage tags through GTM, you can use a consent mode template from the Community Template Gallery or create your own. The critical requirement is that the consent('default', {...}) command fires before any Google tags, and the consent('update', {...}) command fires on the same page when the visitor makes a choice. A common mistake is setting default consent to granted - this violates GDPR's requirement for prior consent and should always default to denied for EEA visitors.

Using gtag.js Directly

For sites that load the Google tag directly, the consent default must be set before the tag configuration. The code pattern looks like this:

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

Your consent banner then calls the update command when the visitor makes a choice:

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

Both commands must execute on the same page load. If the update happens on a different page (say, after a redirect), Google cannot link the two events, and the consent signal is lost.

Region-Specific Defaults

Google's implementation supports geographic targeting through ISO 3166-2 region codes. You can set default consent to denied for EEA countries while setting it to granted for regions where consent is not legally required. This avoids unnecessarily limiting data collection for traffic from countries without cookie consent laws, while staying compliant where it matters.

Common Implementation Mistakes

Getting Consent Mode v2 wrong is arguably worse than not implementing it at all, because you might believe you are compliant while your data quietly breaks. A few pitfalls appear repeatedly.

Setting all defaults to granted is the most dangerous mistake. Some developers hard-code granted states without waiting for actual user consent, which violates GDPR Article 7 and defeats the entire purpose. Default states must be denied until the visitor actively makes a choice.

Plugin conflicts are common on WordPress sites. If you run Site Kit, GTM4WP, MonsterInsights, and a CMP plugin simultaneously, multiple plugins may try to load GA4 or set consent states, creating duplicate tags with inconsistent consent handling. Audit your setup and ensure only one system controls consent signals.

Race conditions between CMP and tags cause subtle issues. If Google tags fire before your CMP has set the default consent state, those initial hits go out with no consent signal at all - and Google treats them as non-compliant. Your CMP's consent default must execute before any Google tag configuration.

Forgetting to update dynamically is another gap. The GDPR requires that consent be as easy to withdraw as it is to give. If your implementation does not immediately update consent signals when a visitor changes their preferences mid-session, you are collecting data without valid consent for the period between the change and the next page load.

Modelling Thresholds: Why Small Sites Struggle

Google's conversion modelling is not magic, and it does not activate for everyone. GA4 behavioural modelling requires a minimum of 1,000 daily events from users who deny cookies for seven consecutive days, plus 1,000 daily events from consenting users. At a typical 50% consent rate, that means roughly 2,000 unique daily visitors before modelling even switches on.

Most small and mid-sized websites fall well below that threshold. If modelling never activates, data from non-consenting visitors is simply gone - not estimated, not recovered, just absent from your reports. This is an important consideration when choosing between Basic and Advanced mode: Advanced mode's main advantage is better modelling, but if your traffic is too low to trigger modelling at all, the legal risk of sending cookieless pings may not be worth the marginal benefit.

For sites that do meet the thresholds, Google's own early results indicated that conversion modelling through Consent Mode recovers around 70% of ad-click-to-conversion journeys lost to consent refusals. Independent sources cite figures closer to 65%. Either way, it is a significant recovery - but not a full replacement for consented data.

Beyond Google: Consent Mode as an Industry Pattern

Google was the first major platform to formalise consent signalling at this level, but others are following. Microsoft Advertising introduced its own consent mode with parameters that mirror Google's approach. Meta's Conversions API increasingly expects consent signals alongside event data. The IAB TCF v2.2 framework provides a standardised consent string that multiple vendors can read.

If you use a CMP that supports multiple vendor integrations, you can manage Google Consent Mode v2, Microsoft consent signals, and TCF consent strings from a single banner. This avoids the maintenance burden of configuring consent plumbing separately for each advertising platform.

The direction of travel is clear. More platforms will require consent signals. More DPAs will enforce granular consent requirements. Building a proper consent infrastructure now - with a scanner that detects what cookies your site actually sets, a banner that collects granular consent, and integrations that pass those signals to every vendor - is cheaper than retrofitting when the next enforcement deadline arrives.

Frequently Asked Questions