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 Grossbritannien 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, wurde in zentralen Teilen eingestellt. 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 luckenhaften Daten, und Consent Mode v2 ist Googles Antwort auf genau diese Lücke.

Für Österreich ist die Reichweite des Themas gross. Anfang 2025 nutzten 8,69 Millionen Menschen das Internet, was einer Penetration von 95,3 Prozent entspricht (Daten für Österreich). Im B2B-Kontext wickelten zudem im Referenzjahr 2023 rund 31 Prozent der österreichischen Unternehmen Verkäufe über E-Commerce ab, mit einem Umsatzanteil von 19,1 Prozent (Daten für Österreich). Jede dieser digitalen Transaktionen erzeugt Messpunkte, die unter die Einwilligungspflicht fallen.

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 eine zertifizierte 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 Mehrwert 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 schliesst.

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 neuer separater Cookie-Prompt 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, TTDSG 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 blosses Weiterscrollen genügt nicht.

Die österreichische Rechtsprechung hat den Massstab 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 heisst 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 serverseitig in einem First-Party-Kontext gesetzt werden, unterliegen nicht den kurzen Ablauffristen, die ITP clientseitig setzt. Das stabilisiert die Messung in Safari und anderen restriktiven Browsern.
• 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.

Zertifizierte CMP und IAB TCF: Auswahl und Integration

Consent Mode v2 setzt für Google-Ads-Funktionen im EWR und in Grossbritannien eine Google-zertifizierte Consent Management Platform voraus, die das IAB Transparency and Consent Framework in einer aktuellen Version unterstützt. Die CMP erfasst die Einwilligung, speichert sie nachweisbar und übergibt die vier Signale an Consent Mode.

Bei der Auswahl und Integration zählen drei Punkte:

• Google-Zertifizierung prüfen: Nur CMPs aus der offiziellen Liste der zertifizierten Anbieter erfüllen die Anforderung. Eine selbstgebaute Lösung ohne Zertifizierung reicht für die Google-Ads-Pflicht nicht aus.
• 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 nicht nur die Messung, sondern 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 Gegenmassnahmen 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 Verstoss.
• 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: Eine CMP ohne Google-Zertifizierung oder ohne aktuelles TCF erfüllt die Anforderungen für Google-Ads-Funktionen nicht.

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 luckenhaft 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 zertifizierten CMP. 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.