LW IT Solutions
« Blog Overview /Data Privacy / ads_data_redaction im Consent Mode v2: Wirkung, Rechtsrahmen...
This post in other languages:

ads_data_redaction im Consent Mode v2: Wirkung, Rechtsrahmen und Einrichtung

Privacy by Design: Eine detaillierte Analyse von ads_data_redaction im Consent Mode v2
Inhalt
  1. Der Mechanismus der Datenredaktion
  2. Der rechtliche Rahmen: DSGVO und ePrivacy
  3. Konfiguration von ads_data_redaction
  4. Implementierung über den Google Tag Manager (Simo Ahava Template)
  5. Quellen

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.

Diagramm zum Artikel: Der Mechanismus der Datenredaktion, Der rechtliche Rahmen: DSGVO und ePrivacy, Konfiguration von ads_data_redaction …
Der Ablauf aus dem Artikel in 4 Schritten: Der Mechanismus der Datenredaktion, Der rechtliche Rahmen: DSGVO und ePrivacy, Konfiguration von ads_data_redaction, Implementierung über den Google Tag Manager.

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_storage auf ‘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 auf true gesetzt.
  • 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.
Lukas Wojcik

Lukas Wojcik

Systems architect and technology enthusiast specializing in scalable tracking solutions, GMP Stack (GA4 & GTM), and robust backend architectures. Advocate for clean code and privacy-first design.

Get in Touch

Briefly describe your project or inquiry for a tailored response. This site is protected by reCAPTCHA.

4 Kommentare

  1. Lorenz Aufderheide

    die Abgrenzung zu url_passthrough steht 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_passthrough sie aber in der Adresse weiterreicht — arbeiten die beiden Einstellungen dann nicht gegeneinander?

    1. Lukas Wojcik Autor

      Beide betreffen verschiedene Wege, deshalb nicht.

      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 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.

  2. Emily Cartwright

    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 dem default-Befehl. Ist diese Reihenfolge zwingend oder Geschmackssache?

    1. Lukas Wojcik Autor

      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.

Kommentar schreiben

Die E-Mail-Adresse wird nicht veröffentlicht. Pflichtfelder sind mit einem Stern versehen.

ALL ARTICLES & CATEGORIES

CCTV

Diese Rubrik per RSS verfolgen

Cloud & AI

Diese Rubrik per RSS verfolgen

Data Privacy

Alle 11 Artikel dieser Rubrik Diese Rubrik per RSS verfolgen

Digital Analytics

Alle 44 Artikel dieser Rubrik Diese Rubrik per RSS verfolgen

Digital Marketing

Alle 25 Artikel dieser Rubrik Diese Rubrik per RSS verfolgen

IT & Networks

Alle 15 Artikel dieser Rubrik Diese Rubrik per RSS verfolgen

Raspberry Pi

Diese Rubrik per RSS verfolgen

Smart Home

Alle 11 Artikel dieser Rubrik Diese Rubrik per RSS verfolgen

Web Entwicklung

Diese Rubrik per RSS verfolgen

WordPress-Plugins & Tricks

Diese Rubrik per RSS verfolgen