Diagnostic du code de suivi publicitaire pour l’e-commerce (2026)

Comment utiliser ce guide

Ce guide s’adresse aux spécialistes du marketing à la performance, aux responsables e-commerce, aux analystes, aux développeurs et aux équipes qui doivent auditer un suivi installé par une agence, un plugin, une application ou une implémentation interne. Effectuez les tests dans un environnement de préproduction ou avec une commande de test annulable et remboursable. Ne réalisez pas de tests répétés avec de vraies commandes clients.

Après avoir suivi ce guide, vous devriez être en mesure de

• Distinguer la présence du code, le déclenchement de la balise, l’envoi de la requête, la réception par la plateforme et l’éligibilité d’une conversion aux enchères.
• Valider les champs critiques tels que l’ID de commande, le chiffre d’affaires, la devise, l’ID produit et l’ID d’événement.
• Diagnostiquer les achats en double, les achats manquants, les conversions de valeur nulle, la perte d’attribution interdomaines et les problèmes de configuration du consentement.
• Choisissez la bonne approche diagnostique pour Shopify, WordPress, WooCommerce, ou une pile e-commerce personnalisée.
• Produire un rapport de diagnostic clair pour les équipes de marketing, de développement, d’analyse ou de gestion.

Pourquoi le suivi installé peut encore produire des données non fiables

Lorsqu’une boutique de e-commerce indépendante commence à faire de la publicité sur Google Ads, Meta Ads, Microsoft Ads ou TikTok Ads, chaque plateforme demande une balise de suivi ou un pixel. Trouver ce code dans la source de la page ne prouve pas que le suivi de conversion fonctionne correctement.

• La plateforme publicitaire affiche le tag comme non vérifié, inactif, ou sans activité récente.
• GA4 enregistre les commandes, mais Google Ads ne montre aucune conversion.
• Le back-office de la boutique contient une commande, tandis que la plateforme publicitaire rapporte deux achats.
• Le compte de conversion semble raisonnable, mais les revenus, les devises ou les données de produit sont erronés.
• Le pixel est détecté sur la page d’accueil mais disparaît lors de la commande ou sur la page de confirmation de commande.
• Les événements navigateur et serveur sont tous les deux envoyés, mais ils ne sont pas dupliqués correctement.
• Le suivi publicitaire ne respecte pas le choix de consentement du visiteur : le stockage publicitaire continue d’être écrit ou lu, ou des identifiants publicitaires ou des données utilisateur continuent d’être envoyés lorsque le consentement marketing est à l’état denied. En mode consentement avancé, des pings de consentement sans cookies peuvent toujours être envoyés lorsque ad_storage ou analytics_storage est défini sur denied ; ce comportement, à lui seul, ne constitue pas une erreur d’implémentation.
• Les balises ne reprennent pas leur fonctionnement après que le visiteur a accordé son consentement.

Un audit complet ne peut pas s’arrêter à la question : « Le code est-il présent ? » Vérifiez que chaque action commerciale réelle atteint la bonne plateforme avec le nom d’événement, les paramètres, la valeur, la devise et l’ID de commande corrects, et que les envois du navigateur et du serveur sont regroupés en une seule conversion logique après déduplication.

1. Ce qu’un diagnostic de suivi de la publicité vérifie réellement

Le suivi publicitaire peut être évalué selon cinq niveaux. Les données ne conviennent à l’analyse des performances, au calcul du ROAS et aux enchères automatiques que si les cinq niveaux sont validés.

Un message « Tag Fired » dans GTM prouve seulement qu’une condition de déclenchement a été remplie. Il ne prouve pas que la conversion est exacte. Continuer en vérifiant la couche de données, la demande réseau, les outils de test de plateforme et l’commande de renvoi correspondant.

2. Créer un plan de suivi des événements du e-commerce

Avant le dépannage, définir les actions du client que le site doit vraiment mesurer. Une implémentation typique du e-commerce devrait au moins couvrir les vues des produits, les actions d’ajout à la carte, les démarrages de caisse et les achats.

