Qu'est-ce que l'event_id dans la Conversions API Meta ?

L'event_id est un identifiant unique généré pour chaque conversion et envoyé à l'identique par le pixel navigateur et par la Conversions API. Quand Meta reçoit deux événements portant le même event_id et le même event_name dans une fenêtre de 48 heures, il n'en garde qu'un : c'est la déduplication.

Faut-il désactiver le pixel quand on installe la CAPI ?

Non. Meta recommande la configuration redondante : pixel ET Conversions API envoient chaque événement, avec un event_id partagé. Le pixel apporte les signaux navigateur (fbp, fbc), le serveur assure la fiabilité. Désactiver le pixel dégrade la qualité de correspondance (EMQ).

La déduplication fonctionne-t-elle entre des événements de noms différents ?

Non. Meta ne déduplique que les événements portant à la fois le même event_name et le même event_id. Un « Purchase » côté pixel et un « Achat » côté serveur ne seront jamais dédupliqués, même avec un event_id identique.

Accueil → Ressources → Déduplication Pixel & CAPI Meta

Pixel Meta + CAPI : pourquoi vos conversions comptent double (et comment le corriger)

Q: Comment savoir si mes conversions Meta sont comptées en double ?

Comparez le nombre d'achats dans le Gestionnaire d'événements Meta avec votre back-office sur 7 jours. Un écart supérieur à +10 % côté Meta est le symptôme classique. Confirmez dans le détail d'un événement purchase : si les réceptions « Navigateur » et « Serveur » n'affichent pas de mention « dédupliqué », chaque vente compte deux fois.

Nicolas Malabre · Publié le 10 juillet 2026 · Lecture 6 min

Quand le pixel Meta et la Conversions API envoient chacun la même conversion sans event_id partagé, Meta ne peut pas savoir qu'il s'agit du même achat : il compte double, ou choisit arbitrairement lequel garder. La correction tient en une règle — même event_name + même event_id des deux côtés — et se vérifie en 5 minutes dans le Gestionnaire d'événements.

Comment Meta déduplique vos conversions ?

Depuis iOS 14, la configuration recommandée par Meta est redondante : chaque événement part deux fois — une fois du navigateur (le pixel), une fois de votre serveur (la Conversions API). Le navigateur apporte les signaux de correspondance (fbp, fbc) ; le serveur assure que l'événement arrive même quand Safari, iOS ou un adblocker bloque le pixel.

Pour ne pas compter chaque vente deux fois, Meta applique une règle simple : deux événements reçus avec le même event_name et le même event_id dans une fenêtre de 48 heures sont fusionnés en un seul. C'est toute la déduplication. Et c'est précisément ce maillon qui manque — ou diverge — dans la majorité des installations que je scanne.

0 / 8Sur 8 marques DTC beauté françaises scannées en juin 2026 (stacks Shopify et WooCommerce, toutes actives en publicité Meta), aucune n'avait de tracking server-side détectable — donc aucune déduplication possible, ou une CAPI branchée par plugin sans event_id cohérent avec le pixel.

Quels sont les deux symptômes (opposés) d'une dédup cassée ?

Symptôme n°1 : vous comptez trop. La CAPI envoie les achats, le pixel aussi, aucun event_id commun : votre colonne « Achats » dans le Gestionnaire de publicités gonfle de +20 à +100 % par rapport au back-office. Le smart bidding croit que tout fonctionne, votre CPA affiché est artificiellement beau, et vos décisions budgétaires reposent sur un mirage.

Symptôme n°2 : vous comptez trop peu. Pas de CAPI du tout (le cas des 8 marques scannées) : dès que le navigateur bloque le pixel — Safari et ses cookies à 7 jours, iOS, adblockers — la conversion disparaît purement. L'algorithme apprend sur un signal amputé et vos meilleures audiences semblent « ne pas convertir ».

Les deux symptômes ont la même racine : le lien entre les deux canaux d'envoi n'existe pas.

Comment vérifier chez vous, en 5 minutes ?

