snorklee
Funktionen KI-Verkehr Preise Manifest Hilfe Audit Kontakt Anmelden Kostenlos starten

Technische Tiefenanalyse

Ihr Shopify-Shop setzt wahrscheinlich Cookies vor der Einwilligung. So beweisen Sie es in fünf Minuten.

Schalten Sie das Cookie-Banner von Shopify ein. Öffnen Sie den Network-Tab (Netzwerk) in einem privaten Fenster. Zählen Sie die Anfragen, die vor Ihrem ersten Klick ausgelöst werden. Bei vielen Shops ist diese Zahl nicht null — und genau das ist die Lücke, auf die Aufsichtsbehörden tatsächlich schauen.

Fred Gaveau16. Juni 2026~9 Min. Lesezeit

Hier ist ein Test, den Sie sofort in Ihrem eigenen Shop durchführen können, ganz ohne anderes Werkzeug als Ihren Browser:

  1. Öffnen Sie Ihr Storefront in einem frischen privaten/Inkognito-Fenster.
  2. Bevor Sie etwas im Cookie-Banner anklicken, öffnen Sie die DevTools und schauen Sie sich die Cookies an, die bereits existieren, sowie die Netzwerkanfragen, die schon hinausgegangen sind.
  3. Klicken Sie jetzt auf Ablehnen. Beobachten Sie, was gelöscht wird — und was trotzdem weiter ausgelöst wird.

Wenn Sie das noch nie gemacht haben, ist das Ergebnis oft überraschend. Nicht, weil Shopify etwas falsch macht — das tut es nicht — sondern wegen der Kluft zwischen dem, was Sie im Admin-Bereich konfiguriert haben, und dem, was der Browser beim Laden der Seite tatsächlich tut.

Der blinde Fleck: was Sie erklären ≠ was der Browser tut

Es gibt zwei sehr unterschiedliche Dinge, und fast jeder wirft sie in einen Topf.

Die Erklärung. In Ihrem Shopify-Admin aktivieren Sie das Consent-Banner, setzen die Häkchen und binden die Customer Privacy API ein. Auf dem Papier ist alles erledigt.

Das Verhalten. Was ein echter Browser tut, wenn ein echter Besucher Ihre Seite lädt: welche Cookies auf die Festplatte geschrieben werden, welche Pixel auslösen, welche Drittanbieter-Domains kontaktiert werden — und entscheidend, wann, im Verhältnis zum Einwilligungsklick.

Die Erklärung lebt in Ihrem Admin. Das Verhalten lebt im Browser des Besuchers. Eine Aufsichtsbehörde, die eine Website prüft, liest nicht Ihre Admin-Einstellungen — sie öffnet die Seite, beobachtet das Netzwerk und liest den Cookie-Speicher aus. Der Browser ist die Quelle der Wahrheit. Das ist nicht spezifisch für Shopify; es gilt für jeden Web-Stack. Aber Shopifys Voreinstellungen, Themes und das App-Ökosystem machen es leicht, diese Lücke zu übersehen.

Eine Einschränkung vorweg: Ich bin kein Anwalt, und nichts hier ist Rechtsberatung oder ein Compliance-Urteil. Es geht darum, was in Ihrem Browser technisch beobachtbar ist. Was das für Ihre konkrete Situation bedeutet, ist eine Frage für qualifizierte Rechtsberatung.

Ein typisches Storefront-Laden auf einer Zeitachse

vor jedem Klick Einwilligungsentscheidung nach der Annahme
Schematisch, keine gemessene Statistik. Der Punkt ist die Form: Ereignisse landen auf beiden Seiten der Einwilligungsmarke. Führen Sie den Selbsttest unten durch, um die echte Zeitachse für Ihren Shop zu erhalten.

Die fünf echten technischen Ursachen

1. Shopifys eigene Cookies und die Grauzone „notwendig vs. Analytics“

Shopify schreibt mehr oder weniger beim Laden eine Reihe von First-Party-Cookies: _shopify_y, _shopify_s, _y, _s, dazu Warenkorb- und Session-Cookies wie cart, _secure_session_id, _shopify_essential. Manche sind wirklich notwendig — ein Warenkorb-Cookie sorgt dafür, dass der Warenkorb funktioniert. Andere haben Analytics-Charakter (die _y/_s-Familie speist Shopifys Storefront-Analytics). Das Etikett „unbedingt erforderlich“ leistet hier eine Menge Arbeit, und wo genau die Grenze verläuft, ist umstritten. Die praktische Schlussfolgerung: Gehen Sie nicht davon aus, dass jedes Shopify-Cookie in die Kategorie „keine Einwilligung nötig“ fällt, nur weil Shopify es gesetzt hat.

2. Die Customer Privacy API meldet die Einwilligung — sie erzwingt sie nicht von allein