Dans l’édition d’août 2026 de ce guide, TikTok utilise Purchase comme événement purchase standard pour l’e-commerce et Lead pour les soumissions de prospects. CompletePayment et SubmitForm sont des noms hérités compatibles, respectivement associés à Purchase et Lead ; ne renommez pas une implémentation héritée qui fonctionne sans plan de migration. Utilisez Contact uniquement pour une véritable prise de contact. GA4 utilise purchase et recommande des paramètres tels que transaction_id, value, currency ainsi qu’un tableau items.

Données minimales requises pour un événement purchase

3. Préparer le test diagnostique

N’utilisez pas une vraie commande client comme test principal. Créez une commande de test qui peut être annulée ou remboursée, puis enregistrez les détails ci-dessous avant de commencer.

Désactiver les extensions de blocage publicitaire du navigateur pour le test d’implémentation primaire, mais ne pas désactiver la bannière consentement du site. Les tests de blocage publicitaire et les tests consentement doivent être exécutés séparément; autrement, vous ne pouvez pas dire si l’extension du navigateur ou la configuration consentement ont bloqué la balise.

Tester au moins trois scénarios consentement

• Un nouveau visiteur qui n’a pas encore fait de choix de cookie.
• Un visiteur qui accepte tous les cookies pertinents.
• Un visiteur qui rejette les cookies marketing.

Pour le mode Consentement de Google, définissez l’état de consentement par défaut avant l’exécution des balises pertinentes, puis mettez-le à jour rapidement sur la même page après que le visiteur ait fait un choix. Vérifier séparément ad_storage, analytics_storage, ad_user_data et ad_personalization. Le mode Consentement avancé peut envoyer des pings sans cookies alors que le stockage est denied; confirmer qu’aucun stockage publicitaire, identifiants publicitaires ou données utilisateur ne sont envoyés contrairement au choix du visiteur.

Outils de diagnostic

1. Google Tag Assistant et GTM Preview

Google Tag Manager Aperçu montre les événements de la page, les balises qui ont tiré, les balises qui n’ont pas tiré, les conditions de déclenchement, les variables et l’état consentement. Il répond à deux questions essentielles : ce qui s’est passé sur le site, et pourquoi GTM a-t-il tiré ou n’a pas tiré une étiquette ?

2. GA4 DebugView

GA4 DebugView confirme si GA4 a effectivement reçu l’événement et affiche ses paramètres. Il aide à séparer un problème d’implémentation GTM d’un problème de livraison ou de collection GA4.

3. Panneau Chrome DevTools Network

Le panneau Network affiche les requêtes que le navigateur envoie vraiment. Vous pouvez filtrer par domaine de plateforme, type de requête, nom de fichier, identifiant de balise ou identifiant de mesure. C’est l’outil clé pour répondre, « Le navigateur a-t-il envoyé les données? »

4. Outils d ‘ essai spécifiques à la plateforme

Utilisez Test Events et diagnostic dans Meta Events Manager; Pixel Helper, Test Events et diagnostic pour TikTok; UET Tag Helper pour Microsoft Advertising; Shopify Pixel Helper pour Shopify pour pixels personnalisés.

4. Suivi complet de la publicité flux de travail diagnostique

Étape 1: Inventairer chaque mise en œuvre de suivi

Les conversions en double proviennent souvent de plusieurs installations de la même plateforme plutôt que d’une seule balise défectueuse.

• GTM est installé une fois dans le thème et à nouveau via un plugin.
• L’application officielle Shopify Meta installe un pixel, et une autre Meta pixel personnalisée est également présente.
• Un plugin WordPress envoie Purchase alors que GTM envoie à nouveau le même Purchase.
• Une action d’achat Google Ads native et une action d’achat GA4 importée sont tous deux des objectifs principaux.
• Meta Pixel et Conversions API envoient le même achat sans dédoublement de travail.
• Une application TikTok, GTM et un code thématique installent chacun le même pixel.

Créer un inventaire de mise en œuvre. Pour la lisibilité, combinez la méthode d’installation, l’emplacement de la balise de base, la source d’achat-événement et l’état serveur-événement dans un champ de notes d’implémentation.

Recherche de chaque ID dans la source de la page, la liste des tags GTM, plugins WordPress, les zones de code personnalisé thème, Shopify Customer Events, Shopify applications, Cloudflare Zaraz, côté serveur GTM, et toute intégration de backend personnalisée.

