Was passiert, wenn jemand seine Cookie-Einwilligung widerruft?

Alle Beiträge

Die Erhebung stoppt für die widerrufenen Kategorien, und die Cookies auf dem Gerät bleiben meist, wo sie sind. Drei Dinge sollten folgen. Der Nachweis erhält ein Widerrufsereignis, statt die ursprüngliche Einwilligung zu verlieren. Jedes Tool, das ein Ablehnungssignal annimmt, bekommt eines. Und jedes Tool setzt die Identität zurück, bevor die Erfassung abgeschaltet wird.

Die übliche Antwort dreht sich um Cookie-Dateien

Wer diese Frage sucht, bekommt eine engere beantwortet: Löscht ein Widerruf die Cookies, die schon auf dem Gerät liegen? Die Antwort lautet nein, und die Begründung ist richtig. Ein Skript kann nur Cookies auf seiner eigenen Domain anfassen, also kommt nichts auf Ihrer Website an ein Cookie heran, das ein anderes Unternehmen auf seiner Domain gesetzt hat. Das ist eine Sicherheitsregel des Browsers, keine Lücke in Ihrem Consent-Tool. First-Party-Cookies wie _ga sind die Ausnahme: Sie liegen auf Ihrer eigenen Domain, also kann Ihre Website sie löschen. Eine Consent-Management-Plattform blockiert stattdessen die Skripte, die diese Cookies lesen und schreiben.

Diese Antwort stimmt, und sie ist der kleinste Teil des Übergangs. Eine Datei hinterher zu löschen, schützt wenig. Entscheidend ist der Moment, in dem Daten fließen, also wenn ein Cookie gesetzt und wenn es gelesen wird. Blockieren stoppt beides. Dateien zu löschen nicht.

Eine echte Ausnahme gibt es. Ist ads_data_redaction aktiviert und ad_storage abgelehnt, schwärzt Google die Klick-IDs in den Pings, die weiterhin gesendet werden, so steht es in Google's Consent-Mode-Leitfaden. Das ist der einzige Hebel im ganzen Stack, der etwas aus dem Gesendeten entfernt, und es ist eine Google-Einstellung, nichts, was Ihr Banner tut.

Was fast niemand aufschreibt: was Ihr Mess-Stack in diesem Moment tun sollte. Genau dort geht der Widerruf schief, und zwar leise. Das Banner schließt sich und sieht gut aus.

Was in welcher Reihenfolge passieren sollte

Ein Widerruf ist eine Abfolge, und die Reihenfolge zählt mehr als jeder einzelne Aufruf.

1. Den Widerruf als neues Ereignis erfassen, nicht als Änderung

   Ein Widerruf korrigiert die ursprüngliche Einwilligung nicht. Er ist eine zweite Tatsache: Dieser Besucher hat zu einem Zeitpunkt eingewilligt und zu einem anderen widerrufen, und beides stimmt. Speichern Sie ihn als neue Zeile, die auf die abgelöste Einwilligung verweist, in einer Tabelle, die sich weder ändern noch löschen lässt. Nach Art. 7 Abs. 3 DSGVO berührt ein Widerruf die Rechtmäßigkeit der bis dahin erfolgten Verarbeitung nicht, und die ursprüngliche Einwilligung ist Ihr Nachweis dafür. Überschreiben Sie sie, haben Sie den einzigen Beleg vernichtet, dass die frühere Erhebung rechtmäßig war. Velo schreibt einen Widerruf als neues Ereignis mit Verweis auf das vorherige und bewahrt ihn unbefristet auf, auch dort, wo normale Einwilligungsdatensätze irgendwann auslaufen.

2. Ein Ablehnungssignal senden, nicht verstummen

   Der erste Impuls ist, alles am Feuern zu hindern. Mit Consent Mode ist das falsch. Das Tag sollte bleiben und ein Update erhalten, das analytics_storage und die drei Werbesignale auf denied setzt. Dann sendet es einen cookielosen Ping ohne Kennungen, und dieser Ping hält Modellierung und Basis-Reporting am Leben. Entfernen Sie das Tag ganz, wird nichts gesendet, und nichts ist nicht dasselbe wie eine erfasste Ablehnung. Das eine ist ein Besucher, der Nein gesagt hat. Das andere ist ein Besucher, den es nicht gibt.

3. Sprechen Sie jedes Tool in seinem Dialekt an

   Es gibt nicht die eine Consent-API. Die Tags von Google lesen einen gtag('consent', 'update', …)-Aufruf, Microsoft einen Push an uetq, Meta einen fbq-Aufruf. Dazu kommt: Die Trigger in Google Tag Manager sehen kein CustomEvent des Browsers. Ein Widerruf, der nur ein solches Event auslöst, lässt also jeden Trigger für benutzerdefinierte Ereignisse stumm. Schieben Sie deshalb zusätzlich ein benanntes Event in den Data Layer. Unser eigenes SDK leitet jeden Weg, der die Einwilligung ändert, durch eine einzige Funktion, die alle vier Signale ausgibt: einen Klick im Banner, eine gespeicherte Entscheidung, die erneut angewendet wird, ein Global-Privacy-Control-Signal, das Kategorien abschaltet. Ein Widerruf kann das System also nicht auf einem anderen Weg verlassen als eine Einwilligung.

