Consent Mode v2 und Privacy Sandbox: Was bleibt nach 2025

Consent Mode v2 ist seit März 2024 für alle Werbetreibenden Pflicht, die im EWR und in Großbritannien Google Ads, Remarketing oder Conversion-Tracking nutzen. Ohne korrekt implementierten Consent Mode liefert Google keine personalisierten Anzeigen mehr aus und schaltet Remarketing-Funktionen ab. Parallel hat sich 2025 die Ausgangslage für die gesamte Tracking-Branche verschoben: Die Privacy Sandbox, jahrelang als Nachfolger der Third-Party-Cookies gehandelt, hat Google in zentralen Teilen aufgegeben. Für B2B-Unternehmen im DACH-Raum bedeutet das eine klare Aufgabe: rechtskonform messen, ohne sich auf eine Cookie-Zukunft zu verlassen, die nicht kommt.

Dieser Artikel ordnet beide Entwicklungen technisch ein, erklärt das korrekte Setup von Consent Mode v2, das dahinterliegende Conversion Modeling und die Konsequenzen für serverseitige Messung, Core Web Vitals und die Sichtbarkeit gegenüber KI-Crawlern.

Warum Consent Mode v2 und das Ende der Privacy Sandbox jetzt zusammengehören

Die beiden Themen wirken getrennt, gehören aber zusammen. Consent Mode v2 regelt, wie ein Werbetreibender den Einwilligungsstatus eines Nutzers an Google übermittelt. Die Privacy Sandbox sollte das technische Fundament liefern, auf dem Werbung nach dem Wegfall der Third-Party-Cookies funktioniert. Mit dem Ende dieser Sandbox-Pläne bleibt die heutige Realität bestehen, und genau diese Realität macht Consent Mode v2 so wichtig.

Die Datengrundlage ist klar: Laut dem HTTP Archive Web Almanac sind 61 Prozent aller Cookies auf den Top-1-Million-Websites Third-Party-Cookies, bei den Top 1.000 sogar 77 Prozent (internationale Messung). Fast 100 Prozent dieser Third-Party-Cookies setzen das Attribut SameSite=None, um überhaupt seitenübergreifend gesendet zu werden. Das zeigt, wie stark das Werbe-Ökosystem weiterhin von genau jenen Cookies abhängt, deren Ablauf jahrelang angekündigt war.

Hinzu kommt der Einwilligungsverlust durch rechtskonforme Banner. Eine Benchmark-Studie aus dem DACH-Raum zeigt: Bei rechtskonformer Gestaltung gehen im Schnitt rund 60 Prozent der Besuchsdaten verloren, weil die Nutzer ablehnen (Daten für Deutschland/EU). Das entspricht einer Zustimmungsquote von etwa 40 Prozent. Wer im EWR misst, arbeitet also strukturell mit lückenhaften Daten, und Consent Mode v2 ist Googles Antwort auf genau diese Lücke.

Was Consent Mode v2 technisch ist: Basic, Advanced und die vier Signale

Consent Mode v2 ist eine Schnittstelle, über die der Einwilligungsstatus an Google Tags übergeben wird. Statt Tags einfach zu blockieren, passt Consent Mode ihr Verhalten an den Status an. Zwei Implementierungsvarianten existieren.

• Basic Consent Mode: Google Tags werden erst geladen, nachdem der Nutzer eingewilligt hat. Vor der Einwilligung werden keinerlei Daten an Google gesendet, auch keine cookielosen Pings. Lehnt der Nutzer ab, fehlen die Daten vollständig, und Google modelliert nur auf Basis aggregierter Beobachtungen.
• Advanced Consent Mode: Die Google Tags laden von Anfang an, senden bei fehlender Einwilligung aber nur anonyme, cookielose Signale ohne personenbezogene Identifikatoren. Diese Pings liefern die Datenbasis für das Conversion Modeling. Sobald der Nutzer einwilligt, wechseln die Tags in den vollen Messmodus.

Vier Signale steuern dieses Verhalten. ad_storage regelt das Setzen werbebezogener Cookies. analytics_storage steuert Cookies für die Analyse, etwa in Google Analytics 4. ad_user_data legt fest, ob Nutzerdaten zu Werbezwecken an Google gesendet werden dürfen. ad_personalization entscheidet über personalisierte Werbung und Remarketing. Die beiden letzten Signale kamen mit Version 2 hinzu und sind der Grund, warum die Umstellung Pflicht wurde.

