Tracking-Architektur auf Shopify nach Checkout Extensibility

Ein Satz, der uns in Gesprächen zur Umstellung der Bestellstatus-Seite im Sommer 2026 mehrfach begegnet ist: Man habe die Skripte aus der alten Box in ein Custom-Pixel kopiert, damit sei der Umzug erledigt. Der erste Teil stimmt dann meistens. Der zweite selten. Kopiert wurde der Code. Nicht mitgezogen wurde die Architektur, in der dieser Code vorher funktioniert hat.

Für Shops ohne Plus-Abo ist die Umstellung mit der Frist zum 26. August 2026 nicht mehr optional, und wer sie nur als Kopier-Aufgabe behandelt, misst danach entweder zu wenig, doppelt oder zum falschen Zeitpunkt. Den Stichtag selbst haben wir in einem eigenen Beitrag abgehandelt. Hier geht es um das, was danach kommt und dauerhaft bleibt: wie Messung auf Shopify heute aufgebaut ist, wo die Einwilligung technisch greift und welche Prüfung den Umzug tatsächlich abschließt.

Dieser Artikel ordnet die vier Ebenen ein, auf denen heute gemessen wird, erklärt den Unterschied zwischen App-Pixel und Custom-Pixel, der im DACH-Raum über die Einwilligung entscheidet, und beschreibt die Prüf-Routine, mit der Sie belegen können, dass Ihr Aufbau tut, was er soll.

Vom Seiten-Skript zum Ereignis-Abonnement

Die alte Box hieß Additional Scripts und tat genau das: Sie schrieb Ihr Skript in die Seite. Damit hatte der Code alles, was ein Skript im Seiten-Kontext hat, nämlich Zugriff auf das Dokument, auf globale Variablen des Themes und auf alles, was andere Skripte vorher hinterlassen hatten. Gewachsene Tracking-Aufbauten haben genau davon gelebt, etwa indem sie den Bestellwert aus einem Element der Danke-Seite gelesen haben.

Der Nachfolger arbeitet anders. Web-Pixel laufen nach der Web-Pixels-Dokumentation in einer Sandbox und bekommen ihre Daten nicht aus der Seite, sondern über Kunden-Ereignisse, die die Plattform ausliefert. Das ist kein Sicherheits-Detail am Rand, sondern der Kern der Umstellung: Aus einem Skript, das sich nimmt, was es findet, wird ein Abonnent, der bekommt, was vorgesehen ist.

Praktisch heißt das: Ein Snippet, das bisher ein DOM-Element ausgelesen hat, funktioniert nach dem Umzug nicht dadurch, dass man es in ein Pixel einfügt. Es läuft, es wirft womöglich nicht einmal einen Fehler, und es liefert keinen Wert. Genau diese Fehlerklasse macht die Umstellung so unangenehm: Sie ist still.

Wie eng die Sandbox ist, hängt dabei von der Pixel-Art ab. Die Dokumentation unterscheidet zwei Stufen: eine strenge Variante für App-Pixel und eine lockerere für Custom-Pixel, die bestimmt, auf welche Browser-Funktionen der Code überhaupt zugreifen darf. Für die Planung ist das weniger eine technische Feinheit als eine Erwartungs-Korrektur. Ein Custom-Pixel hat mehr Spielraum als ein App-Pixel, aber beide bewegen sich in einem abgegrenzten Raum und nicht mehr in Ihrer Seite. Wer im Umzug feststellt, dass ein Werkzeug zwingend Zugriff auf die Seite selbst braucht, hat kein Konfigurations-Problem, sondern muss das Werkzeug ersetzen.

Die vier Ebenen, auf denen heute gemessen wird

Sauber getrennt gibt es vier Orte, an denen Messung stattfindet. Die Trennung dieser vier Ebenen entscheidet darüber, ob ein Aufbau später nachvollziehbar bleibt, denn ein Eintrag auf der falschen Ebene fällt im Alltag nicht auf.

App-Pixel bringt eine App mit. Wenn Sie eine Marketing- oder Analytics-App installiert haben, ist das der vorgesehene Weg, und die App verantwortet den Code. Custom-Pixel legen Sie selbst im Admin an, für Fälle ohne App. Theme-Code deckt weiterhin die Storefront ab, also alles vor dem Checkout, und ist nach der Umstellung nicht mehr die Stelle, an der Kauf-Ereignisse entstehen. Serverseitige Anbindungen schließlich schicken Ereignisse aus einem Backend an einen Empfänger, statt sie im Browser zu erzeugen.

