Pixel et API serveur : ne compte pas chaque vente deux fois

Publié le 24 septembre 2026 par l'équipe Oriva.

Quand une vente part à la fois du navigateur (le pixel) et du serveur (l'API), chaque plateforme ne la compte qu'une fois si les deux copies portent le même nom d'événement et le même identifiant. Le nom du champ change selon la plateforme : eventID et event_id chez Meta, event_id des deux côtés chez TikTok, transaction_id et transactionId chez Google Ads, event_id et id chez ChatGPT Ads. La règle est la même partout : donne ta référence de commande aux deux. Sans identifiant commun, chaque plateforme compte la vente deux fois.

Pourquoi une vente est-elle comptée deux fois ?

Une même vente peut arriver par deux chemins : le pixel du navigateur, quand la page de confirmation s'affiche, et l'API du serveur, quand la commande est confirmée. Chaque copie est légitime. C'est leur comptage qui fait doublon si la plateforme ne peut pas les reconnaître comme la même vente.

Comment chaque plateforme déduplique-t-elle ?

	Meta	TikTok	Google Ads	ChatGPT Ads
Champ côté navigateur	eventID	event_id	transaction_id	event_id
Champ côté serveur	event_id	event_id	transactionId	id
Doit aussi correspondre	Le nom de l'événement	Le nom de l'événement	La même action de conversion	Le Pixel ID et le nom de l'événement
Fenêtre	48 heures	48 heures	Non précisée	Non précisée
Copie gardée	En général la première reçue	La première reçue	La seconde est écartée	La première reçue

Trois précisions écrites par les plateformes :

Meta garde « en général » l'événement reçu en premier, quand les deux ne diffèrent pas de façon significative ;
TikTok exige de partager event_id des deux côtés : « You must share Event ID (event_id) as a parameter through both Pixel and Events API to ensure deduplication takes place. »
ChatGPT Ads : pour un événement personnalisé, le custom_event_name doit aussi être le même des deux côtés.

Quel identifiant utiliser ?

Ta référence de commande : un numéro unique, généré par ton site ou ta plateforme pour chaque achat. Google le demande en ces termes : un identifiant unique, « such as an order confirmation number », généré dynamiquement par le back-office. Une valeur fixe ou codée en dur fait compter beaucoup moins de conversions que la réalité.

Donne exactement la même valeur au pixel et à l'API. Pour un lead, utilise l'identifiant du contact ou de la demande.

Qu'est-ce qui casse la déduplication ?

Un identifiant tiré au hasard côté navigateur. Si le pixel n'a pas ta référence de commande, il en génère une au hasard, que l'API ne peut pas connaître ;
Un nom d'événement différent. Meta et TikTok exigent le même nom des deux côtés, ChatGPT Ads aussi ;
Un côté qui n'envoie pas l'identifiant. TikTok l'exige des deux côtés ;
Une intégration qui envoie une copie avec son propre identifiant, que tu ne choisis pas. C'est le cas de l'app Facebook & Instagram de Shopify réglée sur « Maximum » : lis notre guide Shopify.

Même référence de commande des deux côtés
1. Vente sur ton sitele visiteur achète
2. Pixelenvoie order-1001
3. API serveurenvoie order-1001
Comptée une fois
Le pixel n'a pas ta référence de commande
1. Vente sur ton sitele visiteur achète
2. Pixelgénère un identifiant au hasard
3. API serveurenvoie order-1001
Comptée deux fois

Schéma simplifié, une seule cause parmi celles listées ci-dessus.

Et si je n'ai pas d'identifiant côté pixel ?

Meta propose un repli : elle compare fbp ou external_id, avec le même nom d'événement. Ce repli ne marche que pour un événement envoyé d'abord par le navigateur, puis par le serveur : un événement serveur n'est pas écarté si aucun événement navigateur n'est arrivé dans les 48 heures avant lui. Il ne déduplique pas non plus quand une seule source envoie.

C'est un repli, pas une méthode : une référence de commande commune reste plus fiable.

Comment vérifier ?

Compare, sur quelques commandes réelles, le nombre de ventes que ta plateforme publicitaire annonce et le nombre de commandes de ta boutique. Un écart qui va dans le sens d'un doublon (deux fois plus de ventes côté plateforme) est le signal.

L'onglet Santé d'Oriva le cherche pour toi, sur les 7 derniers jours :

des achats navigateur dont l'identifiant ressemble à un identifiant généré automatiquement ;
des commandes vues à la fois côté navigateur et côté serveur avec des identifiants différents ;
un pixel Meta, TikTok ou OpenAI détecté à côté d'une destination Oriva active, avec le rappel de vérifier que les deux utilisent le même identifiant.

Ce qu'Oriva fait pour toi

Oriva envoie le même identifiant à chaque plateforme comme clé de déduplication : event_id chez Meta et TikTok, transactionId chez Google Ads, id chez ChatGPT Ads ;
Shopify : le pixel personnalisé d'Oriva construit l'identifiant à partir du numéro de commande, donc un rafraîchissement de la page ne compte pas deux fois, et ton pixel Meta peut déduplier contre le même identifiant ;
WooCommerce : l'extrait d'Oriva utilise le numéro de commande comme identifiant ;
Un site quelconque : passe ta référence de commande à oriva("track", "purchase", { event_id: … }) et à l'appel serveur. Si tu la laisses de côté côté navigateur, le snippet en génère une au hasard et la vente sera comptée deux fois ;
Oriva dédoublonne d'abord chez lui : deux événements avec le même event_id sur une même property ne comptent qu'une fois.

Qui n'a pas besoin d'Oriva ?

Tu n'envoies chaque vente que par une seule voie, le pixel seul ou l'API seule. Il n'y a rien à dédupliquer : TikTok l'écrit (« Deduplication is not required if you share different events separately between the Pixel and the Events API, without event overlap »), si tu partages des événements différents sans chevauchement.
Tu sais donner ta référence de commande au pixel et à l'API toi-même, dans ton tag ou ton code. La règle de chaque plateforme est dans le tableau : c'est une question d'identifiant, pas d'outil.

Oriva sert quand tu envoies vers plusieurs plateformes et que tu veux qu'un seul identifiant serve partout, avec un journal qui montre ce qui est parti.

Commencer l'essai gratuit