Warum Cookie-Banner oft Fake sind

Cookie-Banner, also „Consent Management“, nerven gewaltig. Die Leute wären noch mehr genervt, wenn sie wüssten dass nicht wenige Cookie-Banner funktionslose Deko sind.

Deshalb Browser-Tipp: Firefox, privates Fenster (Ctrl-Shift-P), ggf. VPN.

Im Screenshot oben siehst du ein Positivbeispiel: Alles ist sauber, es werden vor Consent cookielose Pings an Google gesendet. Der Screenshot ist eine Auswertung meines Consent-Checker-Tools. Es gibt dafür viele gute Lösungen am Markt, auch als sinnvolle Abo-Modelle mit laufendem Monitoring, aber ein Custom-Script ist im Zeitalter von KI a) kein Hexenwerk und b) lehrreich. Mittels „F12“ im Browser sieht man das natürlich auch alles.

Im Falle einer Fehlkonfiguration bedeutet das: Alle Cookies der Seite werden gesetzt, bzw. Tracking-Daten gesendet, an Google, Meta, TikTok, Klaviyo, Shopify etc. Und zwar mit dem Laden der Seite. Bevor das Cookie-Banner überhaupt geladen wurde.

Wie im Screenshot gilt: In diesen Fällen ist das Cookie-Banner schlicht und einfach funktionslos bzw. technisch wirkungslos.

Ob und welchen Button man klickt hat keine Auswirkungen. Das kann ein Verstoß gegen die DSGVO, das TDDDG etc. sein (für Rechtsberatung bitte Juristen fragen, hier gibt es keine Rechtsberatung).
Für die Analytics-Abteilung ist dieser Verstoß allerdings wertvoll, da alle Daten von allen Usern in die Auswertungen reinlaufen, bspw. in Google Analytics. Mit rechtssicherer Konfiguration sieht Google Analytics nur die User, die Consent erteilt haben (das sind dann vielleicht, worst case, nur 10 % der User).

Ist die Tracking-Schludrigkeit skandalös? Natürlich.

Woran liegt’s? Böse Absicht ist der „Consent Bypass“ nicht zwingend, weil die saubere Einrichtung leider wirklich kompliziert ist. Als Website-Admin kann man versucht sein zu denken: „Ich installiere ein Consent-Tool, und alles ist gut“. Leider nein.

Denn es handelt sich um ein Zusammenspiel aus mehreren Komponenten, die oft in der falschen Reihenfolge im Web-Projekt installiert werden.

Die richtige Reihenfolge fürs Consent-Management

• Das Consent-Banner ist die Basis. Wenn man sich das Leben leichter machen will, nimmt man eine weit verbreitete Lösung. Eine generelle Empfehlung gibt es nicht, es hängt davon ab, was du brauchst (Ist es eine WordPress-Website? Ist es Enterprise-Level mit Multi Domain inklusive App? Welche Zielländer? Wie sind die Tracking-Ansprüche?).
• Der Tag Manager. Ein Tag Manager erleichert das Leben. Meist nimmt man den Google Tag Manager, oder die serverseitige Variante (sGTM).
  Es gibt auch Alternativen wie Stape, Jentis (aus Österreich), etracker, Matomo, Piwik Pro, TAGGRS und mehr. Die Nummer größer sind dann CDPs (Customer Data Platforms) wie Rudderstack, Snowplow, Segment (Twilio) etc. pp.
  Im Tag Manager installiert man alle Cookies, Trackingpixel, Verhaltensanalysen (Scrolltiefen), Events (Klicks auf bestimmte Buttons, abfangen von Daten aus Konfiguratoren etc.)
  Vor allem aber baut man das Verhalten des Consent-Banners ein:
  • Seite wurde geladen, Cookie-Banner auch: Alle Cookies sind in der Startbox und scharren mit den Hufen. Keines darf was tun, mit zwei Ausnahmen:
    • Cookieloses Tracking kann erlaubt sein (anonymisiert)
    • Bei Google gibt es noch den Advanced Consent Modus, der anonymisierte Daten („Pings“) sendet. Diese sind in Google Analytics nicht sichtbar, Google nutzt sie zur „Modellierung“ um „Data Loss“ auszugleichen. Aber kommt man auch an die Rohdaten? Ja sicher! In BigQuery. Dort kann man die cookielosen User (halbwegs) auswerten (mittels SQL), Zeile für Zeile. Man sieht auf alle Fälle, ob und wie viele User auf welcher Unterseite waren, und ob sie UTM-Parameter im Gepäck hatten. Umso wichtiger ist es, UTM-Parameter sauber zu setzen.
      Und Sichtbarkeit bei KI: ChatGPT, Claude und Perplexity hängen (meistens) einen UTM-Parameter dran.
  • Erst wenn der User alle bzw. einige Cookies akzeptiert, werden die entsprechenden Cookies gesetzt und (volle) Trackingdaten gesendet.