Shopifys Customer Privacy API (window.Shopify.customerPrivacy) ist ein gutes, echtes Werkzeug. Sie legt den Einwilligungsstatus des Besuchers offen — analyticsProcessingAllowed(), marketingAllowed() — und löst ein visitorConsentCollected-Ereignis aus, wenn der Besucher entscheidet. Aber ein Signal offenzulegen ist nicht dasselbe wie blockieren. Es liegt an jedem einzelnen Skript, Theme und jeder App, dieses Signal zu lesen und sich selbst daran zu binden. Ein Pixel, das customerPrivacy nie abfragt, löst trotzdem aus. Die API reicht Ihnen den Einwilligungsstatus auf dem Silbertablett; ob Ihr Code tatsächlich darauf wartet, ist eine andere Frage.

3. Pixel, die durch ältere Skripte oder Apps beim Laden fest eingebaut sind

Das ist der Klassiker. Ein Meta- (Facebook-) Pixel, ein TikTok-Pixel oder ein Google-Tag wurde vor zwei Jahren direkt in theme.liquid eingefügt oder von einer App installiert, die es auf jeder Seite injiziert. Es läuft im <head>, sofort, noch bevor das Banner überhaupt gerendert wird. Shopifys moderne Customer Events / Web-Pixel-Sandbox existiert genau dafür, diese durch die Einwilligungsebene zu leiten — aber ein veraltetes, fest eingebautes Tag umgeht das alles. Es weiß nicht, dass das Banner existiert.

4. Eine Ablehnung, die nicht vollständig durchgereicht wird

Hier gibt es zwei Fehlermodi. Erstens: Cookies, die bereits vor der Entscheidung geschrieben wurden, werden nicht gelöscht, wenn der Besucher ablehnt — sie bleiben einfach liegen. Zweitens: Ein Skript liest den Einwilligungsstatus einmal, früh, speichert „noch keine Entscheidung“ zwischen und löst trotzdem aus, weil es nach dem Klick des Besuchers auf Ablehnen nie erneut prüft. Das Banner sagt „abgelehnt“. Das Netzwerk sagt etwas anderes.

5. Drittanbieter-Ressourcen außerhalb der Reichweite des Banners

Eingebettete YouTube-Videos (youtube.com), aus Googles CDN geladene Google Fonts, ein Chat-Widget, ein Bewertungs-Widget, eine eingebettete Karte — jedes davon kann beim Laden Cookies setzen oder einen Drittanbieter-Server kontaktieren, und viele Consent-Banner decken sie überhaupt nicht ab, weil sie keine „Tags“ sind, sondern eingebettete Inhalte. Sie sitzen in einem eigenen blinden Fleck.

Was Sie beobachten vs. was Sie konfiguriert haben

Vor jedem Klick
Anfragen + Cookies
Nach „Ablehnen“
manche lösen weiter aus
Nach „Akzeptieren“
alles
Schema der drei Szenarien, die Sie unten testen werden. Die Balkenlängen sind illustrativ — Ihre werden abweichen. Je kürzer die ersten beiden Balken, desto näher ist das tatsächliche Verhalten Ihres Shops an seinem erklärten Verhalten.

Der Fünf-Minuten-Selbsttest

Das ist der Teil, den es sich zu merken lohnt. Kein Werkzeug, keine Erweiterung, kein Konto. Nur die DevTools Ihres Browsers und beim ersten Mal fünfzehn Minuten, danach jedes Mal fünf. Die Schritte sind für Chrome geschrieben; Firefox und Safari sind nahezu identisch.

  1. Öffnen Sie ein sauberes privates Fenster Nutzen Sie den Inkognito-Modus (Ctrl/ + Shift + N). Ein sauberes Profil bedeutet, dass keine übrig gebliebenen Cookies das Ergebnis verfälschen. Laden Sie Ihren Shop noch nicht.
  2. Öffnen Sie zuerst die DevTools Drücken Sie F12 (oder + Opt + I). Gehen Sie zum Network-Tab (Netzwerk). Aktivieren Sie Preserve log (Protokoll beibehalten) und Disable cache (Cache deaktivieren). Öffnen Sie ihn, bevor Sie die Seite laden, damit Sie die allerersten Anfragen erfassen.
  3. Laden Sie Ihr Storefront — und stoppen Sie. Nicht klicken. Lassen Sie die Seite sich setzen. Berühren Sie das Banner nicht. Das ist Szenario eins: vor jeder Einwilligung.
  4. Lesen Sie den Cookie-Speicher aus Gehen Sie zu Application ▸ Storage ▸ Cookies (Firefox: Storage ▸ Cookies) und wählen Sie Ihre Domain. Listen Sie alles auf, was schon da ist. Jedes davon wurde gesetzt, bevor Sie irgendetwas entschieden haben.
  5. Lesen Sie das Netzwerk Zurück im Network-Tab filtern Sie nach Domain. Tippen Sie facebook, dann tiktok, dann google-analytics, googletagmanager, doubleclick, youtube. Jeder Treffer bedeutet, dass ein Drittanbieter vor der Einwilligung kontaktiert wurde. Notieren Sie sie.
  6. Szenario zwei: Klicken Sie auf „Ablehnen“ Lehnen Sie jetzt ab. Öffnen Sie dann das Cookies-Panel erneut. Sind die zuvor gesetzten Cookies verschwunden? Oft sind sie es nicht. Prüfen Sie die Netzwerk-Filter erneut — lösen Pixel auch nach der Ablehnung noch aus? Notieren Sie den Unterschied.
  7. Szenario drei: frisches Fenster, Klick auf „Akzeptieren“ Schließen Sie alles, öffnen Sie ein neues Inkognito-Fenster, laden Sie neu und akzeptieren Sie diesmal. Das ist Ihre Referenz dafür, „was bei voller Einwilligung auslöst“ — nützlich, um zu sehen, was in den Szenarien eins und zwei eigentlich hätte blockiert sein sollen.