Étape 2: Confirmer que la balise de base se charge correctement

Pour GTM, ne commencez pas par ouvrir la page de confirmation de commande directement. Connectez Aperçu à partir de la page d’accueil ou de la page d’atterrissage publicitaire, puis suivez le parcours client réel à travers la vue des produits, le panier, la caisse et le paiement.

• Confirmez que Preview est connecté au bon domaine.
• Confirmer que le conteneur GTM attendu apparaît lorsque la page se charge.
• Vérifiez que l’ID du conteneur correspond au compte actif et à l’environnement.
• Confirmez que la base Google tag charge sur toutes les pages requises.
• Vérifiez si la page paiement-succès reste dans la même session de débogage.
• Vérifiez si la session se casse après une redirection ou une transition cross-domain.
• Examiner Consent Initialization et n’importe quel état consentement qui bloque la balise.

En même temps, ouvrez Chrome DevTools et recherchez le panneau Network pour l’ID de conteneur GTM, l’ID de mesure GA4, l’ID de conversion Google Ads, l’ID Meta pixel, l’ID TikTok pixel ou l’ID de balise Microsoft UET. La recherche de l’ID réel est plus fiable que le fait de s’appuyer sur un paramètre fixe parce que les chemins de requête peuvent changer.

Lorsqu’aucune demande n’apparaît du tout, vérifiez d’abord

• Le code est manquant ou l’ID configuré est incorrect.
• Le conteneur GTM n’a pas été publié ou le mauvais environnement est chargé.
• Les paramètres consentement empêchent la balise de fonctionner.
• La politique de sécurité du contenu bloque le script ou le paramètre externe.
• Un bloqueur de publicité ou le paramètre de confidentialité du navigateur bloque la requête.
• Une erreur JavaScript se produit avant l’exécution du code de suivi.
• Un cache ou un CDN sert encore une ancienne version du code du site.

Étape 3: Valider la couche de données ou l’événement client

La couche de données est le pont entre l’activité de e-commerce et les balises publicitaires. Google Tag Manager et gtag.js lisent les événements et les variables de ce calque structuré. Utiliser des données prévisibles et structurées plutôt que de forcer les balises à gratter des valeurs provenant d’éléments de page non liés.

Un événement d’achat simplifié au format GA4 peut se présenter ainsi :

<script>
window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
  event: "purchase",
  ecommerce: {
    transaction_id: "ORD-10086",
    value: 129.90,
    currency: "USD",
    tax: 8.20,
    shipping: 0,
    items: [
      {
        item_id: "SKU-001",
        item_name: "Portable Coffee Grinder",
        price: 64.95,
        quantity: 2
      }
    ]
  }
});
</script>

Pour le e-commerce GA4, la valeur de niveau événementiel devrait normalement correspondre à la somme du prix multiplié par quantité pour le tableau items et ne devrait pas inclure l’expédition ou la taxe à moins que votre définition documentée de déclaration et la plateforme de destination exigent explicitement une valeur différente.

Utilisez la commande suivante dans Chrome Console pour une inspection initiale:

window.dataLayer

Pour afficher uniquement les événements purchase :

window.dataLayer?.filter(item => item.event === "purchase")

Valider ces six points

1 L’événement se produit au bon moment : Purchase doit être généré après que la commande ait vraiment réussi, pas seulement lorsque le client clique sur Payer maintenant ou Soumettre la commande.

2 L’ID de la commande est unique : La même commande doit conserver le même ID après un rafraîchissement, alors que les différentes commandes ne doivent jamais partager le même ID.

3 La valeur est numérique: Utilisez 129.90 $, pas « 129.90 $ », « USD 129.90 », ou une chaîne contenant un séparateur de milliers.

4 La devise correspond à la commande : Sur les magasins multi-devises, comparez la devise affichée, la devise de règlement et la devise envoyée à la plateforme.

5 Le tableau items est complet : les identifiants de produit, les prix, les quantités et les rabais doivent se rapprocher de la commande backend.

1. Les anciennes valeurs ne sont pas conservées : les applications monopages, les paniers latéraux et les parcours de paiement AJAX peuvent réutiliser par erreur les données d’un événement précédent.