Comparez les totaux. Gestionnaire d'événements Meta → événement Purchase → total sur 7 jours, contre les commandes réelles de votre back-office. Écart supérieur à ±10 % = creusez.
Ouvrez le détail de l'événement. Dans le Gestionnaire d'événements, cliquez sur Purchase → « Afficher les détails ». Vous devez voir les deux canaux de réception — Navigateur et Serveur — avec la mention explicite d'événements dédupliqués. Un seul canal listé, ou deux canaux sans déduplication affichée : problème confirmé.
Testez un achat (ou un ajout panier) vous-même. Outil de test d'événements → votre événement doit apparaître en double réception, fusionnée. S'il apparaît deux fois séparément, l'event_id diverge.

Pourquoi ça casse, concrètement ?

Cause	Ce qui se passe	Où je le vois en scan
Pas de CAPI	Pixel seul → conversions perdues à chaque blocage navigateur	Aucun endpoint first-party, aucun envoi serveur
CAPI par plugin, pixel par thème	Deux installations qui s'ignorent → `event_id` absents ou différents	Doublons visibles dans le Gestionnaire d'événements
`event_name` divergents	« Purchase » vs nom custom → jamais fusionnés, même avec un bon `event_id`	Deux événements distincts dans l'outil de test
`event_id` régénéré	Chaque canal génère le sien → fusion impossible	IDs aléatoires des deux côtés
Purchase au rechargement	La page de confirmation renvoie l'événement à chaque visite → doublons même sans CAPI	Pas de garde sur le `transaction_id`

Comment corriger proprement ?

La correction durable passe par une source unique de vérité pour la génération de l'event_id :

L'event_id est généré une seule fois, côté navigateur (souvent : transaction_id de la commande, ou un UUID poussé dans le dataLayer).
Le pixel l'envoie dans son appel — paramètre eventID.
Le même identifiant transite vers votre conteneur GTM server-side, qui l'envoie à la Conversions API — champ event_id.
Les event_name sont strictement identiques des deux côtés, et le purchase est protégé contre le rechargement de la page de confirmation (garde sur transaction_id).

C'est exactement le périmètre d'un Tracking Fix server-side : conteneur serveur first-party, CAPI dédupliquée, GA4 propre et Consent Mode V2 — parce qu'une CAPI qui envoie des événements sans respecter le consentement échange un problème de mesure contre un problème juridique.

Une chose que je précise toujours : le server-side n'est pas une religion. Si votre volume est faible ou votre stack très simple, une dédup propre entre un pixel et une CAPI de plugin bien configurée peut suffire. C'est le genre d'arbitrage qui se tranche sur un scan réel, pas sur un article.

FAQ

Comment savoir si mes conversions Meta sont comptées en double ?

Comparez les achats du Gestionnaire d'événements avec votre back-office sur 7 jours. Un écart de plus de +10 % côté Meta est le symptôme classique. Confirmez dans le détail de l'événement Purchase : sans mention « dédupliqué » entre les réceptions Navigateur et Serveur, chaque vente compte deux fois.

Qu'est-ce que l'event_id exactement ?

Un identifiant unique par conversion, envoyé à l'identique par le pixel et par la Conversions API. Même event_id + même event_name dans les 48 h = Meta n'en garde qu'un.

Faut-il couper le pixel quand on installe la CAPI ?

Non — la configuration recommandée est redondante. Le pixel apporte les signaux navigateur (fbp, fbc) qui nourrissent la qualité de correspondance (EMQ) ; le serveur apporte la fiabilité. On garde les deux, dédupliqués.

La dédup marche-t-elle entre des event_name différents ?

Non. « Purchase » côté pixel et « Achat » côté serveur ne seront jamais fusionnés, même avec le même event_id. Les noms doivent être strictement identiques.

Nicolas MalabreMedia buyer senior — 10 ans d'achat média Google Ads & Meta. Je scanne des stacks e-commerce chaque semaine et je répare la couche de mesure des marques qui dépensent en publicité. Profil Malt ↗

Un doute sur votre déduplication ?

Je scanne votre stack avant le call et je vous montre, requêtes réseau à l'appui, si vos conversions comptent double — ou pas du tout.

Diagnostic gratuit — 30 min

Vous repartez avec le diagnostic, que l'on travaille ensemble ou non.