ads_data_redaction im Consent Mode v2: Wirkung, Rechtsrahmen und Einrichtung

Inhalt
Die digitale Werbelandschaft verschiebt sich unaufhaltsam in Richtung datenschutzorientierter Architekturen. Mit der verpflichtenden Einführung des Google Consent Mode v2 für Werbetreibende im Europäischen Wirtschaftsraum (EWR) sind die Compliance-Mechanismen erheblich komplexer geworden. Neben den neu eingeführten Parametern ad_user_data und ad_personalization bleibt eine entscheidende, aber oft übersehene Einstellung von höchster Relevanz: ads_data_redaction.
Der Mechanismus der Datenredaktion
Um die Notwendigkeit dieses Parameters zu verstehen, muss zunächst das Standardverhalten des Consent Mode analysiert werden. Wenn die Zustimmung für Marketing-Cookies ausdrücklich verweigert wird (ad_storage='denied'), passen die Google-Tags ihr Verhalten an. Es werden keine Werbe-Cookies mehr gelesen oder geschrieben. Standardmäßig werden jedoch weiterhin sogenannte “Cookieless Pings” an die Google-Server gesendet, um grundlegende Messfunktionen aufrechtzuerhalten.
Das Datenschutzproblem entsteht, weil diese Pings weiterhin URL-Abfrageparameter übertragen können, die Klick-Identifikatoren wie den Google Click Identifier (GCLID) oder den DoubleClick Identifier (DCLID) enthalten. Diese Identifikatoren sind hochspezifisch und können potenziell genutzt werden, um den Weg eines Nutzers nachzuverfolgen.
Wird der Parameter ads_data_redaction auf true gesetzt, ändert sich dieses Verhalten grundlegend. Ist dieser Befehl aktiv und der Status für ad_storage gleichzeitig verweigert, laufen folgende Prozesse ab:
- Entfernung von Identifikatoren: Sämtliche Klick-Identifikatoren (GCLID, DCLID, wbraid, gbraid) werden aus den von Google Ads- und Floodlight-Tags gesendeten Netzwerkanfragen entfernt.
- Cookielose Domain: Die Netzwerkanfragen werden zudem über eine Domain gesendet, die keine Drittanbieter-Cookies setzt, etwa
pagead2.googlesyndication.com. - Redigierte Seiten-URLs: Auch Seiten-URLs, die Klick-Identifikatoren enthalten, werden in den Werbeanfragen redigiert. Die Link Decoration selbst steuert nicht dieser Parameter, sondern
url_passthrough.
Der rechtliche Rahmen: DSGVO und ePrivacy
Die rechtliche Situation in Europa wird in erster Linie durch die Datenschutz-Grundverordnung (DSGVO) und die ePrivacy-Richtlinie (oft als “Cookie-Richtlinie” bezeichnet) bestimmt.
Gemäß dem Grundsatz der Datenminimierung der DSGVO (Artikel 5) dürfen nur Daten verarbeitet werden, die für einen bestimmten Zweck zwingend erforderlich sind. Darüber hinaus schreibt die ePrivacy-Richtlinie vor, dass eine ausdrückliche Zustimmung eingeholt werden muss, bevor Informationen auf einem Endgerät gespeichert oder abgerufen werden.
Klick-Identifikatoren wie GCLID gelten allgemein als pseudonyme personenbezogene Daten, da sie theoretisch mit anderen Datensätzen kombiniert werden könnten, um eine Einzelperson zu identifizieren. Die Übertragung dieser Identifikatoren, wenn eine marketingbezogene Nachverfolgung ausdrücklich abgelehnt wurde, stellt daher ein erhebliches rechtliches Risiko dar. Durch die Implementierung von ads_data_redaction wird die Datenerfassung an die strengsten Auslegungen der europäischen Datenschutzgesetze angepasst. Dadurch wird sichergestellt, dass ein “abgelehnter” Status tatsächlich bedeutet, dass keine identifizierenden Werbedaten verarbeitet oder übertragen werden.
Konfiguration von ads_data_redaction
Die Konfiguration erfordert eine Modifikation des globalen Website-Tags (gtag.js) oder eine Anpassung der Einstellungen im Google Tag Manager. Bei einer direkten Code-Implementierung muss der Parameter gesetzt werden, bevor der Standard-Zustimmungsstatus definiert wird.
<script>
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
/* Den Redaktions-Parameter auf true setzen */
gtag('set', 'ads_data_redaction', true);
/* Definition der Standard-Zustimmungsstatus */
gtag('consent', 'default', {
'ad_storage': 'denied',
'analytics_storage': 'denied',
'ad_user_data': 'denied',
'ad_personalization': 'denied'
});
</script>Implementierung über den Google Tag Manager (Simo Ahava Template)
Bei der Nutzung des Google Tag Managers (GTM) ist das von Simo Ahava erstellte Community-Template mit dem Namen “Consent Mode (Google tags)” die effizienteste und gängigste Methode zur Verwaltung des Consent Mode. Die Konfiguration der Datenredaktion innerhalb dieses Templates erfordert keinen benutzerdefinierten Code.
Konfigurationsschritte:
- Hinzufügen des Templates: Das Template “Consent Mode (Google tags)” muss aus der GTM Community Template Gallery hinzugefügt werden.
- Tag-Erstellung: Ein neuer Tag wird mit diesem Template erstellt, wobei der Konfigurationsbefehl (Command) auf “Default” gesetzt wird.
- Definition der Status: Die Standard-Zustimmungsstatus werden für alle erforderlichen Kategorien definiert (z. B. wird
ad_storageauf ‘denied’ gesetzt). - Aktivierung der Redaktion: In der Tag-Konfiguration wird unter dem Abschnitt für zusätzliche Einstellungen (“Other Settings” oder “Advanced”) das spezifische Feld für
ads_data_redaction(oft als Kontrollkästchen “Redact Ads Data” oder Dropdown dargestellt) gesucht und auftruegesetzt. - Trigger-Zuweisung: Der Tag wird mit dem frühestmöglichen Trigger verknüpft, zwingend “Consent Initialization – All Pages”. Dadurch wird sichergestellt, dass die Redaktionsregeln aktiv sind, bevor andere Tags ausgelöst werden.
Fragen und Antworten
Arbeiten ads_data_redaction und url_passthrough gegeneinander, wenn das eine Klick-Kennungen entfernt und das andere sie weiterreicht?
Nein, weil beide verschiedene Wege betreffen.
ads_data_redaction entscheidet über das, was an Google gesendet wird: Bei verweigerter Zustimmung fallen gclid, dclid, wbraid und gbraid aus den Anfragen heraus, und die Anfragen laufen über eine Domain ohne Drittanbieter-Cookies. url_passthrough entscheidet über das, was innerhalb der Seite passiert: Die Kennung bleibt beim Klick auf den nächsten Link in der Adresse erhalten, statt beim ersten Seitenwechsel verloren zu gehen.
Zusammen ergibt das ein stimmiges Bild. Google erfährt die Klick-Kennung nicht, solange abgelehnt ist; die Seite behält sie trotzdem und kann sie verwenden, sobald doch zugestimmt wird. Wer beide für dasselbe hält, schaltet leicht eines davon ab und wundert sich anschließend, dass nach einer nachträglichen Zustimmung die Zuordnung zur Kampagne fehlt: Die Kennung war beim zweiten Seitenaufruf schon weg.
Muss gtag(‘set’, ‘ads_data_redaction’, true) vor dem default-Befehl stehen, oder ist die Reihenfolge Geschmackssache?
Die Reihenfolge aus dem Artikel ist die sichere, auch wenn eine andere nirgends als Fehler auffällt.
Der Befehl wirkt ab dem Moment seiner Ausführung. Alles, was davor gesendet wird, geht unredigiert hinaus. Steht die Redaction vor dem default-Befehl, ist sie in jedem Fall gesetzt, bevor der erste Tag eine Anfrage senden kann; steht sie dahinter, hängt das Ergebnis davon ab, dass zwischen beiden Zeilen nichts ausgelöst wird. Eine Fehlermeldung gibt es für diesen Fall nicht, nur einen Treffer im Netzwerk-Tab, den niemand sucht.
Im Tag Manager gilt dasselbe in anderer Form: Die Redaction gehört in denselben Tag wie der Default und damit an denselben Trigger „Consent Initialization – All Pages“. In einem zweiten Tag hängt die Reihenfolge an der Tag-Priorität, und die ist eine Zahl, die später jemand ändert, ohne den Zusammenhang zu kennen.