L’outil de test affiche un succès, mais le rapport de ventes semble incohérent. Par où commencer ? L’événement a peut-être une mauvaise valeur, a été envoyé deux fois ou est arrivé tard. La bonne réception de l’événement est une étape du contrôle, pas sa conclusion.
Le Pixel transmet les événements du site via le navigateur. CAPI signifie Conversions API, un canal d’envoi depuis le serveur. Examinez l’action réelle, les données envoyées et leur lecture dans le rapport. Meta aborde la qualité, la correspondance, la déduplication et la fraîcheur des événements ; TikTok explique le chevauchement entre Pixel et Events API. Les modalités varient selon la plateforme et l’intégration. [1] [2]
1. Définissez l’événement avant de suivre son parcours
Quand une commande devient-elle un achat : à l’envoi du formulaire, au paiement confirmé ou à une autre étape ? Convenez-en avec le responsable de l’activité, puis notez l’événement correspondant dans la plateforme. Précisez valeur, devise et traitement des remises et annulations.
Choisissez un référentiel pour les tests, comme le système de commandes ou le CRM. Cherchez à comprendre les écarts plutôt qu’à imposer une égalité systématique entre rapports publicitaires et données métier. Réception et attribution publicitaire sont deux questions différentes.
2. Distinguez l’heure de l’achat de celle de réception
Notez l’heure de l’action, de l’envoi, de la réception et le fuseau horaire. Après une panne, vérifiez qu’une nouvelle tentative décrit toujours la même opération et ne crée pas une nouvelle transaction par erreur.
Le tracking côté serveur décrit un circuit technique ; il n’autorise pas, à lui seul, à collecter davantage de données. Revoyez consentements, politiques et modalités de traitement avant de modifier les champs. Utilisez des données de test et un environnement adapté.
Mise en pratique : cinq cas précis à vérifier
Ces événements fictifs constituent une checklist proposée, pas une fenêtre de déduplication commune aux plateformes.
| Cas | Action de test | Contrôle |
|---|---|---|
| Événement valide | Achat test de valeur et devise connues | Nom, valeur, devise et horaire |
| Deux sources pour une action | Copies prévues côté navigateur et serveur | Rapprochement sans gonfler le résultat selon le mécanisme de la plateforme |
| Nouvelle tentative | Renvoi après panne simulée | Aucune nouvelle commande métier |
| Valeur invalide | Devise supprimée ou modifiée dans une copie test | Détection et journal de traitement |
| Action incomplète | Abandon avant l’étape convenue | Aucun faux achat finalisé |
Écrivez d’abord le résultat attendu, puis les observations et preuves. Si le parcours reste incomplet, notez « non résolu ». C’est plus utile qu’un indicateur de succès qui masque les étapes non testées.
3. Expliquez l’écart avant de modifier les réglages
Vérifiez période, devise et définition du revenu, puis événements manquants, doublons ou retards, et enfin attribution et modélisation si elles interviennent.
Si navigateur et serveur envoient le même achat, examinez le rapprochement prévu par l’intégration. Si l’événement arrive tard, vérifiez son horaire plutôt que de modifier le budget sur la base d’un rapport incomplet. Testez les hypothèses avant d’accuser un canal.
4. Livrez des corrections que l’on peut retester
Pour chaque problème : responsable, modification et cas à rejouer. Conservez les réglages précédents et séparez si possible le circuit d’envoi de la définition de l’achat.
Rejouez les cas concernés après un changement de thème, d’application boutique ou d’outil de taggage. Le test établit le comportement des cas vérifiés, pas de tous les visiteurs. Avant une décision budgétaire, indiquez ce qui est contrôlé et ce qui reste ouvert.
Sources officielles
Documentation consultée le 16 octobre 2026. Fonctionnalités et conditions peuvent évoluer ; consultez les sources avant la mise en œuvre.
