Cookie-Consent-Tool installiert – und trotzdem feuert alles: die gefährliche Scheinsicherheit

Ein Banner ist eine Benutzeroberfläche, keine Blockade

Der Denkfehler steckt schon im Wort „Cookie-Banner“. Das Banner ist das Frontend einer Einwilligung — die Stelle, an der der Nutzer „Akzeptieren“ oder „Ablehnen“ klickt. Rechtlich relevant ist aber nicht, dass diese Oberfläche existiert, sondern was im Hintergrund passiert: Lädt vor der Einwilligung wirklich kein nicht-notwendiges Skript? Und schweigt bei Ablehnung tatsächlich alles? Ein Consent-Tool, das nur das Banner rendert, die darunterliegenden Tags aber nicht kontrolliert, ist eine Klingel an einer Tür, die ohnehin offensteht.

Das ist auch der Maßstab des Gesetzes: § 25 TDDDG — das vormalige TTDSG, das zum 14. Mai 2024 durch das Digitale-Dienste-Gesetz in TDDDG umbenannt wurde, inhaltlich unverändert — verlangt eine Einwilligung, bevor Informationen im Endgerät gespeichert oder ausgelesen werden, sofern das nicht technisch unbedingt erforderlich ist. Greift parallel eine Verarbeitung personenbezogener Daten, braucht es zusätzlich eine Rechtsgrundlage nach Art. 6 DSGVO. Beide gelten kumulativ [Quelle: § 25 TDDDG; DSK-Orientierungshilfe digitale Dienste]. Der entscheidende Zeitpunkt ist also der Zugriff vor der Einwilligung — nicht das Aussehen des Banners.

Genau das ist der häufigste Zustand in freier Wildbahn: Banner sauber gestylt, Texte juristisch geprüft, „Ablehnen“ gleichwertig sichtbar — und im Netzwerk-Tab feuert das Meta Pixel schon beim Seitenaufruf, bevor überhaupt geklickt wurde. Die UI-Schicht ist korrekt, die Mechanik darunter fehlt. Das ist der Unterschied zwischen aussehen wie compliant und sein.

Wo die Tags wirklich vorbeifeuern

Die Lecks sitzen selten im Consent-Tool selbst, sondern in den vier Wegen, auf denen Tracking in einen Shopify-Shop kommt — und von denen das Tool typischerweise nur einen kontrolliert:

• Hardcoded im Theme. Pixel, die direkt in theme.liquid oder über „Additional Scripts“ im Header eingetragen sind (Meta Pixel, ein nacktes gtag-Snippet, TikTok, Pinterest), laufen vollständig am Consent-Tool vorbei. Sie sind Teil der Seite, bevor das Banner überhaupt initialisiert. Das ist das mit Abstand häufigste Leck.
• Shopifys eigene Pixel-Schicht (Customer Events). Apps und Custom-Pixel laufen über „Customer Events“ und Shopifys Customer Privacy API. Die respektieren den Einwilligungsstatus nur, wenn das Banner ihn über Shopify.customerPrivacy.setTrackingConsent tatsächlich setzt — und wenn der Custom-Pixel-Code seinerseits auf das Consent-Signal hört, statt beim Laden blind zu feuern. Viele App-Pixel tun das nicht.
• Die Race Condition im Google Tag Manager. GTM lädt Tags an Triggern; wenn der Pageview-Trigger feuert, bevor das CMP den Consent-Status gesetzt hat, geht der Tag raus, obwohl noch nichts eingewilligt wurde. Consent Mode v2 ist genau dafür da — aber nur, wenn der consent default denied-Befehl vor dem GTM-Snippet im Quelltext steht. Steht er danach, kommt das Signal zu spät, und das Default-Verhalten ist faktisch „granted“.
• Server-Side-Tracking. Meta Conversions API, serverseitiges GA4, ein eigener Tracking-Gateway: Diese Datenströme verlassen den Server, nicht den Browser — ein clientseitiges Consent-Tool sieht sie nie. Wird das Einwilligungssignal nicht als Flag bis in den Server-Call durchgereicht, leakt die CAPI munter weiter, während das Banner vorne „abgelehnt“ anzeigt.

