80% of Cookie Reject Buttons Don't Actually Work — Here's the Proof

Jedes Cookie-Banner macht dasselbe implizite Versprechen: Klicken Sie auf „Ablehnen" und das Tracking stoppt. Das Banner verschwindet und Sie surfen ungestört. Das ist der Handel, auf dem das Einwilligungsmodell basiert – die Idee, dass Nutzer eine sinnvolle, durchsetzbare Wahlmöglichkeit haben.

Wir haben dieses Versprechen auf 28.891 EU-Websites getestet. Auf 80,4 % von ihnen ist das Versprechen gebrochen. Das Tracking wird fortgesetzt, nachdem der Nutzer ausdrücklich auf Ablehnen geklickt hat. Cookies bleiben bestehen. Werbepixel werden weiterhin ausgelöst. Und auf 1.642 Websites kommen Cookies, die durch die Ablehnungsaktion zunächst gelöscht werden, beim nächsten Laden der Seite zurück – ein Muster, das wir Consent-Respawn nennen.

Dies ist kein marginaler Befund über ein paar falsch konfigurierte Websites. Es deutet auf ein systemisches Problem im Mechanismus hin, auf den sich Hunderte Millionen EU-Bürger für ihre Datenschutzrechte verlassen.

Was „Ablehnen" bewirken soll – rechtlich

Der rechtliche Rahmen ist klar. Gemäß Artikel 5(3) der ePrivacy-Richtlinie erfordert die Speicherung oder der Zugriff auf Informationen auf dem Endgerät eines Nutzers eine vorherige Einwilligung, mit einer engen Ausnahme für Cookies, die für einen vom Nutzer ausdrücklich angeforderten Dienst unbedingt erforderlich sind. DSGVO Artikel 7(3) ergänzt, dass der Widerruf der Einwilligung genauso einfach sein muss wie ihre Erteilung und der Verantwortliche auf diesen Widerruf reagieren muss.

Die EDPB-Leitlinien 05/2020 zur Einwilligung unter der DSGVO buchstabieren aus, was dies für Ablehnungsschaltflächen bedeutet: Wenn eine Website eine „Alle akzeptieren"-Option anbietet, muss sie auch eine gleichermaßen prominente und gleichermaßen zugängliche Option zur Ablehnung bieten. Und diese Ablehnung muss wirksam sein – sie muss die Verarbeitung tatsächlich verhindern, die durch die Einwilligung autorisiert worden wäre.

Der CJEU hat dies in Planet49 (C-673/17) bekräftigt: Einwilligung erfordert eine eindeutige bejahende Handlung, und vorangekreuzte Kontrollkästchen stellen keine gültige Einwilligung dar. Die logische Folgerung ist, dass eine Ablehnung – eine ausdrückliche ablehnende Handlung – ebenso definitiv respektiert werden muss wie eine Annahme. Wenn das Klicken auf „Akzeptieren" das Tracking einschaltet, muss das Klicken auf „Ablehnen" es ausschalten. Nicht teilweise. Nicht vorübergehend. Vollständig und dauerhaft.

Das sagt das Gesetz. Unsere Daten zeigen, was tatsächlich passiert.

Wie wir den Ablehnungsfluss testen

Unser Ablehnungsfluss-Test ist so konzipiert, dass er der Erfahrung eines echten menschlichen Nutzers, der auf Ablehnen klickt, so nahe wie möglich kommt, ergänzt durch umfassende Instrumentierung. Hier ist der Prozess Schritt für Schritt:

Schritt 1: Frische Browser-Sitzung. Der Scanner startet eine saubere Chromium-Instanz – keine Cookies, kein lokaler Speicher, keine zwischengespeicherten Ressourcen, kein Browserverlauf. Dies ist ein echter Erstbesucher ohne vorherigen Einwilligungsstatus. Schritt 2: Navigation und Aufzeichnung des Pre-Consent-Zustands. Der Scanner lädt die Ziel-URL und wartet, bis die Seite stabil ist. Vor jeder Interaktion zeichnet er jedes im Browser vorhandene Cookie, jede getätigte Netzwerkanfrage und jede kontaktierte Drittanbieter-Domain auf. Dies ist die Pre-Consent-Basislinie – was die Website tut, bevor der Nutzer überhaupt eine Entscheidung treffen kann. Schritt 3: Erkennung des Einwilligungsbanners. Mithilfe unserer Erkennungsbibliothek, die 45 bekannte CMPs und generische Heuristiken abdeckt, identifiziert der Scanner den Einwilligungsmechanismus und lokalisiert die Ablehnungsschaltfläche. Dieser Schritt verwendet einen mehrschichtigen Ansatz: Zunächst werden bekannte CMP-Skript-Signaturen und deren zugehörige DOM-Strukturen geprüft, dann folgt eine generische Erkennung von fest positionierten Elementen mit einwilligungsbezogenem Text und Schaltflächenbeschriftungen wie „Alle ablehnen", „Ablehnen", „Verweigern" oder entsprechende Übersetzungen. Schritt 4: Klick auf Ablehnen. Der Scanner klickt auf die Ablehnungsschaltfläche und wartet, bis die Seite sich beruhigt. „Beruhigt" bedeutet, dass ausstehende Netzwerkanfragen abgeschlossen, DOM-Mutationen gestoppt und Animationen oder Übergänge beendet sind. Wir verwenden großzügige Timeouts, um Fehlalarme durch langsame CMP-Implementierungen zu vermeiden. Schritt 5: Post-Reject-Snapshot. Der Scanner zeichnet den vollständigen Zustand erneut auf: alle Cookies, alle Netzwerkaktivitäten, alle Drittanbieter-Domains. Dieser Snapshot wird mit der Pre-Consent-Basislinie verglichen, um festzustellen, was sich geändert hat. Schritt 6: Neuladen und Prüfung auf Respawn. Der Scanner lädt die Seite neu und wartet erneut auf Stabilisierung. Dann erstellt er einen letzten Snapshot. Dieser Schritt ist entscheidend: Er zeigt, ob die Ablehnungsaktion dauerhaft ist (über Seitenladevorgänge hinweg respektiert wird) oder ob Cookies und Tracking beim frischen Laden der Seite wieder aktiviert werden. Wenn Cookies, die in Schritt 5 entfernt wurden, in Schritt 6 wieder erscheinen, handelt es sich um Consent-Respawn.

Jeder Schritt erzeugt zeitgestempelte, archivierbare Nachweise: vollständige Cookie-Inventare mit Namen, Werten, Domains, Ablaufdaten und Flags; vollständige Netzwerkanfrage-Protokolle mit URLs, Methoden, Antwortcodes und Timing; sowie ganzseitige Screenshots. Diese Beweiskette ermöglicht es, jeden einzelnen Befund zu überprüfen und anzufechten.

Die Ergebnisse: 80,4 % Versagen

Von den 28.891 Websites, bei denen wir den vollständigen Ablehnungsfluss-Test erfolgreich abgeschlossen haben:

• 5.650 (19,6 %) haben bestanden. Nach dem Klick auf Ablehnen wurden nicht-essentielle Cookies entfernt, Tracking-Anfragen gestoppt, und die Ablehnung blieb über Seitenladevorgänge hinweg bestehen.
• 23.241 (80,4 %) sind gescheitert. Das Tracking wurde in irgendeiner Form fortgesetzt, nachdem der Nutzer ausdrücklich auf Ablehnen geklickt hatte.

Die Fehler sind nicht einheitlich. Sie fallen in unterschiedliche Kategorien, die sich überlappen – eine einzelne Website kann gleichzeitig mehrere Fehlermodi aufweisen.

Persistierende Cookies: 10.848 Websites

Auf 10.848 Websites (37,5 % der getesteten) verblieben nicht-essentielle Cookies im Browser, nachdem der Ablehnungsfluss abgeschlossen war. Dies sind Cookies, die als Analytics-, Marketing- oder Tracking-bezogen klassifiziert werden und nach einer Ablehnungsaktion hätten entfernt oder am Setzen gehindert werden sollen.

Die häufigsten persistierenden Cookies gehören zu Google Analytics (`_ga`, `_gid`, `_gat`), Meta/Facebook (`_fbp`, `fr`) und verschiedenen Werbeplattformen. In vielen Fällen entfernt das CMP einige Cookies erfolgreich, versäumt es aber, alle zu erfassen – was auf eine unvollständige Integration zwischen der Consent-Management-Plattform und dem vollständigen Repertoire an Drittanbieter-Skripten der Website hindeutet.