Die Faustregel aus unserer eigenen Operation: Was eine App ohnehin mitbringt, wird nicht zusätzlich als Custom-Pixel gebaut. Das klingt banal, führt aber zu doppelten Zahlen, weil beim Aufräumen die App-Seite übersehen wird und beide Wege parallel feuern.

Die Grenze zwischen Theme und Checkout verdient dabei besondere Aufmerksamkeit, weil sie vor der Umstellung durchlässig war und es jetzt nicht mehr ist. Theme-Code sieht die Storefront. Er sieht nicht mehr, was im Checkout und auf der Bestellstatus-Seite passiert. Wenn Ihr Aufbau historisch gewachsen ist, steht der Kauf-Abschluss deshalb an zwei Stellen im Code, einmal als Theme-Variante für alles vor dem Checkout und einmal in der alten Skript-Box. Nach dem Umzug bleibt davon die Theme-Hälfte übrig und misst weiter, während die andere Hälfte ersetzt werden muss. Wer nur die ersetzte Hälfte prüft, übersieht genau die Reste, die später als unerklärliche Differenz auftauchen.

Kunden-Ereignisse sind ein festes Vokabular

Was ein Pixel überhaupt erfahren kann, steht fest. Die Standard-Ereignisse decken den üblichen Weg durch den Shop ab, unter anderem page_viewed, product_viewed, product_added_to_cart, checkout_started, checkout_contact_info_submitted, payment_info_submitted und checkout_completed.

Das ist erst einmal komfortabel, weil der Kaufabschluss nicht mehr aus der Seite rekonstruiert werden muss, sondern als Ereignis kommt. Es ist zugleich die Grenze des Aufbaus: Was im Vokabular nicht vorkommt, misst man nicht nebenbei. Wer beispielsweise eine Interaktion in einem Konfigurator oder einen fachlichen Zwischenschritt messen will, braucht dafür ein eigenes Ereignis aus der Storefront, und das gehört dann auch dorthin und nicht in ein Checkout-Pixel.

Der zweite Punkt betrifft die Erwartung an die Vollständigkeit. Die Ereignis-Liste beschreibt Verhalten, nicht Buchhaltung. Für Umsatzzahlen ist der Shopify-Bericht die Referenz, nicht das Werbekonto. Wenn beide Zahlen bei Ihnen exakt gleich sind, haben Sie meistens Glück gehabt und nicht sauber gemessen.

Der Unterschied, der im DACH-Raum entscheidet

Hier hält sich ein Missverständnis, das teuer werden kann, und zwar in beide Richtungen. Beide Pixel-Arten werden gegen die Einwilligung geprüft. Der Unterschied liegt nicht darin, ob geprüft wird, sondern wer die Anforderung festlegt.

Bei App-Pixeln legt sie der App-Anbieter im Manifest der Erweiterung fest. Die Dokumentation zur Pixel-Privatsphäre beschreibt, dass der Pixel-Manager ein solches Pixel nur lädt, wenn die Erlaubnis für alle als erforderlich deklarierten Einstellungen vorliegt. Fehlt die Einwilligung, startet das Pixel nicht. Auf diese Deklaration haben Sie keinen Einfluss. Sie ersetzt aber nicht Ihre eigene Prüfung, ob der Zweck, den die App tatsächlich bedient, zu den deklarierten Erlaubnissen passt.

Bei Custom-Pixeln legen Sie die Anforderung selbst fest, im Admin. In Märkten, die als einwilligungspflichtig konfiguriert sind, darunter EWR und Vereinigtes Königreich, laufen Web-Pixel nach dem Help Center nur, wenn der Besucher die in der Pixel-Konfiguration verlangten Erlaubnisse erteilt hat. Neu angelegte Custom-Pixel verlangen dabei standardmäßig Marketing und Analyse und gelten zugleich als Datenverkauf.

Die verbreitete Vorstellung, ein Custom-Pixel feuere einfach immer, stimmt also nicht. Wichtiger ist die Kehrseite: Diese Absicherung ist Konfiguration, keine Naturkonstante. Sie hat drei Stellen, an denen sie unbemerkt aufhören kann zu wirken.

