GA4 Consent Mode v2: DSGVO-konform tracken

~70 % Datenverlust ohne Consent Mode, rechtliche Grauzone bei Advanced Mode, 700-Klick-Schwelle für Modellierung. Alles, was du über Consent Mode v2 wissen musst – technisch, rechtlich und praktisch.

Seit dem 6. März 2024 verlangt Google Consent Mode v2 für jede Property, die Daten in den Europäischen Wirtschaftsraum sendet. Wer die neuen Parameter nicht setzt, verliert Remarketing-Listen, Conversion-Daten und perspektivisch den Zugang zu Google Signals. Das betrifft jede Website mit GA4 und Google Ads im DACH-Raum. In diesem Artikel bekommst du die technischen Details, die rechtliche Einordnung und eine klare Implementierungsanleitung.

Wenn du GA4 bisher ohne sauberes Consent-Setup betreibst, lohnt sich vorher ein Blick auf die 7 häufigsten Tracking-Fehler bei KMU – Consent Mode ist dort Fehler Nummer eins.

Was Consent Mode v2 ist und warum Google es erzwingt

Consent Mode ist eine API-Schicht zwischen deinem Consent-Banner und den Google-Tags. Statt Tags komplett zu blockieren oder komplett zu feuern, teilt Consent Mode jedem Tag mit, welche Kategorien der Nutzer erlaubt hat. Google passt das Verhalten seiner Tags dann dynamisch an.

Version 1 kannte zwei Parameter: analytics_storage und ad_storage. Version 2 fügt zwei weitere hinzu: ad_user_data und ad_personalization. Beide kontrollieren, ob nutzerbezogene Daten an Google-Werbedienste fließen dürfen. Google hat sie eingeführt, um die Anforderungen des Digital Markets Act (DMA) der EU zu erfüllen.

Die vier Parameter im Überblick:

Parameter	Steuert	Seit
analytics_storage	GA4-Cookies (z. B. _ga)	v1
ad_storage	Werbe-Cookies (z. B. _gcl_*)	v1
ad_user_data	Übermittlung nutzerbezogener Daten an Google Ads	v2 (03/2024)
ad_personalization	Personalisierte Werbung und Remarketing	v2 (03/2024)

Alle vier müssen per Default auf denied stehen, bevor irgendein Tag feuert. Das ergibt sich aus DSGVO Art. 25 (Privacy by Default) und TTDSG §25 (Einwilligung für Zugriff auf Endeinrichtungen). Erst nach aktivem Opt-in darf der Status auf granted wechseln.

Update Juni 2026: Google hat angekündigt, dass ad_storage ab dem 15. Juni 2026 zum alleinigen Parameter für den gesamten Werbe-Datenfluss wird. ad_user_data und ad_personalization bleiben bestehen, aber ad_storage wird zum Gate-Keeper. Gleichzeitig wird der Zugang zu Google Signals weiter eingeschränkt. Für die Praxis bedeutet das: Wenn ad_storage auf denied steht, fließen gar keine Werbedaten mehr – unabhängig davon, was die anderen Parameter sagen.

Basic Mode vs. Advanced Mode: Der Unterschied, der zählt

Google bietet zwei Implementierungsvarianten. Der Unterschied ist groß, wird aber oft übersehen.

Basic Mode: Tags werden komplett blockiert, bis der Nutzer zustimmt. Kein Consent = kein Tag = keine Daten. Bei einer typischen DACH-Consent-Rate von rund 30 % trackst du nur knapp ein Drittel deines Traffics. Der Rest ist unsichtbar.

Advanced Mode: Tags feuern immer – aber ohne Cookies. Bei denied-Status senden sie sogenannte Cookieless Pings an Google. Diese Pings enthalten keine Nutzer-Identifikatoren, aber aggregierte Signale wie Zeitstempel, User Agent und Seitenreferrer. Google nutzt diese Pings, um die Lücke zwischen den 30 % Consenter:innen und dem gesamten Traffic statistisch zu modellieren.

Advanced Mode kann laut Google 30–50 % der verlorenen Conversions durch Modellierung zurückholen, in manchen Fällen bis zu 70 %. Aber: Es gibt eine Schwelle. Google modelliert nur, wenn mindestens 700 Klicks auf Anzeigen innerhalb von 7 Tagen pro Land und Domain vorliegen. Die meisten KMU im DACH-Raum erreichen diesen Schwellenwert nicht. Das heißt: Auch im Advanced Mode bekommst du unter Umständen keine modellierten Conversions.

Kriterium	Basic Mode	Advanced Mode
Tags bei fehlendem Consent	Blockiert	Feuern cookieless Pings
Conversion-Modellierung	Keine	Ja, ab 700 Klicks/7 Tage
Datenabdeckung (DACH)	~31 %	50–70 % (modelliert)
Remarketing-Listen	Nur Consenter	Modellierte Erweiterung
Technische Komplexität	Niedrig	Mittel
Rechtliche Bewertung	Unkritisch	Umstritten (s. unten)

