Après le lancement de Shopify, vérifiez ces 5 ensembles de données

Le projet Shopify lancé, le malentendu le plus courant est le suivant : la page peut s’ouvrir, le test de paiement peut être effectué, et la publication est considérée comme terminée.

Le succès de la page et des transactions ne prouve que le processus principal fonctionne dans des conditions de test. Une fois en production, les commandes, les points de données, les Webhooks, la synchronisation des stocks et l’attribution marketing écrivent toutes des données simultanément. Toute répétition, omission ou retard à un endroit peut fausser les rapports. Ce type de problème ne génère généralement pas d’erreur immédiate. L’équipe ne se rend souvent compte qu’il y a eu un problème le jour du lancement que lorsque les conversions publicitaires ne correspondent pas, que le service client découvre des anomalies de stock, ou que la comptabilité fait le rapprochement à la fin du mois.

L’acceptation des données après la publication devrait être une étape de lancement distincte, avec un responsable, une fenêtre de temps, des commandes échantillons et des critères de réussite. La méthode n’est pas compliquée : faire passer les mêmes données commerciales à travers différents systèmes, puis vérifier chaque enregistrement laissé.

Conservez un instantané de la publication

Avant l’acceptation, enregistrez la version publiée, l’heure, la boutique, l’ID du thème, la version de l’application et la portée des changements. Lorsque vous exécutez shopify app deploy avec Shopify CLI, cela crée une version de l’application avec les configurations et les extensions et la publie. Vous pouvez créer une version sans la libérer immédiatement en utilisant --no-release. Shopify prend également en charge le retour à une version précédente de l’application.

Sans instantané, il est difficile pour l’équipe de relier une chute soudaine d’un indicateur à une publication spécifique à 20 heures. Il est conseillé de conserver le SHA de commit, la version de l’application, l’ID du thème, l’heure de publication, l’opérateur et la version de migration de la base de données. Si seul le thème a été modifié, notez également les ID de thème et les configurations de section clés avant et après la publication.

Vous pouvez convenir de : terminer les tests de validation en 15 minutes, vérifier les erreurs et les flux d’événements en 2 heures, et vérifier les conversions, les commandes et les différences avec la plateforme publicitaire 24 heures après. Pour les boutiques à fort trafic, effectuez une révision supplémentaire après 7 jours.

Que doit laisser une commande de 188 CNY dans six systèmes

Prenons un exemple : un site indépendant d’articles pour animaux appelé “Station de fourniture de peluches” a environ 200 SKU et vient de lancer une nouvelle logique de réduction et un Meta Pixel. L’équipe prépare une commande de test facilement identifiable : sous-total de 198 CNY, réduction de 20 CNY, frais de port de 10 CNY, montant total de 188 CNY. En même temps, conservez l’ID de commande, le token de paiement, le code de réduction, le mode de paiement, les UTM et l’heure de la commande.

Ensuite, vérifiez la commande. Les montants, les taxes, les frais de port et les réductions dans Shopify Admin sont-ils corrects ? Le backend de paiement a-t-il seulement une capture ? Le stock a-t-il été déduit une seule fois ? L’ERP ou le WMS a-t-il reçu la même commande ? Les e-mails et les points de fidélité ont-ils été déclenchés plusieurs fois ? Les outils d’analyse montrent-ils checkout_started et checkout_completed ? La plateforme publicitaire a-t-elle reçu le montant, la devise et l’ID de l’événement ?

L’API Web Pixels de Shopify définit checkout_completed comme un événement standard déclenché lorsque le visiteur termine un achat. Il est adapté pour confirmer le flux d’analyse frontal, mais ne peut pas agir seul comme la vérité de la commande. Les scripts de navigateur peuvent être interceptés, et l’utilisateur peut fermer la page avant que l’événement ne soit émis. Les commandes et les paiements doivent être basés sur Shopify Admin, l’API Admin et les enregistrements de paiement.

Il est préférable de faire un test de remboursement ou d’annulation pour cette commande. Sinon, vous manquerez le montant du remboursement, la réapprovisionnement du stock, l’annulation des points et le retour publicitaire. Si la boutique prend en charge plusieurs devises, abonnements ou autorisations avant prélèvement, au moins un scénario spécial le plus courant doit être testé. Il n’est pas nécessaire de couvrir toutes les combinaisons en une seule fois, mais il faut clairement indiquer quelles combinaisons n’ont pas été vérifiées.

Ne regardez pas seulement “reçu” pour les Webhooks

Le tableau de bord des développeurs Shopify dans Apps > Nom de l'application > Monitoring permet de voir le nombre de livraisons, le taux d’échec et le temps de réponse de chaque sujet ; Logs permet de filtrer les enregistrements par code d’état, boutique, type d’événement et temps. La plage horaire des journaux inclut les dernières 24 heures, 7 jours ou 30 jours, et la surveillance des Webhooks prend en charge les dernières 24 heures ou 7 jours.

Shopify considère les réponses 2xx comme réussies. L’interface Webhook doit répondre dans les 5 secondes, sinon la livraison échoue. L’entreprise considère également qu’un taux d’échec supérieur à 0,5 % nécessite une attention particulière et affiche le temps de réponse P90. Après la publication, vérifiez les sujets concernés, tels que orders/create, orders/updated ou products/update, et ne regardez pas seulement le taux de réussite global.

Les tentatives de réessai des échecs peuvent créer une illusion. Shopify explique que les Webhooks échoués peuvent être réessayés jusqu’à 8 fois. Le traitement doit être idempotent en utilisant l’ID du webhook ou l’ID de l’objet commercial, retourner rapidement 2xx, puis placer les tâches longues dans une file d’attente. Sinon, une requête lente à la base de données peut simultanément provoquer des délais d’attente, des réessais et des écritures répétées.

