Google Consent Mode v2

Seit dem 6. März 2024 ist die Version 2 faktisch Voraussetzung dafür, Google Ads und Google Analytics im Europäischen Wirtschaftsraum mit vollem Funktionsumfang zu nutzen.

Der wichtigste Satz vorweg, weil er in der Praxis am häufigsten falsch verstanden wird: Der Consent Mode macht kein Tracking rechtmäßig. Er sorgt dafür, dass eine bereits getroffene Entscheidung technisch durchgereicht wird. Wer kein wirksames Banner hat, hat auch mit perfekt konfiguriertem Consent Mode ein Rechtsproblem.

Warum es den Consent Mode v2 gibt: der DMA, nicht das TDDDG

Der Auslöser für Version 2 war nicht das deutsche Telekommunikation-Digitale-Dienste-Datenschutz-Gesetz und auch nicht unmittelbar die DSGVO, sondern der Digital Markets Act. Der DMA verpflichtet benannte Gatekeeper, für die Verknüpfung und Weiterverwendung personenbezogener Daten über Dienste hinweg eine eigene Einwilligung nachweisen zu können. Google hat diese Anforderung an die eigenen Werbeprodukte weitergereicht: Wer im EWR Google Ads mit Personalisierung, Remarketing-Zielgruppen oder Conversion-Messung nutzen will, muss die entsprechenden Einwilligungssignale liefern.

Diese Herkunft erklärt die beiden Parameter, die Version 2 von Version 1 unterscheidet. Es ging nicht um Cookies im engeren Sinne, sondern um die Frage, ob Nutzerdaten an Google übermittelt und für Personalisierung verwendet werden dürfen.

Die Parameter im Überblick

Für die Zusammenarbeit mit Google Ads und Analytics sind die ersten vier relevant. Die übrigen drei existieren seit Version 1 und werden in der Praxis selten differenziert gesetzt.

Default und Update: die Reihenfolge entscheidet

Technisch besteht der Consent Mode aus zwei Befehlen. Der default-Befehl legt den Zustand fest, bevor der Nutzer irgendetwas angeklickt hat — im EWR also typischerweise alle relevanten Parameter auf denied. Der update-Befehl überschreibt diesen Zustand, sobald eine Entscheidung vorliegt.

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

// nach der Entscheidung im Banner:
gtag('consent', 'update', {
  'ad_storage': 'granted',
  'ad_user_data': 'granted',
  'ad_personalization': 'granted',
  'analytics_storage': 'granted'
});

Der häufigste Implementierungsfehler liegt genau hier: Der default-Befehl muss laufen, bevor irgendein Google-Tag feuert. Wird er zu spät gesetzt oder ganz vergessen, gehen Tags von einem Standardzustand aus, der im EWR nicht zulässig ist. Der update-Befehl wiederum sollte unmittelbar nach der Nutzerentscheidung folgen — lädt die Seite erst mit verweigerter Einwilligung und danach neu mit erteilter, verliert Google nach eigener Dokumentation entscheidende Datenpunkte.

Basic Mode und Advanced Mode

Beide Varianten erfüllen die formale Anforderung. Sie unterscheiden sich darin, was passiert, bevor eine Einwilligung vorliegt.

• Basic Mode: Die Google-Tags werden erst geladen, wenn der Nutzer zugestimmt hat. Lehnt er ab, passiert nichts — es wird kein Request an Google gesendet. Das ist datenschutzrechtlich die konservative Variante und die, die sich am einfachsten gegenüber einer Aufsichtsbehörde erklären lässt.
• Advanced Mode: Die Tags laden sofort und senden auch bei Ablehnung sogenannte cookielose Pings, die den Einwilligungsstatus enthalten. Diese Pings sind die Datengrundlage für Googles Conversion-Modellierung, die fehlende Conversions statistisch schätzt.

Die Entscheidung zwischen beiden ist keine technische Detailfrage, sondern eine Abwägung. Der Advanced Mode liefert vollständigere Berichte, überträgt aber auch bei Ablehnung Daten an Google — und die Frage, ob dieser Ping ohne Einwilligung zulässig ist, wird unter Datenschützern unterschiedlich beantwortet. Wer im Zweifel ist, fährt mit dem Basic Mode sicherer und akzeptiert dafür Lücken in der Messung.