Erstens die Anforderung im Pixel selbst. Sie lässt sich auf “nicht erforderlich” stellen, und dann entfällt die Prüfung für dieses Pixel. Zweitens der Markt: Die Prüfung greift dort, wo Einwilligung konfiguriert verlangt wird. Wer Märkte hinzunimmt, ohne die Datenschutz-Einstellungen mitzuziehen, hat dort kein Gating. Drittens der Zuschnitt der Zwecke: Ein Pixel, das faktisch Marketing bedient, aber nur Analyse als erforderlich deklariert hat, läuft bei jemandem, der Analyse erlaubt und Marketing abgelehnt hat.

Wo die Einwilligung technisch herkommt

Die Klammer um alles ist die Customer Privacy API. Sie kennt vier Zwecke, die getrennt voneinander beantwortet werden: Analyse, Marketing, Präferenzen und der Verkauf von Daten. Ein Einwilligungs-Werkzeug schreibt die Entscheidung des Besuchers über diese Schnittstelle in die Plattform, und die Plattform wendet sie auf ihre eigenen Oberflächen an, Pixel eingeschlossen.

Damit ist auch klar, woran ein Aufbau scheitert: Wenn Ihr Banner die Entscheidung nur in ein eigenes Cookie schreibt und nicht in diese Schnittstelle, weiß die Plattform nichts davon. Prüfen Sie das für jedes Einwilligungs-Werkzeug: Das Help Center beschreibt, dass Shopify die Einwilligung berücksichtigt, wenn die automatisierten Datenschutz-Einstellungen genutzt werden oder ein Drittanbieter-Werkzeug sauber in die Customer Privacy API integriert ist. Die Frage im Audit lautet deshalb nie “haben wir ein Banner”, sondern “landet die Entscheidung dort, wo die Pixel sie lesen”.

In die Gegenrichtung liest ein Pixel den aktuellen Stand über dieselbe Schnittstelle aus, getrennt nach den vier Zwecken. Wichtig ist dabei der Fall, den ein einmaliger Abruf beim Laden nicht abdeckt: Der Besucher entscheidet oft erst, nachdem die Seite schon steht, und ohne Neuladen. Ein Pixel, das den Stand nur einmal zu Beginn prüft, arbeitet danach mit einer veralteten Antwort. Die Schnittstelle sieht dafür vor, dass der Wert bei einer Änderung nachgezogen wird, und genau dieser Teil ist in einem Snippet, das für eine andere Umgebung geschrieben wurde, nicht zwangsläufig vorgesehen.

Die zugehörigen Schalter liegen im Admin unter den Kunden-Datenschutz-Einstellungen, und sie sind regional konfigurierbar. Wer mehrere Märkte fährt, sollte die Einstellung pro Region prüfen statt einmal global, weil sonst genau der Markt aus dem Raster fällt, für den die strengere Regel gilt.

Was die Plattform-Einstellung nicht entscheidet

Der rechtliche Anknüpfungspunkt für das Setzen und Auslesen von Informationen auf dem Endgerät ist § 25 TDDDG. Absatz 1 macht Speicherung und Zugriff von einer Einwilligung auf Grundlage klarer und umfassender Informationen abhängig. Absatz 2 nennt die Ausnahmen, unter anderem für den Fall, dass Speicherung oder Zugriff unbedingt erforderlich sind, damit ein vom Nutzer ausdrücklich gewünschter digitaler Dienst bereitgestellt werden kann.

Für die Architektur folgt daraus eine schlichte Arbeitsteilung. Die Plattform stellt die Mechanik bereit, mit der eine Entscheidung erfasst, transportiert und auf Pixel angewendet wird. Ob Ihre konkrete Auswahl an Zwecken, Texten und Vorbelegungen trägt, ist eine juristische Bewertung des Einzelfalls und keine Einstellung im Admin. Wir bauen und prüfen die Mechanik, die rechtliche Bewertung gehört zu Ihrem Anwalt.

Die typischen Fehler nach dem Umzug

Vier Muster lohnen eine eigene Durchsicht.

Doppelte Zählung. Ein Kanal wird gleichzeitig über das App-Pixel der zugehörigen App und über ein selbst gebautes Custom-Pixel bedient. Die Zahlen steigen sprunghaft, was in der ersten Woche gern als Erfolg gelesen wird.

