Shopify same-origin tracking: beperkingen van de checkout en oplossingen

De same-origin-methode leidt server-side trackingverzoeken via het domein van uw website in plaats van via een apart trackingsubdomein.

Ze bepaalt wanneer twee URL’s tot dezelfde web-origin behoren. Een origin bestaat uit drie onderdelen: scheme (https:// of http://), hostnaam (bijv. shop.example.com) en poort (bijvoorbeeld 443 voor HTTPS).

Het URL-pad is een afzonderlijk onderdeel van een URL en bepaalt de origin niet. Deze URL’s hebben bijvoorbeeld dezelfde origin, ook al bevat de tweede een pad:

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

Een gedeelde origin op URL-niveau garandeert echter niet dat elke browseromgeving of elk platform een verzoek naar dat endpoint toestaat. Een voorbeeld hiervan is de Shopify-checkout, die we in deze handleiding uitgebreid bespreken.

Checkout-tracking in Shopify draait in een beperktere omgeving dan de storefront. Afhankelijk van de checkout-implementatie kunnen scripts worden uitgevoerd met beperkingen op netwerkverzoeken, browser-API’s en interacties met andere origins.

Deze beperkingen gelden voor uw trackingimplementatie in de checkout-sandbox en hebben ook invloed op de werking van trackingoplossingen.

Een van de meest voorkomende beperkingen die elke trackingspecialist kan opmerken, is dat u de checkout-events standaard niet ziet in GTM Preview wanneer u de setup test. Dit komt doordat het GTM-containerfragment in de checkout-sandbox wordt geladen en GTM Preview simpelweg niet weet waar het de container moet zoeken. Om GTM-debugging in de checkout in te schakelen, moet de trackingcode voor uw eigen browsersessie in de bovenliggende pagina worden geladen. Met de Stape GTM Helper Chrome-extensie doet u dat in een paar klikken.

De beperking van GTM Preview is slechts één voorbeeld van hoe de checkout-omgeving van Shopify verschilt van de storefrontpagina’s. Achter de schermen beïnvloeden sandboxbeperkingen ook hoe browsers communicatie tussen domeinen afhandelen, wat gevolgen heeft voor tracking via same-origin-domeinen.

Een same-origin-endpoint is een nuttige aanpak voor tracking op de storefront, maar kent beperkingen tijdens de Shopify-checkout.

Wanneer een Shopify-checkoutpixel een verzoek probeert te sturen naar het same-origin-endpoint (bijv. een GA4-event in de vorm https://shop.stapedesk.com/metrics/g/collect), kan de browserconsole een fout weergeven die lijkt op die in de onderstaande screenshot:

In onze test mislukte het verzoek met een RestrictedUrlError. Dit geeft aan dat de checkoutpixel probeerde het XHR/fetch-verzoek te versturen naar hetzelfde domein waarop de storefront draait, maar dat het verzoek door de Shopify-pixelruntime werd geweigerd voordat de browser het verstuurde.

Wat zegt de documentatie van Shopify?

Deze fout is gemeld in de Shopify Community, maar op dit moment beschrijft de documentatie van Shopify niet rechtstreeks de exacte regel die same-origin-verzoeken in de checkout blokkeert.

Shopify geeft wel informatie over de onderliggende architectuur die kan verklaren waarom dit gebeurt. Volgens de pagina van Shopify over web pixels laadt Shopify Web Pixels, zoals eerder vermeld, in een sandboxomgeving in de browser van de bezoeker.

Dit betekent dat een checkoutpixel niet met dezelfde mogelijkheden wordt uitgevoerd als andere scripts die rechtstreeks aan het Shopify-thema zijn toegevoegd. De pixel draait binnen de gecontroleerde runtime van Shopify, die beperkingen oplegt aan browser-API’s en netwerkverzoeken.

Daarom worden verzoeken van een Web Pixel beoordeeld volgens de regels van de sandboxomgeving waarin de pixel draait, en niet alleen op basis van de bestemmings-URL (de URL die het verzoek ontvangt).

Het belangrijkste punt is dat ‘hetzelfde domein’ niet altijd ‘dezelfde uitvoeringscontext’ betekent. Een URL die vanuit het perspectief van de storefront van de verkoper same-origin is, kan toch beperkt zijn wanneer deze wordt aangeroepen vanuit de Web Pixel-sandbox van Shopify.

De volgende test laat zien dat de Web Pixel-sandbox van Shopify niet zomaar alle verzoeken naar het storefrontdomein blokkeert. De beperking geldt specifiek voor programmatische HTTP-verzoeken zoals fetch() en XMLHttpRequest.

Tijdens de test werden de checkout-events geactiveerd in twee setups van een Shopify-winkel: same-origin-endpoint en trackingsubdomein. Een vergelijking van de verzoektypes laat het gedrag zien:

Dit zou kunnen verklaren waarom trackingmethoden op basis van afbeeldingspixels (uw page_views, die meestal GET-verzoeken zijn) kunnen werken, terwijl server-side trackingimplementaties die fetch() naar een same-origin-endpoint gebruiken kunnen mislukken.

Het lijkt erop dat GET- en beacon-verzoeken simpelweg niet via de eigen wrapper van Shopify voor XHR en fetch lopen, en daardoor op elk moment ongemerkt kunnen worden beperkt, ervan uitgaande dat dit een vergissing is. Dit is uiteraard speculatief.

Een service worker is een JavaScript-bestand dat los van de hoofdpagina van de browser draait. Het wordt vaak gebruikt voor functies zoals offline ondersteuning, caching en het onderscheppen van netwerkverzoeken.

In de context van Shopify-checkout-tracking kan een service worker netwerkverzoeken onderscheppen en helpen deze af te handelen, zelfs wanneer het gedrag van de pagina wordt onderbroken. Dat is de oplossing die Google Analytics 4 gebruikt om het verlies van trackingverzoeken te helpen beperken.

Omdat u echter niet expliciet bepaalt welk event via de worker wordt verstuurd en GA4 ze niet voor dit gebruiksscenario heeft geïntroduceerd, kunt u er niet op vertrouwen voor het tracken van checkout-events in Shopify. U kunt zeker een paar checkout-/purchase-events vastleggen, en het kan lijken alsof alles werkt, maar dat is puur geluk – test verder.

Zelfs als same-origin-verzoeken niet zouden worden geblokkeerd in de sandbox voor custom events van Shopify, zouden de praktische voordelen beperkt zijn door de sandboxomgeving van Shopify (ja, alweer).

De same-origin-aanpak is vooral nuttig omdat cookies daarmee met hun beoogde levensduur kunnen worden ingesteld in ITP en vergelijkbare omgevingen. Maar in de checkout-sandbox worden cookies niet meegestuurd in uw trackingverzoeken; evenmin werkt het om ze via responses in te stellen. Daarom bevat onze Data Tag de optie Send Common Cookies, die de cookies aan de payload van het verzoek toevoegt.

Omdat het sandbox-iframe is ingesteld zonder allow-same-origin, geeft de browser het een opaque origin, waardoor deze altijd als null verschijnt. Dit gebeurt zelfs wanneer het iframe vanaf het eigen domein van de winkel wordt geladen, en ongeacht of het verzoek expliciet ‘credentials: include’ of ‘mode: cors’ instelt. Hierdoor beschouwt de browser deze verzoeken bij het verwerken van cookies als cross-site. Eenvoudig gezegd: de browser behandelt de bijbehorende cookies als third-party cookies.

Simo Ahava beschreef dit cookieprobleem in de Shopify-checkout al in 2024 uitgebreid.

Voor Shopify-winkels met server-side tracking wordt een hybride aanpak aanbevolen:

• same-origin-aanpak op de storefront;
• standaard routering via een subdomein voor de checkout.

Op de storefront biedt same-origin tracking de verwachte voordelen (betere first-party routering van verzoeken, betere cookieverwerking en veerkrachtigere tracking), omdat de trackingverzoeken vanuit dezelfde domeincontext als de website worden verstuurd.

De Shopify-checkout kent echter beperkingen waardoor de same-origin-aanpak daar niet op dezelfde manier werkt als op de storefront. Standaard routering via een subdomein is daarom geschikter. Door trackingverzoeken via een speciaal trackingsubdomein te leiden, kunt u deze specifieke beperking vermijden, zodat de verzoeken het tracking-endpoint bereiken.

De same-origin-setup voor de Shopify-storefront kan worden geconfigureerd met verschillende DNS- en infrastructuurproviders. De exacte configuratie hangt af van de provider die u gebruikt.

Cloudflare biedt bijvoorbeeld een Orange-to-Orange-integratie (O2O) waarmee verkeer zowel via de Cloudflare-zone van de verkoper als via de Cloudflare-infrastructuur van Shopify kan worden geleid. Dit geeft extra controle over de verwerking van verkeer, terwijl uw domein tegelijk het toegangspunt blijft.

Andere providers bieden mogelijk vergelijkbare oplossingen via een reverse proxy, CDN of functionaliteit voor aangepaste hostnamen, maar de configuratiestappen en ondersteunde functies kunnen per platform verschillen.

Gebruik voor de Shopify-checkout een standaard subdomeinconfiguratie.

Anders dan bij een same-origin-setup moet u bij een subdomeinconfiguratie DNS-records toevoegen om het subdomein te koppelen aan uw provider voor server-side tracking.

Zodra uw trackingdomeinen voor de storefront en de checkout zijn geconfigureerd, moet u GTM zo instellen dat eventgegevens naar uw server-side container worden verstuurd.

Voeg in uw web-GTM-container de template Data Tag toe en configureer deze. Deze tag verstuurt eventgegevens samen met de geconfigureerde parameters naar uw server-GTM-container.

Installeer en configureer in de server-GTM-container de Data Client. De Data Client ontvangt en verwerkt verzoeken van de Data Tag. Zo worden de binnenkomende eventgegevens beschikbaar voor de server-GTM-tags.

Deze optie verstuurt veelgebruikte browsercookiewaarden samen met de eventgegevens. Deze zijn belangrijk voor attributie, gebruikersidentificatie en conversietracking, vooral wanneer Shopify-checkout-events in een geïsoleerde omgeving met beperkte toegang tot storefrontgegevens draaien.

Schakel deze optie in voor elke Data Tag die op de checkoutpagina moet worden geactiveerd.

De logica voor de domeinselectie wordt in de web-GTM-container afgehandeld, omdat deze beslissing moet worden genomen voordat het verzoek wordt verstuurd. Daarna ontvangt de servercontainer de verzoeken van het geselecteerde endpoint en verwerkt deze verder met de geconfigureerde clients en tags.

Gebruik de variabele RegEx Table om de logica in te stellen.

3.1 Ga om deze te configureren naar het onderdeel Variables in de web-GTM → klik op New → selecteer RegEx Table als variabeleconfiguratie.

3.2 Selecteer een Input Variable voor de variabele.

De specifieke voorwaarde hangt af van de flow van uw Shopify-website. In ons geval worden de checkout- en bedankpagina’s (thank-you) op hetzelfde domein gehost, maar verschilt het Page Path.

Als u meer informatie nodig hebt over het vinden van de Input Variable voor uw Shopify-website, klik dan op het uitklapbare element hieronder:

Geef de Input Variable op (in ons geval Page Path).

3.3 Voer het patroon en de gewenste output in.

Voer het Pattern in met behulp van reguliere expressies.

Voor onze flow werkt de volgende regex:

Komt overeen met elke string die begint met /checkouts, ongeacht wat erna volgt.

Geef bij Output uw subdomein op dat moet worden gebruikt voor tracking in de sandboxomgeving.

Vink het vakje Set Default Value aan en voeg een variabele met uw same-origin-domein toe als Default Value.

Hier is een voorbeeld van de variabeleconfiguratie:

Sla de wijzigingen op.

Vervang in uw tags alle hardcoded same-origin-URL-waarden of variabelen met de same-origin-URL door de variabele RegEx Table.

De variabele retourneert automatisch het juiste domein op basis van de context van de huidige pagina, zodat verzoeken uit de storefront- en checkoutomgeving via het juiste endpoint worden geleid.

Hieronder ziet u een voorbeeld. Controleer de tags in uw web-GTM-container en werk ze waar nodig bij.

Controleer of de trackingsetup correct werkt in zowel de storefront- als de checkoutomgeving.

Klik op het betreffende uitklapbare element hieronder om de debuggingdetails te bekijken:

Checkout-tracking in Shopify is een uitdaging, vooral in de context van server-side tracking. De same-origin-aanpak biedt alle voordelen op de storefrontpagina’s, maar de checkoutomgeving kent sandboxbeperkingen waardoor dezelfde aanpak daar niet goed werkt.

De beste oplossing is op dit moment om uw trackingarchitectuur aan te passen aan de Shopify-omgeving: behoud de same-origin-setup waar die waarde toevoegt en gebruik een standaard subdomeinaanpak voor checkout-events. Met de juiste GTM-configuratie en een goed testproces kunt u nauwkeurige tracking behouden over de volledige customer journey.

Blijf op de hoogte van updates van Stape. We werken voortdurend aan het verbeteren van onze server-side trackingoplossingen en houden de veranderingen in het Shopify-ecosysteem nauwlettend bij. We weten hoe belangrijk nauwkeurige tracking is voor uw bedrijf, en we zoeken naar betere manieren om deze uitdagingen aan te pakken en onze nieuwste bevindingen met u te delen!