Wo die Einwilligung speichern: Cookies, localStorage und serverseitige Aufzeichnungen im Vergleich
Zwei verschiedene Aufgaben
Trifft ein Besucher eine Einwilligungsentscheidung, müssen zwei getrennte Dinge geschehen. Erstens muss der Browser sich die Entscheidung merken, damit das Banner nicht auf jeder Seite wieder erscheint und Tags wissen, was sie dürfen. Zweitens müssen Sie später womöglich belegen, dass die Entscheidung getroffen wurde, was dem Besucher gezeigt wurde und wann. Diese Aufgaben werden oft von unterschiedlichen Speichermechanismen erledigt, und sie zu verwechseln verursacht echte Probleme: Banner, die immer wieder erscheinen, Entscheidungen, die in manchen Browsern verschwinden, oder kein Nachweis, wenn jemand danach fragt.
Dieser Vergleich betrachtet die drei gängigen Optionen — First-Party-Cookies, Browser-Speicher wie localStorage und serverseitige Einwilligungsaufzeichnungen — und wo jede passt.
Option 1: First-Party-Cookies
Cookies sind die traditionelle Heimat des Einwilligungsstatus. TCF-CMPs speichern den Consent-String üblicherweise in einem First-Party-Cookie, und viele CMPs legen auch ihre eigenen Präferenzdaten in einem ab.
Stärken
- Für den Server lesbar. Das Cookie wird mit jeder Anfrage gesendet, sodass serverseitiger Code, Edge-Logik und serverseitiges Tagging die Entscheidung lesen können, ohne auf JavaScript zu warten.
- Über Subdomains teilbar. Ein auf Ihrer registrierbaren Domain gesetztes Cookie kann die Subdomains www, blog und shop abdecken.
- Weithin erwartet. Viele Ad-Tech-Integrationen suchen die Einwilligung in Cookies.
Schwächen
- Größenbeschränkungen. Browser begrenzen die Cookie-Größe auf etwa 4 KB, und ein TCF-String mit vielen Vendors plus anderen Werten kann sich dem nähern.
- Request-Overhead. Jede Anfrage an Ihre Domain trägt das Cookie, auch Bild- und Skriptanfragen.
- Laufzeitgrenzen in manchen Browsern. Die Intelligent Tracking Prevention von Safari begrenzt per JavaScript erzeugte Cookies auf eine maximale Lebensdauer von sieben Tagen. Von Ihrem eigenen Server in einer HTTP-Antwort gesetzte Cookies werden im Allgemeinen großzügiger behandelt, wobei es Ausnahmen gibt.
Option 2: localStorage und anderer Browser-Speicher
Manche CMPs speichern detaillierte Präferenzen in localStorage, manchmal neben einem kleineren Cookie.
Stärken
- Mehr Platz. Mehrere Megabyte pro Origin, genug für detaillierte Entscheidungen auf Vendor-Ebene.
- Kein Request-Overhead. Nichts wird automatisch an den Server gesendet.
Schwächen
- Für den Server unsichtbar. Serverseitiger Code und Edge-Logik können ihn nicht lesen, sodass jede serverseitige Entscheidung auf den Browser warten muss.
- An eine Origin gebunden. Speicher auf www.example.com ist auf shop.example.com nicht verfügbar, sodass ein Besucher das Banner auf jeder Subdomain erneut sehen kann.
- Löschung möglich. Safari kann per Skript beschreibbaren Speicher, einschließlich localStorage, für Websites entfernen, mit denen der Nutzer sieben Tage Browsernutzung lang nicht interagiert hat, und private Browsing-Modi leeren ihn typischerweise am Ende der Sitzung.
Option 3: Serverseitige Einwilligungsaufzeichnungen
Eine serverseitige Aufzeichnung ist ein Eintrag, den Sie oder Ihr CMP-Anbieter bei jeder Entscheidung speichern. Er enthält üblicherweise eine pseudonyme Kennung, den Zeitstempel, die Entscheidungen, die gezeigte Banner- oder Richtlinienversion und Kontext wie die Region.
Stärken
- Dauerhafter Nachweis. Sie übersteht das Löschen von Cookies und Browser-Beschränkungen, was sie zum richtigen Werkzeug macht, um zu zeigen, dass die Einwilligung eingeholt wurde.
- Prüfbar. Sie können über Entscheidungen im Zeitverlauf berichten und Fragen zu bestimmten Vorgängen beantworten.
- Potenzial geräteübergreifend. Bei angemeldeten Lesern kann eine serverseitige Aufzeichnung Entscheidungen zwischen Geräten synchronisieren, wenn Sie ihnen das erklären.
Schwächen
- Kein Ersatz für den lokalen Status. Tags im Browser brauchen weiterhin ein schnelles, lokales Signal; bei jedem Seitenaufruf einen Server zur Abfrage der Einwilligung anzurufen erhöht die Latenz.
- Sie sind selbst personenbezogene Daten. Aufzeichnungen brauchen eine Aufbewahrungsfrist, Zugriffskontrollen und einen Platz in Ihrer Datenschutzerklärung.
- Abhängigkeit von einer Kennung. Anonyme Besucher lassen sich nur über eine auf ihrem Gerät gespeicherte Kennung einer Aufzeichnung zuordnen, womit man wieder beim lokalen Speicher landet.
Gegenüberstellung im Überblick
- Am besten, um die Entscheidung im Web zu merken: First-Party-Cookies, idealerweise vom Server gesetzt, für eine stabile Laufzeit.
- Am besten für detaillierte Präferenzdaten im Browser: localStorage, gepaart mit einem Cookie, das der Server lesen kann.
- Am besten, um die Entscheidung zu belegen: serverseitige Aufzeichnungen.
- Schlechteste Einzelwahl: sich nur auf localStorage zu verlassen, was den Server blind lässt und die Entscheidung in manchen Browsern fragil macht.
Ein praktischer kombinierter Ansatz
- Speichern Sie das maßgebliche lokale Signal — zum Beispiel den TCF-String und einen kompakten Präferenzdatensatz — in einem First-Party-Cookie, das auf Ihre registrierbare Domain begrenzt ist.
- Nutzen Sie localStorage nur für ergänzende Daten, die den Server nicht erreichen müssen.
- Schreiben Sie für jede Entscheidung eine serverseitige Aufzeichnung, einschließlich der Version des gezeigten Banners und der Richtlinie.
- Verschwindet eine gespeicherte Entscheidung, zeigen Sie das Banner erneut, statt eine frühere Antwort anzunehmen.
- Legen Sie einen Zeitraum für die erneute Abfrage gespeicherter Entscheidungen fest und halten Sie ihn in Ihrer Richtlinie fest.
Das Speichern der Einwilligungsentscheidung des Besuchers selbst gilt im Allgemeinen als notwendig, um den vom Besucher gewünschten Dienst zu erbringen — sich seine Entscheidung zu merken —, prüfen Sie aber die in Ihren Hauptmärkten geltenden Leitlinien.
Wichtigste Erkenntnisse
- Eine Entscheidung zu merken und sie zu belegen sind verschiedene Aufgaben, die unterschiedlichen Speicher brauchen.
- Cookies sind für den Server lesbar und über Subdomains teilbar, aber in der Größe und, wenn per Skript gesetzt, in Safari in der Laufzeit begrenzt.
- localStorage bietet Platz, ist aber für den Server unsichtbar und kann von Browsern gelöscht werden.
- Serverseitige Aufzeichnungen sind die Nachweisebene, kein Ersatz für ein lokales Signal.
- Kombinieren Sie ein vom Server gesetztes First-Party-Cookie, optionalen Browser-Speicher und serverseitige Aufzeichnungen.