So erkennen Sie, ob ein Tag wirklich vor der Einwilligung Cookies setzt

Alle Beiträge

Öffnen Sie die Seite in einem privaten Fenster mit bereits geöffneten Entwicklertools und berühren Sie das Banner nicht. Was unter Application, Cookies erscheint und was unter Network rausgeht, ist vor der Einwilligung passiert. Ordnen Sie dann jeden Eintrag zu: Pausieren Sie das verdächtige Tag, laden Sie neu und sehen Sie nach, ob er trotzdem wiederkommt. Ein Container-Audit beantwortet eine andere Frage, nämlich welche Tags ungesperrt sind, nicht welche davon tatsächlich etwas getan haben.

Was eine Audit-Liste Ihnen wirklich sagt

Ein Consent-Audit, ob von einem Scanner oder von jemandem, der einen Container-Export liest, beantwortet eine Frage: Welche Tags haben keine Consent-Bedingung? Das ist eine berechtigte Frage. Sie ist aber nicht dieselbe wie die, ob etwas den Browser verlassen hat, bevor der Besucher entschieden hat.

In einer produktiven Website-Landschaft hat uns die Kundenseite dieses Jahr eine Befundliste mit elf ungesperrten Tags übergeben, samt Beschwerde und Frist. Gemessen an einem einzigen sauberen Seitenaufruf waren drei der elf Anbieter-Tags, die den Consent-Status selbst lesen und dann nichts tun, zwei waren dataLayer-Listener, die weder ein Cookie setzten noch eine Netzwerkanfrage stellten, und sechs waren echte Lecks. Fünf von elf Befunden betrafen Konfigurationshygiene. Das lohnt sich zu beheben, aber darüber hatte sich niemand beschwert.

Der Befund, der die Beschwerde erklärte, stand gar nicht auf der Liste.

So prüfen Sie, ob ein Tag wirklich Cookies setzt

1. Mit einem Profil starten, das sich an nichts erinnert

   Ein privates Fenster, Erweiterungen aus, Entwicklertools geöffnet, bevor die Seite lädt, und Preserve log eingeschaltet. Enthält das Profil bereits einen Consent-Nachweis, behandelt die Seite Sie als wiederkehrenden Besucher, und der Seitenaufruf beweist überhaupt nichts.

2. Ablesen, was passiert ist, bevor Sie das Banner berühren

   Application, dann Cookies, für jede aufgeführte Domain. Network, gefiltert auf Hosts, die nicht Ihnen gehören. Notieren Sie beide Listen, bevor Sie irgendetwas akzeptieren oder ablehnen. Diese Aufzeichnung ist der Befund. Alles nach diesem Schritt ist Abgleichen, nicht Entdecken.

3. Jedem markierten Tag eines von drei Urteilen geben

   Undicht: Es hat ein Cookie geschrieben oder eine Anfrage gesendet. Wirkungslos: Es hat gefeuert und nichts davon getan. Selbstsperrend: Es hat gefeuert, den Consent-Status selbst gelesen und aufgehört. Nur das erste Urteil ist ein Leck. Die anderen beiden sollten Sie trotzdem festhalten, damit sie im nächsten Quartal niemand erneut meldet.

4. Jedes vermutete Leck bestätigen, indem Sie eins nach dem anderen pausieren

   Pausieren Sie das Tag, laden Sie das private Fenster neu und suchen Sie erneut nach demselben Cookie oder derselben Anfrage. Ist es noch da, war dieses Tag nie die Quelle, und als Nächstes sehen Sie sich den Seitenquelltext selbst an: Ein in den Head eingefügtes Snippet isolieren Sie genauso, indem Sie es entfernen und neu laden.

5. Cookies, die niemand gemeldet hat, bis zu ihrem Auslöser zurückverfolgen

   Lesen Sie für jedes Cookie und jede Anfrage auf Ihrer Liste, die kein Tag erklärt, die Spalte Initiator. Eine Anfrage, deren Initiator das Script eines anderen Anbieters ist, kam nachgelagert hinzu, steht nicht in Ihrem Container und übersteht jede Änderung, die Sie dort vornehmen.

6. Nach dem ordnen, was den Browser wirklich verlassen hat

   Eine Cross-Site-Anfrage mit einer Werbe-ID ist ein Befund einer anderen Größenordnung als ein First-Party-Cookie mit einer Session-ID. Beheben Sie in dieser Reihenfolge und schreiben Sie die Rangfolge in die Antwort, nicht die bloße Zahl elf.

