• Hintergrund
• Was ist der Google Consent Mode?
• Wie funktioniert der Google Consent Mode?
• Google Consent Mode implementieren
• Weitere Einstellungen
• Debuggen
• Mehr Daten durch den Consent Mode?
• Consented Only

Hintergrund

Am 3. September veröffentlichte Google den Consent Mode (aktuell in Beta):

• Google Analytics-Hilfe: Einwilligungsmodus (Beta)
• Google Developers: (Beta) Adjust tag behavior based on consent
• Google Marketing Plattform: Measure conversions while respecting user consent choices

Was ist der Google Consent Mode?

Mit dem Google Consent Mode (Einwilligungsmodus) teilt man Google mit, für welches Tracking die eigenen Website-Besucher eine Einwilligung gegeben haben. Auf Basis dieser Zustimmungseinstellungen der Nutzer werden dann die Google-Dienste (Analytics- und Marketing-Pixel) beeinflusst. Der Consent Mode ist eine API über die zwei neue Tag-Einstellungen eingeführt werden:

• analytics_storage
• ad_storage

Damit lassen sich Cookies für Webanalytics- und Werbezwecke kontrollieren. Wie das konkret funktioniert erfährst du weiter unten. Aktuell steht der Consent Mode für folgende Dienste zur Verfügung:

• Google Analytics
• Google Ads (Google Ads-Conversion-Tracking und ‑Remarketing)
• Floodlight
• Conversion Linker

Wichtig zu erwähnen ist, dass der Google Consent Mode kein Consent Management Tool ist! Damit Google Consent Mode funktioniert braucht man ein System oder Tool, welches den benötigten Zustimmungsstatus an die Consent Mode API übermittelt. Die steuert dann das Verhalten von Google-Diensten.

Wie funktioniert der Google Consent Mode?

Grob und vereinfacht funktioniert der Consent Mode wie folgt:

1. Ein Nutzer besucht die Website
2. Ein Cookie-Banner wird präsentiert
3. Der Nutzer hat nun die Möglichkeit allen Cookies zuzustimmen, einzelne Cookies abzuwählen oder allen Cookies zu widersprechen
4. Die Einstellungen des Nutzers werden vom Cookie Consent Tool gespeichert und berücksichtigt
5. Diese Einstellungen werden aber auch über die Consent Mode API an Google-Dienste geschickt
6. Google kann nun mit diesen Informationen die einzelnen Dienste, Tags und Systeme unter Berücksichtigung der Einstellungen des Nutzers aussteuern

Wozu das Ganze?

• Wenn der Nutzer allen zustimmt, bekommt das Google so mit und kann entsprechend normal weiter Cookies zu Tracking-Zwecken einsetzen.
• Wenn der Nutzer einzelnen oder allen Cookies widerspricht, dann passen sich die Google-Dienste ebenfalls an. Hier liegt aber ein großer Vorteil: Während die Cookie-Einstellungen respektiert werden, können jedoch weiterhin ohne den Einsatz von Cookies wichtige Conversions und Statistiken gemessen werden.

Entscheidend für die Funktionalität sind die oben 2 genannten Tag-Einstellungen:

• analytics_storage: Steuert Statistik-Cookies, also Google Analytics.
• ad_storage: Steuert Marketing-Cookies, also Google Ads und Floodlight.

Beide können entweder den Wert “granted” (= Zustimmung gewährt) oder “denied” (= Zustimmung verweigert) annehmen. Wird die Zustimmung gewährt, dann funktionieren Google Analytics und Co. wie gewohnt. Wenn die Zustimmung verweigert wird (Wert “denied”), dann werden dennoch einige Basis-Informationen fix mitgeschickt:

• Funktionsbezogene Informationen: Dazu gehören Zeitstempel, User-Agent und Verweis-URL.
• Zusammengefasste/nicht personenbezogene Daten: Dazu gehören Boolesche Informationen zum Einwilligungsstatus, Zufallszahl und der Hinweis, ob die aktuelle Seite oder eine vorherige Seite Infos zum Anzeigenklick in der URL enthält.

Was im Detail abgeht, erfährst du nachfolgend.

analytics_storage

Hier passt sich Google Analytics auf Basis des Zustimmungsstatus des Nutzers an. Folgende Szenarien gibt es:

• analytics_storage: “granted” -> Das Tracking wird ganz normal erlaubt. Dies ist aktuell auch die Standardeinstellung, falls keine Info an die Consent Mode API geschickt wird.
• analytics_storage: “denied” -> Google Analytics darf hier keine Cookies mehr lesen und schreiben. Dennoch sind einige Basis-Messungen weiterhin cookielos möglich.