Das Vorhandensein dieser Cookies nach der Ablehnung ist nicht nur ein ästhetisches Problem. Jedes einzelne ist ein persistenter Identifikator, der die aktuelle Sitzung des Nutzers mit vergangenen und zukünftigen Besuchen verknüpft. Das `_ga`-Cookie beispielsweise ist eine eindeutige Client-Kennung, die Google Analytics verwendet, um ein longitudinales Profil des Nutzerverhaltens über Sitzungen hinweg aufzubauen. Wenn es nach der Ablehnung bestehen bleibt, wird das Browsing des Nutzers ungeachtet seiner ausdrücklichen Verweigerung weiterhin getrackt und aggregiert.

Persistierende Tracker: 14.547 Websites

Auf 14.547 Websites (50,3 % der getesteten) blieben Tracking-Dienste nach der Ablehnung aktiv – das bedeutet, der Browser stellte weiterhin Anfragen an bekannte Tracking-Domains, selbst nachdem der Nutzer auf die Ablehnungsschaltfläche geklickt hatte.

Dies ist ein anderer Fehlermodus als Cookie-Persistenz. Ein Tracker kann aktiv sein, ohne ein Cookie zu setzen: Pixel-Anfragen, Beacon-Aufrufe und Skript-Ladevorgänge übermitteln alle Informationen (mindestens die IP-Adresse des Nutzers, die verweisende Seite und Zeitdaten) an Drittanbieter-Server, unabhängig davon, ob ein Cookie gespeichert wird. Dies wird manchmal als „Cookieless Tracking" bezeichnet und ist zunehmend verbreitet, da Browser die Einschränkungen für Drittanbieter-Cookies verschärfen.

Die Lücke zwischen der Cookie-Zahl (10.848) und der Tracker-Zahl (14.547) ist signifikant. Sie bedeutet, dass auf etwa 3.700 Websites die Ablehnungsaktion Cookies erfolgreich gelöscht hat, aber die Tracking-Anfragen nicht unterbinden konnte. Das CMP übernahm die Cookie-Bereinigung, blockierte aber nicht die Skripte, die den Tracking-Verkehr überhaupt erst erzeugen. Dies deutet auf ein häufiges architektonisches Problem hin: Das CMP ist so konfiguriert, dass es Cookies verwaltet (sie bei Ablehnung löscht, sie beim Laden verhindert), aber nicht die Skriptausführung steuert.

Consent-Respawn: 1.642 Websites, 4.932 Cookies

Consent-Respawn ist das beunruhigendste Muster, das wir identifiziert haben. Auf 1.642 Websites erschienen Cookies, die durch die Ablehnungsaktion erfolgreich entfernt worden waren, nach dem Neuladen der Seite wieder. Auf diesen Websites zeigten 4.932 einzelne Cookies dieses Respawn-Verhalten.

Consent-Respawn ist kein Bug in einem CMP oder einer Konfiguration. Es ist ein strukturelles Problem in der Art und Weise, wie Einwilligung über den gesamten Web-Stack implementiert wird.

Wie ein Cookie nach dem Löschen zurückkehrt. Wenn ein Nutzer auf Ablehnen klickt, macht ein korrekt konfiguriertes CMP zwei Dinge: Es löscht bestehende nicht-essentielle Cookies (indem es deren Ablaufdatum in die Vergangenheit setzt) und aktualisiert einen Einwilligungsdatensatz (normalerweise ein Cookie selbst oder ein localStorage-Eintrag), der der Blockierungslogik des CMP mitteilt, dass nicht-essentielle Skripte bei zukünftigen Seitenladevorgängen nicht ausgeführt werden sollen. Wenn beides funktioniert, ist der Nutzer sauber: keine Tracking-Cookies, keine Tracking-Skripte.

Consent-Respawn tritt auf, wenn die Löschung gelingt, aber die Blockierung versagt. Das häufigste Szenario:

1. Das CMP löscht das `_ga`-Cookie, wenn der Nutzer auf Ablehnen klickt.

2. Das CMP setzt ein Einwilligungsstatus-Cookie, das festhält, dass der Nutzer Analytics abgelehnt hat.

3. Beim nächsten Seitenladen prüft das CMP seinen Einwilligungsstatus und weiß, dass der Nutzer abgelehnt hat.

4. Aber: Das Google Analytics-Skript-Tag ist direkt in der Seitenvorlage eingebettet (außerhalb des Tag Managers) oder wird durch eine Tag-Manager-Regel geladen, die den Einwilligungsstatus nicht prüft.

5. Das GA-Skript wird geladen, sieht kein `_ga`-Cookie und erstellt ein neues.

6. Die Ablehnungsentscheidung des Nutzers wurde überschrieben.

Variationen dieses Musters umfassen: Drittanbieter-Skripte, die über fest codierte `