Technisch läuft die Steuerung über zwei Befehle. Mit dem default-Befehl wird der Ausgangszustand gesetzt, bevor irgendein Tag feuert. Im EWR muss dieser Default für alle nicht notwendigen Kategorien auf denied stehen. Mit dem update-Befehl wird der Status nach der Nutzerentscheidung aktualisiert. Reihenfolge und Timing sind entscheidend: Der default-Befehl muss vor dem Laden der Google Tags ausgelöst werden, sonst feuert ein Tag, bevor der Einwilligungsstatus bekannt ist. In der Praxis übernimmt meist eine Consent Management Platform diese Steuerung und übergibt die Signale an Google Tag oder den Google Tag Manager.

Conversion Modeling: Wie Google fehlende Conversions schätzt

Conversion Modeling ist der eigentliche Nutzen des Advanced Consent Mode. Wenn ein Nutzer ablehnt, fehlt die direkte Zuordnung zwischen Anzeigenklick und Conversion. Google füllt diese Lücke mit einem statistischen Modell, das aus den beobachtbaren, eingewilligten Pfaden auf die nicht beobachtbaren schließt.

Die Größenordnung belegt Google selbst: Im Schnitt stellt Conversion Modeling im Consent Mode mehr als 70 Prozent der durch fehlende Cookie-Einwilligung verlorenen Ad-Click-to-Conversion-Pfade wieder her (internationale Google-Daten, 2021). Wichtig ist der Vorbehalt, den Google ausdrücklich nennt: Die Ergebnisse variieren stark je nach Zustimmungsrate und Qualität der Implementierung.

Genau hier liegt das B2B-Problem. Modellierung braucht Volumen. Google aktiviert das Conversion Modeling im Consent Mode erst ab einem bestimmten Mindestvolumen an Anzeigenklicks und Nutzeraufkommen. Viele DACH-B2B-Konten erreichen diese Datenbasis nicht: Ein Nischenanbieter mit wenigen Hundert Klicks im Monat liegt darunter. Für solche Konten greift dann nur das allgemeinere, weniger präzise Modell auf Google-Ebene.

Die realistische Erwartung für kleinvolumiges B2B lautet daher: Conversion Modeling ist kein Schalter, der verlorene Conversions garantiert zurückbringt. Es funktioniert dort gut, wo genug Traffic vorhanden ist. Wer wenig Volumen hat, sollte den Fokus auf eine saubere First-Party-Datenstrategie und serverseitige Messung legen, statt sich auf Modellierung zu verlassen.

Das Ende der Privacy Sandbox 2025 richtig einordnen

Die Chronologie ist wichtig, weil sie oft verkürzt dargestellt wird. Im April 2025 kündigte Google an, kein eigenständiges Auswahlfenster für Third-Party-Cookies in Chrome einzuführen und stattdessen am bestehenden Modell festzuhalten. Im Oktober 2025 folgte der entscheidende Schritt. Laut dem offiziellen Privacy Sandbox Blog hat Google angekündigt, eine Reihe von Privacy-Sandbox-Technologien einzustellen, darunter die Attribution Reporting API, Protected Audience und Topics, und in Chrome am bisherigen Umgang mit der Third-Party-Cookie-Wahl festzuhalten (Ankündigung vom 17. Oktober 2025).

Wichtig für die korrekte Einordnung: Google stellt eine konkrete Liste von Technologien ein, nicht pauschal jede Funktion. Eingestellt werden unter anderem Topics, Protected Audience, die Attribution Reporting API, Private Aggregation, IP Protection und Related Website Sets. Was praktisch bleibt:

• Third-Party-Cookies in Chrome: Sie verschwinden auf absehbare Zeit nicht. Das bestehende Modell bleibt erhalten, ein neues, separates Auswahlfenster für Cookies ist nicht angekündigt.
• CHIPS (Cookies Having Independent Partitioned State): Partitionierte Cookies bleiben als Mechanismus bestehen und sind unabhängig von den eingestellten APIs nutzbar.
• Der rechtliche Rahmen: DSGVO und ePrivacy ändern sich durch Googles Entscheidung nicht. Einwilligung bleibt Pflicht, unabhängig davon, welche Browser-Technologie verfügbar ist.

