Cookie-Banner vor dem Livegang testen

Alle Beiträge

Testen Sie ein Cookie-Banner vor dem Livegang auf einer Staging-URL, in einem privaten Fenster, in dieser Reihenfolge: Erscheint es? Hält es nicht notwendige Cookies bis zur Entscheidung zurück? Entspricht das Consent-Signal in der ausgehenden Anfrage der Entscheidung? Wird die Entscheidung protokolliert? Und übersteht das alles einen erneuten Besuch und einen Widerruf? An den letzten drei Punkten scheitern Setups meistens.

Fast jeder veröffentlichte Test ist ein Audit nach dem Launch

Wer danach sucht, wie man ein Cookie-Banner testet, bekommt Anleitungen, die eigentlich Audits sind: Website öffnen, Entwicklertools öffnen, auf Ablehnen klicken, schauen, ob die Tracker aufhören. Das ist ein sinnvolles Audit, und wir würden es auch durchführen. Die heute gut rankenden Anleitungen sind aber für ein Banner geschrieben, das bereits live ist. Sie beantworten damit eine andere Frage als die im Titel oben.

Der Unterschied zählt, weil die beiden Tests unterschiedlich viel kosten, wenn sie scheitern. Ein Live-Banner, das sich als fehlerhaft herausstellt, hat Daten gesammelt, die es nicht hätte sammeln dürfen, oder Daten verpasst, die es hätte erfassen sollen, und zwar so lange, bis es jemandem auffiel. Ein fehlerhaftes Banner auf Staging hat einen Nachmittag gekostet.

Was sollten Sie prüfen, bevor ein Cookie-Banner live geht?

1. Auf Staging testen, nicht auf der Live-Website

   Die Produktion ist keine Testumgebung. Stellen Sie das Banner auf eine Staging-URL und registrieren Sie diese Domain beim Consent-Tool, damit es dort ein echtes Banner ausliefert, statt das Laden zu verweigern. Die meisten Consent-Tools haben dafür einen Staging- oder Entwurfsmodus.

2. Privates Fenster öffnen und prüfen, ob das Banner überhaupt erscheint

   Nur ein sauberes privates Fenster liefert einen ehrlichen ersten Blick, denn Ihr eigener Browser trägt eine früher getroffene Entscheidung mit sich, und ein beantwortetes Banner kommt nicht wieder. Prüfen Sie, ob das Banner beim ersten Laden erscheint, ob die Ablehnen-Option ohne Scrollen sichtbar ist und ob Ablehnen nicht schwerer ist als Zustimmen.

3. Alles ablehnen und beobachten, was die Seite sendet

   Öffnen Sie das Network-Panel und den Speicherbereich der Entwicklertools, bevor Sie das Banner berühren. Es sollte noch kein nicht notwendiges Cookie geschrieben sein und kein Drittanbieter-Tag wie Meta oder Hotjar laden. Google-Anfragen hängen von Ihrem Consent-Mode-Setup ab, dazu mehr im nächsten Abschnitt. Lehnen Sie dann alles ab und laden Sie neu, auch auf einer Produktseite und im Checkout, denn Tags werden oft pro Template von verschiedenen Leuten eingebaut.

4. Das Consent-Signal in der ausgehenden Anfrage lesen, nicht im Banner

   Diese Prüfung trennt ein Banner von einem echten Consent-Setup, und genau sie fehlt in den veröffentlichten Checklisten. Wo Consent Mode umgesetzt ist, tragen Google-Tags den Consent-Status in der Anfrage selbst: Lehnen Sie ab, lesen Sie dann diesen Status aus und prüfen Sie, ob er „denied“ lautet. Fehlt der Consent-Status ganz, ist das ein eigener Befund und ein anderer Fehler. Dann läuft Consent Mode nicht, und nicht das Banner hat versagt.

5. Prüfen, ob die Entscheidung festgehalten wurde

   Eine Einwilligung, die Sie später nicht vorlegen können, nützt bei einer Prüfung wenig. Prüfen Sie, ob eine Antwort auf das Banner einen gespeicherten, abrufbaren Nachweis erzeugt, der festhält, welche Kategorien wann akzeptiert wurden. Was er sonst enthält, unterscheidet sich je nach Anbieter. Fragen Sie vor allem nach der Version des angezeigten Hinweises, denn ohne sie können Sie nicht sagen, wozu der Besucher zugestimmt hat.

6. Als wiederkehrender Besucher, nach einem Widerruf und aus einer zweiten Region wiederholen

   Alle drei gehen regelmäßig fehlerhaft live. Laden Sie die Seite als Besucher neu, der schon geantwortet hat, und prüfen Sie, ob die gespeicherte Entscheidung weiter angewendet wird. Widerrufen Sie die Einwilligung und prüfen Sie, ob Drittanbieter-Tags stoppen und Google-Tags auf „denied“ zurückgehen. Prüfen Sie dann eine Region, in der Ihre Regeln abweichen.

Ist eine Google-Anfrage vor der Einwilligung ein Fehler?