Profi-Tipp

Sortieren Sie im Network-Tab nach der Spalte Time/Waterfall und finden Sie die Anfrage, die durch Ihren Einwilligungsklick ausgelöst wurde. Alles darüber, was eine Drittanbieter-Domain geladen hat, ist vor der Einwilligung passiert. Diese eine Ansicht ist die ganze Geschichte.

Cookies, die Sie typischerweise sehen, und wann sie landen

Namen und Lebensdauern variieren je nach Theme und Shopify-Version, behandeln Sie dies also als Feldführer, nicht als Evangelium. Die Kategorien sind weit verbreitete Konventionen, keine rechtlichen Einstufungen.

CookieTypischerweise gesetztÜblicher Zweck
_shopify_y / _ybeim LadenStorefront-Analytics, ~1 Jahr
_shopify_s / _sbeim LadenAnalytics-Session, ~30 Min.
_shopify_sa_p / _shopify_sa_tbeim LadenMarketing- / Attributions-Analytics
cart, cart_sig, cart_tsfunktionalDer Warenkorb selbst
_secure_session_idfunktionalCheckout / Session
_tracking_consent, _cmp_aEinwilligungSpeichert die Einwilligungsentscheidung selbst
_fbpbeim Laden*Meta Pixel — sollte auf die Einwilligung warten
_ga, _gidbeim Laden*Google Analytics — sollte auf die Einwilligung warten

* _fbp, _ga und Konsorten sind die, die man genau prüfen sollte: Wenn sie in Szenario eins (vor jedem Klick) auftauchen, ist das genau die Lücke, um die es in diesem Artikel geht.

Was Sie dagegen tun können — ohne zu dramatisieren

Nichts davon ist ein Großbrand. Es ist ein Konfigurations- und Hygieneproblem, und es ist behebbar. Realistische Maßnahmen, grob nach Hebelwirkung geordnet:

FAQ

Blockiert Shopifys Consent-Banner das Tracking von allein?
Nicht von allein. Es sammelt die Einwilligungsentscheidung und legt sie über die Customer Privacy API offen. Ob ein bestimmtes Skript diese Entscheidung respektiert, hängt davon ab, wie es eingebunden wurde — über Customer Events (eingewilligungsgebunden) oder fest eingebaut (nicht eingewilligungsgebunden).

Sind Shopifys eigene Cookies ein Problem?
Viele sind wirklich funktional (der Warenkorb funktioniert ohne sie nicht). Die Grauzone sind die mit Analytics-Charakter. Die ehrliche Antwort ist, dass die Grenze „notwendig vs. Analytics“ umstritten ist — was genau der Grund ist, warum das Beobachten des echten Verhaltens dem Vermuten überlegen ist.

Ist das ein Shopify-spezifisches Problem?
Nein. Dieselbe Kluft zwischen Erklärtem und Beobachtetem gibt es bei WordPress, bei individuellen Stacks, überall. Shopify liefert sogar starke Grundbausteine (Customer Privacy API, Customer Events). Die Lücke liegt in der Konfiguration und im Drittanbieter-Code, nicht in der Plattform.

Der Wandel im Denken über Tracking

Die eine Idee, die man behalten sollte: Ein Tracking-Setup ist nur so gut wie sein beobachtetes Verhalten, nicht wie seine erklärte Konfiguration. Ein gesetztes Häkchen in einem Admin-Panel ist eine Behauptung. Der Network-Tab ist der Beweis. Die beiden driften ständig auseinander — eine neue App, ein Theme-Update, ein eingefügter Code-Schnipsel — und niemand merkt es, weil niemand hinschaut.

Also schauen Sie hin. Fünf Minuten in den DevTools verraten Ihnen mehr darüber, was Ihr Shop tatsächlich tut, als jede Einstellungsseite es je könnte. Führen Sie es noch heute in Ihrem eigenen Shop durch. Und dann beim Shop eines Wettbewerbers — Sie werden ein Cookie-Banner nie wieder mit denselben Augen lesen.