Die Konsequenz für Werbetreibende: Die jahrelange Vorbereitung auf eine cookielose Zukunft via Sandbox-APIs ist hinfällig. Stattdessen verschiebt sich der Fokus dauerhaft auf Einwilligung, First-Party-Daten und serverseitige Architektur. Browserseitige Restriktionen wie Apples Intelligent Tracking Prevention in Safari, das in Europa rund 20 Prozent Marktanteil hat (Daten für Europa, Chrome rund 60 Prozent, Edge rund 7 Prozent), wirken davon unberührt weiter.

DSGVO, TKG 2021, TDDDG und der EU-Digital-Omnibus

In Österreich gilt für den Zugriff auf Endgeräte das Telekommunikationsgesetz 2021, konkret die ePrivacy-Umsetzung. Nicht technisch notwendige Cookies und vergleichbare Technologien brauchen eine vorherige, aktive Einwilligung. In Deutschland erfüllt das früher als TTDSG bekannte und inzwischen in TDDDG umbenannte Gesetz dieselbe Funktion über Paragraf 25. Beide verlangen die explizite Zustimmung für alle nicht essenziellen Cookies, ein bloßes Weiterscrollen genügt nicht.

Die österreichische Rechtsprechung hat den Maßstab 2025 weiter geschärft. In einer Entscheidung vom 13. August 2025 erklärte das Bundesverwaltungsgericht ein pauschales Pay-or-Okay-Banner ohne granulare Wahlmöglichkeit für rechtswidrig (Entscheidung für Österreich). Das Gericht bemängelte, dass Nutzer nicht in einzelne Verarbeitungszwecke wie Werbung, Profiling und Analyse granular einwilligen oder diese verweigern konnten. Für die Praxis heißt das: Granularität ist nicht optional, sondern Voraussetzung einer wirksamen Einwilligung.

Auf EU-Ebene zeichnet sich Bewegung ab. Mit dem Vorschlag zum Digital Omnibus vom 19. November 2025 plant die Europäische Kommission einen verpflichtenden Single-Click-Reject-Button, eine zentrale maschinenlesbare Präferenzsetzung etwa über den Browser sowie den Wegfall von Consent-Pop-ups für nicht risikobehaftete Zwecke wie reine Besuchszählung (Vorschlag der EU-Kommission). Sollte der Vorschlag Gesetz werden, könnte er die Banner-Landschaft spürbar verändern. Bis dahin gilt der bestehende Rahmen mit gleichwertigem Ablehnen-Button und granularen Zwecken unverändert.

Server-Side Tagging und First-Party-Daten als Antwort auf den Signalverlust

Serverseitiges Tagging, meist als sGTM (Server-Side Google Tag Manager) umgesetzt, ist die technische Antwort auf Browser-Restriktionen und Signalverlust. Statt Tags im Browser des Nutzers auszuführen, läuft der Tag-Container auf einem eigenen Server, der die Daten empfängt, verarbeitet und kontrolliert an die Zielsysteme weiterleitet.

Der Nutzen ist mehrschichtig:

• Längere Cookie-Lebensdauer: Cookies, die der Server im First-Party-Kontext per HTTP-Antwort setzt, umgehen die kurzen Fristen, die ITP für per JavaScript gesetzte Cookies vorsieht. Das gilt aber nur, wenn Safari den Tagging-Server nicht als Drittanbieter einstuft. Erkennt ITP über CNAME oder IP-Adresse einen Drittanbieter, kappt es auch serverseitig gesetzte Cookies auf 7 Tage. Ein sGTM auf einer Subdomain, die per CNAME auf einen externen Cloud-Hoster zeigt, fällt typischerweise darunter. Läuft der Tagging-Server im selben IP-Bereich wie die Website, stabilisiert er die Messung in Safari.
• Datenkontrolle vor Weitergabe: Auf dem Server lassen sich personenbezogene Felder filtern, kürzen oder pseudonymisieren, bevor Daten an Dritte gehen. Das unterstützt Datenminimierung im Sinne der DSGVO.
• Enhanced Conversions: Gehashte First-Party-Daten wie E-Mail-Adressen werden serverseitig sicher übergeben und verbessern die Conversion-Zuordnung, sofern eine gültige Einwilligung vorliegt.

Wichtig ist die Abgrenzung: Server-Side Tagging ist keine Umgehung der Einwilligung. Es ändert die Architektur der Datenflüsse, nicht die Rechtsgrundlage. Wer ohne Einwilligung serverseitig misst, verstößt genauso gegen TKG und DSGVO wie clientseitig. sGTM verbessert also Datenqualität und Kontrolle, ersetzt aber niemals den Consent.

CMP und IAB TCF: Pflicht für Publisher, Auswahl für Werbetreibende

