Google Consent Mode v2 richtig umsetzen

Wenn ein Teil deiner Besucher im Cookie-Banner ablehnt, sieht dein Google-Ads-Konto auch nur einen Teil deiner Conversions. Google selbst schreibt, dass einwilligende Nutzer typischerweise zwei- bis fünfmal häufiger konvertieren als ablehnende. Die Lücke ist also nicht nur ein Reporting-Problem: Smart Bidding optimiert auf genau die Daten, die ankommen. Google Consent Mode v2 entscheidet, wie groß diese Lücke bleibt.

Google Consent Mode v2 übermittelt Googles Tags den Einwilligungsstatus deiner Besucher über vier Parameter: ad_storage, analytics_storage, ad_user_data und ad_personalization. Im Advanced Mode laden die Tags mit dem Standardwert „denied“ und senden bei Ablehnung cookielose Pings, aus denen Google Ads und GA4 fehlende Conversions und Verhaltensdaten modellieren. Im Basic Mode bleiben die Tags bis zur Einwilligung blockiert, und Google Ads kann nur mit einem allgemeinen Modell arbeiten.

Wichtig vorab: Dieser Beitrag betrachtet Consent Mode aus Sicht von Messqualität und Kampagnensteuerung. Er ist keine Rechtsberatung. Ob und wie du Daten bei Ablehnung verarbeiten darfst, klärst du mit deinem Datenschutzbeauftragten oder einer Anwältin.

Was Google Consent Mode v2 ist und warum es seit 2024 zählt

Consent Mode ist kein Cookie-Banner, sondern eine Schnittstelle zwischen deinem Banner (der Consent Management Platform, kurz CMP) und Googles Tags. Das Banner fragt, Consent Mode übersetzt die Antwort in Signale, und die Tags passen ihr Verhalten daran an.

Im November 2023 hat Google zwei neue Parameter eingeführt: ad_user_data und ad_personalization. Seit März 2024 setzt Google seine EU-Richtlinie zur Nutzereinwilligung strenger durch, und zwar auch für Messfunktionen. Die Richtlinie schützt Endnutzer im Europäischen Wirtschaftsraum, im Vereinigten Königreich und in der Schweiz. Wer dort Messung, personalisierte Werbung und Remarketing weiter nutzen will, muss die Einwilligung einholen und an Google übermitteln. GA4 zeigt in den Consent-Einstellungen sogar direkt an, wenn affirmative Signale fehlen. Ohne sie landen laut Google seit Anfang März 2024 nur noch Nutzer außerhalb des EWR in den Zielgruppen für verknüpfte Werbeprodukte.

Für dein Budget heißt das: Fehlen die v2-Signale, verlierst du im EWR Remarketing-Listen und Personalisierung. Sind sie falsch gesetzt, liefert dein Konto weniger Conversions, und deine Gebotsstrategien lernen auf einer kleineren und verzerrten Datenbasis.

Die vier Parameter und was sie im Konto auslösen

ad_storage steuert Werbe-Cookies. Bei „denied“ werden laut Google keine neuen Werbe-Cookies geschrieben und keine bestehenden Erstanbieter-Werbe-Cookies gelesen. IP-Adressen werden bei der Erfassung gekürzt.

analytics_storage steuert Analytics-Cookies. Bei „denied“ liest und schreibt GA4 keine Erstanbieter-Cookies, im Advanced Mode gehen aber cookielose Pings an Google Analytics.

ad_user_data regelt, ob nutzerbezogene Daten für Werbezwecke an Google gesendet werden dürfen. Google nennt Enhanced Conversions ausdrücklich als Anwendungsfall, der diese Einwilligung braucht. Bei „denied“ ist die Nutzung personenbezogener Daten für Online-Werbung deaktiviert, und der Export von Conversions über Klick-IDs ist eingeschränkt.

ad_personalization regelt personalisierte Werbung. Bei „denied“ erhalten Funktionen wie Remarketing in Google Ads keine Daten. Für personalisierte Werbung müssen ad_user_data und ad_personalization beide auf „granted“ stehen.

Die beiden v2-Parameter sind der Grund, warum alte Setups heute Lücken haben. Google hat für EWR-Kunden mit Consent Mode v1 ad_storage einmalig automatisch auf ad_user_data gespiegelt. ad_personalization wird nicht automatisch übernommen. Wer das nie nachgezogen hat, verliert Zielgruppenfunktionen, ohne dass im Interface etwas Rotes aufleuchtet.

Basic oder Advanced Mode: die eigentliche Budgetentscheidung

Im Basic Mode lädst du Googles Tags erst, wenn der Nutzer im Banner zugestimmt hat. Lehnt er ab, geht nichts an Google, nicht einmal der Einwilligungsstatus. GA4 kann dann keine modellierten Daten ergänzen, und Google Ads modelliert Conversions nur auf Basis eines allgemeinen Modells.