4. Erst die Identität zurücksetzen, dann die Erfassung stoppen, nie umgekehrt

   Die meisten Analytics-Bibliotheken bieten zwei Aufrufe: Einer vergisst, wer der Besucher ist, einer schaltet die Erfassung ab. Fast alle denken sie in dieser Reihenfolge, erst nicht mehr erfassen, dann vergessen, und fast alle bauen damit einen Bug. In vielen Bibliotheken teilen sich Consent-Flag und Identität denselben Speicher, also löscht der Reset das Opt-out, das Sie gerade gesetzt haben. Erst zurücksetzen, die Erfassung zuletzt abschalten.

5. Die Sperre erneut anwenden, dann die Seite neu laden

   Blockieren wirkt nur auf das, was noch nicht gelaufen ist. Ein bereits geladenes Skript liegt weiter im Speicher, hat eigene Timer und kann sein Cookie bei der nächsten Interaktion erneut schreiben, egal was Ihr Banner jetzt sagt. Die Sperre erneut anzuwenden, stoppt das Nächste. Erst ein Neuladen garantiert sauber, dass nichts aus dem vorherigen Einwilligungsstatus mehr läuft. Es spielt außerdem die gespeicherte Entscheidung von vorn ab, genau den Weg, den ein wiederkehrender Besucher nimmt. Diesen Fall testen Sie also gleich mit.

Welcher Schritt geht am häufigsten schief?

Schritt vier haben wir in unserem eigenen Stack gefunden, nicht bei einem Kunden. Unser Banner lehnt Analytics ab; der Ablehnungszweig rief zuerst das Opt-out auf und danach den Identitäts-Reset. Das liest sich richtig: erst nicht mehr erfassen, dann vergessen.

In den Daten entstanden zwei Personen: eine identifizierte und eine anonyme, mit derselben Gerätekennung, wenige Minuten auseinander. Die Ursache lag in der Bibliothek, nicht im Banner. In posthog-js 1.424.1 setzt der Reset-Aufruf auch den gespeicherten Einwilligungsstatus zurück. Lief er nach dem Opt-out, hob er das Opt-out wieder auf, und die Erfassung lief unter einer neuen anonymen Kennung und einer neuen Sitzung weiter. Jeder Besucher, der widerrufen hatte, wurde stillschweigend doppelt gezählt.

Die beiden Aufrufe zu tauschen, hat das Problem behoben, geprüft in einem frischen Browser und nicht im Code-Review. Zustimmen, und eine Kennung erscheint. Ablehnen, und das Opt-out-Flag steht auf true, während bei einem erzwungenen Event null Requests rausgehen. Später erneut zustimmen, und dieselbe Kennung kommt zurück, keine dritte.

Was sollte der Besucher sehen können?

Laut DSGVO muss der Widerruf einer Einwilligung so einfach sein wie ihre Erteilung. Praktisch heißt das: ein Element, das die Einstellungen von jeder Seite aus wieder öffnet, kein Link tief in einer Richtlinie. Die Entscheidung sollte auf der Seite wirken, auf der der Besucher gerade ist.

Es heißt auch: ein Beleg, auf den der Besucher später verweisen kann, derselbe Mechanismus, der beantwortet, wie Sie nachweisen, dass ein Besucher eingewilligt hat. Ein Widerruf ist ein Einwilligungsnachweis wie jeder andere.

Bleibt die Frage, wann Sie erneut fragen. Ein Widerruf ist keine Erlaubnis, beim nächsten Seitenaufruf wieder nachzuhaken. Wer ihn so behandelt, macht das Banner zum Ärgernis. Für das Timing gibt es eine eigene Antwort: wie lange eine Cookie-Einwilligung gilt und wann das Banner erneut fragen sollte.

Wie testen Sie einen Widerruf?

Fast jedes Banner wurde beim Ankommen getestet. Fast keines auf dem Weg hinaus. Deshalb überleben Widerrufsfehler monatelang, während der Zustimmungsweg tadellos läuft. Stimmen Sie zu, rufen Sie zwei Seiten auf, widerrufen Sie dann und achten Sie auf drei Dinge: was den Browser verlässt, ob das Opt-out eine Minute später noch gesetzt ist und für wie viele Personen Ihr Analytics-Tool diesen einen Browser hält.

Velo leitet jede Änderung der Einwilligung, ob Zustimmung oder Widerruf, über einen einzigen Weg: Er erfasst das Ereignis, aktualisiert Consent Mode, schiebt das Data-Layer-Event, auf das Ihr Container triggert, und ruft die Consent-API jedes Anbieters auf. Damit laufen die beiden Richtungen nicht mehr auseinander. Den Test erspart das nicht: In welcher Reihenfolge Ihre eigenen Tools ihre Aufrufe erwarten, müssen Sie weiterhin selbst richtig setzen.