Für Werbetreibende schreibt Google keine zertifizierte Consent Management Platform vor. Consent Mode v2 lässt sich auch über eine eigene gtag- oder Tag-Manager-Implementierung umsetzen, solange default und update korrekt übergeben werden. Pflicht ist eine Google-zertifizierte CMP mit IAB Transparency and Consent Framework (TCF) nur für Publisher, die über AdSense, Ad Manager oder AdMob personalisierte Anzeigen im EWR, in Großbritannien und in der Schweiz ausliefern. Werbetreibenden steht es laut Google frei, auch eine CMP außerhalb des Partnerprogramms für Consent Mode zu nutzen. Eine Partner-CMP lohnt sich trotzdem: Sie erfasst die Einwilligung, speichert sie nachweisbar und übergibt die vier Signale zuverlässig an Consent Mode.

Bei der Auswahl und Integration zählen drei Punkte:

• Zertifizierung richtig einordnen: Publisher mit AdSense, Ad Manager oder AdMob wählen aus Googles Liste zertifizierter Anbieter. Werbetreibende prüfen stattdessen, ob die CMP alle vier Consent-Mode-Signale übergibt. Googles Partnerliste ist dafür ein brauchbarer Startpunkt.
• Korrekte Consent-Mode-Anbindung: Die CMP muss die default-Signale auf denied setzen, bevor Tags laden, und nach der Nutzerentscheidung ein update senden. Diese Verkettung ist der häufigste Fehlerpunkt.
• Granulare Zwecke abbilden: Das TCF arbeitet mit definierten Zwecken und Anbietern. Die Banner-Oberfläche muss diese granular darstellen, damit die Einwilligung der österreichischen Rechtsprechung standhält.

Auswirkungen auf KI-Crawler und GEO

Consent- und Tracking-Setups beeinflussen neben der Messung auch die Sichtbarkeit gegenüber KI-Crawlern wie GPTBot, ClaudeBot und PerplexityBot. Der Mechanismus ist technisch und wird leicht übersehen.

KI-Crawler verhalten sich in einem zentralen Punkt wie klassische Suchmaschinen-Bots: Sie klicken keine Cookie-Banner weg und erteilen keine Einwilligung. Wer Inhalte hinter einer Cookie-Wall verbirgt oder zentrale Textbausteine erst nach Consent per JavaScript nachlädt, riskiert, dass diese Inhalte für KI-Systeme unsichtbar bleiben. Daraus folgen drei Grundsätze für GEO:

• Inhalte nicht an Consent koppeln: Redaktioneller Text, Definitionen und Fachinhalte gehören in das initiale HTML, nicht in Skripte, die erst nach Zustimmung feuern. Nur Tracking und Marketing-Tags gehören hinter den Consent.
• Cookie-Walls vermeiden: Eine harte Cookie-Wall, die den gesamten Inhalt blockiert, schadet sowohl der klassischen Indexierung als auch der KI-Sichtbarkeit. Sie ist zudem rechtlich umstritten.
• Server-Side Rendering bevorzugen: Inhalte, die serverseitig gerendert werden, sind unabhängig von Consent und clientseitigem JavaScript zugänglich. In Next.js-Architekturen ist das die robustere Grundlage für KI-Crawler und AI-Antworten.

Die Trennung ist also klar: Messung hinter den Consent, Inhalt davor. Wer beides vermischt, verliert Sichtbarkeit in genau den Kanälen, die im DACH-B2B zunehmend über Auffindbarkeit entscheiden.

Core Web Vitals: Consent-Skripte auf dem kritischen Pfad

Cookie- und Consent-Skripte laufen naturgemäß früh und blockierend, denn das Banner muss vor jeder Interaktion erscheinen. Genau das macht sie zu einem Risiko für die Core Web Vitals. Ein schweres CMP-Skript verzögert das Rendering und belastet zwei Metriken besonders.

• LCP (Largest Contentful Paint): Ein render-blockierendes Consent-Skript verschiebt den größten sichtbaren Inhalt nach hinten. Wenn das Banner über dem Hauptinhalt liegt, kann es selbst zum LCP-Element werden und die Messung verschlechtern.
• INP (Interaction to Next Paint): Umfangreiche CMP-Logik blockiert den Hauptthread und verzögert die Reaktion auf die erste Nutzerinteraktion, etwa den Klick auf Annehmen oder Ablehnen.

