Suivi de même origine sur Shopify : limites du checkout et solutions

La méthode de même origine achemine les requêtes de suivi côté serveur via le domaine de votre site web plutôt que via un sous-domaine de suivi distinct.

Elle définit quand deux URL appartiennent à la même origine web. Une origine se compose de trois éléments : le schéma (https:// ou http://), le nom d’hôte (p. ex. shop.example.com) et le port (par exemple, 443 pour HTTPS).

Le chemin de l’URL est un élément distinct de l’URL et ne détermine pas son origine. Par exemple, ces URL ont la même origine, bien que la seconde comporte un chemin :

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

Cependant, partager une origine au niveau de l’URL ne garantit pas que chaque environnement de navigateur ou plateforme autorisera une requête vers cet endpoint. C’est le cas, par exemple, du checkout Shopify, que nous abordons en détail dans ce guide.

Le suivi du checkout Shopify s’exécute dans un environnement plus restreint que la vitrine. Selon l’implémentation du checkout, les scripts peuvent s’exécuter avec des restrictions sur les requêtes réseau, les API du navigateur et les interactions avec d’autres origines.

Ces restrictions s’appliquent à votre implémentation de suivi dans la sandbox du checkout et influent également sur le fonctionnement des solutions de suivi.

Parmi les restrictions les plus courantes que tout spécialiste du suivi peut remarquer : par défaut, vous ne pouvez pas voir les événements du checkout dans GTM Preview lorsque vous testez la configuration. Cela s’explique par le fait que l’extrait du conteneur GTM est chargé dans la sandbox du checkout, et GTM Preview ne sait tout simplement pas où chercher le conteneur. Pour activer le débogage GTM sur le checkout, le code de suivi doit être chargé dans la page parente pour votre propre session de navigateur. L’extension Chrome Stape GTM Helper vous permet de le faire en quelques clics.

La limitation de GTM Preview n’est qu’un exemple de la différence entre l’environnement du checkout Shopify et les pages de la vitrine. En arrière-plan, les restrictions de la sandbox influent également sur la manière dont les navigateurs gèrent la communication entre domaines, ce qui a un impact sur le suivi via des domaines de même origine.

Un endpoint de même origine est une approche utile pour le suivi sur la vitrine, mais il présente des limites lors du checkout Shopify.

Lorsqu’un pixel du checkout Shopify tente d’envoyer une requête vers l’endpoint de même origine (p. ex. un événement GA4 au format https://shop.stapedesk.com/metrics/g/collect), la console du navigateur peut afficher une erreur semblable à celle de la capture d’écran ci-dessous :

Lors de notre test, la requête a échoué avec une RestrictedUrlError, ce qui indique que le pixel du checkout a tenté d’effectuer la requête XHR/fetch vers le même domaine que celui où s’exécute la vitrine, mais que la requête a été rejetée par le runtime des pixels Shopify avant que le navigateur ne l’envoie.

Que dit la documentation de Shopify ?

Cette erreur a été signalée dans la Shopify Community, mais, à l’heure actuelle, la documentation de Shopify ne décrit pas directement la règle exacte qui bloque les requêtes de même origine dans le checkout.

Cependant, Shopify fournit des informations sur l’architecture sous-jacente qui peuvent expliquer ce comportement. D’après la page de Shopify consacrée aux web pixels, Shopify charge les Web Pixels dans un environnement isolé (sandbox) dans le navigateur du visiteur, comme mentionné précédemment.

Cela signifie qu’un pixel du checkout ne s’exécute pas avec les mêmes capacités que les autres scripts ajoutés directement au thème Shopify. Le pixel s’exécute dans le runtime contrôlé de Shopify, qui applique des restrictions aux API du navigateur et aux requêtes réseau.

Par conséquent, les requêtes effectuées par un Web Pixel sont évaluées selon les règles de l’environnement sandbox dans lequel le pixel s’exécute, et pas uniquement en fonction de l’URL de destination (l’URL qui reçoit la requête).

Le point clé est le suivant : « même domaine » ne signifie pas toujours « même contexte d’exécution ». Une URL de même origine du point de vue de la vitrine du marchand peut tout de même être restreinte lorsqu’on y accède depuis la sandbox Web Pixel de Shopify.

Le test suivant montre que la sandbox Web Pixel de Shopify ne bloque pas simplement toutes les requêtes vers le domaine de la vitrine. La restriction s’applique plus précisément aux requêtes HTTP programmatiques comme fetch() et XMLHttpRequest.

Pendant le test, les événements du checkout ont été déclenchés sur deux configurations d’une boutique Shopify : endpoint de même origine et sous-domaine de suivi. Une comparaison des types de requêtes montre le comportement :

Cela pourrait expliquer pourquoi les approches de suivi basées sur des pixels image (vos page_views, qui sont principalement des requêtes GET) peuvent fonctionner, alors que les implémentations de suivi côté serveur utilisant fetch() vers un endpoint de même origine peuvent échouer.

Il semble que les requêtes GET et beacon ne passent tout simplement pas par le wrapper propre à Shopify pour XHR et fetch, et qu’elles pourraient donc être limitées sans préavis à tout moment, à supposer qu’il s’agisse d’un oubli. Il ne s’agit, bien entendu, que d’une hypothèse.

Un service worker est un fichier JavaScript qui s’exécute séparément de la page principale du navigateur. Il est couramment utilisé pour des fonctionnalités comme le fonctionnement hors ligne, la mise en cache et l’interception des requêtes réseau.

Dans le contexte du suivi du checkout Shopify, il peut intercepter les requêtes réseau et aider à les traiter même lorsque le fonctionnement de la page est interrompu. C’est la solution qu’utilise Google Analytics 4 pour aider à réduire la perte de requêtes de suivi.

Cependant, comme vous ne contrôlez pas explicitement quel événement sera envoyé via le worker et que ce n’est pas le cas d’usage pour lequel GA4 les a introduits, il ne faut pas compter sur eux pour le suivi des événements du checkout Shopify. Vous pourrez certes capter quelques événements checkout/purchase, et tout semblera peut-être fonctionner, mais c’est un pur hasard : testez davantage.

Même si les requêtes de même origine n’étaient pas bloquées dans la sandbox des événements personnalisés de Shopify, leurs avantages pratiques seraient limités en raison de l’environnement sandbox de Shopify (oui, encore lui).

L’approche de même origine est intéressante notamment parce qu’elle permet de définir les cookies avec leur durée de vie prévue dans ITP et des environnements similaires. Mais dans la sandbox du checkout, les cookies ne sont pas transmis dans vos requêtes de suivi ; de même, les définir via les réponses ne fonctionnera pas non plus. C’est pourquoi notre Data Tag inclut l’option Send Common Cookies, qui ajoute les cookies au payload de la requête.

Comme l’iframe de la sandbox est configuré sans allow-same-origin, le navigateur lui attribue une origine opaque, qui apparaît donc toujours comme null. Cela se produit même lorsque l’iframe est servi depuis le propre domaine de la boutique, que la requête définisse explicitement ou non « credentials: include » ou « mode: cors ». Par conséquent, le navigateur considère ces requêtes comme cross-site lors de la gestion des cookies. En termes simples, le navigateur traite les cookies associés comme des cookies tiers.

Simo Ahava a décrit en détail ce problème de cookies dans le checkout Shopify dès 2024.

Pour les boutiques Shopify dotées d’un suivi côté serveur, l’approche recommandée est hybride :

• approche de même origine sur la vitrine ;
• routage standard par sous-domaine pour le checkout.

Sur la vitrine, le suivi de même origine apporte les avantages attendus (meilleur routage des requêtes first-party, meilleure gestion des cookies et suivi plus résilient), car les requêtes de suivi sont envoyées depuis le même contexte de domaine que le site web.

Cependant, le checkout Shopify présente des restrictions qui empêchent l’approche de même origine de fonctionner comme sur la vitrine. Le routage standard par sous-domaine est donc plus adapté. Acheminer les requêtes de suivi via un sous-domaine de suivi dédié permet d’éviter cette restriction précise et de faire parvenir ces requêtes à l’endpoint de suivi.

La configuration de même origine pour la vitrine Shopify peut être réalisée à l’aide de différents fournisseurs DNS et d’infrastructure. La configuration exacte dépend du fournisseur que vous utilisez.

Par exemple, Cloudflare propose une intégration Orange-to-Orange (O2O) qui permet d’acheminer le trafic à la fois via la zone Cloudflare du marchand et via l’infrastructure Cloudflare de Shopify. Cela offre un contrôle supplémentaire sur la gestion du trafic tout en conservant votre domaine comme point d’entrée.

D’autres fournisseurs peuvent proposer des solutions similaires via un proxy inverse, un CDN ou une fonctionnalité de nom d’hôte personnalisé, mais les étapes de configuration et les fonctionnalités prises en charge peuvent varier d’une plateforme à l’autre.

Pour le checkout Shopify, utilisez une configuration standard par sous-domaine.

Contrairement à une configuration de même origine, la configuration d’un sous-domaine nécessite l’ajout d’enregistrements DNS pour connecter le sous-domaine à votre fournisseur de suivi côté serveur.

Une fois les domaines de suivi de la vitrine et du checkout configurés, vous devez configurer GTM pour envoyer les données d’événements à votre conteneur côté serveur.

Dans votre conteneur GTM web, ajoutez et configurez le modèle Data Tag. Cette balise envoie les données d’événements ainsi que les paramètres configurés à votre conteneur GTM serveur.

Dans le conteneur GTM serveur, installez et configurez Data Client. Data Client reçoit et analyse les requêtes de Data Tag. Ainsi, les données d’événements entrantes deviennent disponibles pour les balises du GTM serveur.

Cette option envoie les valeurs des cookies de navigateur couramment utilisés avec les données d’événement. Elles sont importantes pour l’attribution, l’identification des utilisateurs et le suivi des conversions, en particulier lorsque les événements du checkout Shopify s’exécutent dans un environnement isolé avec un accès restreint aux données de la vitrine.

Activez cette option pour chaque Data Tag qui doit se déclencher sur la page du checkout.

La logique de sélection du domaine est gérée dans le conteneur GTM web, car cette décision doit être prise avant l’envoi de la requête. Le conteneur serveur reçoit ensuite les requêtes depuis l’endpoint sélectionné et poursuit leur traitement à l’aide des clients et des balises configurés.

Pour définir la logique, utilisez la variable RegEx Table.

3.1 Pour la configurer, accédez à la section Variables du GTM web → cliquez sur New → sélectionnez RegEx Table comme configuration de variable.

3.2 Sélectionnez une Input Variable pour la variable.

La condition précise dépend du parcours de votre site Shopify. Dans notre cas, les pages de checkout et de remerciement (thank-you) sont hébergées sur le même domaine, mais le Page Path diffère.

Si vous avez besoin de plus de détails pour trouver l’Input Variable de votre site Shopify, cliquez sur l’élément repliable ci-dessous :

Indiquez l’Input Variable (dans notre cas, Page Path).

3.3 Saisissez le pattern et la sortie requise.

Saisissez le Pattern à l’aide d’expressions régulières.

Pour notre parcours, l’expression régulière suivante fonctionne :

Elle correspond à toute chaîne commençant par /checkouts, quelle que soit la suite.

Comme Output, indiquez le sous-domaine à utiliser pour le suivi dans l’environnement sandbox.

Cochez la case Set Default Value et ajoutez une variable contenant votre domaine de même origine comme Default Value.

Voici un exemple de configuration de variable :

Enregistrez les modifications.

Remplacez dans vos balises toutes les valeurs d’URL de même origine codées en dur, ou les variables contenant l’URL de même origine, par la variable RegEx Table.

La variable renverra automatiquement le bon domaine en fonction du contexte de la page en cours, afin que les requêtes provenant des environnements de la vitrine et du checkout soient acheminées via l’endpoint approprié.

Voici un exemple ci-dessous. Passez en revue les balises de votre conteneur GTM web et mettez-les à jour si nécessaire.

Vérifiez que la configuration du suivi fonctionne correctement dans les environnements de la vitrine et du checkout.

Pour afficher les détails du débogage, cliquez sur l’élément repliable correspondant ci-dessous :

Le suivi du checkout Shopify est complexe, en particulier dans le contexte du suivi côté serveur. L’approche de même origine apporte tous ses avantages sur les pages de la vitrine, mais l’environnement du checkout présente des restrictions de sandbox qui empêchent cette même approche de fonctionner correctement.

La meilleure solution, pour l’instant, consiste à adapter votre architecture de suivi à l’environnement de Shopify : conserver la configuration de même origine là où elle apporte de la valeur et utiliser une approche standard par sous-domaine pour les événements du checkout. Avec une configuration GTM correcte et un processus de test rigoureux, vous pouvez maintenir un suivi précis tout au long du parcours utilisateur.

Restez à l’écoute des actualités de Stape. Nous travaillons en permanence à l’amélioration des solutions de suivi côté serveur et suivons de près les évolutions de l’écosystème Shopify. Nous savons à quel point un suivi précis est important pour votre entreprise, et nous cherchons de meilleures façons de relever ces défis et de partager avec vous nos dernières découvertes !