Die rechtliche Grauzone: Advanced Mode und deutsches Datenschutzrecht

Advanced Mode ist technisch die bessere Lösung. Rechtlich ist die Lage weniger klar.

Das Problem: Bei denied-Status sendet Advanced Mode trotzdem Daten an Google-Server – die Cookieless Pings. Zwar enthalten diese keine Cookies und keine direkten Nutzer-IDs. Aber sie übermitteln IP-Adressen (gekürzt), User-Agent-Strings, Zeitstempel und Referrer-Daten. Ob diese Kombination als personenbezogene Daten nach Art. 4 DSGVO gilt, wird in der deutschen Datenschutz-Community kontrovers diskutiert.

Portale wie der Datenschutz-Generator und eRecht24 weisen darauf hin, dass jede Datenübermittlung an Google-Server vor dem Consent ein Risiko darstellt – unabhängig davon, ob Cookies gesetzt werden. Die Gegenposition: Google verarbeitet diese Pings serverseitig und aggregiert, ohne individuelles Tracking. Eine höchstrichterliche Klärung steht aus.

Die pragmatische Einordnung für KMU: Advanced Mode ist weit verbreitet, Google empfiehlt ihn offiziell, und bisher gibt es keine Bußgeldbescheide gegen Websites, die ihn korrekt implementiert haben. Das Risiko ist vorhanden, aber überschaubar. Wer auf Nummer sicher gehen will, bleibt bei Basic Mode und akzeptiert den Datenverlust. Wer die modellierten Daten braucht, implementiert Advanced Mode mit sauberer Dokumentation in der Datenschutzerklärung und hält die Entwicklung im Blick.

Implementierung: Schritt für Schritt

Die technische Umsetzung ist nicht kompliziert, aber fehleranfällig. Hier ist der Ablauf für ein GTM-Setup mit einer gängigen Consent Management Platform (CMP) wie Cookiebot, Usercentrics oder Borlabs Cookie.

Schritt 1 – Default-Status setzen. Im <head> deiner Seite, vor dem GTM-Container, setzt du den Consent Mode Default. Das muss der allererste JavaScript-Aufruf sein:

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

Der wait_for_update-Parameter gibt der CMP 500 ms Zeit, um den tatsächlichen Consent-Status zu übermitteln, bevor Tags feuern. Ohne diesen Parameter kann es passieren, dass Tags mit dem Default-Status denied feuern, obwohl der Nutzer bereits zugestimmt hat.

Schritt 2 – CMP-Integration. Deine CMP muss den gtag('consent', 'update', {...})-Aufruf senden, sobald der Nutzer seine Wahl trifft. Die meisten großen CMPs (Cookiebot, Usercentrics, OneTrust) haben dafür vorgefertigte Templates oder GTM-Integrationen. Prüfe, ob alle vier v2-Parameter korrekt gemappt sind – viele ältere Templates kennen nur die v1-Parameter.

Schritt 3 – GTM konfigurieren. Im Google Tag Manager stellst du unter Admin > Container Settings sicher, dass "Enable consent overview" aktiviert ist. Jeder Tag braucht die korrekte Consent-Konfiguration: GA4-Tags benötigen analytics_storage, Google Ads Tags benötigen ad_storage, ad_user_data und ad_personalization.

Schritt 4 – Testen. Öffne den GTM-Vorschaumodus und simuliere beide Szenarien: Consent erteilt und Consent verweigert. Prüfe im Tag Assistant, ob die Consent-Status korrekt übermittelt werden. Im GA4-DebugView sollte bei verweigerten Cookies kein _ga-Cookie gesetzt werden. Mehr zum Thema Testing findest du in unserem Tracking & Analytics Überblick.

Die 6 häufigsten Fehler bei der Consent-Mode-Implementierung

Wir sehen diese Fehler regelmäßig bei Audits. Jeder einzelne kann dazu führen, dass dein Tracking entweder DSGVO-widrig läuft oder deutlich weniger Daten liefert als nötig.

