Tracking same-origin su Shopify: limiti del checkout e soluzioni

Il metodo same-origin instrada le richieste di tracking lato server attraverso il dominio del sito web anziché tramite un sottodominio di tracking separato.

Definisce quando due URL appartengono alla stessa origine web. Un’origine è composta da tre elementi: schema (https:// o http://), nome host (ad es. shop.example.com) e porta (ad esempio, 443 per HTTPS).

Il percorso dell’URL è un componente separato dell’URL e non ne determina l’origine. Ad esempio, questi URL hanno la stessa origine, anche se il secondo contiene un percorso:

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

Tuttavia, condividere un’origine a livello di URL non garantisce che ogni ambiente browser o piattaforma consenta una richiesta verso quell’endpoint. Un esempio è il checkout di Shopify, che trattiamo in dettaglio in questa guida.

Il tracking del checkout di Shopify viene eseguito in un ambiente più restrittivo rispetto alla vetrina. A seconda dell’implementazione del checkout, gli script possono essere eseguiti con restrizioni sulle richieste di rete, sulle API del browser e sulle interazioni con altre origini.

Queste restrizioni si applicano all’implementazione del tracking nella sandbox del checkout e influiscono anche sul funzionamento delle soluzioni di tracking.

Tra le restrizioni più comuni che qualsiasi specialista di tracking potrebbe notare c’è il fatto che, per impostazione predefinita, non è possibile vedere gli eventi del checkout in GTM Preview durante il test della configurazione. Ciò accade perché lo snippet del container GTM viene caricato nella sandbox del checkout e GTM Preview semplicemente non sa dove cercare il container. Per abilitare il debug di GTM nel checkout, il codice di tracking deve essere caricato nella pagina principale (parent) per la propria sessione del browser. L’estensione Chrome Stape GTM Helper consente di farlo in pochi clic.

La limitazione di GTM Preview è solo un esempio di come l’ambiente del checkout di Shopify differisca dalle pagine della vetrina. Dietro le quinte, le restrizioni della sandbox influiscono anche sul modo in cui i browser gestiscono la comunicazione tra domini, con ripercussioni sul tracking tramite domini same-origin.

Un endpoint same-origin è un approccio utile per il tracking sulla vetrina, ma presenta dei limiti durante il checkout di Shopify.

Quando un pixel del checkout di Shopify tenta di inviare una richiesta all’endpoint same-origin (ad es. un evento GA4 nel formato https://shop.stapedesk.com/metrics/g/collect), la console del browser può segnalare un errore simile a quello nello screenshot qui sotto:

Nel nostro test, la richiesta non è andata a buon fine con un RestrictedUrlError, il che indica che il pixel del checkout ha tentato di effettuare la richiesta XHR/fetch verso lo stesso dominio su cui è in esecuzione la vetrina, ma la richiesta è stata rifiutata dal runtime dei pixel di Shopify prima che il browser la inviasse.

Cosa dice la documentazione di Shopify?

Questo errore è stato segnalato nella Shopify Community, ma al momento la documentazione di Shopify non documenta direttamente la regola esatta che blocca le richieste same-origin nel checkout.

Tuttavia, Shopify fornisce informazioni sull’architettura sottostante che possono spiegare perché ciò accade. Secondo la pagina di Shopify dedicata ai web pixel, Shopify carica i Web Pixel all’interno di un ambiente sandbox nel browser del visitatore, come già accennato.

Ciò significa che un pixel del checkout non viene eseguito con le stesse capacità degli altri script aggiunti direttamente al tema Shopify. Il pixel viene eseguito all’interno del runtime controllato di Shopify, che applica restrizioni alle API del browser e alle richieste di rete.

Per questo motivo, le richieste effettuate da un Web Pixel vengono valutate in base alle regole dell’ambiente sandbox in cui è in esecuzione il pixel, e non solo in base all’URL di destinazione (l’URL che riceve la richiesta).

Il punto chiave è che “stesso dominio” non significa sempre “stesso contesto di esecuzione”. Un URL che è same-origin dal punto di vista della vetrina del merchant può comunque essere soggetto a restrizioni quando vi si accede dalla sandbox dei Web Pixel di Shopify.

Il test seguente mostra che la sandbox dei Web Pixel di Shopify non blocca semplicemente tutte le richieste verso il dominio della vetrina. La restrizione si applica specificamente alle richieste HTTP programmatiche come fetch() e XMLHttpRequest.

Durante il test, gli eventi del checkout sono stati attivati su due configurazioni in un negozio Shopify: endpoint same-origin e sottodominio di tracking. Un confronto tra i tipi di richiesta mostra il comportamento:

Questo potrebbe spiegare perché gli approcci di tracking basati su pixel immagine (le page_views, che sono per lo più richieste GET) possono funzionare, mentre le implementazioni di tracking lato server che usano fetch() verso un endpoint same-origin possono fallire.

Sembra che le richieste GET e beacon semplicemente non passino attraverso il wrapper di Shopify per XHR e fetch e, di conseguenza, potrebbero essere limitate senza preavviso in qualsiasi momento, ammesso che si tratti di una svista. Si tratta, ovviamente, di un’ipotesi.

Un service worker è un file JavaScript che viene eseguito separatamente dalla pagina principale del browser. Viene comunemente utilizzato per funzionalità come il supporto offline, il caching e l’intercettazione delle richieste di rete.

Nel contesto del tracking del checkout di Shopify, può intercettare le richieste di rete e aiutare a gestirle anche quando il comportamento della pagina viene interrotto. È la soluzione che Google Analytics 4 utilizza per contribuire a ridurre la perdita di richieste di tracking.

Tuttavia, poiché non si controlla esplicitamente quale evento verrà inviato tramite il worker e questo non è il caso d’uso per cui GA4 li ha introdotti, non è consigliabile affidarsi a essi per il tracking degli eventi del checkout di Shopify. Certo, si possono intercettare alcuni eventi checkout/purchase e può sembrare che tutto funzioni, ma è pura fortuna: è meglio eseguire altri test.

Anche se le richieste same-origin non venissero bloccate nella sandbox degli eventi personalizzati di Shopify, i loro vantaggi pratici sarebbero limitati a causa dell’ambiente sandbox di Shopify (sì, di nuovo).

L’approccio same-origin è vantaggioso in particolare perché consente di impostare i cookie con la durata prevista in ITP e in ambienti simili. Ma nella sandbox del checkout i cookie non vengono inclusi nelle richieste di tracking e, allo stesso modo, nemmeno impostarli tramite le risposte funzionerà. Ecco perché il nostro Data Tag include l’opzione Send Common Cookies, che aggiunge i cookie al payload della richiesta.

Poiché l’iframe della sandbox è impostato senza allow-same-origin, il browser gli assegna un’origine opaca, che quindi appare sempre come null. Ciò accade anche quando l’iframe viene servito dal dominio stesso del negozio e indipendentemente dal fatto che la richiesta imposti esplicitamente ‘credentials: include’ o ‘mode: cors’. Di conseguenza, nella gestione dei cookie il browser considera queste richieste cross-site. In parole semplici, il browser tratta i cookie associati come cookie di terze parti.

Simo Ahava ha descritto in dettaglio questo problema dei cookie nel checkout di Shopify già nel 2024.

Per i negozi Shopify con tracking lato server configurato, l’approccio consigliato è ibrido:

• approccio same-origin sulla vetrina;
• instradamento standard tramite sottodominio per il checkout.

Sulla vetrina, il tracking same-origin offre i vantaggi attesi (migliore instradamento delle richieste di prima parte, migliore gestione dei cookie e maggiore resilienza del tracking), poiché le richieste di tracking vengono inviate dallo stesso contesto di dominio del sito web.

Tuttavia, il checkout di Shopify presenta restrizioni che impediscono all’approccio same-origin di funzionare come sulla vetrina. Per questo l’instradamento standard tramite sottodominio è più indicato. Instradare le richieste di tracking attraverso un sottodominio di tracking dedicato consente di evitare questa specifica restrizione e permette alle richieste di raggiungere l’endpoint di tracking.

La configurazione same-origin per la vetrina Shopify può essere effettuata con diversi provider DNS e di infrastruttura. La configurazione esatta dipende dal provider utilizzato.

Ad esempio, Cloudflare offre un’integrazione Orange-to-Orange (O2O) che consente di instradare il traffico sia attraverso la zona Cloudflare del merchant sia attraverso l’infrastruttura Cloudflare di Shopify. Ciò offre un controllo aggiuntivo sulla gestione del traffico e, allo stesso tempo, mantiene il proprio dominio come punto di ingresso.

Altri provider possono offrire soluzioni simili tramite reverse proxy, CDN o funzionalità di hostname personalizzato, ma i passaggi di configurazione e le funzionalità supportate possono variare da una piattaforma all’altra.

Per il checkout di Shopify, utilizzi una configurazione standard con sottodominio.

A differenza di una configurazione same-origin, la configurazione del sottodominio richiede l’aggiunta di record DNS per collegare il sottodominio al proprio provider di tracking lato server.

Una volta configurati i domini di tracking della vetrina e del checkout, è necessario configurare GTM per inviare i dati degli eventi al container lato server.

Nel container GTM web, aggiunga e configuri il template Data Tag. Questo tag invia i dati degli eventi insieme ai parametri configurati al container GTM server.

Nel container GTM server, installi e configuri il Data Client. Il Data Client riceve e analizza le richieste del Data Tag. In questo modo, i dati degli eventi in entrata diventano disponibili per i tag del GTM server.

Questa opzione invia i valori dei cookie del browser più comunemente utilizzati insieme ai dati dell’evento. Sono importanti per l’attribuzione, l’identificazione degli utenti e il tracking delle conversioni, in particolare quando gli eventi del checkout di Shopify vengono eseguiti in un ambiente isolato con accesso limitato ai dati della vetrina.

Attivi questa opzione per ogni Data Tag che deve attivarsi nella pagina del checkout.

La logica di selezione del dominio viene gestita nel container GTM web, poiché questa decisione deve essere presa prima dell’invio della richiesta. Successivamente, il container server riceve le richieste dall’endpoint selezionato e continua a elaborarle tramite i client e i tag configurati.

Per impostare la logica, utilizzi la variabile RegEx Table.

3.1 Per configurarla, vada alla sezione Variables del GTM web → clicchi su New → selezioni RegEx Table come configurazione della variabile.

3.2 Selezioni una Input Variable per la variabile.

La condizione specifica dipende dal flusso del proprio sito Shopify. Nel nostro caso, la pagina di checkout e la pagina di ringraziamento (thank-you) sono ospitate sullo stesso dominio, ma il Page Path è diverso.

Se servono maggiori dettagli su come trovare la Input Variable per il proprio sito Shopify, clicchi sull’elemento espandibile qui sotto:

Specifichi la Input Variable (nel nostro caso, Page Path).

3.3 Inserisca il pattern e l’output richiesto.

Inserisca il Pattern utilizzando le espressioni regolari.

Per il nostro flusso funziona la seguente regex:

Corrisponde a qualsiasi stringa che inizia con /checkouts, indipendentemente da ciò che segue.

Come Output, specifichi il sottodominio da utilizzare per il tracking nell’ambiente sandbox.

Selezioni la casella Set Default Value e aggiunga come Default Value una variabile contenente il proprio dominio same-origin.

Ecco un esempio di configurazione della variabile:

Salvi le modifiche.

Sostituisca nei tag tutti i valori di URL same-origin inseriti direttamente nel codice (hardcoded) o le variabili contenenti l’URL same-origin con la variabile RegEx Table.

La variabile restituirà automaticamente il dominio corretto in base al contesto della pagina corrente, così che le richieste provenienti dagli ambienti della vetrina e del checkout vengano instradate attraverso l’endpoint appropriato.

Di seguito è riportato un esempio. Controlli i tag nel container GTM web e li aggiorni dove necessario.

Verifichi che la configurazione del tracking funzioni correttamente sia nell’ambiente della vetrina sia in quello del checkout.

Per visualizzare i dettagli del debug, clicchi sull’elemento espandibile corrispondente qui sotto:

Il tracking del checkout di Shopify è complesso, in particolare nel contesto del tracking lato server. L’approccio same-origin offre tutti i suoi vantaggi nelle pagine della vetrina, ma l’ambiente del checkout presenta restrizioni della sandbox che impediscono a questo stesso approccio di funzionare correttamente.

La soluzione migliore, per ora, è adattare l’architettura di tracking all’ambiente di Shopify: mantenere la configurazione same-origin dove porta valore e utilizzare un approccio standard con sottodominio per gli eventi del checkout. Con la corretta configurazione di GTM e un adeguato processo di test, è possibile mantenere un tracking accurato lungo l’intero percorso dell’utente.

Continui a seguire gli aggiornamenti di Stape. Lavoriamo costantemente per migliorare le soluzioni di tracking lato server e stare al passo con i cambiamenti dell’ecosistema Shopify. Sappiamo quanto sia importante un tracking accurato per la Sua attività e cerchiamo modi migliori per superare queste sfide e condividere con Lei le nostre ultime scoperte!