Zur Modellierung noch ein nüchterner Hinweis: Sie greift erst ab bestimmten Datenmengen. Kleinere Shops sehen oft überhaupt keine modellierten Conversions und haben damit vom Advanced Mode wenig, während sie sein rechtliches Risiko voll tragen.

Realbeispiel: die Konsolidierung bei Google Analytics 4

Google baut die Steuerung schrittweise so um, dass allein die Consent-Mode-Signale zählen. Zum 15. Juni 2026 ist Google Signals umgestellt worden: Statt einer doppelten Kontrolle über die Google-Signals-Einstellung in Analytics und den Consent Mode entscheidet nun ausschließlich der Consent Mode innerhalb von Google Ads darüber, ob Google-Ads-Cookies und -IDs erfasst werden. Für die Ads-Personalisierung ist im weiteren Jahresverlauf 2026 derselbe Schritt angekündigt — dann steuert allein ad_personalization, ob Daten für personalisierte Werbung genutzt werden. Die Details dazu dokumentiert Google in der Entwicklerdokumentation zum Consent Mode.

Praktische Konsequenz: Property-Einstellungen in Analytics, die man vor Jahren gesetzt und seither nicht angefasst hat, verlieren ihre Wirkung. Wer Zielgruppen oder Conversion-Importe in Ads nutzt und sich auf diese alten Schalter verlassen hat, sollte die Consent-Signale prüfen, die seine CMP tatsächlich sendet — nicht die, die im Admin-Bereich der CMP konfiguriert sind.

Consent Mode, CMP und Banner: wer macht was

Die Arbeitsteilung ist einfach, wird aber regelmäßig vermischt:

1. Das Banner stellt die Frage und muss dabei den rechtlichen Anforderungen genügen — informiert, freiwillig, granular, und mit einer Ablehnen-Option, die genauso leicht erreichbar ist wie die Zustimmung.
2. Die Consent Management Platform dokumentiert die Entscheidung, verwaltet den Widerruf und stellt sie technisch bereit.
3. Der Consent Mode übersetzt sie in die vier Parameter und reicht sie an die Google-Tags weiter.

Fehler auf Ebene eins lassen sich auf Ebene drei nicht reparieren. Ein Banner ohne gleichwertigen Ablehnen-Button bleibt angreifbar, auch wenn die Signale technisch sauber gesetzt sind. Umgekehrt nützt ein vorbildliches Banner wenig, wenn die Signale nie bei Google ankommen — dann fehlen Zielgruppen und Conversions, ohne dass jemand merkt, woran es liegt.

Typische Fehler bei der Umsetzung

• Der Advanced Mode als Ausrede. „Wir tracken trotzdem" ist keine zulässige Auslegung. Der cookielose Ping ersetzt keine Einwilligung.
• Nur v1-Parameter gesetzt. Wer ad_user_data und ad_personalization nicht überträgt, verliert im EWR Remarketing-Zielgruppen und Personalisierung — meist unbemerkt, bis eine Kampagne nicht ausliefert.
• Der Tag-Manager lädt vor dem Default. Reihenfolge prüfen, nicht annehmen.
• Widerruf ohne Wirkung. Wenn der Nutzer seine Einwilligung zurückzieht, muss ein update mit denied folgen. Ein Häkchen, das nur in der CMP-Oberfläche umspringt, genügt nicht.
• Kein Nachweis. Die Rechenschaftspflicht verlangt, den Zustand des Banners und die Einwilligungen dokumentieren zu können. Screenshots der Konfiguration mit Datum sind das Minimum.

Server-Side Tagging ändert nichts an der Einwilligung

Eine Variante, die regelmäßig als Umgehung verkauft wird: Man verlagert die Tag-Verarbeitung auf einen eigenen Server, und damit sei die Einwilligungsfrage erledigt. Das ist falsch. § 25 TDDDG knüpft an den Zugriff auf Informationen im Endgerät an, nicht daran, welcher Server die Daten anschließend entgegennimmt. Wird im Browser eine ID gesetzt oder ausgelesen, bleibt die Einwilligung erforderlich — unabhängig davon, ob der Request an Google oder an eine eigene Subdomain geht.

