Additional scripts arrêté sur Shopify ? Réparer le suivi
Qu’est-ce qui a cessé de fonctionner sur la page de remerciement de Shopify ?
Les pages de remerciement et d’état de la commande de Shopify n’exécutent plus Additional scripts ni les script tags. Les boutiques Plus les ont perdus le 28 août 2025 ; pour les autres boutiques, la date limite était le 26 août 2026, et Shopify a mis à niveau automatiquement toute boutique qui l’a manquée. Les balises d’achat de Meta, Google Ads et les affiliés s’y sont arrêtées sans erreur. Déplacez-les vers Customer events.
Sur une boutique hors Plus, Additional scripts s’est arrêté le jour où ses pages ont été mises à niveau, que vous les ayez mises à niveau vous-même ou que Shopify l’ait fait. À propos de la date limite du 26 août 2026, Shopify indique : « Stores that weren’t upgraded by that date were upgraded automatically » (upgrading the Thank you and Order status pages). Une mise à niveau remplace les deux pages et toute personnalisation qui s’y trouvait, et mettre une boutique en pause la met aussi à niveau (guide de mise à niveau hors Plus).
| Date | Shopify Plus | Autres forfaits |
|---|---|---|
| 28 août 2025 | Les pages de remerciement et d’état de la commande cessent d’exécuter Additional scripts, checkout.liquid et les script tags | La case Additional scripts devient en lecture seule |
| 26 août 2026 | — | Date limite de mise à niveau, après laquelle Shopify met à niveau les boutiques qui l’ont manquée ; les script tags s’arrêtent sur les deux pages |
| 1 octobre 2026 | Les applications ne peuvent plus créer ni mettre à jour de script tags | La même |
| 1 mars 2027 | Shopify arrête de charger les script tags sur les pages de la boutique | La même |
Sources : la page de mise à niveau de Shopify ci-dessus, et shopify.dev sur checkout.liquid, les script tags de la page d’état de la commande et les script tags de la boutique, vérifiées le 24 septembre 2026.
Un autre changement piège les objectifs construits sur des adresses. La page de remerciement mise à niveau se termine par /thank-you plutôt que /thank_you, donc un objectif ou un déclencheur de conversion qui correspondait à l’ancienne adresse a cessé de correspondre (Shopify).
Comment savoir si mon suivi a cassé ?
Si les achats d’une plateforme publicitaire ont chuté alors que les commandes de Shopify sont restées stables, c’est la mesure qui a cassé, pas vos ventes. Comparez les deux sur les mêmes jours, en partant du jour où vos pages ont été mises à niveau plutôt que du 26 août.
- Vérifiez les propres chiffres de Shopify. Dans Analytics → Reports, filtrez Category sur Marketing et ouvrez Performance by referring channel ou Performance by UTM campaign (rapports marketing). Shopify enregistre les données de commande et d’analytique quand la commande est traitée, donc les fonctions de confidentialité du navigateur et les bloqueurs de publicités ne touchent pas ces rapports (app pixels). Un fil de la Communauté de septembre 2026 suggère d’y surveiller les commandes des canaux payants plutôt que les commandes totales, qui peuvent rester stables pendant que les commandes payantes chutent et que les commandes organiques augmentent.
- Alignez les dates. Les colonnes de conversion standards de Google Ads comptent les achats à la date du clic, pas de l’achat (Google), donc une rupture un jour donné peut ressembler à un déclin lent. Sa colonne Conversions (by conv. time) compte par date d’achat.
- Regardez comment les achats arrivent. Dans Meta Events Manager, comparez les décomptes navigateur et serveur de l’événement Purchase pour les semaines avant et après la mise à niveau de vos pages, comme le suggéraient des réponses dans un fil d’août 2026. Si la part navigateur s’est effondrée alors que les événements serveur tenaient bon, une balise navigateur s’est arrêtée : une copie serveur de chaque achat cache la perte dans les totaux, et une copie qui ne couvrait que certains achats ne le fait pas.
Qu’est-ce qui remplace Additional scripts ?
Customer events : un pixel d’application venant de l’application propre à la plateforme quand il en existe une, un pixel personnalisé quand il n’en existe aucune, et des blocs d’application pour tout ce que les clients voient. Shopify recommande d’abord les pixels d’application, pour leur stabilité, leur sécurité et leur performance (remplacer Additional scripts).
- Le suivi se déplace vers les pixels sous Settings → Customer events. Les deux types se chargent sur votre boutique, le paiement, la page de remerciement et la page d’état de la commande (pixels overview). Les différences sont dans pixels d’application et pixels personnalisés.
- Le contenu visible, comme un sondage, une offre ou un lien de téléchargement, devient un bloc d’application sur les nouvelles pages, car un pixel ne peut rien afficher.
- Le code du thème n’est pas un moyen de le contourner. La mise en page de votre thème ne s’applique qu’aux pages hors paiement (theme layouts), et les app embeds ne peuvent pas se charger sur les pages de paiement ni la page d’état de la commande (app embeds).
Vos anciens scripts sont déjà désactivés, donc le risque va maintenant dans l’autre sens : ajouter la même balise via deux nouvelles voies. Shopify demande de retirer les copies existantes d’un pixel avant de l’ajouter à nouveau, sinon les événements comptent deux fois (managing custom pixels).
Comment déplacer une balise d’achat Meta, Google Ads ou TikTok ?
Installez d’abord l’application Shopify propre à la plateforme : chacune suit les achats sans code. N’utilisez un pixel personnalisé que pour une plateforme sans application, ou une application de suivi pour faire tourner plusieurs plateformes depuis un seul endroit.
Meta
Dans Sales channels → Facebook & Instagram → Settings → Data sharing settings, choisissez un niveau. Standard utilise le pixel Meta ; Enhanced et Maximum ajoutent l’API Conversions de Meta, qui envoie l’achat entre les serveurs de Shopify et de Facebook (Facebook data sharing). Les configurations serveur comparées : configurer l’API Conversions sur Shopify. Si les achats manquent encore ensuite, voir le pixel Meta ne suit pas les achats.
Google Ads et GA4
Shopify recommande de remplacer un script Google Tag Manager sur la page de remerciement par l’application Google & YouTube, parce que Google la maintient (Shopify). Connectez-y votre compte Google Ads pour la mesure de conversion, et votre propriété GA4 aussi (configuration Google & YouTube). Garder Tag Manager suppose un pixel personnalisé qui s’abonne à checkout_completed, une voie que Google ne prend pas en charge et que Tag Assistant ne peut pas tester.
TikTok
L’application Shopify de TikTok a trois niveaux de partage de données : Standard utilise le pixel TikTok, Enhanced ajoute l’Events API et l’appariement avancé, et Maximum ajoute les API de Shopify et le paiement intégré à l’application (TikTok, mis à jour en février 2025).
Avec une application de suivi
cPixel, que nous développons, déplace plusieurs plateformes à la fois. Son pixel d’application, cPixel sous Customer events, s’exécute au paiement et sur la page de remerciement, et il reconstruit chaque achat côté serveur depuis la commande Shopify plutôt que depuis la page, donc le changement d’août ne l’a pas affecté. Il n’a aucune permission pour ajouter des script tags. Il envoie les achats depuis ses serveurs vers Meta, TikTok, GA4, ChatGPT Ads, Pinterest et Snapchat, et déclenche la balise de conversion de Google Ads dans le navigateur du client sur la page de remerciement.
Commencez par configurer cPixel, ou allez directement à connecter Google Ads à cPixel. Plus d’informations sur cPixel, qui envoie les achats Shopify à sept plateformes publicitaires.
Que ne peut pas faire un pixel qu’un script pouvait faire ?
Toucher la page. Les pixels s’exécutent dans le bac à sable de Shopify, donc ils ne peuvent rien montrer aux clients, lire ce qui est sur la page, ni s’exécuter avant le consentement qu’ils requièrent.
- Afficher du contenu. Les pixels ne peuvent pas dessiner de boutons, de formulaires, de bannières ni de fenêtres modales (limites du bac à sable).
- Lire la page. Ils ne peuvent pas y récupérer d’événements, de détails produit, d’e-mail ou de numéro de téléphone, de clics sur des liens, de défilement ni de données de heatmap. Sur les pages de la boutique, publiez ce dont vous avez besoin depuis le code du thème avec
Shopify.analytics.publish()et abonnez-vous-y dans le pixel. - Réutiliser d’anciens extraits. Un extrait qui lisait l’ID de commande depuis l’ancienne page doit le prendre de l’événement à la place :
checkout_completedporte l’ID de commande, le total, la devise et les articles (Shopify). Collé sans modification dans un pixel personnalisé, un ancien extrait peut échouer sans erreur, car le bac à sable ne peut pas atteindre la page, et même l’adresse qu’il lit est celle du bac à sable (Shopify : web pixels). - Ignorer le consentement. Les pixels attendent les permissions qu’ils requièrent partout où votre boutique demande le consentement.
Pourquoi mes décomptes d’événements ont-ils chuté après le passage aux pixels ?
Surtout le consentement. Shopify indique que les pixels suivent le comportement client seulement avec le consentement, alors que le consentement était souvent mal configuré dans Additional scripts, donc moins d’événements après le passage peut être le bon chiffre (remplacer Additional scripts).
- Une certaine baisse est attendue. Shopify s’attend aussi à des baisses de quelques pourcents, car certains bots ne déclenchent pas le bac à sable des pixels (migration des pixels).
- Le consentement doit atteindre Shopify. Une bannière de cookies tierce doit synchroniser ses choix via la Customer Privacy API de Shopify, sinon les pixels restent silencieux même après qu’un client a accepté. Avec un domaine personnalisé, les comptes clients ont besoin d’un sous-domaine de celui-ci, comme
account.example.com, sinon les pixels et le consentement ne fonctionnent pas sur la nouvelle page d’état de la commande (remplacer Additional scripts). - Les décomptes peuvent aussi augmenter. Le même événement suivi depuis une application, un pixel personnalisé et du code de thème restant compte plus d’une fois : voir pourquoi Meta compte les achats deux fois. Ne comparez des chiffres qu’au sein d’un même service.
Comment tester la nouvelle configuration ?
Passez une commande de test et regardez-la à trois endroits : le Pixel Helper de Shopify, l’outil de test propre à la plateforme, et les rapports de la plateforme un jour plus tard. Pour les balises hors des pixels de Shopify, vérifiez si un pixel fonctionne dans le navigateur.
- Dans Settings → Customer events, choisissez Test depuis le menu d’un pixel d’application, ou cliquez sur un pixel personnalisé puis Test (app pixels). Si Pixel Helper affiche Pixel is awaiting consent, acceptez votre bannière de cookies ou cliquez sur Give consent to continue test.
- Naviguez, ajoutez au panier et terminez la commande. Chaque événement devrait obtenir un point vert, en finissant par
checkout_completed(testing custom pixels). - Regardez l’achat arriver dans l’outil de test propre à la plateforme. Test events de Meta ne liste que les événements navigateur, sauf si un envoi serveur porte un code d’événement de test, que les vrais envois ne portent pas ; un achat envoyé seulement depuis un serveur, comme celui de cPixel, s’affiche dans En direct de cPixel à la place. Tag Assistant de Google ne peut pas voir les balises à l’intérieur d’un pixel personnalisé, vérifiez donc Google Ads lui-même.
- Si vous vendez des offres après achat, faites passer la commande par l’une d’elles : Shopify déclenche
checkout_completedsur la première page d’offre au lieu de la page de remerciement, et pas du tout si cette page ne se charge pas. - Quelques jours plus tard, comparez à nouveau la plateforme avec les rapports marketing de Shopify.
Questions fréquentes
Je suis sur Shopify Plus. Cela m’a-t-il concerné ?
Pas le 26 août 2026. Les pages de remerciement et d’état de la commande des boutiques Plus ont cessé d’exécuter Additional scripts, checkout.liquid et les script tags le 28 août 2025, donc si votre suivi fonctionne depuis, la date de 2026 n’a rien changé. Les script tags de la boutique sont les prochains concernés, pour tous les forfaits : les applications ne peuvent plus les créer ni les mettre à jour à partir du 1 octobre 2026, et Shopify arrête de les charger le 1 mars 2027.
Qu’en est-il des pages de vente incitative après achat ?
Elles déplacent l’événement d’achat. Avec des offres après achat, checkout_completed se déclenche sur la première page d’offre, une seule fois, et jamais si cette page ne se charge pas, donc testez avec une commande qui traverse votre offre. Une offre qu’une application dessinait sur la page de remerciement ou d’état de la commande avec une script tag a besoin du bloc de l’application pour les nouvelles pages à la place ; une réponse dans le fil de septembre note que cette perte apparaît comme une baisse de la valeur moyenne des commandes plutôt que comme un suivi cassé.
Qu’en est-il des postbacks d’affiliation ?
Si la balise se déclenchait depuis la page de remerciement, elle s’est arrêtée aussi. Demandez au réseau s’il a une application Shopify qui utilise un pixel d’application ; sinon, un pixel personnalisé peut déclencher la balise sur checkout_completed. Pour une commission que vous ne pouvez pas vous permettre de manquer, demandez si le réseau accepte des postbacks serveur, qu’un développeur peut envoyer depuis les webhooks de commande de Shopify sans aucun chargement de page.