Lors de l’acceptation, vous pouvez créer manuellement un événement, par exemple en créant un produit dans la boutique de développement, ce qui déclenche products/create. Ensuite, comparez avec le journal de livraison Shopify, les journaux de requêtes de l’application, les tâches de la file d’attente et les enregistrements de la base de données, en vérifiant la boutique, le sujet, l’ID du webhook et le temps. Les journaux du tableau de bord des développeurs ne sont pas en temps réel, et l’entreprise précise qu’il peut y avoir un retard de quelques minutes. Par conséquent, ne pas voir d’enregistrement en quelques secondes ne signifie pas directement un échec.

Lorsque les indicateurs ne correspondent pas

Les chiffres de Shopify Analytics, GA4, Meta Ads et du backend de paiement ne seront pas naturellement égaux. La définition des sessions, le fuseau horaire, la fenêtre d’attribution et l’état de consentement des cookies peuvent tous être différents. Le centre d’aide de Shopify précise également les écarts d’analyse et affichera des icônes d’interruption de données sur certaines cartes et rapports d’indicateurs affectés.

L’acceptation ne nécessite pas que toutes les plateformes soient complètement identiques, mais il faut confirmer que chaque plateforme enregistre comme convenu et noter les différences explicables. Par exemple, un même utilisateur qui clique d’abord sur un e-mail, puis sur Google Shopping, deux plateformes externes peuvent enregistrer des conversions respectivement ; le rapport des campagnes marketing de Shopify peut alors attribuer en fonction du dernier clic publicitaire. Équivaloir directement le “nombre d’achats” des trois backends n’est généralement pas fiable.

Une méthode plus pratique consiste à établir un tableau de rapprochement. Chaque ligne représente une commande de test, chaque colonne contient la commande Shopify, le paiement, l’événement pixel, la conversion publicitaire, la commande ERP et les enregistrements de remboursement, en vérifiant l’ID de commande, le montant, la devise, le temps et l’état. Si la plateforme ne peut pas transmettre l’ID de commande, utilisez l’ID d’événement autorisé ou l’identifiant de test pour établir la relation. Vérifiez d’abord l’échantillon, puis examinez les indicateurs globaux, ce qui permettra de localiser plus rapidement les problèmes.

Préparez également une base de référence historique pour comparer le taux de complétion de paiement, le taux d’échec de paiement, le taux d’échec de Webhook et le délai de synchronisation des stocks pour la même semaine et le même créneau horaire avant et après la publication. Les échantillons des petites boutiques peuvent être insuffisants, et les fluctuations de conversion dans les 24 heures peuvent ne pas avoir de signification statistique, dans ce cas, privilégiez les commandes de test traçables et les journaux d’erreurs.

Les critères de réussite doivent permettre de décider d’un retour en arrière, et indiquer quelles données ne peuvent pas être récupérées

“Cela semble normal” n’est pas un critère d’acceptation. La publication doit au moins préciser quelques seuils : la commande de test n’apparaît qu’une fois dans les systèmes nécessaires ; le montant et la devise sont cohérents ; les Webhooks principaux n’ont pas ajouté de 4xx ou 5xx ; le temps de réponse P90 ne s’approche pas de 5 secondes ; les événements clés du frontend sont déclenchés dans l’ordre ; l’échantillonnage des commandes réelles n’a pas entraîné de déductions de stock répétées.

Les seuils doivent être combinés avec la base de référence existante. L’entreprise considère qu’un taux d’échec de Webhook supérieur à 0,5 % est élevé, mais une application dont le taux d’échec habituel est de 0,02 % et qui passe à 0,4 % après le lancement mérite également d’être suspendue. S’il n’y a eu que quelques livraisons au total, un échec peut rendre le pourcentage très exagéré, dans ce cas, vérifiez les journaux spécifiques, sans revenir en arrière mécaniquement.

Les conditions de retour en arrière doivent également être écrites à l’avance : revenir à la version de l’application, restaurer l’ancien thème, désactiver le drapeau de fonctionnalité, ou suspendre la file d’attente des consommateurs ? Si la migration de la base de données n’est pas réversible, l’ancien code peut-il encore lire la nouvelle structure ? Discuter des pannes après qu’elles se soient produites gaspille le temps le plus précieux.

Shopify peut revenir à une version précédente de l’application, mais les points de fidélité déjà créés, les e-mails déjà envoyés et les commandes écrites dans l’ERP ne seront pas automatiquement restaurés et nécessiteront un traitement compensatoire. Les délais et les temps de mise à jour d’attribution des applications tierces varient, et l’entreprise n’a pas précisé de durée d’acceptation unifiée. Je n’ai pas encore testé cette fenêtre dans chaque combinaison de passerelle de paiement et d’application d’abonnement, donc 15 minutes, 2 heures et 24 heures ne sont que des points de départ.

Enfin, les enregistrements doivent être divisés en trois parties : instantané de publication et commandes de test, preuves des systèmes et anomalies, responsable et temps de révision. La publication de la page n’est qu’une action accomplie ; ces enregistrements peuvent prouver que les données de production restent fiables.

Références

Shopify Dev : Monitoring and logs in the Dev Dashboard https://shopify.dev/docs/apps/build/dev-dashboard/monitoring-and-logs

Shopify Dev : Troubleshoot webhooks https://shopify.dev/docs/apps/build/webhooks/troubleshoot

Shopify Dev : Deploy app versions https://shopify.dev/docs/apps/launch/deployment/deploy-app-versions

Shopify Dev : Web Pixels API Standard Events https://shopify.dev/docs/api/web-pixels-api/standard-events

Shopify Help Center : Analytics discrepancies https://help.shopify.com/en/manual/reports-and-analytics/discrepancies