Vous avez installé la CAPI et votre chiffre d'affaires a doublé. Non.

Installer l'API Conversions est la bonne décision. Le suivi navigateur perd des événements à cause des bloqueurs de publicité, de la protection contre le pistage, des sessions interrompues et des pages abandonnées, et un flux côté serveur en récupère une bonne partie. Presque tout le monde devrait faire tourner les deux.

Mais « faire tourner les deux » signifie que Meta reçoit désormais deux signalements de chaque achat, et la seule chose qui l'empêche de les compter deux fois est un identifiant commun. Si cet identifiant est faux dans un sens, votre chiffre d'affaires double sur le papier. S'il est faux dans l'autre, votre chiffre d'affaires est discrètement divisé par deux.

Comment fonctionne réellement la déduplication

Meta fait correspondre deux champs ensemble : event_name et event_id. Les deux doivent concorder.

Browser:
  event_name: "Purchase"
  event_id:   "a91f-2026-08-12"

Server:
  event_name: "Purchase"
  event_id:   "1047"

Browser:
  event_name: "Purchase"
  event_id:   "order_1047"

Server:
  event_name: "Purchase"
  event_id:   "order_1047"

La règle est simple à énoncer et facile à enfreindre en pratique, car les deux côtés sont généralement construits par des systèmes différents à des moments différents. L'événement navigateur est généré par un thème ou un gestionnaire de balises ; l'événement serveur par une application, un service intermédiaire ou votre propre code. Rien ne les oblige à concorder, et rien ne vous prévient quand ce n'est pas le cas.

Choisir un identifiant qui ne peut pas dériver

L'identifiant doit être unique par commande et identique sur les deux chemins. Ces deux exigences éliminent la plupart des choix qui viennent spontanément.

Les horodatages sont le pire choix et le plus tentant, car ils semblent uniques. Ils ne le sont pas : deux commandes passées dans la même seconde se télescopent, et l'horloge du navigateur n'est pas celle de votre serveur. Un UUID convient uniquement s'il est généré une fois puis transmis à l'autre côté. Si chaque côté génère le sien, vous avez construit une machine à doublons.

Prouver que ça fonctionne, au lieu de le supposer

Configuré ne veut pas dire fonctionnel. Voici le test qui tranche, et il prend environ quinze minutes.

1. Passer une vraie commandeUn vrai achat via le vrai checkout, pas un lien de test. Notez le numéro de commande.
2. Récupérer l'ID d'événement côté navigateurOuvrez les DevTools avant le paiement, filtrez l'onglet Network sur facebook, finalisez la commande et lisez l'eventID de la requête Purchase.
3. Récupérer l'ID d'événement côté serveurDans les journaux de votre intégration CAPI, ou dans le Gestionnaire d'événements, trouvez l'événement côté serveur de la même commande et lisez son event_id.
4. Les comparer caractère par caractèrePas similaires. Identiques. Un préfixe d'un côté (order_1047 contre 1047) est une erreur, pas un détail.
5. Vérifier les rapports de déduplicationDans le Gestionnaire d'événements, ouvrez l'événement Purchase et regardez comment il est reçu. Une configuration correctement dédupliquée montre le navigateur et le serveur comme sources du même événement, pas deux totaux séparés.
6. Rapprocher une semaine complèteComparez le nombre de commandes de votre boutique avec les achats du Gestionnaire d'événements sur une semaine clôturée. Nettement au-dessus de vos commandes, c'est un doublon. Nettement en dessous, c'est une perte.

Le chiffre qui vous dit que ça marche

Une fois la déduplication correcte, l'indicateur à surveiller est l'Event Match Quality. Il reflète la quantité d'informations d'identification envoyées avec chaque événement (e-mail haché, téléphone, nom, localisation, identifiants de clic) et détermine la capacité de Meta à attribuer une conversion à la personne qui a vu la publicité.

C'est là que l'API Conversions justifie son existence. Votre serveur connaît l'e-mail et le téléphone du client parce qu'il vient d'acheter. Le navigateur, souvent, non. Envoyer ces données côté serveur, correctement hachées, est généralement un gain plus important que la récupération des événements bloqués.

Ce que je n'affirme pas

Je ne vous ai pas donné de score Event Match Quality cible ni de gain attendu grâce à la CAPI. Les deux dépendent entièrement des données clients que vous pouvez légitimement collecter, de votre checkout et de votre trafic, et chaque référence publiée que j'ai vue provient d'un éditeur dont le produit améliore justement le chiffre mesuré.

Mesurez votre propre point de départ avant le changement, mesurez à nouveau après une fenêtre d'attribution complète, et comparez-vous à vous-même. Cette comparaison vaut plus que n'importe quelle moyenne publiée.