Sinnvoll ist Server-Side Tagging aus anderen Gründen: bessere Kontrolle darüber, welche Felder überhaupt an Dritte gehen, geringere Ladelast im Browser und robustere Messung. Der Consent Mode läuft dabei weiter, nur werden die Signale an den Server-Container übergeben. Wer die Einwilligung bei dieser Architektur nicht sauber durchreicht, hat den Aufwand investiert und trotzdem eine Lücke.

Wie du die Implementierung überprüfst

Eine Consent-Mode-Konfiguration lässt sich nicht am Screenshot der CMP-Oberfläche beurteilen, sondern nur an dem, was der Browser tatsächlich sendet. Drei Prüfungen reichen für eine belastbare Aussage:

1. Der Zustand vor der Entscheidung. Seite in einem frischen Profil öffnen, ohne das Banner anzufassen. In den Entwicklerwerkzeugen prüfen, ob überhaupt Requests an Google-Domains hinausgehen und welchen Einwilligungsstatus sie tragen. Im Basic Mode sollte hier nichts an Google laufen.
2. Der Übergang. Ablehnen, dann in einem zweiten Durchlauf zustimmen. In beiden Fällen sollte ein update-Aufruf erfolgen — auch bei der Ablehnung. Fehlt er dort, ist die Ablehnung für Google unsichtbar.
3. Der Widerruf. Einwilligung erteilen, Seite nutzen, dann über den Widerruf-Link zurückziehen. Danach müssen die Parameter wieder auf denied stehen und die entsprechenden Cookies gelöscht sein. Dieser Schritt wird in der Praxis am häufigsten übersprungen und fällt bei einer Prüfung zuerst auf.

Der Google Tag Assistant zeigt den Einwilligungsstatus je Tag an und macht sichtbar, ob ein Tag mit granted oder denied ausgelöst hat. Für die laufende Kontrolle lohnt es sich, diese drei Durchläufe nach jedem größeren Release zu wiederholen — ein Deployment, das die Ladereihenfolge im Tag-Manager verschiebt, kippt den Default-Befehl lautlos nach hinten, und niemand bekommt davon eine Fehlermeldung.

Wer dokumentieren will, hält Datum, geprüfte URL, Browser und Ergebnis der drei Durchläufe fest. Das ist kein Bürokratie-Selbstzweck: Die Rechenschaftspflicht nach Artikel 5 Absatz 2 DSGVO verlangt, die Einhaltung nachweisen zu können, und ein Protokoll dieser Prüfungen ist der einfachste Nachweis, den ein Marketing-Team ohne juristische Unterstützung führen kann.

Häufige Fragen zum Google Consent Mode v2

Ist der Consent Mode v2 Pflicht?

Er ist keine gesetzliche Pflicht, sondern eine Anforderung von Google. Ohne die Signale stehen im EWR zentrale Funktionen von Google Ads und Google Analytics nicht oder nur eingeschränkt zur Verfügung. Die gesetzliche Pflicht zur Einwilligung ergibt sich unabhängig davon aus § 25 TDDDG und der DSGVO.

Was ist der Unterschied zwischen v1 und v2?

Version 2 ergänzt die beiden Parameter ad_user_data und ad_personalization. Sie trennen die Übermittlung von Nutzerdaten an Google und deren Nutzung für personalisierte Werbung von der reinen Cookie-Frage.

Basic oder Advanced — was ist richtig?

Beides ist zulässig implementierbar. Der Basic Mode ist die datensparsamere und leichter zu verteidigende Variante, der Advanced Mode liefert modellierte Daten, setzt aber Pings auch ohne Einwilligung ab. Bei kleinen Datenmengen bringt der Advanced Mode oft keinen messbaren Vorteil.

Ersetzt der Consent Mode meine Consent Management Platform?

Nein. Die CMP holt die Einwilligung ein und dokumentiert sie; der Consent Mode überträgt nur das Ergebnis an Google-Tags.

Funktioniert der Consent Mode auch für andere Anbieter?

Die Parameter sind eine Google-Spezifikation und werden von Google-Tags ausgewertet. Andere Anbieter brauchen eigene Anbindungen an die CMP. Ein gut konfiguriertes Consent-Setup steuert deshalb immer mehr als nur Google.