Étape 4: Inspecter les déclencheurs et les variables GTM

Effectuez un véritable voyage d’essai en GTM Preview, sélectionnez l’événement purchase et inspectez Tags Fired, Tags Not Fired, Variables, Data Layer et consentement.

Le déclencheur est trop large

Une règle telle que « Page URL contient thank-you » peut se déclencher de nouveau chaque fois que le visiteur actualise, ajoute aux favoris ou revisite la page de confirmation. Pour les achats e-commerce, il est préférable d’utiliser un véritable événement de finalisation de commande et un identifiant de commande unique.

Le déclencheur est trop restrictif

L’URL réelle peut être /en/checkout/success alors que le déclencheur n’autorise que /checkout/success. Les répertoires de langue, les chaînes de requête et les autres parcours de paiement peuvent faire échouer une règle trop stricte.

Les noms d’événements personnalisés ne correspondent pas

La couche de données envoie l’événement « checkout_completed », mais GTM écoute à l’achat. Les noms des événements doivent correspondre exactement, y compris la capitalisation et les soulignés.

Le tag s’allume avant l’arrivée des données

La balise s’exécute pendant le chargement de la page, mais la valeur, la devise et l’ID de commande saisissent la couche de données plusieurs centaines de millisecondes plus tard. La balise semble s’allumer avec succès en envoyant des paramètres vides.

AJAX ou une application monopage ne génère aucun chargement de page classique

Les tiroirs à chariot, les commandes modales et les applications React ou Vue peuvent ne pas générer une vue normale de la page. Déclencher le suivi à partir d’événements d’affaires plutôt que de ne compter que sur des charges de page ou des changements d’URL.

Étape 5 : Utilisez Network pour confirmer qu’une demande a été envoyée

Ouvrir Chrome DevTools -> Network, activer Preserve log et répéter le test complet. Filtrer par ID de plateforme ou domaine. Ouvrez la demande correspondante et inspectez Headers et Payload.

• Vérifier la plateforme de destination et la balise ou pixel ID.
• Vérifier le nom de l’événement, la valeur, la devise et l’identifiant de commande.
• Confirmez que les ID de produit, les quantités et le tableau items sont présents.
• Confirmez que les événements du navigateur et du serveur partagent les identifiants de déduplication spécifiques à la plateforme : Meta et TikTok nécessitent un nom ou un type d’événement correspondant plus event_id, tandis que les achats de GA4 et Google Ads utilisent transaction_id.
• Vérifiez si la demande a été annulée, bloquée ou renvoyée.
• Vérifiez si la requête s’est produite avant ou après la redirection de la page.

Une demande observée avec une charge utile plausible prouve seulement que le navigateur a tenté la livraison ou qu’un paramètre a accepté une demande. Il ne prouve pas le traitement de la plateforme, l’attribution, l’admissibilité des soumissions ou l’exactitude des données commerciales. Une requête Purchase d’une valeur de 0 peut encore être transmise avec succès.

GTM signale que la balise a été activée, mais Network n’affiche aucune requête

• Contrôles consentement et consentement intégrés.
• Paramètres de blocage publicitaire ou de confidentialité du navigateur.
• Les restrictions de la politique de sécurité du contenu.
• Un modèle de balise cassé ou une erreur d’exécution JavaScript.
• Une demande annulée par navigation immédiate.
• Limites Shopify Pixel Sandbox.

Étape 6 : Confirmer la réception à l’intérieur de chaque plateforme publicitaire

GA4

Ouvrez DebugView, sélectionnez l’appareil d’essai et confirmez que la séquence d’événement est raisonnable :

page_view
view_item
add_to_cart
begin_checkout
purchase

Ouvrir l’achat et vérifier transaction_id, la valeur, la devise et les articles.

Google Ads

Ouvrir Goals -> Conversions -> Summary et examiner l’état de suivi de l’action pertinente. Pour Unverified, Tag inactive, or Need attention, lancez Tag Assistant à partir de l’action de conversion. L’état du compte peut prendre du temps pour se rafraîchir après une correction, donc utilisez Tag Assistant et la requête réelle comme couche de validation immédiate.

Meta Ads