Dazu kommen die stillen Mitläufer: Onsite-Tracking von E-Mail-Tools (z. B. Klaviyos „Active on Site“), Heatmaps, Chat-Widgets, eingebettete Videos. Jedes davon ist ein eigener Kanal, der einzeln gegen den Consent-Status geprüft werden muss.

Der Test, den fast niemand macht: drei Zustände im Netzwerk-Tab

Ob ein Setup hält, entscheidet sich nicht im Banner, sondern im Netzwerk-Tab der Entwicklertools. Die Methodik ist simpel und wird trotzdem fast nie sauber durchgezogen:

• Drei Zustände, nicht einer. (1) Vor jeder Interaktion, Banner noch offen — das ist der kritische Pre-Consent-Moment. (2) Nach Ablehnung. (3) Nach Teilzustimmung (z. B. nur „Statistik“, nicht „Marketing“). In jedem Zustand Seite neu laden und durch eine typische Reise klicken (PDP, Cart, Checkout-Einstieg).
• Auf Requests filtern, nicht auf Cookies. Im Netzwerk-Tab nach den bekannten Endpunkten filtern: facebook.com/tr, google-analytics.com/g/collect, analytics.tiktok.com, klaviyo.com. Geht in Zustand 1 oder 2 ein solcher Request raus, der nicht dürfte, ist das Leck bewiesen. Der Application-/Cookie-Tab allein genügt nicht — ein Tag kann auch ohne Cookie über URL-Parameter personenbezogene Daten senden.
• GTM Preview / Tag Assistant. Zeigt pro Tag, an welchem Trigger er feuert und welchen Consent-Status er dabei gesehen hat. So trennt man „Tag hat gefeuert“ von „Tag hat trotz denied gefeuert“ — der eigentlich relevante Unterschied.
• Den Pre-Consent-Moment ernst nehmen. Der gefährlichste Zustand ist nicht „nach Ablehnen“, sondern die Sekunde, in der das Banner noch offen ist und der Nutzer nichts entschieden hat. Genau hier feuern hardcodete Theme-Pixel — und genau hier schaut kaum jemand hin.

Was eine Behörde tatsächlich prüft

Aufsicht und Abmahner interessieren sich nicht primär für die Optik des Banners. Der technische Kern der Prüfung ist, ob vor der Einwilligung ein Zugriff auf das Endgerät stattfindet — also ob etwas gespeichert oder ausgelesen wird, das nicht technisch notwendig ist — und ob personenbezogene Daten ohne Rechtsgrundlage übertragen werden. Dass das Banner überhaupt angezeigt wird oder dass der Nutzer weitersurft, ist dabei keine wirksame Einwilligung: Der EuGH hat in der Entscheidung Planet49 (C-673/17) klargestellt, dass es eine aktive, informierte Handlung braucht — vorangekreuzte Häkchen oder bloßes Weitersurfen genügen nicht [Quelle: EuGH C-673/17 (Planet49)]. Das Banner-Design (gleichwertiges „Ablehnen“, kein Nudging) ist die zweite Schicht; die erste ist schlicht: Feuert etwas vor Consent?

Aus Operator-Sicht heißt das: Ein Audit, das nur die Banner-Texte und die „Ablehnen“-Schaltfläche abhakt, prüft die falsche Schicht. Die nachweisrelevante Frage ist die Liste der Requests je Consent-Zustand — dieselbe Trennung von Deklaration (was das Banner sagt) und tatsächlichem Verhalten (was die Seite tut), die auch bei der elektronischen Widerrufsfunktion über Schein und Substanz entscheidet.

Consent Mode v2 ist kein Freifahrtschein