1. Default feuert zu spät. Der gtag('consent', 'default', ...)-Aufruf steht nach dem GTM-Container oder wird asynchron geladen. Tags feuern kurz mit granted-Status, bevor der Default greift. Lösung: Consent Default vor dem GTM-Snippet im <head> platzieren.
2. v2-Parameter fehlen. Ältere Setups haben nur analytics_storage und ad_storage. Die zwei neuen Parameter ad_user_data und ad_personalization werden nicht gesetzt. Google behandelt fehlende Parameter je nach Kontext unterschiedlich – im schlimmsten Fall als granted.
3. Default steht auf granted. Manche CMPs oder schlecht konfigurierte Templates setzen den Default auf granted und warten dann auf ein denied-Signal. Das ist DSGVO-widrig. Der Default muss immer denied sein.
4. Doppelte Implementierung. Die CMP setzt ihren eigenen Consent Mode Default, und zusätzlich liegt ein manueller Default im <head>. Die beiden überschreiben sich gegenseitig, oft mit unvorhersehbarem Timing.
5. Basic statt Advanced – ohne es zu wissen. Viele denken, sie hätten Advanced Mode aktiv, weil sie Consent Mode v2 implementiert haben. Aber wenn die CMP Tags bei denied komplett blockiert (statt cookieless Pings zu erlauben), bist du im Basic Mode. Das lässt sich nur über den Network Tab im Browser prüfen.
6. Kein Testing nach dem Deploy. Consent Mode wird einmal eingerichtet und nie wieder geprüft. CMP-Updates, GTM-Container-Änderungen oder neue Tags können das Setup jederzeit brechen. Ein monatlicher Check im Tag Assistant sollte Standard sein.

Diese Fehler überschneiden sich stark mit den typischen Tracking-Fehlern bei KMU. Ein sauberes Consent-Setup ist die Basis für alles Weitere.

Modellierung: Was du erwarten kannst und was nicht

Googles Conversion-Modellierung im Advanced Mode füllt die Lücke zwischen den tatsächlich getrackten Conversions (nur Consenter) und dem geschätzten Gesamtbild. Das klingt gut – aber die Erwartungen sollten realistisch sein.

Die Modellierung basiert auf Machine-Learning-Modellen, die das Verhalten der Consenter auf die Nicht-Consenter hochrechnen. Google hat dafür den Schwellenwert von 700 Anzeigenklicks innerhalb von 7 Tagen pro Land und Domain gesetzt. Unterhalb dieser Schwelle gibt es keine Modellierung – die Datenbasis reicht nicht.

Für ein durchschnittliches KMU mit 200–500 Klicks pro Woche in Deutschland bedeutet das: keine modellierten Conversions in Google Ads. Du siehst nur die direkt getrackten Werte. In GA4 greift die Modellierung teilweise auch bei weniger Traffic, aber die Genauigkeit sinkt mit dem Datenvolumen.

Größere Accounts mit ausreichend Klickvolumen berichten von 30–50 % Recovery Rate bei verlorenen Conversions. Google selbst spricht von bis zu 70 % unter idealen Bedingungen. In der Praxis sehen wir Werte zwischen 25 % und 45 % – abhängig von Branche, Traffic-Volumen und Conversion-Typ.

Was das für dich heißt: Consent Mode Advanced ist kein Allheilmittel. Es ist besser als Basic Mode, aber kein Ersatz für eine hohe Consent-Rate. Arbeite parallel daran, deine Consent-Rate zu verbessern – durch besseres Banner-Design, klarere Formulierungen und schnellere Ladezeiten des Banners.

Der Blick nach vorn: Was sich 2026 und 2027 ändert

Das Consent-Mode-Ökosystem entwickelt sich weiter. Drei Entwicklungen, die du im Blick behalten solltest:

1. Ad Storage als zentraler Gate-Keeper (Juni 2026). Ab dem 15. Juni 2026 wird ad_storage der alleinige Parameter für den gesamten Werbe-Datenfluss. Das vereinfacht die Logik, verschärft aber die Konsequenz: Ein denied bei ad_storage schneidet alle Werbedaten ab.

2. Google Signals wird eingeschränkt. Google Signals – die geräteübergreifende Tracking-Funktion auf Basis von Google-Konten – wird in GA4 weiter zurückgebaut. Für DACH-Websites bedeutet das: weniger Cross-Device-Daten, selbst wenn Consent erteilt wurde. Die Abhängigkeit von First-Party-Daten steigt.

3. Server-Side Tagging als Ergänzung. Immer mehr Unternehmen kombinieren Consent Mode mit Server-Side Tagging über einen eigenen GTM-Server-Container. Das ermöglicht bessere Kontrolle über Datenflüsse, kann die Consent-Rate durch schnellere Banner-Ladezeiten verbessern und erlaubt First-Party-Cookie-Setzung mit längerer Laufzeit. Server-Side Tagging ersetzt Consent Mode nicht, ergänzt ihn aber sinnvoll.

Die strategische Frage ist: Wie baust du ein Tracking-Setup, das bei 30 % Consent-Rate tragfähige Entscheidungen ermöglicht? Consent Mode ist ein Teil der Antwort. First-Party-Daten, saubere CRM-Integration und – perspektivisch – KI-gestützte Analysen sind die anderen.