Consent Mode v2 implementieren: Schritt-für-Schritt

Worum es geht

Consent Mode v2 ist Googles Antwort auf den Digital Markets Act und die DSGVO. Seit März 2024 ist die Implementierung verpflichtend für Werbetreibende mit EU-Traffic, die Daten an Google Ads, Google Analytics oder andere Google-Werbe-Plattformen senden. Ohne korrekt eingebundenen Consent Mode v2 verlieren Google-Ads-Konten Targeting-Daten, Remarketing-Audiences schrumpfen und Smart Bidding wird ungenauer.

Technisch ist Consent Mode v2 ein Signal-Layer: Bei jedem Tracking-Request übermittelt der Browser nicht nur die eigentliche Conversion-Information, sondern auch den Consent-Status. Das heißt, Google weiß bei jedem eingehenden Event, ob der Nutzer Cookies und personenbezogenes Tracking erlaubt hat oder nicht. Ist die Antwort „nein", werden trotzdem anonymisierte Pings gesendet, die das Conversion-Modeling füttern. Damit lassen sich auch ohne Einwilligung statistisch hochgerechnete Conversion-Werte in Google Ads ausweisen.

Der Unterschied zu Consent Mode v1 ist substantiell: Es gibt jetzt vier Consent-Stufen statt zwei, und die Signale werden nicht nur in Google Ads ausgewertet, sondern explizit auch in der Audience-Bildung und im Server-Side-Tracking. Vor allem die Trennung zwischen ad_storage und ad_user_data hat juristische Implikationen, die für DACH-Werbetreibende relevant sind.

Zurück zum Überblick: DSGVO-konformes Tracking, der vollständige Leitfaden.

Die vier Consent-Stufen

Consent Mode v2 unterscheidet vier separate Consent-Werte, die jeweils auf „granted" oder „denied" gesetzt werden können. Die Granularität ist eine direkte Folge des Digital Markets Act, der Nutzer-Wahlfreiheit fordert.

ad_storage

Erlaubt das Setzen von Cookies und Identifiern für Werbe-Zwecke. Steht der Wert auf „denied", werden keine Conversion-Cookies gesetzt, aber anonyme Pings gehen weiter an Google. Diese Pings füttern das Modeling.

analytics_storage

Erlaubt das Setzen von Cookies für Analytics-Zwecke, etwa GA4 Client-ID. Steuert getrennt von ad_storage, weil Analytics in vielen Setups auf anderer Rechtsgrundlage läuft als Werbung.

ad_user_data

Neu in v2. Erlaubt die Übermittlung personenbezogener Daten wie gehashte Email-Adresse über Enhanced Conversions an Google. Auch wenn ad_storage „granted" ist, muss ad_user_data separat eingeholt werden. Wer Enhanced Conversions ausspielen will, ohne ad_user_data zu haben, verstößt gegen die DSGVO.

ad_personalization

Auch neu in v2. Erlaubt die Verwendung der gesendeten Daten zur Personalisierung von Werbung, also Remarketing und Audience-Lookalikes. Trennt die Datenübermittlung von der personalisierten Verwendung der Daten.

Setup-Voraussetzungen

Für eine korrekte Implementation braucht es drei Komponenten.

Ein konformes Consent-Management-System

Das CMP muss die vier Consent-Stufen separat auslesen und an Google weiterleiten können. Im DACH-Markt sind Usercentrics, Cookiebot, Consentmanager.net und Borlabs Cookie etabliert. Alle vier unterstützen Consent Mode v2 nativ, einige davon (Usercentrics, Cookiebot) haben Google-zertifizierte Integrationen, die den Setup-Aufwand deutlich reduzieren.

Google Tag Manager

Der Consent-Status wird zentral im GTM verwaltet und an alle Tags weitergegeben. Wer ohne GTM arbeitet, muss die Consent-Logik manuell in jedem Tag implementieren, was fehleranfällig ist und Updates erschwert. In der Praxis lohnt sich der Umstieg auf GTM fast immer.

Aktive Google-Ads- oder GA4-Verknüpfung

Consent Mode v2 ist nur sinnvoll, wenn Daten an Google-Plattformen gesendet werden. Bei reinen Affiliate-Setups ohne Google-Ads-Anbindung ist v2 nicht zwingend, aber empfohlen, weil GA4 in den meisten DACH-Setups parallel läuft und die Modeling-Vorteile sich auch dort entfalten.

Implementation in fünf Schritten

Die folgende Anleitung geht von der häufigsten Konstellation aus: GTM in der Web-Property, ein zertifiziertes CMP und Google-Ads-Verknüpfung.

Schritt 1: Default-Consent in GTM setzen

Im GTM einen neuen Tag vom Typ „Consent Initialization" anlegen. Dieser läuft als allererster Tag bei jedem Pageview, noch vor allen anderen Tags, und setzt die Default-Werte. Für DACH-Setups ist die DSGVO-konforme Default-Stellung: alle vier Werte auf „denied".

Konkret im Tag wird folgender Code hinterlegt:

gtag('consent', 'default', {
  'ad_storage': 'denied',
  'analytics_storage': 'denied',
  'ad_user_data': 'denied',
  'ad_personalization': 'denied',
  'wait_for_update': 500
});

Der wait_for_update-Parameter gibt Google 500 Millisekunden Zeit, bis die finale Consent-Entscheidung des Nutzers ankommt. In dieser Zeit werden Tracking-Pings zurückgehalten und erst nach Eingang der Nutzer-Entscheidung gesendet.