Im Advanced Mode laden die Tags sofort mit dem Standardwert „denied“. Lehnt der Nutzer ab, senden sie cookielose Pings. Laut Googles Entwicklerdokumentation enthalten diese funktionale Informationen wie Zeitstempel, User-Agent und Referrer sowie aggregierte Angaben, etwa ob die URL Klickinformationen wie eine GCLID enthielt, einen Boolean für den Einwilligungsstatus und eine Zufallszahl pro Seitenaufruf. Daraus baut Google ein advertiser-spezifisches Modell, das laut Google genauer ist als das allgemeine.

Aus Performance-Sicht spricht fast alles für Advanced. Ob du Advanced einsetzen darfst, ist aber eine datenschutzrechtliche Frage, die du nicht im Marketingteam allein beantworten solltest. Triff diese Entscheidung bewusst und dokumentiert, nicht über eine Voreinstellung in der CMP.

Conversion-Modellierung: Voraussetzungen, die viele nicht erreichen

Modellierung ist kein Schalter, sondern hängt an Schwellenwerten.

Für die Conversion-Modellierung in Google Ads brauchst du laut Google eine korrekte Consent-Mode-Implementierung und 700 Anzeigenklicks über 7 Tage pro Kombination aus Land und Domain. Das sind im Schnitt 100 Klicks pro Tag, nicht pro Konto, sondern je Land und Domain. Ein B2B-Anbieter mit 40 Klicks am Tag pro Land kommt damit nicht in die Modellierung, egal wie sauber das Setup ist.

Für die Verhaltensmodellierung in GA4 verlangt Google mindestens 1.000 Events pro Tag mit analytics_storage „denied“ an mindestens 7 Tagen und mindestens 1.000 tägliche Nutzer mit analytics_storage „granted“ an mindestens 7 der letzten 28 Tage. Consent Mode muss auf allen Seiten aktiv sein, und die Tags müssen vor dem Banner laden. Auch dann garantiert Google die Eignung nicht. Sichtbar werden die modellierten Daten erst, wenn du unter Verwaltung › Datenanzeige › Berichtsidentität „Blended“ auswählst.

Die Konsequenz für deine Steuerung: Liegt dein Konto unter den Schwellen, ersetzt Modellierung nichts. Dann sind Enhanced Conversions und ein sauberer Offline-Import deine wichtigsten Hebel.

Praxis: Setup in sechs Schritten prüfen

Default vor allem anderen. Der Befehl gtag('consent', 'default', …) muss auf jeder Seite vor jedem config- oder event-Befehl stehen. Google warnt ausdrücklich: Wird der Consent-Code in falscher Reihenfolge aufgerufen, funktionieren die Defaults nicht. Setze alle vier Parameter explizit.
Asynchrone Banner abfangen. Lädt deine CMP verzögert, gib wait_for_update mit einem Millisekundenwert mit. Googles Beispiel nutzt 500 ms. Ohne diesen Puffer feuern Tags, bevor das Update ankommt.
Regionen sauber trennen. Mit dem region-Parameter (ISO 3166-2) kannst du Defaults je Land setzen. Der spezifischere Wert gewinnt. Ein Default ohne Region gilt für alle übrigen Besucher.
Update bei jeder Änderung. Auch ein Widerruf von „granted“ auf „denied“ läuft über den Update-Befehl, und zwar auf der Seite, auf der er passiert, vor dem Seitenwechsel. In Google Tag Manager nutzt du dafür die APIs setDefaultConsentState und updateConsentState beziehungsweise ein Consent-Mode-Template deiner CMP, nicht gtag('consent','update').
Tag Assistant durchklicken. Öffne die Seite im Tag Assistant und prüfe im ersten Consent-Event, dass alle vier Parameter als Default gesetzt sind (Spalte „On-page Default“: Denied). Stimme im Banner zu und prüfe im letzten Consent-Event die Spalte „On-page Update“: Granted. Im Tab „Tags“ siehst du, welches Tag gefeuert hat und welches wegen Consent blockiert wurde. Wiederhole den Test mit „Ablehnen“.
Status in Google Ads und GA4 lesen. In Google Ads findest du unter Ziele › Conversions › Übersicht bei jeder Website-Conversion-Aktion den Tab „Diagnose“. „Consent mode is implemented“ heißt: Setup erkannt, Schwellen nicht erreicht. „Consent mode is implemented and modeling is active“ heißt: Modellierung läuft. Der Status braucht bis zu 48 Stunden, in Einzelfällen bis zu zwei Wochen. In GA4 zeigen dir die Consent-Einstellungen unter Datenerfassung und -änderung, ob Signale für Werbemessung und Personalisierung ankommen. Hinweise dort aktualisieren sich nach einer Korrektur innerhalb von 48 bis 72 Stunden.

