Consent Mode v2 and Privacy Sandbox: What Remains After 2025

Consent Mode v2 has been mandatory since March 2024 for all advertisers that use Google Ads, remarketing, or conversion tracking in the EEA and the UK. Without a correctly implemented Consent Mode, Google no longer serves personalized ads and turns off remarketing features. At the same time, the starting point for the entire tracking industry shifted in 2025: Google has abandoned key parts of the Privacy Sandbox, which for years was billed as the successor to third-party cookies. For B2B companies in the DACH region, this sets a clear task: measure in a legally compliant way without relying on a cookie future that is not coming.

This article puts both developments into technical context and explains the correct Consent Mode v2 setup, the conversion modeling behind it, and the consequences for server-side measurement, Core Web Vitals, and visibility to AI crawlers.

Why Consent Mode v2 and the end of the Privacy Sandbox belong together now

The two topics look separate, but they belong together. Consent Mode v2 governs how an advertiser passes a user's consent status to Google. The Privacy Sandbox was supposed to provide the technical foundation for advertising after third-party cookies go away. With the end of these Sandbox plans, today's reality stays in place, and that reality is exactly what makes Consent Mode v2 so important.

The data is clear: according to the HTTP Archive Web Almanac, 61% of all cookies on the top 1 million websites are third-party cookies, and among the top 1,000 the share is as high as 77% (international measurement). Almost 100% of these third-party cookies set the SameSite=None attribute so they can be sent across sites at all. This shows how heavily the advertising ecosystem still depends on the very cookies whose phase-out was announced for years.

On top of that comes the consent loss caused by compliant banners. A benchmark study from the DACH region shows that with a legally compliant design, around 60% of visit data is lost on average because users decline (data for Germany/EU). That corresponds to a consent rate of about 40%. If you measure in the EEA, you are structurally working with incomplete data, and Consent Mode v2 is Google's answer to exactly this gap.

What Consent Mode v2 is technically: Basic, Advanced, and the four signals

Consent Mode v2 is an interface that passes consent status to Google tags. Instead of simply blocking tags, Consent Mode adjusts their behavior to the status. There are two implementation variants.

• Basic Consent Mode: Google tags load only after the user has consented. Before consent, no data at all is sent to Google, not even cookieless pings. If the user declines, the data is missing entirely, and Google models only on the basis of aggregated observations.
• Advanced Consent Mode: The Google tags load from the start, but without consent they send only anonymous, cookieless signals without personal identifiers. These pings provide the data basis for conversion modeling. As soon as the user consents, the tags switch to full measurement mode.

Four signals control this behavior. ad_storage governs whether advertising cookies are set. analytics_storage controls cookies for analytics, for example in Google Analytics 4. ad_user_data determines whether user data may be sent to Google for advertising purposes. ad_personalization decides on personalized advertising and remarketing. The last two signals were added with version 2 and are the reason the switch became mandatory.

Technically, control runs through two commands. The default command sets the initial state before any tag fires. In the EEA, this default must be set to denied for all non-essential categories. The update command updates the status after the user's decision. Order and timing are critical: the default command must fire before the Google tags load; otherwise a tag fires before the consent status is known. In practice, a consent management platform usually handles this control and passes the signals to the Google tag or Google Tag Manager.

Conversion modeling: how Google estimates missing conversions

Conversion modeling is the actual benefit of Advanced Consent Mode. When a user declines, the direct link between ad click and conversion is missing. Google fills this gap with a statistical model that infers the unobservable paths from the observable, consented ones.

Google itself provides the order of magnitude: on average, conversion modeling in Consent Mode recovers more than 70% of the ad-click-to-conversion paths lost to missing cookie consent (international Google data, 2021). The caveat Google states explicitly matters: results vary widely depending on consent rate and implementation quality.

This is exactly where the B2B problem lies. Modeling needs volume. Google activates conversion modeling in Consent Mode only above a certain minimum volume of ad clicks and user traffic. Many DACH B2B accounts do not reach this data threshold: a niche provider with a few hundred clicks per month falls below it. For such accounts, only the more general, less precise model at the Google level applies.

The realistic expectation for low-volume B2B is therefore: conversion modeling is not a switch that is guaranteed to bring back lost conversions. It works well where there is enough traffic. If your volume is low, focus on a clean first-party data strategy and server-side measurement instead of relying on modeling.

Putting the end of the Privacy Sandbox in 2025 into context

The chronology matters because it is often oversimplified. In April 2025, Google announced that it would not introduce a standalone choice prompt for third-party cookies in Chrome and would keep the existing model instead. In October 2025, the decisive step followed. According to the official Privacy Sandbox blog, Google announced that it will retire a range of Privacy Sandbox technologies, including the Attribution Reporting API, Protected Audience, and Topics, and keep its current approach to third-party cookie choice in Chrome (announcement of October 17, 2025).

