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.
4 Kommentare
die Abgrenzung zu
url_passthroughsteht hier in einem Nebensatz und fehlt sonst überall — danke dafür.Ganz aufgelöst hat sich die Frage für mich aber nicht: Wenn die Redaction die Klick-Kennungen aus den Anfragen entfernt,
url_passthroughsie aber in der Adresse weiterreicht — arbeiten die beiden Einstellungen dann nicht gegeneinander?Beide betreffen verschiedene Wege, deshalb nicht.
ads_data_redactionentscheidet über das, was an Google gesendet wird: Bei verweigerter Zustimmung fallengclid,dclid,wbraidundgbraidaus den Anfragen heraus, und die Anfragen laufen über eine Domain ohne Drittanbieter-Cookies.url_passthroughentscheidet ü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 meist eines davon versehentlich ab und wundert sich anschliessend, dass nach einer nachträglichen Zustimmung die Zuordnung zur Kampagne fehlt — die Kennung war beim zweiten Seitenaufruf schon weg.
Der Beitrag ist die erste Beschreibung, die den Parameter nicht als Nebensache behandelt. Bei uns stand er zwei Jahre lang auf der Vorgabe, ohne dass jemand danach gefragt hätte.
Eine Detailfrage zur Reihenfolge: Im Beispiel steht
gtag('set', 'ads_data_redaction', true)vor demdefault-Befehl. Ist diese Reihenfolge zwingend oder Geschmackssache?Zwingend im Ergebnis, auch wenn sie nirgends als Fehler auffällt.
Der Befehl wirkt ab dem Moment seiner Ausführung. Alles, was davor entsteht, geht unredigiert hinaus — und der
default-Befehl gibt die Messung unmittelbar frei. Zwischen beiden Zeilen liegt damit genau das Zeitfenster, in dem die erste Anfrage die Klick-Kennung noch mitnimmt. Eine Fehlermeldung gibt es dafür nicht, nur einen Treffer im Netzwerk-Tab, den niemand sucht.Im Tag Manager gilt dasselbe in anderer Form: Redaction gehört in dasselbe Tag wie der Default und damit an denselben Auslöser „Consent Initialization“. 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.