Enthält “analytics_storage” den Wert “denied” dann heißt das nicht, dass Hits nicht an Google Analytics geschickt werden! Folgendes passiert dabei:

• Google Analytics-Cookies werden nicht gelesen oder geschrieben.
• Cookielose Hits werden mit einem gcs-Parameter an Google Analytics übermittelt.
• Seitenaufrufe und Events werden anonymisiert und auf aggregierter Basis erfasst, die aber aktuell (noch) nicht in den Reports zur Verfügung stehen.
• Conversions und andere Interaktionen können keinem Nutzer und keiner Sitzung zugeordnet werden.
• Jedes Mal wenn eine Seite neu geladen wird, wird ein neuer Client Identifier vergeben.
• Zudem muss noch erwähnt werden, dass Google Optimize von dieser Einstellung nicht betroffen ist.

ad_storage

Hier passen sich Marketing-Cookies an. Dazu zählen:

• Google Ads-Conversion-Tracking
• Google Ads Remarketing
• Floodlight

Folgende Szenarien gibt es:

• ad_storage:”granted” -> Werbung auf Basis persönlicher Daten (damit sind nicht personenidentifizierbare Daten gemeint) ist weiter möglich, da der Nutzer seine Zustimmung gegeben hat. Dies ist aktuell auch die Standardeinstellung, falls keine Info an die Consent Mode API geschickt wird.
• ad_storage:”denied” -> Hier kann kontextbezogene Werbung nur noch auf Basis anonymer Daten weiter betrieben werden. Zudem können Conversions nicht einzelnen Nutzern zugewiesen werden, sondern werden nur Kampagnen auf aggregierter Ebene zugeschrieben.
• ad_storage:”denied” + ads_data_redaction=true -> Hier werden dann Werbe-Cookies noch weiter eingeschränkt.

Enthält “ads_storage” den Wert “denied” dann passiert folgendes:

• Neue Werbe-Cookies werden nicht gesetzt.
• Vorhandene Werbe-Cookies werden nicht gelesen.
• Es gibt aber einzelne Third-Party-Cookies (von google.com und doubleclick.net), die weiterhin gesetzt und verschickt werden. Dazu zählen aber nur Cookies zur Erkennung von Klick-Betrügern und Spammern.
• Um den Standort des Nutzers aggregiert zu erfassen, werden IP-Adressen anonymisiert ausgewertet. Dadurch soll das Land für Geotargeting-Zwecke abgeleitet werden. Die Daten werden aber danach sofort wieder gelöscht und nicht protokolliert.
• Daten wie Interessen, demografische Daten und Informationen zu Google Signals werden nicht an Google Analytics verschickt, auch wenn analytics_storage=granted vorliegt.
• Die vollständige URL inkl. Infos zu Anzeigenklicks in URL-Parametern wird erfasst.

Ist zusätzlich “ads_data_redaction” aktiviert, dann werden Marketing-Cookies noch strenger behandelt:

• dclid- (Doubleclick) und gclid-Parameter (Google Ads) werden bei Requests nicht mitübergeben.
• Auch URLs mit Kennungen für Anzeigenklicks werden entfernt.
• Requests werden über eine andere Domain (= googleadsyndication.com) verschickt. Dazu soll verhindert werden, dass in Request-Headern vorher gesetzte Third-Party-Cookies übermittelt werden.

Google Consent Mode implementieren

Um den Consent Mode zu nutzen, müssen Tracking- und Marketing-Tags über das Global Site Tag (gtag.js) oder den Google Tag Manager laufen. Zudem muss der dataLayer initialisiert werden.

Zudem muss die Integration vor dem Laden des Global Site Tags und des Google Tag Managers erfolgen. Der Consent Mode wird in 2 Schritten initialisiert:

1. Standardeinstellungen: Die Standardeinstellung greift, wenn keine Einwilligung ausgelesen werden konnte.
2. Nutzer-Einstellungen: Danach werden die getätigten Einwilligungen seitens dem Nutzer ausgelesen.

Für die Implementierung sind folgende Schritte notwendig:

1. dataLayer- und gtag-Initialisierung
2. Standardeinstellungen senden
3. Nutzer-Einstellungen senden
4. Update von Consent-Änderungen

dataLayer- und gtag-Initialisierung

Zunächst müssen dataLayer und gtag initialisiert werden:

window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments); }

Wichtig ist, dass dieser Code vor dem GTM und gtag implementiert wird.

Standardeinstellungen senden

Auch vor dem GTM und gtag müssen die Standardeinstellungen festgelegt werden. Der Code sieht dann erweitert wie folgt aus:

window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments); }
gtag('consent', 'default', {
  ad_storage: 'denied',
  analytics_storage: 'denied'
});


Am Code ist zu sehen, dass Analytics- und Marketing-Tags standardmäßig blockiert werden, wenn keine Nutzer-Einwilligung ausgelesen wird. Für eine noch strengere Behandlung der Marketing-Tags kann noch “ads_data_redaction” aufgerufen werden:

window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments); }
gtag('consent', 'default', {
  ad_storage: 'denied',
  analytics_storage: 'denied'
});
gtag('set', 'ads_data_redaction', true);


Die Standardeinstellungen können zusätzlich um unterschiedliche regionale Aussteuerungen erweitert werden. Im folgenden Fall werden Analytics- und Marketing-Tags für Österreich und Deutschland standardmäßig blockiert, während für den Rest das Gegenteil gilt:

window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments); }
gtag('consent', 'default', {
  ad_storage: 'denied',
  analytics_storage: 'denied',
  region: ['AT', 'DE'] });
gtag('consent', 'default', {
  ad_storage: 'granted',
  analytics_storage: 'granted'
});

Wichtig ist, dass dieser Code vor dem Google Tag Manager und gtag.js lädt. Wer mit dem Google Tag Manager arbeitet, kann diesen Code auch innerhalb eines benutzerdefinierten HTML-Tags verwenden. Man muss aber sicherstellen, dass das Tag dann vor allen anderen Google-Tags feuert.

Nutzer-Einstellungen senden

Hat der Nutzer dann seine Einstellungen getätigt, müssen die Standardeinstellungen ggf. aktualisiert werden. Das geschieht folgendermaßen:

gtag('consent', 'update', {
  ad_storage: 'granted',
  analytics_storage: 'granted'
});

Update von Consent-Änderungen

Entscheidet sich der selbe Nutzer seine initiale Einwilligung noch zu ändern, dann muss das an die Consent Mode API ebenfalls übertragen werden. Dies geschieht ebenfalls mit dem update-Kommando:

gtag('consent', 'update', {
  ad_storage: 'denied',
  analytics_storage: 'denied'
});

Dieses Update-Kommando kann ebenfalls direkt über den Google Tag Manager implementiert wird (über ein benutzerdefiniertes HTML-Tag).

Weitere Einstellungen

Bei der Implementierung gibt es noch 2 Sonderfälle, die man berücksichtigen sollte:

• Tracking verzögern
• URL weitergeben

Tracking verzögern

Hintergrund einer Tracking-Verzögerung ist, dass Tracking-Tags zwischen Standardeinstellungen und den tatsächlichen Consent-Einstellungen des Nutzers verschickt werden können. Im diesem Fall würden die Request der Tracking-Tags auf Basis der Standardeinstellungen verschickt werden. Daher kann bei den Standardeinstellungen eine Wartezeit mitdefiniert werden. Die Tracking-Tags werden dann um diese Wartezeit verzögert ausgespielt. Dadurch gibt man dem Setup etwas Zeit, den Consent der Nutzer auszulesen, um dann die Tracking-Tags gemäß der Nutzer-Einstellungen zu feuern:

gtag('consent', 'default', {
  ad_storage: 'denied',
  analytics_storage: 'denied',
  'wait_for_update': 1500 // Wert wird in Millisekunden angegeben
});

URL weitergeben

Oben haben wir gesehen, das bei Änderungen der Consent-Einstellungen das Update-Kommando aufgerufen werden muss. Wenn der Nutzer jedoch in der Sitzung einige Seiten schon aufgerufen hat und dann erst den Consent gibt, hat man das Problem, dass die nachfolgenden Seiten keiner Traffic-Kampagnen-Quelle zugeordnet werden können. Grund: Parameter wie utm, gclid, etc. fehlen in der URL. Dies kann man umgehen, in dem man die url_passthrough-Methode aufruft:

gtag('set', 'url_passthrough', true);

Dies funktioniert aber nur, wenn man gtag.js verwendet. Nutzt du den Google Tag Manager, dann solltest du stattdessen den Conversion Linker benutzen. Dazu wählst du die folgende Einstellung:

Debuggen

Ob die Hits laut Consent Mode korrekt an Google Analytics übertragen werden, lässt sich in den DevTools im Network-Tab überprüfen. Dazu wählt man den Collect-Hit und hält Ausschau nach dem Parameter “gcs”. Hinter dem Parameter wird ein Wert mitgegeben (z.B. G100), der wie folgt aufgebrochen werden kann:

