
Consent Mode v2: Pflicht, Funktionsweise & Einrichtung
Consent Mode v2 erklärt: Warum er für Google Ads im EWR Pflicht ist, Basic vs. Advanced ehrlich verglichen – und die Einrichtung über CMP + GTM.
TL;DR
Consent Mode v2 ist Googles Standard, um die Cookie-Banner-Entscheidung deiner Besucher über die vier Signale ad_storage, analytics_storage, ad_user_data und ad_personalization an Google Ads und GA4 weiterzugeben – seit März 2024 verlangt Google ihn für Remarketing und personalisierte Werbung im EWR. Eingerichtet wird er über ein CMP plus Google Tag Manager; entscheidend ist, dass die Default-Signale vor allen Google-Tags auf denied stehen und erst nach der Banner-Entscheidung aktualisiert werden.
Kurz zur Einordnung: Seit März 2024 verlangt Google von allen Werbetreibenden, die Nutzer im Europäischen Wirtschaftsraum erreichen, den Consent Mode v2 – sonst funktionieren Remarketing und personalisierte Werbung dort schlicht nicht mehr. Trotzdem sehe ich in Audits regelmäßig Setups, bei denen der Cookie-Banner zwar hübsch aussieht, die Consent-Signale aber nie bei Google ankommen – oder erst, nachdem die Tags längst gefeuert haben. Dieser Guide erklärt, was Consent Mode v2 genau macht, worin sich Basic und Advanced Mode ehrlich unterscheiden und wie du das Setup über CMP + Google Tag Manager sauber aufbaust und prüfst.
Was ist Consent Mode v2?
Der Consent Mode v2 ist Googles Schnittstelle zwischen deinem Cookie-Banner (der Consent Management Platform, kurz CMP) und den Google-Tags auf deiner Website. Er beantwortet für jeden einzelnen Besucher die Frage: Was dürfen Google Ads und GA4 mit den Daten dieses Nutzers tun?
Die Antwort wird über vier Signale transportiert:
| Signal | Steuert | Betrifft konkret |
|--------|---------|------------------|
| ad_storage | Werbe-Cookies lesen und schreiben | Klick-Cookies für die Conversion-Zuordnung |
| analytics_storage | Analytics-Cookies | GA4-Sitzungs- und Nutzer-Cookies |
| ad_user_data | Übermittlung von Nutzerdaten an Google zu Werbezwecken | z. B. Daten für Enhanced Conversions |
| ad_personalization | Personalisierte Werbung | Remarketing-Listen, ähnliche Zielgruppen |
Jedes Signal kann granted (erteilt) oder denied (abgelehnt) sein. Dein CMP setzt diese Werte automatisch – abhängig davon, was der Nutzer im Banner anklickt.
Was ist neu an „v2"? Die ersten beiden Signale gibt es schon seit 2020 (Consent Mode v1). Mit v2 kamen im März 2024 ad_user_data und ad_personalization dazu. Hintergrund ist der Digital Markets Act (DMA) der EU: Google wurde als sogenannter Gatekeeper eingestuft und muss nachweisen, dass Nutzerdaten aus dem EWR nur mit Einwilligung für Werbung verwendet werden. Diese Nachweispflicht reicht Google technisch an dich als Werbetreibenden weiter.
Wichtig zur Abgrenzung: Consent Mode ersetzt deinen Cookie-Banner nicht – er übersetzt dessen Entscheidung für Google. Ob und wie du Einwilligungen einholen musst, regeln DSGVO und TDDDG (ehemals TTDSG) unabhängig davon. Dieser Artikel ist Praxiswissen aus dem Tracking-Alltag, keine Rechtsberatung.
Warum Consent Mode v2 für EWR-Werbetreibende Pflicht ist
„Pflicht" ist hier präzise zu verstehen: Es gibt kein Gesetz namens Consent Mode. Aber Google hat die Übermittlung der v2-Signale seit März 2024 zur Bedingung für zentrale Werbefunktionen im EWR gemacht. Ohne korrekt gesetzte Signale gilt laut Google:
- Remarketing fällt aus: Nutzer aus dem EWR werden nicht mehr in Remarketing-Listen aufgenommen. Bestehende Listen schrumpfen mit der Zeit, weil keine neuen Nutzer nachkommen – deine Remarketing-Strategien laufen ins Leere.
- Personalisierte Werbung ist blockiert: Zielgruppenfunktionen, die auf Nutzerdaten basieren, stehen für EWR-Traffic nicht zur Verfügung.
- Die Conversion-Messung wird lückenhafter: Ohne Consent-Signale verzichtest du auf die Conversion-Modellierung, mit der Google Messlücken durch abgelehnte Einwilligungen statistisch schließt. Smart Bidding optimiert dann auf einer kleineren Datenbasis – und trifft schlechtere Entscheidungen.
Aus meiner Praxis: Die Fälle, in denen „plötzlich das Remarketing nicht mehr funktioniert" oder Conversions unerklärlich einbrechen, haben auffallend oft dieselbe Ursache – ein fehlender oder falsch verdrahteter Consent Mode. Wer im EWR wirbt, kommt an dem Thema nicht vorbei.
Basic vs. Advanced Mode: der ehrliche Vergleich
Consent Mode v2 gibt es in zwei Varianten, und die Wahl ist ein echter Trade-off – nicht die eine „richtige" Lösung:
| | Basic Mode | Advanced Mode | |---|---|---| | Tags ohne Einwilligung | Werden gar nicht geladen | Laden immer, senden aber nur cookielose Pings | | Daten bei Ablehnung | Keine – auch keine anonymen Signale | Anonyme Pings (ohne Cookies, ohne Nutzer-IDs) | | Conversion-Modellierung | Nur auf genereller Ebene (laut Google) | Detaillierter, weil eigene Pings als Basis dienen | | Datenschutz-Bewertung | Konservativ, leicht zu verteidigen | Umstritten – cookielose Pings sind rechtlich nicht abschließend geklärt | | Komplexität | Gering | Höher (Ping-Verhalten muss verstanden und dokumentiert sein) |
Basic Mode ist die konservative Variante: Lehnt ein Nutzer ab, passiert nichts – kein Tag, kein Ping, keine Daten. Der Preis: Google kann die fehlenden Conversions nur grob modellieren, weil keinerlei Signale dieser Nutzer vorliegen.
Advanced Mode lädt die Tags immer und sendet bei Ablehnung cookielose Pings ohne Nutzer-Identifier. Daraus modelliert Google Conversions präziser. Der Haken: Ob diese Pings ohne Einwilligung datenschutzrechtlich zulässig sind, ist unter Juristen umstritten, und die Aufsichtsbehörden haben sich nicht einheitlich positioniert.
Meine ehrliche Empfehlung aus der Praxis: Basic Mode ist der sichere Default, mit dem du selten etwas falsch machst. Advanced Mode kann sich lohnen, wenn deine Ablehnungsquote hoch ist und dir Datenqualität für Smart Bidding wichtig ist – aber nur als bewusste Entscheidung, die du mit deinem Datenschutzbeauftragten oder Anwalt abgestimmt hast. Advanced „aus Versehen", weil das CMP es als Standard vorschlägt, ist die schlechteste aller Varianten.
Einrichtung über CMP + Google Tag Manager
Die Voraussetzungen: Ein installierter Google Tag Manager, ein funktionierendes Conversion Tracking und ein CMP. Dann geht es in fünf Schritten:
Schritt 1: CMP auswählen und Banner aufsetzen
Nutze ein CMP mit nativer Consent-Mode-v2-Unterstützung – idealerweise eines aus Googles CMP-Partnerprogramm. Verbreitete Optionen im DACH-Raum sind Cookiebot, Usercentrics und Borlabs. Wichtig bei der Banner-Konfiguration: Ablehnen muss genauso einfach sein wie Akzeptieren, und die Kategorien (Marketing, Statistik) müssen sauber den Consent-Signalen zugeordnet sein.
Schritt 2: Default-Zustand definieren
Bevor irgendein Tag feuert, müssen alle vier Signale für EWR-Besucher auf denied stehen. Bei den meisten CMPs erledigt das die Template-Integration automatisch. Manuell sieht der Default so aus:
gtag('consent', 'default', {
'ad_storage': 'denied',
'analytics_storage': 'denied',
'ad_user_data': 'denied',
'ad_personalization': 'denied',
'wait_for_update': 500
});
wait_for_update gibt dem CMP Zeit (hier 500 ms), eine bereits gespeicherte Einwilligung zu laden, bevor die Tags feuern – sonst zählen wiederkehrende Nutzer mit erteilter Einwilligung fälschlich als abgelehnt.
Schritt 3: CMP-Template auf „Consent-Initialisierung" legen
Im GTM gibt es einen eigenen Trigger-Typ Consent-Initialisierung – Alle Seiten. Er feuert garantiert vor allen anderen Triggern. Genau dort gehört das CMP-Template (oder dein Default-Snippet) hin – nicht auf den normalen Seitenaufruf-Trigger. Das ist der häufigste Verdrahtungsfehler.
Schritt 4: Consent-Übersicht aktivieren und Tags prüfen
Aktiviere in den GTM-Container-Einstellungen die Einwilligungsübersicht (Zahnrad → „Übersicht für Einwilligung aktivieren"). Damit siehst du pro Tag, welche Consent-Checks eingebaut sind. Google-Tags (Google Ads Conversion, GA4) bringen die Checks für ad_storage bzw. analytics_storage von Haus aus mit – du musst in der Regel keine zusätzlichen Einwilligungsanforderungen konfigurieren. Für Nicht-Google-Tags (Meta Pixel & Co.) definierst du zusätzliche Consent-Anforderungen manuell.
Schritt 5: Update-Verhalten verifizieren
Klickt der Nutzer im Banner auf Akzeptieren, muss das CMP ein Consent-Update senden:
gtag('consent', 'update', {
'ad_storage': 'granted',
'analytics_storage': 'granted',
'ad_user_data': 'granted',
'ad_personalization': 'granted'
});
Bei Template-Integrationen passiert das automatisch – verlassen solltest du dich darauf trotzdem nicht, sondern es testen (dazu gleich mehr).
Zusammenspiel mit Enhanced Conversions und Server-Side Tracking
Consent Mode v2 ist die Basis, auf der andere Tracking-Bausteine aufsetzen – die Reihenfolge ist nicht verhandelbar:
- Consent Mode v2 zuerst: Ohne saubere Consent-Signale fehlt allem anderen das Fundament.
- Dann Enhanced Conversions: Gehashte First-Party-Daten dürfen nur fließen, wenn
ad_user_dataaufgrantedsteht. Ein Enhanced-Conversions-Setup ohne Consent-Verdrahtung ist ein Datenschutzproblem, kein Feature. - Dann Server-Side: Beim Server-Side Tagging muss der Consent-Status vom Browser an deinen Server-Container weitergereicht werden. Server-Side ist ausdrücklich keine Consent-Umgehung – ohne Einwilligung serverseitig voll zu tracken ist ein Verstoß, egal wo die Daten verarbeitet werden. Wie das Gesamtbild aussieht, liest du im Server-Side Tracking Guide.
Wer diese Reihenfolge umdreht – erst Server-Side kaufen, dann irgendwann Consent nachrüsten – baut auf Sand. Das komplette technische Fundament inklusive GTM-Struktur behandelt unser Tracking-Setup-Guide.
Typische Fehler beim Consent Mode v2
Fehler 1: Default-Signale feuern nach den Tags
Der Klassiker. Das CMP lädt asynchron irgendwo im Seitenquelltext, während gtag oder GTM bereits gefeuert haben. Ergebnis: Die ersten Hits laufen ohne Consent-Status – Google behandelt sie im Zweifel als nicht eingewilligt. Lösung: Default-Snippet bzw. CMP-Template konsequent auf den Trigger Consent-Initialisierung legen.
Fehler 2: Banner ohne Verdrahtung
Der Banner wird angezeigt, Nutzer klicken fleißig – aber die Entscheidung erreicht Google nie, weil die Consent-Mode-Integration im CMP nie aktiviert wurde. Von außen sieht alles korrekt aus; im Tag Assistant fehlen Default und Update komplett. Aus meiner Praxis einer der häufigsten Befunde in Audits.
Fehler 3: Nur v1-Signale gesetzt
Ältere Setups übermitteln ad_storage und analytics_storage, aber nicht ad_user_data und ad_personalization. Folge: Remarketing für EWR-Nutzer fällt aus, obwohl „Consent Mode läuft". Prüfe explizit, ob alle vier Signale gesendet werden.
Fehler 4: Doppelte Consent-Logik
Ein hart codiertes Default-Snippet im Quellcode plus ein CMP-Template im GTM, die sich gegenseitig überschreiben. Je nach Ladereihenfolge gewinnt mal das eine, mal das andere – die Daten werden unvorhersehbar. Entscheide dich für genau einen Ort, an dem Consent gesetzt wird.
Fehler 5: Advanced Mode unbewusst aktiv
Manche CMPs aktivieren Advanced als Voreinstellung. Wenn deine Datenschutzerklärung und dein Verarbeitungsverzeichnis aber von Basic ausgehen, passt Dokumentation nicht zu Realität. Prüfe die Einstellung bewusst und dokumentiere die Entscheidung.
Fehler 6: Wiederkehrende Nutzer verlieren ihre Einwilligung
Fehlt wait_for_update oder ist der Wert zu knapp, feuern Tags bei wiederkehrenden Besuchern, bevor das CMP die gespeicherte Einwilligung geladen hat. Die Folge sind unnötig viele „denied"-Hits trotz erteilter Zustimmung.
Prüfen mit dem Tag Assistant
So verifizierst du das Setup in etwa zehn Minuten:
- tagassistant.google.com öffnen, deine Domain verbinden (Inkognito-Fenster, damit keine alte Einwilligung gespeichert ist)
- Nach dem Seitenaufruf links den Consent-Tab öffnen: Es muss ein Default-Eintrag existieren, bei dem alle vier Signale auf
deniedstehen – vor dem ersten Google-Tag in der Ereignisliste - Im Banner Akzeptieren klicken: Jetzt muss ein Update-Eintrag mit
grantederscheinen - Seite neu laden: Die gespeicherte Einwilligung muss beim nächsten Aufruf innerhalb des
wait_for_update-Fensters greifen - Gegenprobe mit Ablehnen (neues Inkognito-Fenster): Signale bleiben auf
denied, im Basic Mode dürfen keine Google-Tags feuern - Zusätzlich im GTM-Vorschaumodus pro Tag prüfen, welcher Consent-Status beim Feuern galt
Ergänzend lohnt der Blick in Google Ads unter Ziele → Conversions → Diagnose: Dort weist Google auf Probleme mit den Consent-Signalen hin.
Fazit: Erst die Consent-Basis, dann die Optimierung
Consent Mode v2 ist kein Nice-to-have, sondern seit März 2024 die Eintrittskarte für Remarketing und belastbare Conversion-Daten im EWR. Die Kernpunkte:
- Vier Signale, zwei neue:
ad_user_dataundad_personalizationmachen den Unterschied zwischen v1 und v2 - Basic vs. Advanced ist ein Trade-off: Datenschutz-Sicherheit gegen Datenqualität – bewusst entscheiden, nicht dem CMP-Default überlassen
- Die Reihenfolge entscheidet: Default-Signale vor allen Tags, Update nach der Banner-Entscheidung
- Testen statt hoffen: Zehn Minuten Tag Assistant decken die meisten Fehler auf
Wenn du das nicht selbst bauen willst oder unsicher bist, ob dein bestehendes Setup sauber verdrahtet ist: Im Rahmen unserer Consent Mode & Cookiebanner Implementation setzen wir das Ganze zum Festpreis auf – CMP-agnostisch, egal ob Cookiebot, Usercentrics, Borlabs oder ein anderes System.
FAQ zu Consent Mode v2
Ist Consent Mode v2 Pflicht?
Für Werbetreibende, die Nutzer im EWR mit Google Ads erreichen und Funktionen wie Remarketing, Zielgruppen oder personalisierte Werbung nutzen wollen: faktisch ja. Google verlangt seit März 2024 die Übermittlung der Consent-Signale ad_user_data und ad_personalization – ohne sie lassen sich EWR-Nutzer nicht mehr in Remarketing-Listen aufnehmen und die Conversion-Messung wird lückenhafter. Ein Gesetz namens Consent Mode gibt es allerdings nicht: Die Einwilligungspflicht selbst kommt aus DSGVO und TDDDG, Consent Mode v2 ist Googles technische Anforderung obendrauf.
Was ist der Unterschied zwischen Basic und Advanced Consent Mode?
Beim Basic Mode werden Google-Tags erst nach der Einwilligung geladen – lehnt ein Nutzer ab, erhält Google gar keine Daten, auch keine anonymen Pings. Beim Advanced Mode laden die Tags immer, senden ohne Einwilligung aber nur cookielose Pings, aus denen Google Conversions modellieren kann. Advanced liefert mehr Daten für die Modellierung, ist datenschutzrechtlich aber umstritten – diese Entscheidung solltest du gemeinsam mit deinem Datenschutzbeauftragten treffen.
Wie richte ich Consent Mode v2 mit dem Google Tag Manager ein?
Der übliche Weg: Ein CMP mit Consent-Mode-Unterstützung (z. B. Cookiebot, Usercentrics oder Borlabs) setzt die Default-Signale auf denied, bevor irgendein Tag feuert, und aktualisiert sie nach der Banner-Entscheidung per Consent Update. Im GTM aktivierst du die Consent-Übersicht, lässt das CMP-Template im Trigger Consent-Initialisierung feuern und prüfst für jeden Google-Tag die eingebauten Consent-Checks. Danach testest du das Ganze im Tag Assistant.
Was passiert, wenn ich Consent Mode v2 nicht einsetze?
Ohne die v2-Signale ad_user_data und ad_personalization kannst du EWR-Nutzer nicht mehr in Remarketing-Listen aufnehmen oder mit personalisierter Werbung ansprechen – deine Zielgruppen laufen mit der Zeit leer. Zusätzlich verzichtest du auf die Conversion-Modellierung: Conversions von Nutzern, die ablehnen, fehlen dann komplett in Google Ads, und Smart Bidding optimiert auf einer kleineren Datenbasis.
Wie prüfe ich, ob Consent Mode v2 korrekt funktioniert?
Öffne tagassistant.google.com, verbinde deine Website und schau in den Consent-Tab: Beim Seitenaufruf müssen alle vier Signale als Default auf denied stehen – und zwar bevor ein Google-Tag feuert. Nach einem Klick auf Akzeptieren muss ein Consent-Update auf granted folgen. Die Reihenfolge ist der kritische Punkt: Erscheint das Default-Signal erst nach den Tags, ist das Setup fehlerhaft. Ergänzend zeigt dir der GTM-Vorschaumodus pro Tag, welcher Consent-Status beim Feuern galt.

Mijo Jurisic
Google Ads Consultant & Gründer von MJ Marketing. Über fünf Jahre Praxis — vom autodidaktischen Start bis zum Google Premier Partner Programm mit 500+ direkten Google-Ads-Kunden und €20+ Mio. verantwortetem Mediabudget.
Share this article:
