Consent- und Tag-Drift überwachen: Datenschutz nach Deploy

Was Consent- und Tag-Drift bedeutet

Tag-Drift ist die unbeabsichtigte Abweichung der auf einer Seite aktiven Tags und Tracker vom erwarteten Sollzustand. Im Datenschutzkontext geht es vor allem um eine Form: Skripte und Netzwerk-Aufrufe, die vor der Einwilligung (pre-consent) ausgelöst werden, obwohl sie das nicht dürften. Der Begriff stammt ursprünglich aus dem Konfigurationsmanagement, wo „Drift" die schleichende Abweichung eines Systems von seiner definierten Baseline beschreibt. Auf eine Website übertragen heißt das: Der Soll-Zustand ist „kein nicht-essenzieller Tracker feuert, bevor der Besucher zugestimmt hat" - und jede Abweichung davon ist Drift.

Die rechtliche Grundlage ist eindeutig. Artikel 5 Absatz 3 der ePrivacy-Richtlinie und in Deutschland Paragraf 25 TDDDG (vormals TTDSG) verlangen eine vorherige Einwilligung, bevor nicht zwingend erforderliche Informationen auf dem Endgerät gespeichert oder ausgelesen werden. Ein Tracker, der vor dem Opt-in eine Verbindung zu einem Drittserver aufbaut, eine Cookie-ID setzt oder die IP-Adresse überträgt, verstößt damit potenziell gegen geltendes Recht. Das Verwaltungsgericht Hannover stellte am 19. März 2025 klar, dass selbst das bloße Laden des Google Tag Manager - inklusive des „denied"-Signals im Consent Mode v2 - bereits eine einwilligungspflichtige Verarbeitung darstellt, weil schon beim Seitenaufruf eine Verbindung zu Google aufgebaut wird (VG Hannover 2025).

Drift ist heimtückisch, weil sie kein Fehler im klassischen Sinn ist. Die Seite funktioniert, der Banner erscheint, das Layout sieht aus wie stets. Erst ein Blick in die Netzwerk-Anfragen vor dem Klick auf „Akzeptieren" zeigt, dass ein neues Skript bereits Daten sendet. Genau diese Lücke zwischen sichtbarer Funktion und tatsächlichem Datenfluss macht das Thema für manuelle Kontrollen so schwer greifbar. Hinzu kommt, dass die Prüfung mit jedem geänderten Endgerät, Browser und Standort anders ausfallen kann - ein Tag, das im Büro-Browser sauber bleibt, kann auf einem Mobilgerät oder in einer anderen Region bereits vor dem Consent feuern. Eine punktuelle Sichtprüfung am Entwickler-Laptop bildet diese Vielfalt nicht ab und übersieht genau die Fälle, die später zum Problem werden.

Warum Deploys die häufigste Drift-Ursache sind

Moderne Web-Teams releasen oft - und genau das ist das Problem. Laut dem DORA-Report deployen die leistungsstärksten Teams „on demand", typischerweise mehrfach pro Tag, und rund 19 % der befragten Teams zählen zu diesen Elite-Performern (DORA State of DevOps 2024). Jeder dieser Deploys ist eine Gelegenheit, ungewollt ein Tag einzuschleusen, das vor dem Consent feuert. Die Ursachen sind selten böswillig - meist sind sie banal.

Hinzu kommt die schiere Masse: Websites laden im Schnitt 48 Tracker (NordVPN), und 75 % der Desktop-Seiten enthalten mindestens einen Tracker (Web Almanac 2025). Bei dieser Dichte ist die Wahrscheinlichkeit hoch, dass irgendwo in der Kette ein Element nicht korrekt gegated ist. Verwandte Konfigurations-Driften - etwa bei Weiterleitungen - beschreibt der Beitrag zur Überwachung von Redirect-Chains; das Muster ist dasselbe: ein Deploy ändert unbemerkt das Verhalten.

Erschwerend kommt hinzu, dass an einem modernen Release selten nur ein einzelnes Team beteiligt ist. Entwicklung, Marketing und externe Dienstleister greifen oft unabhängig voneinander in dieselbe Seite ein - die einen über den Code, die anderen über einen Tag-Manager, wieder andere über ein Plugin. Keiner dieser Beteiligten hat den vollständigen Überblick darüber, was am Ende tatsächlich im Browser des Besuchers passiert. Genau in dieser Verantwortungsdiffusion entsteht Drift: Jeder geht davon aus, dass die Consent-Logik bereits an anderer Stelle greift. Eine objektive, von außen messende Kontrolle ist deshalb der einzige verlässliche Weg, den realen Zustand festzustellen, statt sich auf Annahmen zu verlassen. Wie alltäglich diese geteilte Verantwortung ist, belegt die Datenlage: über 90 Prozent der Websites binden mindestens eine Drittanbieter-Ressource ein (Web Almanac 2025).

Was vor dem Consent feuert - die typischen Verdächtigen

