Warum kommt ein Tracking-Cookie nach der Ablehnung zurück?

Alle Beiträge

Meist, weil das Skript, das ihn gesetzt hat, noch läuft. Einen Cookie zu löschen, stoppt nicht den Code, der ihn geschrieben hat: Weiß dieser Code nicht, dass die Einwilligung abgelehnt ist, schreibt er den Cookie beim nächsten Hit neu. Die anderen Ursachen sind ein Löschbefehl für die falsche Domain oder den falschen Pfad und ein Cookie, den Ihr Server setzt.

Warum taucht ein gelöschter Cookie nach einer Ablehnung wieder auf?

Ein Cookie ist eine Datei, die der Browser speichert. Das Tag, das ihn gesetzt hat, ist Code, der in der Seite läuft, und er läuft weiter, wenn das Banner geschlossen ist. Löschen Sie die Datei, ist der Code noch da und schreibt sie beim nächsten Senden wieder.

Wir haben das im November 2026 mit dem echten gtag.js von Google auf einer Testdomain nachgestellt. Bei weiterhin erteilter Analytics-Einwilligung haben wir _ga und _ga_<id> korrekt gelöscht. Beide waren weg. Das nächste Event des Tags schrieb den Session-Cookie _ga_<id> sofort wieder. Auf der Website eines Kunden, mit dem wir im selben Monat gearbeitet haben, kam ein Analytics-Cookie zurück, als die Seite in den Hintergrund ging, nicht bei einem Event. Teams halten das oft für einen Fehler des Consent-Tools. Tatsächlich stimmt die Reihenfolge nicht.

Die Lösung: Informieren Sie zuerst das Tag. Im selben Test hielt das Senden von gtag('consent', 'update', { analytics_storage: 'denied' }) mit anschließendem Löschen die Cookies fern, auch nach einem weiteren Event und einer simulierten ausgeblendeten Seite. Ein Tag, das von der Ablehnung weiß, schreibt nicht mehr; eines, das es nicht weiß, macht Ihr Löschen rückgängig.

Warum scheint das Löschen des Cookies nichts zu bewirken?

Weil der Löschbefehl zum Ziel-Cookie passen muss. Ein Browser entfernt einen Cookie nur, wenn Name, Domain und Pfad des Löschbefehls denen beim Setzen entsprechen, wie die MDN-Referenz zum Set-Cookie-Header beschreibt. Google-Tags setzen ihre Cookies auf der höchstmöglichen Domainebene, auf shop.example.com liegt der Cookie _ga also auf .example.com.

In unserem Test entfernte ein Löschbefehl als document.cookie = '_ga=; Max-Age=0; path=/', ohne Domain, überhaupt nichts. Das Skript lief ohne Fehler, der Cookie blieb. Ergänzen Sie domain=.example.com, und er ist weg. Für den Pfad gilt dasselbe: Ein Löschbefehl auf / erreicht keinen Cookie, der auf einem anderen Pfad als / gesetzt wurde.

Und Cookies, die der Server setzt?

Einen als HttpOnly markierten Cookie kann kein Skript auf der Seite lesen oder löschen. Server-side Tagging nutzt oft einen solchen, etwa den Cookie FPID, den ein Server-Container ausgeben kann. Nur der Server kann ihn ablaufen lassen, er muss also von der Ablehnung wissen und bei der nächsten Anfrage handeln. Wenn Sie einen Server-Container betreiben, prüfen Sie, ob sein Client den Einwilligungsstatus liest und den Cookie bei Ablehnung nicht mehr ausgibt. Das Einwilligungssignal an einen Server-Container übergeben behandelt diesen Teil.

Ist der Cookie wirklich zurück, oder war er nie weg?

Prüfen Sie, bevor Sie etwas ändern. Manche Cookies sollen bleiben: Ihr Einwilligungsnachweis und unbedingt erforderliche Cookies wie ein Session- oder Warenkorb-Cookie. Cookies auf der Domain eines anderen Unternehmens kann Ihre Website ohnehin nicht entfernen. Öffnen Sie dann den Speicherbereich der Entwicklertools und sehen Sie sich die Spalte „Domain“ an. Ein Cookie auf der übergeordneten Domain kann zu einer anderen Website gehören, die Sie auf derselben Domain betreiben, und dann entscheidet deren Banner. Ein Cookie mit neuem Wert wurde neu geschrieben. Einer mit altem Wert wurde nie gelöscht. Und erschien er, bevor der Besucher etwas gewählt hat, lief das Tag vor dem abgelehnten Standardwert: Das ist ein Problem der Ladereihenfolge, nicht des Löschens. Unser Beitrag zur Prüfung, ob ein Tag wirklich Cookies setzt zeigt, wie Sie diese Bereiche lesen.

Wie verhindern Sie, dass ein Cookie nach der Ablehnung zurückkommt?

1. Zuerst das Ablehnungssignal senden

   Informieren Sie jedes Tool in dem Format, auf das es hört, bevor Sie den Speicher anfassen: ein Consent-Update für Google-Tags, den entsprechenden Aufruf für jeden anderen Anbieter. Ein Tag, das von der Ablehnung weiß, schreibt nicht mehr.

2. Auf jeder Domainebene löschen

   Löschen Sie jeden Cookie auf dem aktuellen Host und auf jeder übergeordneten Domain bis zur registrierbaren, mit path=/. Ein Löschbefehl ohne Domain verfehlt stillschweigend Cookies auf der übergeordneten Domain.

3. Noch nicht gelaufene Tags zurückhalten

   Stellen Sie sicher, dass nichts, was noch laden soll, nach der Ablehnung starten und den Cookie neu schreiben kann. Das ist Aufgabe der Tag-Sperre, nicht des Löschens.

4. Server-Cookies auf dem Server ablaufen lassen

   Lassen Sie den Server bei jedem HttpOnly-Cookie den Einwilligungsstatus lesen und den Cookie bei der nächsten Anfrage ablaufen. Kein Seitenskript kann das.

5. Mit ausgeblendeter Seite und Neuladen testen

   Akzeptieren, dann ablehnen, dann ein Event senden, den Tab wechseln und neu laden. Prüfen Sie nach jedem Schritt die Cookie-Ansicht. Eine Ablehnung, die nur bis zum nächsten Hit hält, hält nicht.

Die vollständige Reihenfolge eines Widerrufs, einschließlich des Identitäts-Resets, den die meisten Bibliotheken brauchen, finden Sie unter Was passiert, wenn jemand seine Cookie-Einwilligung widerruft.

So geht Velo damit um

Lehnt ein Besucher eine Kategorie ab, die er erlaubt hatte, sendet Velo das Ablehnungssignal an jeden Anbieter, den es benachrichtigen soll, und löscht dann die bekannten First-Party-Cookies und Speicherschlüssel dieser Kategorie auf dem aktuellen Host und jeder übergeordneten Domain bis zur registrierbaren, mit path=/. HttpOnly-Cookies und Cookies auf einem anderen Pfad erreicht es nicht, und seinen eigenen Einwilligungsnachweis lässt es unberührt, denn dieser belegt, dass die Ablehnung stattgefunden hat.