Tracking server-side sur Shopify : guide pas à pas

Si vous découvrez le sujet, commencez par notre guide complet du tracking server-side : cette page se concentre sur ce qui est propre à Shopify.

Contenu mis à jour le 26 octobre 2026.

Pourquoi le suivi Shopify perd des conversions

Trois mécanismes se cumulent sur une boutique Shopify.

1. Les scripts de paiement ont été déplacés dans des pixels isolés

Avec le passage à Checkout Extensibility, Shopify a supprimé entre 2024 et 2025 la possibilité d’ajouter des scripts libres sur les pages de paiement et de confirmation (l’ancien champ « scripts supplémentaires » et checkout.liquid). Le suivi passe désormais par l’onglet Événements client (Customer Events), où chaque pixel tourne dans un environnement isolé (sandbox). Conséquence : un conteneur Google Tag Manager installé dans le thème ne voit plus l’achat, et un pixel personnalisé n’a pas accès à la page elle-même. Beaucoup de boutiques ont perdu leur suivi d’achat à cette bascule sans s’en apercevoir. Vous êtes sur Shopify ? Voici notre sélection des meilleures agences SEO Shopify.

2. Les bloqueurs et les restrictions des navigateurs

Les bloqueurs de publicité empêchent le chargement des scripts de Meta et de Google. Safari limite la durée de vie des cookies posés par JavaScript, ce qui coupe le lien entre un clic publicitaire et un achat réalisé quelques jours plus tard. Ce sont les limites classiques du suivi dans le navigateur, que nous comparons en détail dans server-side ou client-side.

3. Le consentement

En Europe, les pixels Shopify respectent la bannière de consentement (API Customer Privacy). Un visiteur qui refuse n’est pas suivi : c’est normal et légal. Le suivi côté serveur ne doit pas contourner ce refus. Il permet en revanche de transmettre correctement les signaux du mode Consentement v2 à Google, qui modélise alors une partie des conversions non observées.

Les trois façons de passer au server-side sur Shopify

Il n’y a pas de mauvaise option en soi : une petite boutique qui ne fait que Meta peut se contenter de l’intégration native bien réglée ; une boutique multicanale qui investit plusieurs milliers d’euros par mois en publicité gagne à maîtriser son flux. Le détail des coûts est dans notre article coût et retour sur investissement du tracking server-side.

Notre méthode de déploiement, étape par étape

Les vérifications à faire vous-même

Pas besoin d’être développeur pour contrôler qu’un suivi fonctionne. Voici ce que vous devez voir à chaque point de contrôle.

Le mode Aperçu du conteneur serveur

En passant une commande de test, chaque événement doit arriver dans le conteneur depuis votre sous-domaine, puis repartir vers les plateformes. Si les appels partent encore directement du navigateur vers les domaines de Meta ou Google en plus du conteneur, c’est qu’un ancien script tourne toujours : risque de doublons.

Le Gestionnaire d’événements Meta

Dans l’onglet de test des événements, un achat doit apparaître reçu à la fois par le navigateur et par le serveur, et être signalé comme dédupliqué. Un événement reçu uniquement par le serveur fonctionne, mais sans possibilité de déduplication avec le pixel.

La qualité de correspondance des événements

Meta attribue à chaque événement une note de 0 à 10 selon les informations client transmises (e-mail, téléphone, adresse IP, navigateur, identifiants de clic). Une note faible sur l’achat signifie en général que l’e-mail ou le téléphone haché n’est pas envoyé. C’est le premier réglage à corriger.

L’écart avec le back-office

Un écart résiduel est normal : visiteurs qui refusent les cookies, achats sans aucun contact publicitaire, attribution propre à chaque plateforme. Ce qui doit disparaître, ce sont les écarts brutaux et inexpliqués, ou les plateformes qui affichent plus d’achats que le back-office (signe de doublons).

Les pièges Shopify que nous rencontrons le plus

• Double comptage des achats : l’application Meta native reste active alors qu’un second pixel envoie aussi l’achat. Résultat, un retour sur dépense publicitaire flatteur et faux. Même problème côté GA4 avec l’application Google installée en plus d’une balise maison.
• Identifiant de produit ou de variante : le pixel envoie l’identifiant du produit parent alors que le catalogue Meta contient les variantes (ou l’inverse). Les publicités catalogue ne retrouvent plus les articles. Voir notre guide du catalogue produits Meta Ads.
• Conteneur GTM du thème qui ne voit plus l’achat depuis Checkout Extensibility : le suivi d’achat semble actif, mais n’enregistre rien sur la page de confirmation.
• Pages après achat : les applications de vente additionnelle après paiement ou les commandes modifiées ensuite ne déclenchent pas toujours un nouvel événement. Pour une valeur exacte, on complète avec les webhooks de commande de Shopify, côté serveur.
• Abonnements : les renouvellements automatiques ne passent pas par le navigateur. Sans webhook, ils sont invisibles pour les plateformes publicitaires.
• Devise et taxes : valeur envoyée TTC d’un côté, HT de l’autre, ou devise de la boutique différente de celle du compte publicitaire. Les chiffres ne se recoupent plus.
• Consentement mal relié : pixel personnalisé configuré sans respecter le statut de consentement, ce qui pose un problème de conformité, ou au contraire signaux du mode Consentement v2 non transmis à Google.

Ce que vous pouvez attendre

Les éditeurs de solutions publient des hausses de conversions remontées après passage au server-side : Stape, par exemple, présente un cas Shopify avec 36 % de conversions Google Ads remontées en plus. Ce sont des cas choisis par l’éditeur, à lire avec recul. Ce que l’on peut dire sans exagérer :

• la part des achats vus par les plateformes augmente, surtout quand le suivi de départ était cassé par Checkout Extensibility ou doublonné ;
• les algorithmes d’enchères reçoivent plus de signaux fiables, ce qui les aide à trouver des acheteurs ;
• les décisions (couper, augmenter un budget) reposent sur des chiffres qui se recoupent avec le back-office.

Le gain réel dépend de l’état de départ : un suivi déjà propre gagnera peu, un suivi cassé beaucoup.

Questions fréquentes

Les Événements client de Shopify, c’est déjà du server-side ?

Non. Les pixels des Événements client s’exécutent dans le navigateur du visiteur, dans un environnement isolé. C’est le bon point de départ pour collecter les événements, mais l’envoi aux plateformes depuis un serveur est une étape supplémentaire.

Faut-il Shopify Plus ?

Non. Les Événements client et les pixels personnalisés sont disponibles sur toutes les formules. Plus apporte surtout davantage de personnalisation du paiement.

Le server-side permet-il de suivre les visiteurs qui refusent les cookies ?

Il ne doit pas servir à ça. Le refus doit être respecté. En revanche, il transmet correctement les signaux de consentement, ce qui permet à Google de modéliser une partie des conversions.

Combien de temps prend la mise en place ?

Pour une boutique standard, comptez quelques jours de travail technique puis une à deux semaines de recette et de comparaison avec le back-office.

Que se passe-t-il si Shopify modifie ses événements ?

C’est arrivé avec Checkout Extensibility et cela arrivera encore. Un contrôle mensuel de l’écart entre back-office et plateformes permet de repérer une rupture en quelques jours.

Sources : documentation Shopify (Événements client, pixels personnalisés, Checkout Extensibility, API Customer Privacy), documentation Meta (API Conversions, qualité de correspondance des événements), documentation Google Tag Manager côté serveur, étude de cas publiée par Stape.