Dans Events Manager, sélectionnez la bonne source de données et consultez Aperçu, Test Events, diagnostic, Event Deduplication et Event Match Quality. Test Events confirme la livraison du navigateur et du serveur; diagnostic identifie les événements dupliqués, les paramètres invalides ou les problèmes de qualité des données.

TikTok Ads

Utilisez TikTok Pixel Helper pour inspecter les balises, événements et paramètres du navigateur; Events Manager -> Test Events pour la réception en temps réel; Events Manager -> diagnostic pour les erreurs persistantes d’implémentation.

Microsoft Advertising

Utilisez UET Tag Helper pour valider l’identifiant de balise UET, l’événement de chargement de page, les événements personnalisés, les revenus variables, la devise et les conditions de conversion-objectif. Le statut UET dans Microsoft Advertising peut prendre du temps supplémentaire à mettre à jour. Si Microsoft Advertising Conversions API est également utilisé, vérifiez son event_id et confirmez que la livraison du navigateur et du serveur ne crée pas de reporting en double. Pour des revenus variables, conservez revenue_value et la devise exactement comme requis par la destination.

5. Dupliquer le diagnostic Conversions et Event Deduplication

Les achats dupliqués gonflent les rapports ROAS et alimentent les appels d’offres automatisés en signaux incorrects. Passez en revue le navigateur, le serveur, les plugins, les applications, GTM, et les objectifs importés ensemble plutôt que de vérifier un seul calque.

Dédéduplication Google Ads

Google Ads recommande d’envoyer un ID de transaction unique à chaque achat. Si la page de confirmation se rafraîchit et que la même commande est de nouveau envoyée à la même opération de conversion, Google Ads peut utiliser l’ID de transaction correspondant pour identifier le duplicata. Un identifiant de transaction ne dédouble pas automatiquement les actions de conversion séparées Purchase.

• Différentes commandes ne doivent pas partager le même ID de transaction.
• L’ID de la transaction ne doit pas être vide.
• N’utilisez pas une adresse e-mail client ou un numéro de téléphone comme ID de commande.
• Les balises du navigateur et les téléchargements de backend devraient utiliser le même identifiant de commande pour la même transaction.

Dédéduplication Meta Pixel et Conversions API

Lorsque le même Purchase est envoyé par Meta Pixel et Conversions API, les événements du navigateur et du serveur doivent partager les mêmes event_name et event_id. Des commandes différentes doivent utiliser des valeurs event_id distinctes. Sinon, une seule commande peut être comptabilisée comme deux événements.

• Les événements du navigateur et du serveur utilisent-ils le même event_name ?
• Les deux versions du même commande utilisent-elles le même event_id ?
• Chaque commande différente reçoit-elle un identifiant d’événement différent?
• Un serveur réessaye-t-il de créer un nouvel ID d’événement et génère-t-il accidentellement un second événement ?
• Est-ce qu’une application Shopify et une implémentation CAPI personnalisée envoient le même achat ?

Dédéduplication TikTok Pixel et Events API

Lorsque TikTok Pixel et Events API envoient le même événement, les deux côtés doivent utiliser le même nom ou type d’événement et le même event_id afin que TikTok puisse reconnaître la paire et conserver un événement logique.

Mise à jour de la page de confirmation de commande

Utiliser seulement une page de confirmation pour déclencher Purchase est un risque élevé. Le rafraîchissement, le marquage ou la réouverture de la page peuvent déclencher l’événement à nouveau. Utilisez un identifiant d’commande unique et, dans la mesure du possible, un déclencheur à partir d’un véritable événement de fin d’commande plutôt qu’une charge de page ordinaire.

6. Conversion de l’examen Goals, vérification interdomaines et attribution

Primary par rapport aux actions de conversion secondaire

Dans Google Ads, les actions de conversion primaires apparaissent normalement dans la colonne Conversions et peuvent être utilisées pour les soumissions lorsque la campagne utilise le but pertinent. Les actions Secondary sont principalement destinées à l’observation et apparaissent généralement dans All conversions. Cependant, une action secondaire peut être utilisée pour soumissionner lorsqu’elle est incluse dans un objectif personnalisé que la campagne utilise activement.

Lorsque l’événement apparaît dans le compte, mais que la campagne n’est pas optimale, vérifiez que l’action est primaire et que la campagne utilise l’objectif correspondant.