Praktische Gegenmaßnahmen sind, das CMP-Skript so klein wie möglich zu halten, es asynchron zu laden, wo es die Logik erlaubt, und Layout-Verschiebungen durch reservierten Platz für das Banner zu vermeiden, damit der CLS-Wert stabil bleibt. Datenschutzfreundliche, cookielose Analytics-Lösungen mit schlankem Skript reduzieren die Last zusätzlich und liefern eine einwilligungsfreie, aggregierte Messperspektive.

Häufige Fehler bei der Implementierung

Die typischen Fehler wiederholen sich und sind meist mit überschaubarem Aufwand zu beheben.

• Default auf granted im EWR: Wird der Standardstatus nicht auf denied gesetzt, feuern Tags vor der Einwilligung mit vollem Tracking. Das ist der schwerwiegendste und häufigste Verstoß.
• Fehlendes Update-Signal: Der default-Befehl ist vorhanden, aber das update nach der Nutzerentscheidung fehlt. Dann bleibt der Status dauerhaft auf denied, und auch eingewilligte Nutzer werden nicht voll gemessen.
• Falsche Reihenfolge: Das Consent-Mode-Snippet lädt nach den Google Tags. Ein Tag feuert dann, bevor der Status bekannt ist.
• Ungleichwertiger Ablehnen-Button: Ein farbiger Annehmen-Button neben einem grauen Ablehnen-Link gilt als unzulässiges Nudging und gefährdet die Wirksamkeit der Einwilligung.
• Inhalt hinter Consent: Redaktioneller Text wird erst nach Zustimmung geladen und verschwindet dadurch für Suchmaschinen- und KI-Crawler.
• Nicht zertifizierte CMP bei Publishern: Wer über AdSense, Ad Manager oder AdMob personalisierte Anzeigen ausliefert und dafür eine CMP ohne Google-Zertifizierung oder ohne aktuelles TCF nutzt, verfehlt Googles Publisher-Anforderung. Für Werbetreibende mit Consent Mode ist eine zertifizierte CMP keine Pflicht.

Metriken, Messung und Debugging

Die Wirksamkeit eines Consent-Mode-v2-Setups muss aktiv geprüft und überwacht werden. Ein einmal eingerichtetes Banner ist kein Beleg für korrekte Funktion.

• Tag Assistant und Consent-Status prüfen: Mit dem Google Tag Assistant lässt sich nachvollziehen, welche Consent-Signale gesetzt sind und ob default vor update feuert. Im Idealfall zeigt der Debug-Modus den Statuswechsel von denied auf granted nach der Zustimmung.
• Modellierte Conversions überwachen: In Google Ads und GA4 sollten modellierte Conversions als eigene Größe beobachtet werden. Ein plötzlicher Einbruch deutet auf ein gebrochenes Setup hin.
• Consent-Rate als Kennzahl: Die Zustimmungsquote selbst ist eine Steuerungsgröße. Bei einer typischen Quote um 40 Prozent ordnet sie die Datenbasis ein und bewertet die Banner-Gestaltung.
• Schwellenwerte realistisch einschätzen: Gerade kleinvolumige B2B-Konten sollten prüfen, ob überhaupt genug Volumen für Conversion Modeling vorliegt, statt modellierte Werte unkritisch zu interpretieren.
• Trends statt Absolutwerte: Da die Datenbasis systematisch lückenhaft ist, sind relative Entwicklungen über die Zeit aussagekräftiger als absolute Zahlen.

Weiterführendes

Consent Mode v2 und das Ende der Privacy Sandbox markieren denselben Wendepunkt: Die Zukunft der Messung liegt nicht in einer cookielosen Browser-Technologie, sondern in Einwilligung, First-Party-Daten und serverseitiger Architektur. Für DACH-B2B-Unternehmen ergibt sich daraus eine klare Reihenfolge. Zuerst ein granular gestaltetes Banner mit gleichwertigem Ablehnen-Button und einer CMP, die Einwilligungen nachweisbar speichert. Dann ein sauberes Consent-Mode-v2-Setup mit default auf denied und korrektem update. Darauf aufbauend serverseitiges Tagging und Enhanced Conversions, wo Volumen und Einwilligung es tragen. Und durchgehend die Trennung von Inhalt und Messung, damit Suchmaschinen und KI-Crawler die Inhalte sehen, während Tracking erst nach Zustimmung läuft. Wer diese Kette konsequent umsetzt, misst rechtssicher und bleibt sichtbar, unabhängig davon, welche Browser-Technologie als nächstes kommt oder geht.