Schritt 2: CMP-Integration aktivieren

Im CMP-Dashboard die Google-Consent-Mode-v2-Integration einschalten. Bei Usercentrics, Cookiebot und Consentmanager.net ist das ein Klick im Setup-Wizard. Das CMP übernimmt dann die Übersetzung der Nutzer-Entscheidung in ein passendes gtag-consent-update-Signal und feuert das automatisch in den dataLayer.

Schritt 3: Google-Tags entsprechend konfigurieren

In allen Google-Tags (Google Ads Conversion Tracking, GA4 Configuration, Floodlight) den Reiter „Advanced Settings" öffnen und „Consent Required" auf die passende Stufe setzen, typischerweise ad_storage. Damit weiß GTM, welche Consent-Stufe dieser Tag braucht und feuert ihn nur, wenn die Stufe „granted" ist.

Schritt 4: URL-Passthrough aktivieren

Im Consent-Initialization-Tag zusätzlich url_passthrough auf true setzen. Damit hängt Google bei abgelehntem Consent eine Click-ID an die Conversion-URL, sodass nachgelagert eine Zuordnung trotzdem möglich ist. Dieser Mechanismus heißt Conversion Linker und ist Voraussetzung für die Modeling-Recovery in den meisten Branchen.

Schritt 5: Container preview-en und live testen

Container im GTM-Preview-Mode starten, mit aktivem Tag Assistant durchklicken. Nach jedem Klick die Consent-Status-Variablen prüfen. Wenn alle vier Werte korrekt umschalten (denied vor Banner-Klick, granted nach Annahme), im Live-Container publizieren. Erst dann ist Consent Mode v2 produktiv aktiv.

Testen und Validieren

Die korrekte Implementation lässt sich auf mehreren Wegen prüfen. Empfehlung: alle drei Wege durchlaufen, weil jeder andere Fehlerklassen sichtbar macht.

Browser-DevTools mit Tag Assistant

Auf der Live-Site Tag Assistant oder die GTM-Debug-Konsole öffnen, eine Pageview triggern und die dataLayer-Events durchsehen. Jedes Consent-Update sollte als eigenes Event erscheinen, mit allen vier Stufen sichtbar.

Google Ads Diagnostics

Im Google-Ads-Konto unter Tools, Conversion-Tracking, Diagnostics prüfen, ob Consent-Signale korrekt ankommen. Bei Fehlern zeigt Google konkret an, welche Stufe nicht durchkommt und woran es liegt.

Server-Logs prüfen

Bei korrekt eingebundenem Server-Side-Tracking erscheinen die Consent-Werte als HTTP-Headers in jedem Request. Wer Server-Side-GTM betreibt, kann die Werte direkt im Container loggen und sie über die Logging-Pipeline auswerten.

Was das Modeling daraus macht

Wenn ad_storage auf „denied" steht, sendet Consent Mode v2 trotzdem einen anonymen Ping mit Conversion-Information an Google, aber ohne Nutzer-Identifier. Google nutzt diese Pings für das sogenannte Conversion Modeling: Auf Basis der bekannten Conversions (mit Consent) wird der Anteil der nicht-zuordbaren Conversions (ohne Consent) statistisch hochgerechnet.

In Branchen mit hoher Datendichte (große E-Commerce-Setups, B2C mit hohem Conversion-Volumen) liegt die Recovery-Rate bei 60 bis 80 Prozent der ohne Einwilligung verlorenen Conversions. Bei niedrigem Conversion-Volumen funktioniert das Modeling schlechter, weil die statistische Basis fehlt. Konkret braucht Google etwa 1.000 Conversions pro Monat in einem Konto, damit das Modeling stabile Werte liefert.

Die modellierten Conversions erscheinen in Google Ads als „modeled" gekennzeichnet und fließen in Smart-Bidding-Strategien ein. Damit lässt sich Performance bei niedrigen Consent-Raten deutlich begrenzen, wenn auch nicht vollständig retten.

Typische Fehler

In der Praxis sehen wir bei DSGVO-Audits dieselben drei Fehler immer wieder.

Default-Consent steht versehentlich auf „granted"

Wer die Default-Werte nicht explizit auf „denied" setzt, verstößt gegen die DSGVO, weil Tracking ohne Einwilligung läuft. Die DSK-Aufsichtsbehörden prüfen das in Audits konkret, weil es technisch leicht überprüfbar ist. Häufige Ursache: Der Consent-Initialization-Tag wurde vergessen oder feuert zu spät.

Consent-Update wird vor dem CMP-Banner ausgelöst

Wenn ein anderes Skript versehentlich ein gtag-consent-update ruft, bevor der Nutzer im Banner entschieden hat, überschreibt es die Default-Stellung. Die Konsequenz: Tracking läuft mit „granted", ohne dass der Nutzer zugestimmt hat. Häufige Ursache: Custom-HTML-Tags, die unkontrolliert in den dataLayer schreiben.

Nur ad_storage und analytics_storage gesetzt, neue Stufen fehlen

Viele CMP-Setups haben den v2-Upgrade noch nicht vollzogen und mappen nur die zwei alten Stufen aus v1. Ohne ad_user_data und ad_personalization dürfen Enhanced Conversions nicht ausgespielt werden, was Smart Bidding bei niedrigem Consent erheblich beschränkt. Häufige Ursache: ein nicht aktualisiertes CMP oder eine veraltete CMP-Konfiguration.

Mehr zur Audit-Praxis: DSGVO-konformes Tracking, der vollständige Leitfaden.