Weil viele Setups inzwischen Consent Mode v2 ausrollen, lohnt die Grenze: Consent Mode v2 ist keine gesetzliche Compliance, sondern eine Plattform-Anforderung von Google — gestützt auf die EU User Consent Policy und den DMA, faktisch seit dem 6. März 2024 erforderlich, um etwa Remarketing-Audiences weiter befüllen zu können [Quelle: Google Consent Mode v2]. Er ersetzt weder § 25 TDDDG noch Art. 6 DSGVO. Technisch ist Consent Mode ein Mechanismus, mit dem Google-Tags ihr Verhalten am übermittelten Einwilligungsstatus ausrichten. Er ersetzt nicht die korrekte Default-Konfiguration (alle Consent-Typen auf denied, bevor irgendein Tag lädt), und er kontrolliert nicht die Nicht-Google-Tags — Meta, TikTok, Pinterest blockiert er ohnehin nicht. Dazu kommt: Bei Ablehnung sendet Consent Mode weiterhin cookielose Pings für „Conversion Modeling“. Ob das im konkreten Fall zulässig ist, ist ein eigener, zu bewertender Punkt — und keinesfalls ein Automatismus für Konformität. „Wir haben Consent Mode v2“ ist also kein Ende der Prüfung, sondern bestenfalls deren Anfang.

Das saubere Setup in Shopify

Compliance entsteht, wenn der Einwilligungsstatus an jedem der vier Kanäle greift — als durchgehende Kette, nicht als Banner-Häkchen:

• Keine hardcodeten Tags im Theme. Alles aus theme.liquid und „Additional Scripts“ rausziehen und über eine einzige, kontrollierte Schicht (GTM) laufen lassen. Was hart in der Seite steht, kann das Tool nicht blockieren — Punkt.
• Consent Mode v2 mit korrektem Default. Der consent default denied-Befehl muss als Allererstes laden, vor dem GTM-Snippet. Erst nach Klick im Banner wird per Update auf granted hochgesetzt — granular nach Zweck.
• Shopifys Customer Privacy API bedienen. Das Consent-Tool muss den Status über Shopify.customerPrivacy.setTrackingConsent setzen, damit Shopifys eigene Pixel und App-Pixel gaten. Jeder Custom-Pixel in „Customer Events“ hört über analytics.subscribe auf das Signal, statt beim Laden zu feuern.
• Server-Side an den Consent koppeln. Das Einwilligungssignal als Flag bis in den CAPI-/Server-Call durchreichen (Consent-Status im Event-Payload), damit serverseitiges Tracking bei Ablehnung tatsächlich schweigt — nicht nur clientseitig.
• Je Zustand testen und protokollieren. Das oben beschriebene Drei-Zustände-Verfahren nach jedem Theme-Update, jeder App-Installation und jeder Pixel-Änderung wiederholen — und das Ergebnis als datierten Prüf-Report ablegen. Ein Consent-Setup ist kein einmaliges Projekt, sondern ein Zustand, der mit jeder Änderung kippen kann.

Die kurze Version

Ein Consent-Banner ist die Benutzeroberfläche einer Einwilligung, nicht die Einwilligung selbst. Konform ist ein Shop erst, wenn vor der Zustimmung nachweislich kein nicht-notwendiges Tag lädt und bei Ablehnung wirklich nichts feuert — über alle vier Kanäle: Theme, Shopify-Pixel, GTM und Server-Side. Geprüft wird das nicht im Banner, sondern im Netzwerk-Tab, in drei Zuständen. Ein installiertes Tool, unter dem trotzdem alles feuert, ist Scheinsicherheit: teurer und riskanter als gar kein Banner, weil es Kenntnis ohne Umsetzung dokumentiert. Maßgeblich sind § 25 TDDDG und Art. 6 DSGVO kumulativ — der konkrete rechtliche Maßstab gehört vor dem Go-Live an der Norm verifiziert [Quelle: § 25 TDDDG; DSGVO Art. 6].

Ihr wollt wissen, ob euer Consent-Setup wirklich blockiert — oder ob unter dem sauberen Banner trotzdem Meta, GA4 und TikTok rausgehen? Wir machen das Tracking-/Consent-Audit: alle vier Kanäle, drei Zustände im Netzwerk-Tab, ein datierter Prüf-Report mit jedem Leck und der sauberen Umsetzung in Shopify. Gespräch anfragen. Weiter im Kontext: die elektronische Widerrufsfunktion und weitere operative Compliance-Themen.