Important for an accurate assessment: Google is retiring a specific list of technologies, not every feature across the board. Those being retired include Topics, Protected Audience, the Attribution Reporting API, Private Aggregation, IP Protection, and Related Website Sets. What remains in practice:

• Third-party cookies in Chrome: They will not disappear in the foreseeable future. The existing model stays in place, and no new, separate choice prompt for cookies has been announced.
• CHIPS (Cookies Having Independent Partitioned State): Partitioned cookies remain in place as a mechanism and can be used independently of the retired APIs.
• The legal framework: Google's decision does not change the GDPR or ePrivacy rules. Consent remains mandatory, regardless of which browser technology is available.

The consequence for advertisers: years of preparing for a cookieless future via Sandbox APIs are now moot. Instead, the focus shifts permanently to consent, first-party data, and server-side architecture. Browser-side restrictions such as Apple's Intelligent Tracking Prevention in Safari, which has around 20% market share in Europe (data for Europe, Chrome around 60%, Edge around 7%), continue to apply unaffected.

GDPR, TKG 2021, TDDDG, and the EU Digital Omnibus

In Austria, access to end devices is governed by the Telekommunikationsgesetz (Telecommunications Act) 2021, specifically its implementation of the ePrivacy rules. Cookies and comparable technologies that are not technically necessary require prior, active consent. In Germany, the law formerly known as the TTDSG and since renamed the TDDDG serves the same function through Section 25. Both require explicit consent for all non-essential cookies; simply continuing to scroll is not enough.

Austrian case law tightened the standard further in 2025. In a decision of August 13, 2025, the Federal Administrative Court (Bundesverwaltungsgericht) ruled that a blanket pay-or-okay banner without granular choice is unlawful (decision for Austria). The court objected that users could not consent to or refuse individual processing purposes such as advertising, profiling, and analytics on a granular basis. In practice, this means granularity is not optional; it is a prerequisite for valid consent.

Movement is emerging at the EU level. With its Digital Omnibus proposal of November 19, 2025, the European Commission plans a mandatory single-click reject button, central machine-readable preference settings, for example via the browser, and the removal of consent pop-ups for non-risky purposes such as simple visitor counting (proposal by the European Commission). If the proposal becomes law, it could noticeably change the banner landscape. Until then, the existing framework with a reject button as prominent as the accept button and granular purposes applies unchanged.

Server-side tagging and first-party data as the answer to signal loss

Server-side tagging, usually implemented as sGTM (server-side Google Tag Manager), is the technical answer to browser restrictions and signal loss. Instead of running tags in the user's browser, the tag container runs on your own server, which receives the data, processes it, and forwards it to the destination systems in a controlled way.

The benefits work on several levels:

• Longer cookie lifetime: Cookies that the server sets in a first-party context via HTTP response bypass the short limits ITP applies to cookies set via JavaScript. This holds only if Safari does not classify the tagging server as a third party. If ITP detects a third party via CNAME or IP address, it also caps server-set cookies at 7 days. An sGTM on a subdomain that points via CNAME to an external cloud host typically falls into this category. If the tagging server runs in the same IP range as the website, it stabilizes measurement in Safari.
• Data control before sharing: On the server, you can filter, truncate, or pseudonymize personal fields before data goes to third parties. This supports data minimization as required by the GDPR.
• Enhanced conversions: Hashed first-party data such as email addresses is passed securely server-side and improves conversion attribution, provided valid consent exists.

The distinction matters: server-side tagging is not a way around consent. It changes the architecture of the data flows, not the legal basis. If you measure server-side without consent, you violate the TKG and the GDPR just as much as you would client-side. So sGTM improves data quality and control, but it never replaces consent.

CMP and IAB TCF: mandatory for publishers, a choice for advertisers

For advertisers, Google does not require a certified consent management platform. You can also implement Consent Mode v2 through your own gtag or Tag Manager implementation, as long as default and update are passed correctly. A Google-certified CMP with the IAB Transparency and Consent Framework (TCF) is mandatory only for publishers that serve personalized ads through AdSense, Ad Manager, or AdMob in the EEA, the UK, and Switzerland. According to Google, advertisers are free to use a CMP outside the partner program for Consent Mode as well. A partner CMP is still worth it: it captures consent, stores it in a verifiable way, and reliably passes the four signals to Consent Mode.

Three points matter for selection and integration:

• Understand certification correctly: Publishers using AdSense, Ad Manager, or AdMob choose from Google's list of certified providers. Advertisers instead check whether the CMP passes all four Consent Mode signals. Google's partner list is a useful starting point for this.
• Correct Consent Mode integration: The CMP must set the default signals to denied before tags load and send an update after the user's decision. This chain is the most common point of failure.
• Map granular purposes: The TCF works with defined purposes and vendors. The banner interface must present them granularly so that consent holds up under Austrian case law.