Schritt eins und zwei sind die ganze Methode. Der Rest ist Buchhaltung, und zwar Buchhaltung, die die Frage beantwortet, die der Kunde tatsächlich gestellt hat: nicht wie viele Tags ungesperrt sind, sondern welche davon etwas tun.

Warum ein Container-Audit diese Liste nicht liefern kann

Zwei strukturelle Gründe, und keiner ist ein Fehler der Tools.

Ein Container kennt seine eigenen Tags und sonst nichts. Er weiß nicht, was ein Script tut, sobald es geladen ist, und er sieht nichts, was direkt in den Head der Website eingefügt wurde. Genau dort stecken meist die ältesten und am wenigsten geprüften Anbieter-Snippets. Ob sich ein bestimmtes Snippet überhaupt in den Container verschieben lässt, ist eine Entscheidung, die Sie Script für Script treffen sollten.

Ungesperrt und undicht sind zwei verschiedene Eigenschaften. Immer mehr Anbieter-Tags lesen den Consent-Mode-Status selbst und halten sich von allein zurück. Ein Tag kann also im Container ohne Bedingung stehen und sich trotzdem korrekt verhalten. Das Umgekehrte gilt auch, und es ist schlimmer: Ein Tag kann eine perfekte Bedingung haben und trotzdem Daten durchlassen, weil das, was das Cookie setzt, ihm nachgelagert ist. Jedem Script die richtige Kategorie zuzuordnen, ist eine eigene Aufgabe, und den Entscheidungstest dafür finden Sie hier.

Der Befund, der auf keiner Liste stehen wird

Bei diesem Audit wurde das entscheidende Cookie von einem Drittanbieter-Pixel gesetzt, auf das kein Tag im Container verweist. Das Script eines anderen Anbieters hatte es nach dem Laden angefordert. Diese Kette kann ein Container-Export nicht zeigen, und ein Scanner, der die Tag-Konfiguration liest, meldet sie nicht.

Die Spalte Initiator im Network-Panel bringt es ans Licht. Verfolgen Sie die Anfrage zurück zu dem Script, das sie ausgelöst hat, und Sie landen meist bei einem Tool, das vor Jahren für etwas ganz anderes freigegeben wurde. Tags zu pausieren bringt hier nichts, weil das Tag nie die Quelle war. Der Mechanismus hinter diesem Muster lohnt die vollständige Lektüre, denn wer ihn einmal gesehen hat, prüft jedes Mal darauf.

Was Sie zurückschicken

Antworten Sie mit Urteilen statt mit einer Zahl. Sechs undicht, sortiert nach dem, was den Browser verlassen hat. Fünf ungesperrt und wirkungslos, mit dem Beleg dafür. Ein Leck, das nicht auf Ihrer Liste stand, samt dem Script, das es geladen hat. Diese Antwort ist kürzer als die ursprüngliche Liste, und mit ihr kann man arbeiten.

Strenge lohnt sich hier, weil beide Fehler echtes Geld kosten, nur in entgegengesetzte Richtungen. Wer ein Tag sperrt, das nie etwas durchgelassen hat, verliert Messdaten für nichts. Wer ein Tag übersieht, das Daten durchlässt, lässt die Beschwerde unbeantwortet. Und der rechtliche Maßstab ist, was die Seite getan hat, nicht was der Container sagt: Die Leitlinien des EDSA zum technischen Anwendungsbereich von Art. 5 Abs. 3 behandeln Tracking-Pixel ebenso wie Cookies als erfasst. Deshalb zählt die Liste der Anfragen genauso viel wie die Liste der Cookies.

Wiederholen Sie nach jeder Korrektur denselben sauberen Seitenaufruf, denn nur er beweist, dass die Korrektur greift. Den vollständigen Ablauf vor dem Livegang finden Sie hier, es ist dieselbe Disziplin, nur früher angewendet. Velo blockiert nach Kategorie, bevor ein Tag laufen kann, und protokolliert im selben Moment, was erlaubt wurde. Das verkürzt diese Übung erheblich. Überflüssig macht es sie nicht: Die Scripts, die Ihre Anbieter nachladen, müssen Sie weiterhin selbst finden.