Shopify Tracking Checkliste: 42 Prüfpunkte vor der Abnahme
Die Abnahmeliste, die wir bei jedem Shopify-Messsetup durchgehen: Konten, Customer Events, Consent, Purchase-Parameter, Deduplizierung, Google Ads und der Testkauf. Mit allen Shopify-Änderungen bis September 2026.
Ein Shopify-Tracking sieht in der Tag-Vorschau richtig aus, verliert im Betrieb aber Käufe, zählt sie doppelt, überträgt falsche Werte oder hängt noch an Skripten und Cookies, die Shopify inzwischen abgeschaltet hat
Eine schriftliche Abnahmeliste für Konten, Messpfade, Events, Werte, Consent, Google Ads und einen echten Testkauf abarbeiten, abgeglichen mit der offiziellen Shopify- und Google-Dokumentation
Ein grüner Tag ist kein Abnahmetest
Die meisten kaputten Shopify-Setups wurden nicht schlampig gebaut. Sie wurden gebaut, einmal im Vorschaumodus geprüft und danach nie gegen eine echte Bestellung verifiziert. Der Vorschaumodus sagt dir, dass ein Tag gefeuert hat. Er sagt dir nicht, ob der Wert stimmte, ob ein zweiter Pfad denselben Kauf ebenfalls gemeldet hat oder ob der Consent-Zustand, der bei Google ankam, dem entsprach, was der Besucher geklickt hat.
Dazu kommt, dass Shopify zwischen August 2025 und September 2026 mehrere Dinge abgeschaltet hat, auf denen ältere Setups aufbauen: Additional Scripts und Script Tags auf der Bestellbestätigung, mehrere Tracking-Cookies und die Weitergabe von Kundendaten an App-Pixel ohne Freigabe. Ein Setup, das im Frühjahr 2025 abgenommen wurde, kann heute still Daten verlieren, ohne dass sich im Tag Manager irgendetwas geändert hat.
Das ist die Liste, die wir abarbeiten, bevor ein Shopify-Messsetup als fertig gilt. Gehe sie der Reihe nach durch. Jeder Block setzt voraus, dass der vorherige sauber ist. Bei den zentralen Punkten steht die offizielle Quelle direkt dabei.
Wenn du das lieber als Festpreisprojekt umgesetzt haben möchtest, ist das der Service Shopify Tracking.
Block 1: Konten und Eigentum
Bevor du ein einziges Tag anfasst, halte fest, wem was gehört. Fast jedes geerbte Chaos beginnt genau hier.
- GTM-Konto und Container-ID sind dokumentiert und der Auftraggeber ist Kontoinhaber, nicht nur Benutzer.
- GA4-Property und Mess-ID sind dokumentiert, inklusive der Frage, welcher Datenstream zum Shop gehört.
- Google-Ads-Konto und Kundennummer sind dokumentiert und die Conversion-Aktionen liegen in diesem Konto statt in einem Agenturkonto.
- Merchant Center ist getrennt von der Messverbindung dokumentiert.
- App-Inventar: jede installierte App, die Tracking, Pixel oder den Produktfeed berührt, ist gelistet.
- Benutzerrechte sind geprüft. Frühere Agenturen und ausgeschiedene Mitarbeiter sind entfernt.
- Ein Ausgangsexport des GTM-Containers existiert, bevor irgendetwas geändert wird.
Punkt sieben ist der, den man überspringt und danach bereut. Ohne Ausgangsexport gibt es keinen Rollback, sondern nur einen Neuaufbau.
Block 2: Aktive Messpfade
Der häufigste Shopify-Defekt ist nicht ein fehlender Pfad. Es sind zwei Pfade, die dasselbe Ereignis senden.
- Google & YouTube App: installiert? Welche Conversion-Aktionen hat sie im Ads-Konto angelegt und ist eine GA4-Property verknüpft? Beim Verknüpfen des Ads-Kontos schlägt die App standardmäßig die Aktionen Kauf, In den Warenkorb und Checkout gestartet vor. Google warnt in der eigenen Anleitung ausdrücklich vor doppelten Tags, wenn Conversions sowohl in der App als auch im Storefront oder in einem Custom Pixel gemessen werden (Google Ads Hilfe).
- Theme-Skripte:
theme.liquidund jede Header- oder Footer-Einbindung auf fest verdrahtete gtag- oder GTM-Snippets prüfen. - Custom Pixels: jedes Custom Pixel unter Einstellungen, Kundenereignisse auflisten und vermerken, ob es von einer App oder vom Shop selbst verwaltet wird. Notiere je Pixel die Berechtigungen. Neue Custom Pixels verlangen standardmäßig Marketing und Analytics und gelten standardmäßig als Datenverkauf (Shopify Hilfe).
- Alte Checkout-Skripte und Script Tags sind Geschichte.
checkout.liquidund Additional Scripts wurden auf der Danke-Seite und der Bestellstatusseite für Plus-Shops am 28. August 2025 abgeschaltet, Script Tags auf diesen Seiten für alle anderen Shops am 26. August 2026 (checkout.liquid, Script Tags auf der Bestellstatusseite). Ein Kauf-Tag, das dort noch gesendet hat, meldet seit dem Stichtag nichts mehr. Auch im Storefront läuft die ScriptTag-API aus: ab 1. Oktober 2026 liefernscriptTagCreateundscriptTagUpdateeinen Fehler, ab 1. März 2027 fügt Shopify keine Script Tags mehr in Storefronts ein (Changelog). Prüfe im App-Inventar, welche App noch auf diesem Weg misst und ob der Anbieter auf ein Web Pixel oder einen App Embed Block migriert hat. - Drittanbieter-Apps, die eigene Analytics-, Upsell- oder Bewertungspixel mitbringen. Für die Facebook & Instagram App die Datenfreigabestufe festhalten: Standard setzt nur den Meta Pixel, Erweitert und Maximal senden zusätzlich über die Conversions API (Shopify Hilfe). Ein zweiter Meta Pixel im Theme oder im GTM verdoppelt dann die Ereignisse.
- Doppelte GA4-Mess-IDs auf derselben Seite. Im gerenderten Seitenquelltext nach
G-suchen. - Genau ein Besitzer je Ereignis: für jedes Event im Messplan ist genau ein Pfad zuständig.
Punkt 14 ist das Abnahmekriterium. Alles andere in diesem Block ist Beweisaufnahme.
Block 3: Customer Events und Datalayer
Web Pixels laufen in einer Sandbox. App-Pixel laufen in der strengen Sandbox, Custom Pixels in der Lax-Sandbox (Web Pixels API). Keine der beiden kann Oberflächenelemente rendern oder Daten aus dem DOM lesen (Shopify Hilfe). Pixels laden auf Storefront, Checkout, Danke-Seite und Bestellstatusseite. Auf den Kundenkonto-Seiten laden sie seit Juli 2025 nur mit eigener Subdomain und dort nur mit dem Ereignis page_viewed (Changelog).
- Subscriber werden auf oberster Ebene des Pixels registriert, bevor irgendein Fetch oder Script-Load abgewartet wird. In Consent-Regionen führt Shopify die Callbacks erst nach der Einwilligung aus und spielt dann bereits aufgetretene Ereignisse nach (Shopify Docs). Auf diese Nachspielung verlässt du dich nicht, sondern prüfst im Testkauf, dass das erste
page_viewedeiner Sitzung ankommt. page_viewfeuert mit der echten Seitenadresse und dem echten Referrer, nicht mit der Sandbox-URL. In der Lax-Sandbox enthält die automatisch erkannte URL eine Sandbox-Version und entspricht nicht genau der Adresse des Hauptfensters (Shopify Hilfe). Liesevent.context.document.location.hrefundevent.context.document.referrerund prüfepage_locationundpage_referrerauf einer Produktseite im Live-Shop, damit keine internen Verweise als Akquisition erscheinen.- Kein Code liest mehr abgeschaltete Shopify-Cookies.
_tracking_consent,_landing_pageund_orig_referrersetzt Shopify seit dem 15. September 2025 nicht mehr (Changelog),_shopify_yund_shopify_sseit dem 1. Januar 2026 (Changelog). Für die Besucherkennung istevent.clientIdaus dem Ereignis der Ersatz, für die Sitzung gibt es keinen. Betroffen sind Custom Pixels, GTM-Variablen und Apps, die Landingpage, Referrer oder Kennung daraus gelesen und an ein Server-Side-Setup weitergereicht haben. view_itemfeuert auf Produktseiten mit Artikel-ID, Name, Preis und Währung.add_to_cartfeuert mit Menge und Wert.view_cartfeuert auf der Warenkorbseite.begin_checkoutfeuert beim Checkout-Start und zwar auf der Checkout-Version, die tatsächlich aktiv ist.checkout_startedfeuert in Shops mit Checkout Extensibility bei jedem Betreten des Checkouts, in älteren Shops nur beim ersten Mal (Standard Events). Entscheide, ob du jeden Eintritt oder nur den ersten zählst.purchasefeuert genau einmal beim Abschluss.checkout_completedwird einmal je Checkout ausgelöst, normalerweise auf der Danke-Seite. Mit Post-Purchase-Upsell feuert es auf der ersten Upsell-Seite. Lädt diese Seite nicht fertig, feuert es gar nicht (Standard Events). Seit Juli 2025 laden Web Pixels auch auf der Bestellstatusseite. Ein erneuter Aufruf der Bestellung liefert dortpage_viewed, kein zweitescheckout_completed. Prüfe, dass kein Custom Pixel den Kauf anpage_viewedauf einer Bestell-URL hängt.- Artikel-Arrays sind normalisiert: gleiche Feldnamen, gleiche Typen, in jedem Ereignis.
Block 4: Purchase-Parameter
Dieser Block entscheidet, ob Google Ads auf echten Zahlen bietet.
transaction_idist vorhanden und je Bestellung eindeutig. Nicht das Cart-Token, kein Zeitstempel, kein statischer Wert.valuestimmt für dieselbe Bestellung mit dem Shopsystem überein. Halte fest, welches Feld du nimmst:checkout.subtotalPrice.amountist seit dem 24. April 2025 auf der neuen Danke-Seite und in den Checkout-Ereignissen nach Produkt- und Bestellrabatten berechnet, vorher fehlten die Bestellrabatte (Changelog).checkout.totalPrice.amountenthält Steuer und Versand.currencyist explizit gesetzt, auch in einem Shop mit nur einer Währung.taxundshippingfolgen derselben Konvention wie das Shop-Reporting. Entscheide, ob der Wert sie enthält und dokumentiere die Entscheidung.couponist gesetzt, wenn ein Rabatt angewendet wurde und stimmt auch bei zwei kombinierten Codes. Quelle istcheckout.discountApplications.priceundquantityje Artikel ergeben in Summe den Bestellwert, bis auf Rundung.- Mehrere Währungen: gemeldet wird die tatsächlich belastete Währung aus
checkout.currencyCode, nicht die Standardwährung des Shops.
Block 5: Consent
- Die Shopify Customer Privacy API wird ausgelesen, nicht angenommen. Im Storefront sind das
analyticsProcessingAllowed(),marketingAllowed(),preferencesProcessingAllowed()undsaleOfDataAllowed(), im Pixel steht derselbe Zustand ininit.customerPrivacy(Customer Privacy API, Pixel Privacy). Das Cookie_tracking_consentist seit dem 15. September 2025 kein Ersatz mehr, siehe Punkt 17. - Ein Listener auf Consent-Änderungen ist registriert, damit eine spätere Zustimmung korrekt behandelt wird. Das Ereignis heißt
visitorConsentCollected, im Storefront als Document-Event, im Pixel übercustomerPrivacy.subscribe. - Analytics- und Marketing-Consent werden getrennt behandelt. Ein Pixel, das nur bei beiden Kategorien lädt, verliert stillschweigend Analytics-Daten. Genau das ist der Standard für neue Pixels: sie verlangen Marketing und Analytics. Stelle die Berechtigung je Pixel bewusst ein und prüfe, was bei reiner Analytics-Zustimmung noch lädt.
- Der Default-Zustand steht, bevor irgendein Tag ausgeführt wird.
- Der Update-Zustand erreicht Google nach der Entscheidung, geprüft am Netzwerk-Request statt an der Banner-Oberfläche. Seit dem 15. Juni 2026 steuert die Google-Signals-Einstellung in GA4 nur noch die Verknüpfung von Analytics-Daten mit angemeldeten Nutzern für Verhaltensberichte. Für Google Ads gelten ausschließlich die über Consent Mode übermittelten Entscheidungen (Google Analytics Hilfe). Prüfe deshalb, dass
ad_storage,ad_user_dataundad_personalizationvom Banner korrekt gesetzt werden und nichts auf eine GA4-Einstellung vertraut. Wie die gängigen Banner mit Consent Mode v2 verbunden werden, steht im Leitfaden Cookie-Banner mit Consent Mode v2 verbinden. - Keine rückwirkende Wiedergabe im Basic Mode.
- Falls eine WordPress-Hauptseite existiert, wird deren CMP getrennt geprüft und die beiden Systeme werden abgeglichen oder die Differenz wird dokumentiert.
Was die beiden Consent-Modi unterscheidet und was sie jeweils tatsächlich verändern, steht im Leitfaden Consent Mode Basic vs. Advanced.
Block 6: Google Ads
- Die Conversion-Aktion liegt im Ads-Konto des Auftraggebers, mit durchgereichtem Wert, Währung und Transaktions-ID. Den Aufbau von Grund auf beschreibt der Leitfaden Google Ads Conversion-Tracking einrichten.
- Die Zählmethode ist eine bewusste Entscheidung, nicht der Standardwert.
- Ein GA4-Import, eine native Aktion und die Aktion der Google & YouTube App sind nicht gleichzeitig primär. Google empfiehlt, die App-Conversion als primär zu setzen und Alt-Tags zu entfernen, wenn du die App nutzt (Google Ads Hilfe). Umgekehrt gilt dasselbe: wer über GTM misst, schaltet die App-Aktion auf sekundär.
- Enhanced Conversions werden nur dort aktiviert, wo die User-Provided-Data-Variable korrekt befüllt ist und Marketing-Consent vorliegt. Die gehashte Nutzlast wird im Netzwerk-Request geprüft. Bei App-Pixeln kommt hinzu: seit dem 10. Dezember 2025 setzt Shopify E-Mail, Name, Telefon und Adresse in Ereignissen von App-Pixeln auf
null, wenn die App keine Freigabe für geschützte Kundendaten hat. Custom Pixels sind davon nicht betroffen (Changelog). Wenn eine App Enhanced Conversions oder eine Conversions API befüllt, prüfe im Netzwerk-Request, dass die Felder tatsächlich gefüllt sind.
Block 7: Der Testkauf
Nichts von oben zählt, bevor eine Bestellung vollständig durchgelaufen ist.
- Führe einen echten Testkauf durch und prüfe in dieser Reihenfolge:
- Artikelansicht, Warenkorb, Checkout-Start und Kauf erscheinen alle in der GA4 DebugView
- Kaufwert, Währung, Steuer, Versand und Gutschein stimmen mit der Shopify-Bestellung überein
- die Transaktions-ID in GA4 entspricht der Bestellnummern-Konvention aus Shopify
- der Google-Ads-Conversion-Request feuert mit demselben Wert und derselben ID
- ein erneuter Aufruf der Bestellbestätigung erzeugt keinen zweiten Kauf
- der Aufruf der Bestellstatusseite aus der Bestätigungsmail erzeugt
page_viewedund ebenfalls keinen zweiten Kauf - der Kauf kommt aus genau einem Pfad, geprüft im Netzwerk-Tab und nicht nur in der Tag-Vorschau
- derselbe Durchlauf mit abgelehntem Consent erzeugt keine Messereignisse
- derselbe Durchlauf mit reiner Analytics-Zustimmung erzeugt Analytics-Ereignisse und keine Werbeereignisse
- der Einstieg über die Hauptseite erhält die Kampagnenquelle
- Merchant Center und Produktfeed bleiben unverändert
Storniere oder erstatte die Testbestellung, sobald die Nachweise gesichert sind.
Was trotzdem nicht übereinstimmen wird
Auch ein sauberes Setup lässt sich nicht exakt mit dem Shop-Backend abgleichen. Abgelehnte Einwilligung, Adblocker, Browserrestriktionen, Bestellbestätigungen, die nie fertig laden, Stornierungen und die Verarbeitungslogik der Plattformen hinterlassen immer eine Restdifferenz.
Das Ziel ist keine exakte Übereinstimmung. Das Ziel ist eine Differenz, die du erklären kannst. Wer die eigene beziffern will, findet im Tracking-Abdeckungsrechner den Vergleich von Bestellungen und Umsatz mit dem, was Analytics tatsächlich gemessen hat.
Wann du eskalieren solltest
Wenn diese Liste mehr als zwei strukturelle Defekte zutage fördert, hör mit dem Flicken auf und prüfe richtig. Ein Setup mit doppelten Kaufpfaden, gebrochener Consent-Kette und einer geerbten App, die niemand dokumentiert hat, ist keine Reparatur, sondern ein Neuaufbau mit kontrolliertem Cutover.
Genau dafür gibt es die Web Tracking Foundation: Ausgangsexport, Rollback-Punkt, neuer Pfad im Workspace, Parallelbetrieb, Testkauf, danach Abschalten des alten Pfads.
Fachliche Einordnung, keine Rechtsberatung. Ob ein konkretes Setup deine rechtlichen Pflichten erfüllt, hängt von den verarbeiteten Daten, den Empfängern und der Rechtsgrundlage ab.