Impact on AI crawlers and GEO

Besides measurement, consent and tracking setups also affect visibility to AI crawlers such as GPTBot, ClaudeBot, and PerplexityBot. The mechanism is technical and easy to overlook.

On one key point, AI crawlers behave like classic search engine bots: they do not dismiss cookie banners and do not give consent. If you hide content behind a cookie wall or load key blocks of text via JavaScript only after consent, you risk this content staying invisible to AI systems. This leads to three principles for GEO:

• Do not tie content to consent: Editorial text, definitions, and specialist content belong in the initial HTML, not in scripts that fire only after consent. Only tracking and marketing tags belong behind consent.
• Avoid cookie walls: A hard cookie wall that blocks all content harms classic indexing as well as AI visibility. It is also legally contested.
• Prefer server-side rendering: Content rendered on the server is accessible regardless of consent and client-side JavaScript. In Next.js architectures, this is the more reliable foundation for AI crawlers and AI answers.

So the separation is clear: measurement behind consent, content in front of it. If you mix the two, you lose visibility in exactly the channels that increasingly decide discoverability in DACH B2B.

Core Web Vitals: consent scripts on the critical path

Cookie and consent scripts by nature run early and block rendering, because the banner has to appear before any interaction. That is exactly what makes them a risk for Core Web Vitals. A heavy CMP script delays rendering and puts particular strain on two metrics.

• LCP (Largest Contentful Paint): A render-blocking consent script pushes back the largest visible content element. If the banner sits over the main content, it can itself become the LCP element and worsen the measurement.
• INP (Interaction to Next Paint): Extensive CMP logic blocks the main thread and delays the response to the first user interaction, such as the click on Accept or Reject.

Practical countermeasures are to keep the CMP script as small as possible, to load it asynchronously where the logic allows, and to avoid layout shifts by reserving space for the banner so the CLS value stays stable. Privacy-friendly, cookieless analytics solutions with a lightweight script reduce the load further and provide a consent-free, aggregated view of measurement.

Common implementation mistakes

The typical mistakes recur and can usually be fixed with moderate effort.

• Default set to granted in the EEA: If the default status is not set to denied, tags fire with full tracking before consent. This is the most serious and most common violation.
• Missing update signal: The default command is in place, but the update after the user's decision is missing. The status then remains set to denied permanently, and even users who consented are not fully measured.
• Wrong order: The Consent Mode snippet loads after the Google tags. A tag then fires before the status is known.
• Unequal reject button: A colored Accept button next to a gray Reject link counts as impermissible nudging and puts the validity of consent at risk.
• Content behind consent: Editorial text loads only after consent and therefore becomes invisible to search engine and AI crawlers.
• Non-certified CMP for publishers: If you serve personalized ads through AdSense, Ad Manager, or AdMob and use a CMP without Google certification or without a current TCF version, you fail to meet Google's publisher requirement. For advertisers using Consent Mode, a certified CMP is not mandatory.

Metrics, measurement, and debugging

You need to actively test and monitor whether a Consent Mode v2 setup works. A banner that was set up once is no proof that it functions correctly.

• Check Tag Assistant and consent status: Google Tag Assistant lets you trace which consent signals are set and whether default fires before update. Ideally, debug mode shows the status change from denied to granted after consent.
• Monitor modeled conversions: In Google Ads and GA4, track modeled conversions as a separate metric. A sudden drop points to a broken setup.
• Consent rate as a KPI: The consent rate itself is a metric to manage by. At a typical rate of around 40%, it puts the data basis into context and lets you assess the banner design.
• Assess thresholds realistically: Low-volume B2B accounts in particular should check whether there is enough volume for conversion modeling at all instead of interpreting modeled values uncritically.
• Trends over absolute values: Because the data basis is systematically incomplete, relative changes over time say more than absolute numbers.

Next steps

Consent Mode v2 and the end of the Privacy Sandbox mark the same turning point: the future of measurement lies in consent, first-party data, and server-side architecture, not in a cookieless browser technology. For DACH B2B companies, this results in a clear sequence. First, a granularly designed banner with a reject button as prominent as the accept button and a CMP that stores consent in a verifiable way. Then a clean Consent Mode v2 setup with default set to denied and a correct update. Building on that, server-side tagging and enhanced conversions where volume and consent support them. And throughout, the separation of content and measurement, so that search engines and AI crawlers see the content while tracking runs only after consent. If you implement this chain consistently, you measure in a legally sound way and stay visible, regardless of which browser technology comes or goes next.