Nicht jeder Netzwerk-Aufruf vor dem Opt-in ist ein Verstoß. Technisch notwendige Anfragen - das Ausliefern des HTML, der Consent-Lösung selbst, von Schriftarten aus der eigenen Domain - sind erlaubt. Problematisch werden erst die nicht-essenziellen Tracker. Die folgende Übersicht zeigt, welche Kategorien typischerweise driften und wie sie sich verhalten.

Eine besonders tückische Quelle von Drift ist die Consent-Lösung selbst. Mehrere große Anbieter solcher Banner standen in Untersuchungen in der Kritik, weil ihre Skripte teils schon vor der Einwilligung Verbindungen aufbauten - das Werkzeug, das den Datenschutz sicherstellen soll, wurde so selbst zur Lücke. Auch die Auswahl des Consent-Anbieters bewegt sich: Laut Web Almanac 2025 hat sich die Verteilung der eingesetzten Plattformen deutlich verschoben, und die Konformität bleibt schwach - die TCFv2-Compliance lag unverändert bei nur 1,7 % (Web Almanac 2025). Ein Update oder Wechsel der Banner-Lösung sollte deshalb genauso als potenzieller Drift-Auslöser behandelt werden wie ein Code-Deploy. Wer den Anbieter wechselt, sollte die Pre-Consent-Prüfung unmittelbar danach wiederholen.

Die Kosten unentdeckter Drift

Pre-Consent-Tracking ist kein theoretisches Risiko mehr, sondern aktiver Schwerpunkt der Aufsichtsbehörden. Die französische CNIL verhängte am 1. September 2025 gegen die SHEIN-Gesellschaft ein Bußgeld von 150 Millionen Euro und gegen einen weiteren großen Anbieter 325 Millionen Euro - in beiden Fällen ging es zentral um Cookies, die vor der Einwilligung gesetzt wurden (CNIL 2025). Insgesamt sprach die CNIL 2025 83 Sanktionen mit einem Volumen von rund 486,8 Millionen Euro aus (CNIL 2025).

Auch die Verbreitung des Problems ist gut belegt. Eine Untersuchung von über 36.000 Unternehmens-Websites in Dänemark fand, dass 73,02 % Tracking bereits vor der Einwilligung starteten (Danish DPA / Datatilsynet). Eine internationale Studie über 254.148 Websites in 31 Ländern ergab, dass nur 15 % der Cookie-Banner die Mindestanforderungen erfüllten und über 50 % der Websites Cookies setzten, bevor Nutzer eine Wahl getroffen hatten (Trielli et al. 2025). Diese Zahlen zeigen: Pre-Consent-Drift ist eher die Regel als die Ausnahme.

Neben dem Bußgeldrisiko durch die Aufsichtsbehörden besteht in Deutschland ein zweites, oft unterschätztes Risiko: die wettbewerbsrechtliche Abmahnung. Mitbewerber und qualifizierte Verbände können Datenschutzverstöße als unlauteren Wettbewerbsvorteil werten und kostenpflichtig abmahnen. Ein vor dem Consent feuernder Tracker liefert dafür einen technisch leicht nachweisbaren Anknüpfungspunkt - es genügt, die Seite einmal ohne Klick zu laden und die Netzwerk-Anfragen zu protokollieren. Gerade weil der Nachweis so einfach ist, eignet sich Pre-Consent-Tracking besonders gut als Abmahngrund, und genau das macht die kontinuierliche Eigenkontrolle wertvoll. Das Landgericht München I sprach bereits 2022 einem Websitebesucher Schadensersatz zu, weil seine IP-Adresse ohne Einwilligung an einen US-Dienst übermittelt wurde (LG München I, Az. 3 O 17493/20) - ein Urteil, das eine Welle gleichartiger Abmahnungen auslöste.

Pre-Consent-Netzwerk-Calls technisch erkennen

Die zuverlässigste Prüfung ist nicht der Blick in den Tag-Manager, sondern die Beobachtung des tatsächlichen Netzwerkverkehrs in einem echten Browser. Eine kopflose Browser-Instanz lädt die Seite, wartet aber bewusst auf keinen Klick: Was jetzt an Drittserver-Anfragen, Cookie-Setzungen und Beacon-Calls passiert, ist der Pre-Consent-Footprint. Dieser wird gegen eine Baseline verglichen - die Liste der erlaubten, technisch notwendigen Aufrufe.

Baseline (Soll, vor Consent erlaubt):
  GET  /                      eigene Domain   ok
  GET  /consent.js            eigene Domain   ok
  GET  /fonts/inter.woff2     eigene Domain   ok

Beobachtet nach Deploy v119:
  GET  /                      eigene Domain   ok
  GET  /consent.js            eigene Domain   ok
  GET  /fonts/inter.woff2     eigene Domain   ok