Stille Lücke. Ein Ereignis, das der alte Aufbau aus der Seite gelesen hat, existiert im neuen Vokabular nicht in dieser Form. Nichts bricht, ein Wert fehlt einfach.

Fehlende Kopplung. Der Banner ist da, schreibt die Entscheidung aber nicht in die Schnittstelle, oder das Custom-Pixel fragt sie nicht ab. Das Ergebnis sieht in der Auswertung völlig unauffällig aus.

Alter Rest im Theme. Ein Snippet aus der Zeit vor der Umstellung liegt weiterhin im Theme und feuert auf der Storefront weiter, während der Checkout-Teil längst umgezogen ist.

Serverseitig messen, nüchtern betrachtet

Serverseitige Anbindungen werden gern als Lösung für alles angeboten, was im Browser wegbricht. Was sie tatsächlich ändern, ist der Transportweg: Das Ereignis entsteht nicht mehr im Browser des Besuchers, sondern wird aus einem System heraus gesendet.

Was sie nicht ändern, ist die Frage nach der Erlaubnis. Wenn für die Erhebung eine Einwilligung nötig ist, wird sie durch einen anderen Transportweg nicht entbehrlich, und die Entscheidung des Besuchers muss auch auf diesem Weg mitgeführt werden. Ein serverseitiger Aufbau ohne saubere Übergabe des Einwilligungs-Stands verlagert das Problem, statt es zu lösen.

Wir setzen serverseitige Wege deshalb dort ein, wo sie ein konkretes technisches Problem lösen, etwa Ereignisse, die nach dem Kauf im Backend entstehen und im Browser gar nicht vorkommen. Als pauschalen Ersatz für Pixel behandeln wir sie nicht, und belastbare eigene Zahlen zum Mehrertrag haben wir nicht, weshalb wir hier auch keine nennen.

Die Prüf-Routine, die den Umzug abschließt

Ein Tracking-Aufbau ist fertig, wenn er nachweisbar tut, was er soll, nicht wenn er gespeichert wurde. Drei Schritte genügen dafür.

Erstens die doppelte Testbestellung: einmal mit Zustimmung, einmal mit Ablehnung. Interessant ist nicht, ob im ersten Fall etwas ankommt, sondern ob im zweiten Fall nichts ankommt. Diese zweite Hälfte fällt beim Testen leicht unter den Tisch, weil der erste Fall sich wie der eigentliche Beweis anfühlt.

Zweitens der Zeitreihen-Vergleich: Ereignis-Zahlen aus einigen Tagen vor und nach der Umstellung nebeneinanderlegen. Ein fehlendes Ereignis erkennt man an der Lücke, eine Doppelzählung am Sprung. Beides ist in der Einzelbestellung schwer zu sehen und in der Reihe offensichtlich.

Drittens die Liste: je Pixel Zweck, Empfänger, benötigte Einwilligung und Zuständiger. Diese Liste ist derselbe Arbeitsschritt wie das App-Inventar, das wir im Artikel zu DSGVO und Shopify-Apps beschrieben haben, nur aus der Messungs-Perspektive. Wer beides getrennt führt, pflegt am Ende keines von beiden.

Die Reihenfolge, die wir empfehlen

Bestandsaufnahme vor Umbau. Erst die vollständige Liste dessen, was heute misst, inklusive der App-Seite, dann die Entscheidung je Eintrag zwischen App-Pixel, Custom-Pixel und Streichung. Danach die Einwilligungs-Kopplung, und zwar für jedes Custom-Pixel einzeln statt einmal pauschal. Zum Schluss die doppelte Testbestellung und der Zeitreihen-Vergleich.

Diese Reihenfolge ist deshalb wichtig, weil jeder Schritt den nächsten prüfbar macht. Wer mit dem Umbau beginnt, hat hinterher keinen Vergleichs-Stand und kann nicht mehr feststellen, ob etwas fehlt.

Wenn Sie unsicher sind, ob Ihr Aufbau nach der Umstellung noch vollständig ist, sehen wir uns die Pixel-Liste und die Einwilligungs-Kopplung im Rahmen von Compliance-Care an. Einen ersten Überblick über die formalen Baustellen im Shop gibt der Compliance-Check. Schildern Sie uns über das Kontaktformular kurz, welche Tools bei Ihnen messen, dann sagen wir Ihnen, welche Ebene für welches davon die richtige ist.