Nicht immer. Hier werden zwei verschiedene Tests verwechselt. Keine nicht notwendigen Cookies vor der Einwilligung ist ein Speichertest: Bis der Besucher zustimmt, wird nichts über das unbedingt Notwendige hinaus im Browser gespeichert oder daraus gelesen. Keine Analytics-Anfragen vor der Einwilligung ist ein strengerer Netzwerktest, und er gilt nur im einfachen Consent Mode oder für Tags, die Sie komplett blockieren.

Im erweiterten Consent Mode laden Google-Tags mit allen Signalen auf „denied“ und senden cookielose Pings. Laut Google-Dokumentation ist das erwartetes Verhalten. In diesem Setup besteht eine /g/collect-Anfrage vor der Einwilligung, wenn sie gcs=G100 enthält und kein Cookie setzt. Eine Anfrage von Meta oder Hotjar an derselben Stelle fällt durch.

Welcher Test gilt, ist eine rechtliche ebenso wie eine technische Entscheidung. In seinen Leitlinien zu Art. 5 Abs. 3 der ePrivacy-Richtlinie legt der EDSA die Vorschrift so aus, dass sie mehr als Cookies erfasst, und manche Teams wählen auf rechtlichen Rat hin den einfachen Modus. Entscheiden Sie, welches Setup Sie betreiben, und testen Sie dann genau dieses.

Wie ein echtes Bestehen aussieht

Vier dieser Prüfungen gibt es in einer bequemen und einer ehrlichen Version, und die meisten Testanleitungen geben sich mit der bequemen zufrieden. In der Lücke zwischen den beiden Spalten stellen sich Setups, die alle abgenommen haben, Monate später als falsch heraus.

Bei der dritten Zeile lohnt es sich, länger hinzusehen. Meldet ein Consent-Tool, dass es eine Entscheidung angewendet hat, meldet es seinen eigenen internen Zustand, und das ist etwas anderes als das, was Ihre Tags empfangen haben. Entschieden wird die Frage an der Anfrage, die den Browser verlässt. Deshalb ist es ein eigener Schritt, das Consent-Mode-v2-Signal zu prüfen, und kein Detail des Ablehnungstests.

Welche drei Zustände testet niemand?

Erste Besuche werden getestet, weil sie sich leicht nachstellen lassen. Fehlerhaft live gehen die Zustände, die etwas Vorbereitung brauchen.

Der erneute Besuch. Eine gespeicherte Entscheidung muss beim nächsten Besuch wieder ausgelesen und angewendet werden, und dieser Weg läuft über anderen Code als der, der sie gespeichert hat. Schlägt er fehl, sieht der Besucher das Banner bei jedem Seitenaufruf erneut. Oder schlimmer: Das Banner bleibt weg, die gespeicherte Entscheidung wird stillschweigend ignoriert, und die Tags laufen mit einem Standardwert, den niemand gewählt hat.

Der Widerruf. Art. 7 DSGVO verlangt, dass der Widerruf der Einwilligung so einfach ist wie ihre Erteilung. Spannend ist, was danach passiert: Drittanbieter-Tags, die erlaubt waren, müssen stoppen, und Google-Tags müssen auf einen „denied“-Status zurückfallen. Ein Widerruf kann den gespeicherten Nachweis aktualisieren und bereits geladene Tags bis zum nächsten Seitenaufruf weiterlaufen lassen. Das sollten Sie vor dem Launch wissen, nicht erst nach einer Beschwerde.

Die zweite Region. Regelsets werden für den Markt konfiguriert, an den jemand an diesem Tag gedacht hat. Ein Setup, das in einem Land ein korrektes Banner zeigt, kann in einem anderen gar nichts zeigen. Wer testet, sitzt meist im ersten Land, und deshalb fällt es niemandem auf.

Belege aufbewahren

Halten Sie fest, was Sie gesehen haben, denn der Wert des Tests sinkt, sobald sich die Website wieder ändert. Bewahren Sie die ausgehende Anfrage mit „denied“-Status auf, den gespeicherten Consent-Nachweis und eine Notiz, welche Seitentemplates Sie geprüft haben. Das ist der Unterschied zwischen „das Banner wurde getestet“ und „wir können es zeigen“, dieselbe Unterscheidung wie in unserem Beitrag dazu, wie Sie tatsächlich nachweisen, dass ein Besucher eingewilligt hat.

Man sollte ehrlich sagen, was der Test schützt. Consent-Entscheidungen verbergen einen Teil der Sitzungen vor Analytics, und dieser Anteil schwankt je nach Region, Zielgruppe und Banner-Design. Die Zustimmungsrate Ihres Consent-Tools zeigt Ihnen Ihren Wert. Ein Banner, das auf eine der oben beschriebenen Arten falsch ist, ist nicht nur ein Compliance-Risiko: Es verändert stillschweigend, was jeder nachgelagerte Bericht zählt, ohne Fehlermeldung.

Velo ist so gebaut, dass der Großteil dieser Liste schon beim ersten Laden stimmt: Der Consent-Status wird über ein einziges Snippet gesetzt, bevor Ihre Tags initialisiert werden, die Entscheidung wird mit ihren Kategorien und der Version des Hinweises protokolliert, und ein erneuter Besuch verhält sich wie der erste. Wie das funktioniert, steht auf der Produktseite.