+ GET  1   DRITT-DOMAIN  NEU
+ SET  _cw_sid (Cookie)          vor Opt-in    VERSTOSS

=> Drift erkannt: 1 neuer Pre-Consent-Tracker

Entscheidend ist, dass die Prüfung mit aktivem JavaScript läuft. Reine HTML-Abrufe per Kommandozeile übersehen Tags, die erst durch ein Skript nachgeladen werden - und genau diese dynamisch injizierten Tags sind die häufigste Drift-Quelle. Das XICTRAQ DSGVO-Compliance-Monitoring nutzt deshalb einen echten Browser, der die Seite vollständig rendert, alle Netzwerk-Anfragen vor jeder Interaktion protokolliert und sie gegen die zuletzt bekannte saubere Baseline abgleicht.

• Vollständiges Rendering - die Seite wird in einem echten Browser mit JavaScript geladen, nicht nur als HTML abgerufen
• Keine Interaktion - der Scan wartet bewusst nicht auf einen Banner-Klick, um den reinen Pre-Consent-Zustand zu erfassen
• Cookie- und Storage-Inventar - jedes vor dem Opt-in gesetzte Cookie und jeder localStorage-Eintrag wird erfasst
• Drittserver-Klassifizierung - Anfragen werden nach eigener Domain vs. Drittanbieter unterschieden
• Baseline-Diff - der aktuelle Zustand wird gegen den letzten freigegebenen Stand verglichen, sodass nur echte Änderungen alarmieren

Drift nach jedem Release überwachen

Ein einmaliger Cookie-Scan ist eine Momentaufnahme - bei der nächsten Codeänderung kann er bereits veraltet sein. Da Drift typischerweise durch Deploys entsteht, muss die Überwachung kontinuierlich laufen. XICTRAQ prüft die hinterlegten Websites regelmäßig und nach Konfiguration auch ereignisgesteuert, vergleicht das Ergebnis mit der Baseline und meldet jede neue Pre-Consent-Anfrage.

Weicht der aktuelle Zustand ab - taucht ein neuer Tracker auf, wird ein Cookie früher gesetzt als zuvor oder verschwindet ein zuvor sauberes Consent-Gate - löst das eine Benachrichtigung per E-Mail, Slack, Discord oder Telegram aus. So erfahren Sie von der Drift, während sie noch wenige Stunden alt ist, statt erst bei einer Abmahnung oder Aufsichtsprüfung. Dasselbe Prinzip der kontinuierlichen Soll-Ist-Prüfung liegt auch der Überwachung der security.txt und Vulnerability-Disclosure zugrunde.

Drift-Monitoring als Teil der DSGVO-Compliance

Pre-Consent-Drift ist nur ein Baustein eines belastbaren Datenschutz-Setups. Die DSGVO verlangt „geeignete technische und organisatorische Maßnahmen" - und ein dokumentiertes, kontinuierliches Monitoring der tatsächlichen Datenflüsse ist ein nachweisbarer Beleg dafür. Wer regelmäßig prüft, kann im Prüfungsfall belegen, dass Abweichungen erkannt und behoben wurden, statt monatelang unbemerkt zu bestehen.

Wichtig ist dabei die Abgrenzung zur reinen Bestandsaufnahme. Ein klassischer Datenschutz-Audit hält fest, wie die Seite zu einem Zeitpunkt aussah - er sagt nichts darüber aus, was beim nächsten Deploy passiert. Drift-Monitoring dreht diese Logik um: Nicht der Zustand zählt, sondern die Veränderung gegenüber dem freigegebenen Stand. Damit wird die Überwachung anschlussfähig an moderne Entwicklungsprozesse, in denen sich die Seite ohnehin ständig verändert. Statt einer jährlichen Prüfung, die zwischen zwei Terminen blind ist, entsteht eine laufende Kontrolle, die genau dann anschlägt, wenn sich etwas Relevantes ändert.

Der praktische Wert liegt im Zeitfaktor. Ohne Monitoring fällt eine Drift erfahrungsgemäß erst auf, wenn ein externer Hinweis kommt - ein Hinweisgeber, eine Abmahnung oder eine Behördenanfrage. Mit kontinuierlicher Überwachung wird dieselbe Abweichung innerhalb von Stunden sichtbar, oft noch bevor nennenswerter Datenverkehr vor dem Consent entstanden ist. Diese Verkürzung des Zeitfensters ist der eigentliche Schutz.

Ein Deploy lässt sich nicht verhindern - und das soll er auch nicht. Schnelle Releases sind ein Wettbewerbsvorteil. Was sich verhindern lässt, ist, dass eine ungewollte Pre-Consent-Änderung wochenlang unbemerkt bleibt. Genau dafür ist ein DSGVO-Compliance-Monitoring gedacht: Es macht aus dem unsichtbaren Datenfluss vor dem Consent ein sichtbares, alarmierbares Signal.

Häufig gestellte Fragen zu Consent- und Tag-Drift