Typische Konfigurationsfehler

• Newsletter / CRM: Man baut Formulare in die Website ein, und diese laden nicht nur die Formulardaten, sondern setzen direkt langlebige Cookies. Fies. Sieht man oft bei Klaviyo-Installationen. Bei HubSpot muss man auch aufpassen.
• E-Commerce: Die Shopify-Seite lädt ihr eigenes Tracking mit dem Laden der Seite direkt mit. Hier muss man das Tracking in den Tag Manager verschieben.
• Fehler im Tag Manager: Im Google Tag Manager gibt es viele Vorlagen, die man sehr einfach übernehmen kann. Leider sind diese nicht immer datenschutzkonform. Bedeutet: Man nimmt die Vorlage für Microsoft Clarity (ist ganz cool, zeigt Heatmaps) und bindet sie ein wie Google Analytics. Tückisch: Die Google-Vorlagen kennen (Advanced) Consent, da muss man fast nichts anpassen. Die Microsoft-Vorlagen kennen das nicht, die muss man manuell nachkonfigurieren. Das gilt auch für viele weitere Vorlagen, die man per Handarbeit ans Verhalten des Cookie-Banners koppeln muss.
• Affiliate, Dealfront etc: Hier sind sich die Gelehrten uneinig. Es gibt Leute, die sind der Ansicht, dass Affiliate-Cookies „berechtigtes Interesse“ sind und deswegen keine Einwilligung benötigen. Ähnliches gilt für Leadfeeder / Dealfront, also „Welche Firma war auf meiner Website“ Tools. Zu diesem Thema bitte Juristen nach Wahl befragen.

Ausflug zu BigQuery

Mit sauerem Consent-Setup ist Google Analytics de facto fast wertlos, da ja nur ein Bruchteil der User sichtbar ist (außer man macht eine Paywall und sagt: „Entweder du akzeptierst alle Cookies, oder zu zahlst).

Auf alle Fälle kannst du in BigQuery die Rohdaten der cookielosen Pings sehen. Jedes „Event“ ist eine Zeile, also bspw. der erste Aufruf der Landingpage. Die Daten lassen sich dann filtern und aggregieren (SQL) und exportieren (im einfachsten Fall in eine Tabelle).

So kann man bspw. Kampagnenperformance in Meta bis auf Asset- und Uhrzeit-Ebene runter messen.

Beispiel für einen User ohne Consent, Tabellenspalten:

• Landingpage
• Keine ID, keine IP, sondern „NO-CONSENT PING“. Wir wissen nicht, wer das ist.
• Zeitstempel
• Ort (von Google geraten, sagen wir „Köln“)
• Land (Germany)
• utm_source: bspw. ig (instagram) – das UTM-Setup muss top sein!
• utm_medium: bspw. paid-social
• utm_campaign: bspw. 2026-traffic
• utm_content: bspw. 2026-traffic-ad
• utm_term: bspw. name-des-assets
• devicy_type: mobile
• meta_placement: Instagram_Reels
• visitor_type: REAL-VISITOR (habe ich manuell als Filter angelegt, um Admins auszufiltern)
• session_start: Datum und Uhrzeit (menschenlesbar)
• total_events: lasse ich per SQL aggregieren. That’s where the magic happens: Wie viele Events hat dieser cookielose User ausgelöst? Wenn es bspw. nur 3 sind, hat der User nicht mit der Seite interagiert. Es war wahrscheinlich ein „Fat Finger Click“.
  So kann ich auswerten, welche Werbeplattformen, Assets und Platzierungen (oder auch Uhrzeiten) wertlose Klicks liefern (die natürlich trotzdem bezahlt werden müssen). Wenn ich feststelle, dass Nachts um 12 nur Besoffskis („Low-Engagement-Traffic durch versehentliche Klicks“) unabsichtlich auf meine Ads klicken, dann kann ich die Uhrzeit aus dem Mediaplan rausnehmen.
• page_views: 1

Und wie kann man das Verhalten der Website prüfen?

Um das herauszufunden habe ich ein Audit-Script bauen lassen, entstanden u.a. mit Claude Fable 5.1 (verlässlich) und Google Gemini Flash 3.8 (kreativer Welpe).

Es zeigt, was eine Website gegenüber dem User macht:

• Google Tag Manager Consent Setup: funktioniert es?
• Tracker, Cookies, Pixel: Was wird wann gesetzt, und ist das erlaubt?
• AdTech: irgendwelche Sachen unsauber? Facebook-Pixel fies eingebunden?
• Andere „rauchende Colts“?

Kontakt