christian baumgertel

Blog · Shopify

Shopify mit Checkout Extensibility sauber tracken

Seit Checkout Extensibility läuft Tracking im Shopify-Checkout nur noch in einer Sandbox. Das ist gut für Sicherheit und Ladezeit, aber es ändert, wie man misst und wie man testet.

· 4 min Lesezeit · Christian Baumgertel

Was sich geändert hat

Früher klebte man Skripte in checkout.liquid oder in „Additional Scripts“. Das gibt es nicht mehr. Im Checkout bleiben zwei Wege: App-Pixel und Custom Pixel. Shopify lädt App-Pixel in einer strikten Sandbox (Web Worker) und Custom Pixel in einer „lax“ Sandbox, einem iframe mit allow-scripts und allow-forms. Beide haben keinen Zugriff auf das DOM der Seite.

In meinen Projekten nutze ich für den Checkout ein einziges Custom Pixel, das den Google Tag Manager lädt. Apps setze ich nur ein, wenn es nicht anders geht. Der Grund ist Kontrolle: Apps dokumentieren selten, welche Bibliotheken sie nachladen. Ich habe erlebt, dass sich App-Skripte und eigenes Tracking gegenseitig gestört haben, etwa bei Meta-Conversions. Die Fehlersuche dauerte länger als jede Implementierung.

Die Grenzen der Sandbox

Fast jedes Problem im Custom Pixel lässt sich auf eine dieser fünf Grenzen zurückführen:

  1. Kein DOM. Klicks, Formulare oder Elemente lassen sich nicht direkt auslesen. Was Sie messen können, kommt aus den Shopify-Events (analytics.subscribe) und dem init-Objekt.
  2. Falsche URL. GA4 und andere Tags sehen die URL der Sandbox, nicht die des Shops. Die echte URL steht im Event-Kontext und muss aktiv als page_location mitgegeben werden. Fehlt sie, fehlen auch UTM-Parameter und Klick-IDs.
  3. Cookies nur über eine API. document.cookie meint das iframe, nicht den Shop. Cookies der Hauptseite liest man über browser.cookie.get(), und das ist asynchron: Es liefert ein Promise, keinen String.
  4. Consent kommt von Shopify. Der Einwilligungsstatus steht in init.customerPrivacy und ändert sich über das Event visitorConsentCollected. Wer zusätzlich das CMP-Cookie selbst parst, baut eine zweite Wahrheit.
  5. Wenig Werkzeug. Die Versionshistorie im Admin ist kurz, und getestet wird am veröffentlichten Pixel. Ich führe den Pixel-Code deshalb in Git und veröffentliche nur, was dort committet ist.

Ein Fehler, der lehrreich war

In einem Projekt sollte nur ein redundantes Consent-Skript aus dem Pixel entfernt werden. Beim Testen fielen Sprünge im Consent-Status auf. Ein schneller Workaround las daraufhin zusätzlich das CMP-Cookie aus. Weil browser.cookie.get() ein Promise liefert, wurde das Ergebnis als leerer Consent gedeutet. Ab da gingen Checkout-Events mit „abgelehnt“ raus, obwohl Nutzer zugestimmt hatten. Ein Rollback hat es behoben.

Drei Regeln, die ich daraus mitgenommen habe:

  • Consent nur aus einer Quelle lesen, im Pixel aus init.customerPrivacy und dem Consent-Event.
  • Änderungen an Consent-Logik end-to-end testen, bis zum ausgehenden Request im sGTM, nicht nur bis zum Data Layer.
  • Marketing und Data vor jedem Deployment informieren, auch bei „kleinen“ Änderungen.

Ein zweites Muster sehe ich häufig im Theme: Liquid-Werte, die ohne Anführungszeichen in einen dataLayer.push geschrieben werden. Für manche Kunden entsteht dadurch ungültiges JavaScript. Der ganze Push bricht ab, es gibt keinen page_view und keine GA4-Session. Werte aus Liquid gehören immer durch | json.

QA: in welchem Fenster Sie suchen müssen

Der häufigste Satz beim Testen ist „der Data Layer ist leer“. Meist schaut man nur in das falsche Fenster. Jedes Custom Pixel läuft in einem eigenen iframe mit eigenem window, eigenem dataLayer und eigenem GTM.

  1. Chrome DevTools öffnen, Tab Console.
  2. Oben links im Kontext-Menü (Standard: top) das iframe des Pixels wählen. Shopify benennt es nach dem Muster web-pixel-sandbox-CUSTOM-…. Jedes Custom Pixel erscheint als eigener Eintrag, App-Pixel laufen als Worker.
  3. Im richtigen Kontext dataLayer eingeben. Jetzt sehen Sie die Events, die das Pixel an GTM übergibt.
  4. Im Tab Network nach der Domain Ihres Server-Containers filtern. Dort prüfen Sie den Request selbst: Event-Name, page_location, Parameter und die Consent-Felder (gcs, gcd).
  5. Im sGTM-Preview kontrollieren, welche Tags feuern und was sie an die Plattformen senden.

Der GTM-Vorschaumodus des Web-Containers verbindet sich mit der Sandbox nach meiner Erfahrung nicht zuverlässig. Ich teste deshalb über Console, Network und sGTM-Preview.

Checkliste vor dem Go-live

  • page_location kommt aus dem Event-Kontext, nicht aus der Sandbox
  • Consent stammt aus init.customerPrivacy, kein eigenes Cookie-Parsing
  • Jeder browser.cookie-Zugriff wird mit await gelesen
  • purchase feuert einmal, auch bei Neuladen der Danke-Seite
  • Pixel-Code liegt versioniert in Git
  • Keine App sendet dieselben Events zusätzlich

Quellen: Shopify: Web Pixels API · Shopify: Sandbox-Umgebungen