Every versus One

Les actions Purchase doivent généralement compter chaque transaction. Les formulaires Lead utilisent souvent One parce que les soumissions répétées du même clic publicitaire peuvent ne pas représenter plusieurs pistes de valeur. Pour les ventes, utilisez un ID de transaction unique pour supprimer les commandes en double.

Dupliquer les objectifs d’achat primaires

Un compte peut contenir un Google Ads Purchase, un GA4 Purchase importé et un Purchase créé par une application Shopify. Si tous les trois sont primaires et utilisés par la campagne, la colonne Conversions peut contenir plusieurs signaux d’achat pour une commande.

Amélioration de Conversions

Après avoir activé Enhanced Conversions, confirmez que les données du premier client admissible sont effectivement envoyées dans le format requis. Une balise Purchase de base ne prouve pas que Conversions amélioré est sain.

Passage et redirections de paiement

Certains magasins déplacent les visiteurs du domaine principal vers un domaine de paiement séparé, un fournisseur de paiement tiers, un système de réservation, un service de formulaire, un sous-domaine ou un site régional. Une configuration croisée incorrecte peut causer:

• Une même session client peut être scindée en plusieurs sessions.
• La source de publicité originale à disparaître.
• Le fournisseur de paiement doit devenir la source de référence déclarée.
• Le clic ID à perdre avant la caisse.
• Les événements en vitrine, mais aucun événement après le paiement réussit.

Utilisez la mesure du domaine GA4 uniquement entre les domaines que vous contrôlez et sur lesquels la même balise GA4 peut être déployée. Pour les domaines de paiement tiers où vous ne pouvez pas déployer cette balise, consultez List unwanted referrals afin que le fournisseur ne remplace pas la source d’origine; ce n’est pas un substitut à la mesure croisée. Testez toute la redirection depuis une page d’atterrissage au lieu d’ouvrir la page de succès directement.

7. Suivi spécifique Shopify diagnostic

Shopify Customer Events pixels fonctionnent dans des environnements sandboxed. Les pixels de l’application utilisent un bac à sable Strict, tandis que les pixels personnalisés utilisent un bac à sable Lax; leurs capacités ne sont pas identiques. Les deux devraient s’appuyer sur Shopify Customer Events et sur Web Pixels API au lieu de la raclure traditionnelle DOM.

1. Ne pas compter sur Google Tag Assistant seul

Google Tag Assistant n’est pas compatible avec les pixels personnalisés GTM dans Shopify. Utilisez Shopify Pixel Helper pour confirmer que les événements clients entrent dans le bac à sable, puis validez la demande Network résultante et le Test Events ou les diagnostics de la plateforme de destination.

Shopify Pixel Helper
-> Données Pixel personnalisées
-> balise GTM
-> Demande Network
-> Plateforme publicitaire Test Events

2. Éviter le grattage de DOM à l’intérieur du bac à sable

Shopify Web Pixels fonctionnent dans un bac à sable. Les implémentations qui lisent ou modifient le standfront DOM peuvent échouer ou se comporter de manière incohérente. Préférez les données fournies par Shopify Customer Events et le Web Pixels API au lieu de gratter les prix du produit, les boutons ou les détails de commande avec des sélecteurs CSS.

• Un déclencheur de clic qui écoute directement un bouton de thème.
• A DOM Élément Variable qui efface le prix du produit affiché.
• Utilisation directe de document.querySelector.
• Utiliser l’URL du bac à sable comme si c’était l’URL du magasin.
• En supposant que GA4 mesure améliorée peut découvrir chaque interaction sandboxed automatiquement.

3. Vérifier si le pixel attend consentement

Ouvrir Shopify Paramètres -> Événements clients -> Personnalisez les pixels et lancez un test. Si Pixel Helper signale que Pixel attend consentement, revoyez :

• Les autorisations de confidentialité client attribuées au pixel personnalisé.
• Configuration de bannière de cookies pour le marché actif.
• Que ce soit le visiteur granted Analytics ou le marketing consentement.
• Indique si la plateforme de gestion consentement s’intègre à l’API de confidentialité client Shopify.

4. Utiliser correctement checkout_completed

