Déduplication d'événements Pixel / CAPI : pourquoi et comment

Quand on met en place la Conversions API (CAPI) en complément du Pixel, on envoie le même achat deux fois à Meta : une fois depuis le navigateur, une fois depuis le serveur. Sans déduplication, Meta compte deux conversions au lieu d'une. Résultat : des chiffres gonflés, un ROAS faussé, et des décisions de budget prises sur de mauvaises données. C'est l'une des erreurs les plus fréquentes — et les plus coûteuses — sur les installations de tracking server-side.

Pourquoi envoyer l'événement deux fois ?

Ce n'est pas une erreur, c'est volontaire. Le Pixel (navigateur) capte le contexte (cookies, comportement de navigation, paramètres publicitaires) mais perd des événements à cause d'iOS, des bloqueurs de pub et des navigateurs stricts comme Safari. La CAPI (serveur) est fiable — rien ne l'arrête — mais elle a moins de contexte natif. En envoyant les deux, on maximise la couverture : ce que le navigateur perd, le serveur le rattrape. Mais il faut alors dire à Meta que ces deux signaux décrivent un seul et même événement.

La clé : l'event_id

La déduplication repose sur deux paramètres que Meta compare pour rapprocher les signaux : l'event_name (ex. Purchase) et surtout l'event_id, un identifiant unique partagé entre le Pixel et la CAPI pour un même événement. Si les deux signaux portent le même couple event_name + event_id dans la fenêtre de déduplication, Meta comprend qu'il s'agit d'un doublon et n'en garde qu'un.

• On génère un event_id unique par événement (par exemple un identifiant de commande, ou un UUID stocké au moment de l'achat).
• Le Pixel envoie l'événement avec cet event_id (paramètre eventID côté navigateur).
• La CAPI envoie le même événement avec le MÊME event_id (champ event_id côté serveur).
• Meta voit deux signaux portant le même event_id → il les fusionne et ne compte qu'une conversion.

La bonne architecture : une seule source d'event_id

Le secret d'une déduplication fiable tient en une phrase : l'event_id doit être généré une seule fois, puis partagé aux deux canaux. La méthode robuste consiste à générer l'identifiant au niveau du serveur (ou à figer l'identifiant de commande) et à l'injecter dans la page pour que le Pixel l'utilise, tout en l'envoyant à la CAPI. On évite ainsi le piège n°1 : deux générations indépendantes qui produisent deux valeurs différentes.

• Générer l'event_id à un seul endroit (idéalement côté serveur, ou l'identifiant de commande).
• Le transmettre au Pixel via la page (pas de re-génération dans le navigateur).
• Envoyer strictement la même valeur à la CAPI, avec le même event_name.
• Aligner aussi les paramètres de matching (fbp, fbc) pour un rapprochement optimal.

Les pièges classiques

• Générer l'event_id à deux endroits différents (Pixel et serveur indépendamment) → les ID ne correspondent pas → aucune déduplication.
• Oublier d'envoyer exactement le même event_name des deux côtés (un « Purchase » côté Pixel et un « purchase » côté serveur ne se rapprochent pas).
• Dépasser la fenêtre de déduplication : Meta ne rapproche les signaux que sur une période limitée (de l'ordre de quelques jours). Un serveur qui envoie l'événement trop tard crée un doublon.
• Confondre event_id et external_id : l'external_id sert au matching d'utilisateur (Advanced Matching), pas à la déduplication des événements.
• Ne dédupliquer que l'achat et oublier les autres événements (Lead, AddToCart) envoyés eux aussi en double.

Comment vérifier que ça marche

Dans le gestionnaire d'événements Meta, chaque événement affiche le nombre reçu par le navigateur, par le serveur, et le pourcentage dédupliqué. Une intégration propre montre un taux de déduplication élevé : Meta reçoit bien les deux signaux mais ne compte qu'une conversion. L'outil de test d'événements (Test Events) permet en plus de voir en direct, événement par événement, si le rapprochement se fait bien pendant la phase de réglage.

Le symptôme à surveiller est simple : si vous voyez vos conversions doubler après l'ajout de la CAPI, c'est le signal d'une déduplication absente ou cassée — à corriger en priorité avant d'optimiser quoi que ce soit. À l'inverse, une déduplication qui fonctionne se traduit par un volume de conversions stable mais bien plus fiable, car nourri par les deux canaux sans double comptage. C'est cette fiabilité qui permet ensuite de piloter les budgets sur des chiffres justes.