Shopify Same-Origin-Tracking: Checkout-Einschränkungen und Lösungen

Die Same-Origin-Methode leitet serverseitige Tracking-Anfragen über die Domain Ihrer Website statt über eine separate Tracking-Subdomain.

Sie legt fest, wann zwei URLs zum selben Web-Origin gehören. Ein Origin besteht aus drei Komponenten: Schema (https:// oder http://), Hostname (z. B. shop.example.com) und Port (zum Beispiel 443 für HTTPS).

Der URL-Pfad ist eine separate Komponente einer URL und bestimmt nicht deren Origin. So haben beispielsweise diese URLs denselben Origin, obwohl die zweite einen Pfad enthält:

• https://shop.example.com/
• https://shop.example.com/metrics

Ein gemeinsamer Origin auf URL-Ebene garantiert jedoch nicht, dass jede Browserumgebung oder Plattform eine Anfrage an diesen Endpunkt zulässt. Ein Beispiel dafür ist der Shopify-Checkout, den wir in diesem Leitfaden ausführlich behandeln.

Das Shopify-Checkout-Tracking läuft in einer stärker eingeschränkten Umgebung als die Storefront. Je nach Checkout-Implementierung können Skripte mit Einschränkungen bei Netzwerkanfragen, Browser-APIs und Interaktionen mit anderen Origins ausgeführt werden.

Diese Einschränkungen gelten für Ihre Tracking-Implementierung in der Checkout-Sandbox und beeinflussen auch die Funktionsweise der Tracking-Lösungen.

Zu den häufigsten Einschränkungen, die jedem Tracking-Spezialisten auffallen dürften, gehört, dass Sie die Checkout-Ereignisse beim Testen des Setups standardmäßig nicht in GTM Preview sehen können. Das liegt daran, dass das GTM-Container-Snippet in die Checkout-Sandbox geladen wird und GTM Preview schlicht nicht weiß, wo es nach dem Container suchen soll. Um das GTM-Debugging im Checkout zu aktivieren, muss der Tracking-Code für Ihre eigene Browsersitzung in die übergeordnete Seite geladen werden. Mit der Chrome-Erweiterung Stape GTM Helper gelingt das mit wenigen Klicks.

Die Einschränkung von GTM Preview ist nur ein Beispiel dafür, wie sich die Checkout-Umgebung von Shopify von den Storefront-Seiten unterscheidet. Im Hintergrund beeinflussen Sandbox-Einschränkungen auch, wie Browser die Kommunikation zwischen Domains handhaben, was sich auf das Tracking über Same-Origin-Domains auswirkt.

Ein Same-Origin-Endpunkt ist ein nützlicher Ansatz für das Tracking auf der Storefront, stößt im Shopify-Checkout jedoch an Grenzen.

Wenn ein Shopify-Checkout-Pixel versucht, eine Anfrage an den Same-Origin-Endpunkt zu senden (z. B. ein GA4-Ereignis im Format https://shop.stapedesk.com/metrics/g/collect), kann die Browserkonsole einen Fehler ähnlich dem im folgenden Screenshot melden:

In unserem Test schlug die Anfrage mit einem RestrictedUrlError fehl. Das zeigt, dass das Checkout-Pixel versucht hat, die XHR/fetch-Anfrage an dieselbe Domain zu senden, auf der die Storefront läuft, die Anfrage jedoch von der Shopify-Pixel-Runtime abgelehnt wurde, bevor der Browser sie gesendet hat.

Was sagt die Dokumentation von Shopify?

Ein solcher Fehler wurde in der Shopify Community gemeldet, doch derzeit dokumentiert die Shopify-Dokumentation die genaue Regel, die Same-Origin-Anfragen im Checkout blockiert, nicht direkt.

Shopify stellt jedoch Informationen zur zugrunde liegenden Architektur bereit, die erklären können, warum das passiert. Laut Shopifys Seite zu Web Pixels lädt Shopify Web Pixels, wie bereits erwähnt, in einer Sandbox-Umgebung im Browser des Besuchers.

Das bedeutet, dass ein Checkout-Pixel nicht mit denselben Möglichkeiten ausgeführt wird wie andere Skripte, die direkt zum Shopify-Theme hinzugefügt wurden. Das Pixel läuft innerhalb der kontrollierten Runtime von Shopify, die Browser-APIs und Netzwerkanfragen einschränkt.

Daher werden Anfragen eines Web Pixels nach den Regeln der Sandbox-Umgebung bewertet, in der das Pixel läuft, und nicht nur anhand der Ziel-URL (der URL, die die Anfrage empfängt).

Entscheidend ist: „Dieselbe Domain“ bedeutet nicht immer „derselbe Ausführungskontext“. Eine URL, die aus Sicht der Storefront des Händlers Same-Origin ist, kann dennoch eingeschränkt sein, wenn aus der Web-Pixel-Sandbox von Shopify darauf zugegriffen wird.

Der folgende Test zeigt, dass die Web-Pixel-Sandbox von Shopify nicht einfach alle Anfragen an die Storefront-Domain blockiert. Die Einschränkung gilt vielmehr gezielt für programmatische HTTP-Anfragen wie fetch() und XMLHttpRequest.

Während des Tests wurden die Checkout-Ereignisse in einem Shopify-Shop mit zwei Setups ausgelöst – Same-Origin-Endpunkt und Tracking-Subdomain. Ein Vergleich der Anfragetypen zeigt das Verhalten:

Das könnte erklären, warum Tracking-Ansätze auf Basis von Bildpixeln (Ihre page_views, die überwiegend GET-Anfragen sind) funktionieren können, während serverseitige Tracking-Implementierungen, die fetch() an einen Same-Origin-Endpunkt nutzen, fehlschlagen können.

Es scheint, dass GET- und beacon-Anfragen schlicht nicht über Shopifys eigenen Wrapper für XHR und fetch geleitet werden und daher jederzeit stillschweigend eingeschränkt werden könnten – vorausgesetzt, es handelt sich um ein Versehen. Das ist natürlich Spekulation.

Ein Service Worker ist eine JavaScript-Datei, die getrennt von der Hauptseite des Browsers ausgeführt wird. Er wird häufig für Funktionen wie Offline-Unterstützung, Caching und das Abfangen von Netzwerkanfragen eingesetzt.

Im Kontext des Shopify-Checkout-Trackings kann er Netzwerkanfragen abfangen und dabei helfen, sie auch dann zu verarbeiten, wenn das Seitenverhalten unterbrochen wird. Diese Lösung nutzt Google Analytics 4, um den Verlust von Tracking-Anfragen zu verringern.

Da Sie jedoch nicht explizit steuern, welches Ereignis über den Worker gesendet wird, und GA4 sie nicht für diesen Anwendungsfall eingeführt hat, sollten Sie sich beim Tracking von Shopify-Checkout-Ereignissen nicht auf sie verlassen. Sicher, Sie können einige checkout-/purchase-Ereignisse erfassen, und es mag so aussehen, als würde alles funktionieren – doch das ist reines Glück. Testen Sie weiter.

Selbst wenn Same-Origin-Anfragen in der Sandbox für benutzerdefinierte Ereignisse von Shopify nicht blockiert würden, wäre ihr praktischer Nutzen aufgrund der Sandbox-Umgebung von Shopify begrenzt (ja, schon wieder).

Der Same-Origin-Ansatz ist insbesondere deshalb vorteilhaft, weil er es ermöglicht, Cookies in ITP und ähnlichen Umgebungen mit ihrer vorgesehenen Lebensdauer zu setzen. In der Checkout-Sandbox werden Cookies jedoch nicht in Ihren Tracking-Anfragen mitgesendet; ebenso wenig funktioniert es, sie über Antworten zu setzen. Deshalb enthält unser Data Tag die Option Send Common Cookies, die die Cookies zur Payload der Anfrage hinzufügt.

Da der Sandbox-iframe ohne allow-same-origin eingerichtet ist, weist der Browser ihm einen opaken Origin zu, sodass er stets als null erscheint. Das geschieht selbst dann, wenn der iframe von der eigenen Domain des Shops ausgeliefert wird, und unabhängig davon, ob die Anfrage explizit ‘credentials: include’ oder ‘mode: cors’ setzt. Infolgedessen stuft der Browser diese Anfragen beim Umgang mit Cookies als Cross-Site ein. Einfach ausgedrückt: Der Browser behandelt die zugehörigen Cookies als Third-Party-Cookies.

Simo Ahava hat dieses Cookie-Problem im Shopify-Checkout bereits 2024 ausführlich beschrieben.

Für Shopify-Shops mit konfiguriertem serverseitigem Tracking empfiehlt sich ein hybrider Ansatz:

• Same-Origin-Ansatz auf der Storefront;
• Standard-Subdomain-Routing für den Checkout.

Auf der Storefront bietet Same-Origin-Tracking die erwarteten Vorteile (verbessertes First-Party-Routing der Anfragen, bessere Cookie-Verarbeitung und höhere Ausfallsicherheit des Trackings), da die Tracking-Anfragen aus demselben Domain-Kontext wie die Website gesendet werden.

Der Shopify-Checkout weist jedoch Einschränkungen auf, die verhindern, dass der Same-Origin-Ansatz dort genauso funktioniert wie auf der Storefront. Daher ist das Standard-Subdomain-Routing besser geeignet. Wenn Tracking-Anfragen über eine dedizierte Tracking-Subdomain geleitet werden, lässt sich genau diese Einschränkung umgehen, sodass die Anfragen den Tracking-Endpunkt erreichen.

Das Same-Origin-Setup für die Shopify-Storefront lässt sich mit verschiedenen DNS- und Infrastrukturanbietern konfigurieren. Die genaue Konfiguration hängt vom verwendeten Anbieter ab.

Cloudflare bietet beispielsweise eine Orange-to-Orange-Integration (O2O), mit der der Traffic sowohl über die Cloudflare-Zone des Händlers als auch über die Cloudflare-Infrastruktur von Shopify geleitet werden kann. Das ermöglicht zusätzliche Kontrolle über die Traffic-Verarbeitung, während Ihre Domain gleichzeitig der Einstiegspunkt bleibt.

Andere Anbieter bieten möglicherweise ähnliche Lösungen über Reverse Proxy, CDN oder benutzerdefinierte Hostnamen an, die Konfigurationsschritte und unterstützten Funktionen können sich jedoch je nach Plattform unterscheiden.

Verwenden Sie für den Shopify-Checkout eine Standard-Subdomain-Konfiguration.

Anders als beim Same-Origin-Setup müssen für die Subdomain-Konfiguration DNS-Einträge hinzugefügt werden, um die Subdomain mit Ihrem Anbieter für serverseitiges Tracking zu verbinden.

Sobald Ihre Tracking-Domains für Storefront und Checkout konfiguriert sind, müssen Sie GTM so einrichten, dass Ereignisdaten an Ihren serverseitigen Container gesendet werden.

Fügen Sie in Ihrem Web-GTM-Container die Vorlage Data Tag hinzu und konfigurieren Sie sie. Dieses Tag sendet Ereignisdaten zusammen mit den konfigurierten Parametern an Ihren Server-GTM-Container.

Installieren und konfigurieren Sie im Server-GTM-Container den Data Client. Der Data Client empfängt und verarbeitet die Anfragen des Data Tag. Auf diese Weise stehen die eingehenden Ereignisdaten den Server-GTM-Tags zur Verfügung.

Diese Option sendet häufig verwendete Browser-Cookie-Werte zusammen mit den Ereignisdaten. Sie sind wichtig für Attribution, Nutzeridentifikation und Conversion-Tracking, insbesondere wenn Shopify-Checkout-Ereignisse in einer isolierten Umgebung mit eingeschränktem Zugriff auf Storefront-Daten ausgeführt werden.

Aktivieren Sie diese Option für jedes Data Tag, das auf der Checkout-Seite ausgelöst werden soll.

Die Logik zur Domain-Auswahl wird im Web-GTM-Container umgesetzt, da diese Entscheidung vor dem Senden der Anfrage getroffen werden muss. Anschließend empfängt der Server-Container die Anfragen vom ausgewählten Endpunkt und verarbeitet sie mit den konfigurierten Clients und Tags weiter.

Verwenden Sie zur Umsetzung der Logik die Variable RegEx Table.

3.1 Um sie zu konfigurieren, öffnen Sie im Web-GTM den Bereich Variables → klicken Sie auf New → wählen Sie RegEx Table als Variablenkonfiguration aus.

[Image alt: RegEx Table]

3.2 Wählen Sie eine Input Variable für die Variable aus.

Die konkrete Bedingung hängt vom Ablauf Ihrer Shopify-Website ab. In unserem Fall werden die Checkout- und die Danke-Seite (thank-you) auf derselben Domain gehostet, der Page Path unterscheidet sich jedoch.

Wenn Sie weitere Details dazu benötigen, wie Sie die Input Variable für Ihre Shopify-Website finden, klicken Sie auf das ausklappbare Element unten:

Geben Sie die Input Variable an (in unserem Fall Page Path).

3.3 Geben Sie das Muster und die gewünschte Ausgabe ein.

Geben Sie das Pattern mithilfe regulärer Ausdrücke ein.

Für unseren Ablauf funktioniert der folgende reguläre Ausdruck:

Er trifft auf jeden String zu, der mit /checkouts beginnt, unabhängig davon, was danach folgt.

Geben Sie als Output Ihre Subdomain an, die für das Tracking in der Sandbox-Umgebung verwendet werden soll.

Wenn ein Wert in mehreren GTM-Entitäten verwendet wird, definieren Sie ihn einmal als Variable vom Typ Konstante und verwenden Sie diese Variable überall dort, wo sie benötigt wird.

Aktivieren Sie das Kontrollkästchen Set Default Value und fügen Sie eine Variable mit Ihrer Same-Origin-Domain als Default Value hinzu.

Hier ein Beispiel für die Variablenkonfiguration:

Speichern Sie die Änderungen.

Ersetzen Sie in Ihren Tags alle fest codierten Same-Origin-URL-Werte oder Variablen mit der Same-Origin-URL durch die Variable RegEx Table.

Die Variable gibt automatisch die richtige Domain basierend auf dem aktuellen Seitenkontext zurück, sodass Anfragen aus der Storefront- und der Checkout-Umgebung über den jeweils passenden Endpunkt geleitet werden.

Unten sehen Sie ein Beispiel. Überprüfen Sie die Tags in Ihrem Web-GTM-Container und aktualisieren Sie sie bei Bedarf.

Prüfen Sie, ob das Tracking-Setup sowohl in der Storefront- als auch in der Checkout-Umgebung korrekt funktioniert.

Um die Debugging-Details anzuzeigen, klicken Sie unten auf das entsprechende ausklappbare Element:

Checkout-Tracking in Shopify ist anspruchsvoll, insbesondere im Kontext des serverseitigen Trackings. Der Same-Origin-Ansatz bietet auf den Storefront-Seiten alle Vorteile, die Checkout-Umgebung weist jedoch Sandbox-Einschränkungen auf, die verhindern, dass derselbe Ansatz dort korrekt funktioniert.

Die beste Lösung ist derzeit, Ihre Tracking-Architektur an die Shopify-Umgebung anzupassen: Behalten Sie das Same-Origin-Setup dort bei, wo es Mehrwert bringt, und verwenden Sie für Checkout-Ereignisse einen Standard-Subdomain-Ansatz. Mit der richtigen GTM-Konfiguration und einem sauberen Testprozess können Sie ein genaues Tracking über die gesamte Customer Journey hinweg aufrechterhalten.

Bleiben Sie über Neuigkeiten von Stape auf dem Laufenden. Wir arbeiten ständig daran, unsere Lösungen für serverseitiges Tracking zu verbessern und mit den Veränderungen im Shopify-Ökosystem Schritt zu halten. Wir wissen, wie wichtig genaues Tracking für Ihr Unternehmen ist, und suchen nach besseren Wegen, diese Herausforderungen zu meistern und unsere neuesten Erkenntnisse mit Ihnen zu teilen!