Shopify checkout_completed tire normalement une fois par caisse et est souvent observé sur la page Merci. Avec un upsell post-achat, il peut tirer sur la première page de upsell plutôt que de nouveau sur la page Merci. Il peut également ne pas tirer lorsque la page attendue ne se charge pas avec succès.

Tester la caisse standard, Shop Pay ou la caisse accélérée, les commandes à prix réduit, les commandes gratuites, les ventes en hausse après achat, les commandes multi-devises et les cas où la page Merci ne charge pas entièrement.

8. Questions courantes de diagnostic WordPress et WooCommerce

Le problème WordPress le plus courant n’est pas une incapacité à installer le suivi ; il installe le même suivi dans trop d’endroits. Examiner les emplacements suivants dans l’commande :

• Plugins d’installation GTM.
• GA4 ou plugins de conversion publicitaire.
• Séparer les plugins Meta, TikTok ou Microsoft Advertising.
• En-tête de thème et zones de code personnalisé de pied de page.
• Code personnalisé du constructeur de pages.
• WooCommerce Merci Vous personnalisez les pages.
• CDN, cache, script-combination et paramètres de retard JavaScript.

Les parcours WooCommerce d’ajout au panier, de paiement et de règlement sont souvent modifiés par AJAX ou des extensions tierces. Ne supposez pas qu’une règle standard fondée sur un clic de bouton ou qu’une règle par défaut liée à la page de confirmation fonctionne encore. Utilisez la couche de données réelle et l’événement de finalisation de commande comme source de référence.

Contrôles supplémentaires des performances et des plugins de cache

• Doivent-ils retarder le chargement de GTM ou de pixel ?
• Les scripts combinés changent-ils l’commande d’exécution ?
• Une page de confirmation de commande contenant des données de commande est-elle en cache ?
• La mise à jour consentement se produit-elle après que les balises publicitaires ont déjà été exécutées ?
• Est-ce que les requêtes de suivi de tiers sont bloquées ou proxiées incorrectement?
• Le problème n’apparaît-il que lorsque l’administrateur est déconnecté?

9. Matrice de dépannage

10. Critères d’acceptation pour une mise en œuvre fiable

Un achat d’essai réussi doit satisfaire à toutes les conditions suivantes :

• Purchase n’allume qu’après que la commande soit vraiment réussie.
• L’commande de test One résout une conversion logique après la déduplication.
• L’identification de commande correspond au système e-commerce.
• La valeur de conversion suit la définition convenue et la devise est correcte.
• Les ID de produit, les prix et les quantités sont exacts.
• GTM Preview montre l’événement complet et les variables peuplées.
• La requête correspondante existe dans Network.
• La plateforme de destination reconnaît l’événement dans son outil de test.
• Les événements navigateur et serveur sont dédoublés.
• Les états consentement acceptés et rejetés produisent le comportement prévu.
• Google Ads Primary, Secondary et les paramètres de comptage sont corrects.
• La commande croisée conserve la source originale.
• Rafraîchir la page de confirmation ne crée pas une autre conversion indépendante.

Norme d'acceptation finale
One commande d'affaires réel -> une conversion de publicité logique après la dédéduplication -> l'identification de commande correcte, la valeur, la devise et les données de produit -> vérifié dans la plateforme -> conciliable avec le système e-commerce.

11. Modèle de rapport diagnostique de suivi de la publicité

Utilisez la structure ci-dessous pour enregistrer la vérification. Enregistrer les captures d’écran du chemin de test, la charge utile Network, la plateforme Test Events et l’commande du moteur comme pièces jointes.

1. Site Web et environnement

2. Inventaire des installations de suivi

3. Ordre d ‘ essai

4. Résultats du diagnostic

5. Questions et mesures correctives

6. Essais de régression

Chaîne complète des preuves

Action des entreprises
-> Événement client / Data Layer
-> GTM Déclencheur
-> Étiquette publicitaire
-> Network Demande
-> Événement de test de plateforme
-> Objectif de conversion
-> Réconciliation des moteurs

Les données de conversion ne doivent être utilisées pour évaluer les campagnes, produire des rapports ROAS et automatiser les enchères que lorsque chaque niveau de cette chaîne est correct.