• G1: Dieser Anfangswert ist immer gleich.
• Die zweite Zahl (0 oder 1) bezieht sich auf ad_storage. 0 bedeutet “denied” und 1 bedeutet “granted”.
• Die dritte Zahl (0 oder 1) bezieht sich auf analytics_storage. 0 bedeutet “denied” und 1 bedeutet “granted”.

Es können also folgende Werte mit folgenden Bedeutungen vorkommen:

• G100: Marketing- und Statistik-Cookies haben keine Zustimmung.
• G110: Marketing-Cookies können gesetzt und ausgelesen werden, Statistik-Cookies jedoch nicht.
• G111: Marketing- und Statistik-Cookies haben eine Zustimmung erhalten.
• G101: Statistik-Cookies können gesetzt und ausgelesen werden, Marketing-Cookies jedoch nicht.

Erneutes Senden von Hits

Der Google Consent Mode ist so ausgelegt, dass der Trigger auf “All Pages” gesetzt werden. Über den entsprechenden gcs-Parameter weiß dann Google, ob ein Consent vorhanden ist oder nicht und kann dann die Tags danach ausrichten wie oben beschrieben. Nun gibt es einen – sagen wir mal “Umstand” – den man hierbei berücksichtigen muss.

Zunächst zum Flow:

1. Nutzer kommt auf die Seite.
2. GA4 feuert sofort mit gcs=G100, da die Standardeinstellung auf “analytics_storage: denied” gesetzt ist
3. Cookie-Banner poppt auf.
4. Nutzer stimmt zu und “analytics_storage” wechselt zu “granted”.

Was glaubst du passiert dann? Die Antwort: Nichts! GA4 sendet nicht erneut das Event mit gcs=G111 oder gcs=G101 automatisch, was aktuell suboptimal ist (da das Event dann in den Reports fehlt). Lösungen:

• Einen zusätzlichen Trigger so anlegen, dass das Tag nochmal feuert nachdem “analytics_storage” zu “granted” wechselt.
• GA4 mit serverside Google Tag Manager nutzen. Wenn der eigene Endpoint mittels dem Feld “Send to server container” gesetzt ist, dann feuert GA4 automatisch nochmal. Eine pure clientseitige GA4-Integration macht das nicht automatisch.

Mehr Daten durch den Consent Mode?

Wie weiter oben erwähnt, werden aktuell (Stand: März 2021) Daten, die ohne Zustimmung des Nutzers über den Google Consent Mode dennoch gesammelt werden nicht in den Reports innerhalb von Google Analytics und Google Ads präsentiert.

Update: 15. April 2021
Google hat nun zum Vorgehen der gesammelten Daten über den Consent Mode mehr Details veröffentlicht (“Conversion modeling through Consent Mode in Google Ads”). In den Google Ads-Berichten werden modellierte Conversions für die Consent-Pings (also Hits, wo der Nutzer abgelehnt hat) ab sofort aufgenommen. Zunächst einmal für Websites aus dem europäischen Wirtschaftsraum und UK. Für die Modellierung kommt Maschine Learning zum Einsatz. Wie qualitativ hochwertig die Daten sind, kann ich aktuell nicht sagen. Sobald erste Erkenntnisse da sind, werde ich diese hier gerne teilen.

Wann eine ähnliche Modellierung für Google Analytics ausgerollt wird, ist noch nicht klar.

Update August 2021
Im Laufe des Augusts sind nun auch die Consent-Mode-Informationen in BigQuery verfügbar:

Update Mai 2022
Einige GA4-Konten bekommen nun die Möglichkeit, das Verhaltens-Modelling (Daten, die durch die Consent Mode Pings gesammelt wurden) in den GA4-Reports innerhalb der UI zu aktivieren. In den Verwaltungseinstellungen unter “Identität für die Berichterstellung” lässt sich definieren, ob modellierte Daten mit einbezogen werden sollten. Auch sind nun Voraussetzungen genannt worden, wann und wie Consent Mode in den Daten herangezogen wird. Mehr Infos hier.

Consented Only

Wem das alles zu riskant ist – also Hits ohne Consent an Google übermitteln – kann auf “Consented Only” zurückgreifen. Diese Möglichkeit ist zwar nicht offiziell dokumentiert, es werden aber nur Hits rausgeschickt, wenn dem Tracking auch tatsächlich zugestimmt wurde. Im Grund ist das eine Implementierung des Google Consent Mode mit weiterhin Optout-Triggern in GTM. Es läuft also alles wie gewohnt ab, nur wird eben noch zusätzlich der entsprechende Parameter mitgegeben, was für Google ein Signal ist, das Modelling zu aktvieren.