Zur Einordnung der Lücke hilft eine einfache Rechnung. Ist c deine Einwilligungsquote und k der Faktor, um den Einwilliger häufiger konvertieren, dann siehst du ohne Modellierung ungefähr diesen Anteil deiner echten Conversions: c × k ÷ (c × k + (1 − c)). Rechenbeispiel mit c = 50 % und k = 2: 1 ÷ 1,5 = rund 67 %. Ein Drittel deiner Conversions fehlt dann im Konto, und genau dieses Drittel lernt dein Smart Bidding nicht. Die Formel ist eine Näherung, kein Ersatz für die Uplift-Daten aus der Diagnose.

Die häufigsten Implementierungsfehler

Der Klassiker ist ein Default, der zu spät kommt: Das GA4-Tag feuert beim Seitenaufruf, die CMP setzt den Default erst danach. Fast genauso häufig fehlt ad_personalization, weil das Setup aus der v1-Zeit stammt. Dritter Fehler: Die CMP sendet zwar ein Update, aber nur auf der Folgeseite. Dann geht der Einstiegsseitenaufruf mit der GCLID verloren. Viertens wird Consent Mode nur auf der Hauptdomain eingerichtet, obwohl Checkout oder Buchungsstrecke auf einer anderen Domain laufen. Google weist darauf hin, dass Consent Mode bei mehreren Domains auf allen ausgerollt sein muss. Fünftens wird url_passthrough vergessen. Mit diesem Parameter reicht der Google-Tag Klick- und Sitzungsinformationen bei abgelehnten Cookies über URL-Parameter weiter, sofern der Link auf dieselbe Domain führt.

Enhanced Conversions und Server-Side: was Consent Mode ergänzt

Enhanced Conversions senden gehashte Erstanbieterdaten wie E-Mail-Adressen (SHA-256) zusätzlich zur Conversion an Google. Das verbessert die Zuordnung, ist aber an ad_user_data gebunden. Ohne diese Einwilligung fließen keine nutzerbezogenen Daten. Enhanced Conversions vergrößern also nicht die Zahl der messbaren Nutzer, sondern die Genauigkeit innerhalb der Einwilliger.

Server-Side Tagging umgeht Consent ebenfalls nicht. Google beschreibt, dass du Consent Mode nur im Web-Container einrichten musst, weil die Signale mit der Anfrage an den Server-Container reisen. Googles Tags im Server-Container sind consent-aware. Für Google-Ads-Conversions und Floodlight brauchst du dort zusätzlich das Conversion-Linker-Tag, und wenn du regionsspezifische Defaults nutzt, muss auch der Tagging-Server diese unterstützen. Für Tags von Drittanbietern im Server-Container musst du die Consent-Logik selbst sicherstellen.

Unterm Strich: Consent Mode sorgt dafür, dass Ablehnungen nicht zum blinden Fleck werden. Enhanced Conversions machen die Einwilliger präziser. Server-Side verbessert Kontrolle und Datenqualität. Erst zusammen ergeben sie ein Messsystem, auf das du Budget verlässlich steuern kannst. Wenn du das als Ganzes aufsetzen willst, schau dir unsere Leistung Tracking & Analytics an; wie sich saubere Daten in bessere Gebote übersetzen, zeigt Performance Marketing.

Häufige Fragen

Brauche ich Consent Mode v2, wenn ich nur außerhalb des EWR werbe?

Laut Googles Tag-Manager-Hilfe ist keine Aktion nötig, wenn du im EWR nicht wirbst. Die EU-Richtlinie zur Nutzereinwilligung betrifft Endnutzer im EWR, im Vereinigten Königreich und in der Schweiz. Sobald du dort Remarketing, Personalisierung oder Ads-Messung nutzt, brauchst du die Signale.

Wie lange dauert es, bis modellierte Conversions erscheinen?

Erst wenn die Schwellen erfüllt sind, beginnt das Training. Google spricht von Trainingsphasen und schrittweisen Verbesserungen, der Diagnosestatus kann bis zu zwei Wochen nachlaufen. Uplift-Daten je Domain und Land zeigt die Diagnose vier Wochen lang ab Modellierungsbeginn.

Reicht ein zertifiziertes CMP-Plug-in?

Es nimmt dir die Signalübergabe ab, aber nicht die Prüfung. Google sagt, dass zertifizierte CMP-Partner auf die neueste Consent-Mode-Version aktualisieren. Reihenfolge, Regionen, Folgeseiten und Zweitdomains musst du trotzdem im Tag Assistant testen.

Quellen

Du willst, dass aus mehr Blicken bei dir Kunden werden? Lass uns 15 Minuten auf dein Setup schauen, kostenlos und ohne Pitch-Deck. Jetzt Erstgespräch buchen

Google Consent Mode v2 richtig umsetzen: Datenverlust in Ads und Analytics begrenzen