Le symptôme : le Gestionnaire d’événements (Events Manager) affiche des Purchase ou des Lead que votre système de commandes ou votre CRM ne retrouve pas. Un annonceur a signalé 105 achats en une journée sur une publicité de trafic, contre zéro commande en boutique (fil de la communauté d’une plateforme de boutique, ouvert le 25 déc. 2023, signalé par des annonceurs). Cet écart désigne des événements qui n’ont jamais eu lieu ou des bugs de suivi. Une vraie action frauduleuse ne laisse pas d’écart, puisque la commande ou le lead existe ; elle apparaît plus tard sous la forme d’une rétrofacturation ou d’un lead que personne ne parvient à joindre. Pour savoir comment les bots et le trafic non valide atteignent d’abord les publicités Meta, commencez par notre guide de la fraude au clic sur Meta Ads.
Comment nous avons vérifié. Aucun test n’a été mené sur un compte publicitaire. Le comportement de Meta provient de pages Meta for Developers lues le 12 novembre 2026, et les schémas signalés par les annonceurs proviennent de fils de communauté datés.
Comment les faux événements Meta Pixel sont-ils créés ?
Les événements suspects ont trois causes : des événements qui n’ont jamais eu lieu (un script ou un navigateur headless qui déclenche le pixel), de vraies actions frauduleuses qui produisent de vrais événements (comme des commandes de test de cartes) et des bugs de suivi (doubles installations, règles de configuration qui se déclenchent à tort, test_event_code oublié). Une question en trie la plupart : existe-t-il un enregistrement dans votre système de commandes ou votre CRM ? Sans enregistrement et avec un événement qui se reproduit sur votre propre page, c’est un bug ; sans enregistrement et sans reproduction, il n’a jamais eu lieu ; avec un enregistrement frauduleux, c’est une vraie fraude.
La nouvelle documentation de Meta appelle jeu de données l’espace où sont stockés vos événements : le Meta Pixel y envoie les événements du navigateur, l’API Conversions de Meta y envoie les événements serveur, et le Gestionnaire d’événements affiche les deux. Le pixel est un script public dont l’identifiant figure dans le code source de votre page. Meta définit Purchase ainsi : « lorsqu’un achat est effectué ou que le parcours de paiement est terminé », et indique que currency et value sont obligatoires pour cet événement (référence du Meta Pixel). Rien dans cet appel ne prouve qu’un achat a eu lieu.
Événements qui n’ont jamais eu lieu. Tout script capable d’exécuter le pixel peut appeler fbq('track', 'Purchase') avec n’importe quelle valeur. Un navigateur headless fait la même chose de façon moins visible, en déclenchant les événements qu’une personne déclencherait.
Actions frauduleuses réelles. Un bot de test de cartes qui termine le paiement avec une carte volée crée une vraie commande : le Purchase est donc un vrai événement. Un commerçant a signalé en mai dernier des bots qui commandaient des centaines de fois le même produit, ce qui touchait son pixel (fil de la communauté d’une plateforme de boutique, ouvert le 16 mai 2026, signalé par des annonceurs). Notre page sur la protection contre la fraude au clic pour l’e-commerce traite le côté boutique.
Bugs de suivi. Les plus courants sont les doubles installations du pixel, une page de remerciement qui se redéclenche à chaque rechargement, un test_event_code oublié en production, des clés de déduplication défaillantes et des règles de configuration qui déclenchent Purchase sur la mauvaise page. En octobre 2026, une réponse dans le fil des 105 achats cité plus haut suggérait de chercher une règle de l’outil de configuration d’événements (Event Setup Tool) qui transforme des pages vues en événements Purchase (signalé par des annonceurs).
Bugs côté Meta. Un commerçant a signalé des achats à valeur nulle qui gonflaient les totaux, puis a écrit le 20 février 2025 que Meta avait corrigé un bug de son côté, issu d’un déploiement de code entre le 8 et le 11 février, depuis annulé (fil de la communauté d’une plateforme de boutique, ouvert le 10 févr. 2025, signalé par des annonceurs).
Pourquoi Meta optimise-t-il sur de faux événements ?
Notre lecture : la diffusion de Meta apprend des conversions que vous signalez ; un faux Purchase ou Lead lui apprend donc à trouver davantage de visites semblables au faux.
L’optimisation de la valeur ajoute une seconde distorsion : une série de Purchase à 0 $ ou à valeur ronde fausse la valeur qu’un acheteur apporte selon le système, toujours selon notre lecture.
Où les faux événements apparaissent-ils dans le Gestionnaire d’événements ?
Le Gestionnaire d’événements affiche des volumes, des méthodes de connexion et des taux de déduplication, et les contrôles de données documentés de Meta signalent des données mal formées, pas les faux événements Meta Pixel. Servez-vous-en pour repérer un écart, puis confirmez la cause ailleurs.
- Overview (vue d’ensemble). Meta indique qu’Overview affiche « le nombre d’événements reçus avant qu’ils ne soient dédoublonnés », et que, sous Connection Method, « on voit le canal par lequel cet événement a été envoyé » (Verifying Your Setup, Meta for Developers). Comparez son nombre quotidien de Purchase aux commandes payées.
- Event Details (détails de l’événement). Ouvert depuis Overview, son onglet Event Deduplication affiche le « pourcentage d’événements dédoublonnés pour chaque source d’événements » et la fréquence d’utilisation de chaque clé de déduplication (même page).
- API Dataset Quality. L’API Dataset Quality de Meta recherche les événements dont le « paramètre de valeur ou de devise est absent ou non valide », les adresses IP client qui « ne correspondent pas à celles du Meta Pixel » et les événements qui « partagent le même e-mail fictif plutôt qu’un vrai » (Dataset Quality API, Meta for Developers). Ce sont des contrôles de format ; nous n’avons trouvé aucune page de Meta décrivant un contrôle de bots, de spam ou de fraude : un faux bien formé les passe donc tous.
- Test Events (événements de test). Le chemin indiqué par Meta est Gestionnaire d’événements, puis Data Sources, puis votre pixel, puis Test Events, et les événements serveur envoyés avec un paramètre test_event_code y apparaissent (Using the Conversions API).
- Event Match Quality (EMQ, qualité de correspondance des événements). L’EMQ indique dans quelle mesure les informations client d’un événement peuvent correspondre à un compte Meta (Conversions API best practices), pas si l’événement est frauduleux. Meta indique qu’elle « est notée de 1 à 10 » et recommande de « viser un score de qualité de correspondance des événements de 6,0 ou plus » (Verifying Your Setup).
Notre lecture, pas celle de Meta : si l’EMQ des événements Lead baisse alors que le volume de leads grimpe, vérifiez les leads, car des coordonnées inventées ne peuvent pas correspondre à de vrais comptes. Un formulaire qui a cessé de transmettre un champ fait aussi baisser l’EMQ.
Faux événement ou bug de suivi ?
La plupart des schémas ont une explication innocente et une explication hostile, et un seul contrôle suffit généralement pour trancher.
| Schéma | Généralement un bug quand | N’a jamais eu lieu ou vraie fraude quand | Contrôle qui tranche |
|---|---|---|---|
| Purchase sans identifiant de commande | Votre configuration ne transmet jamais d’identifiant de commande | N’a jamais eu lieu : les vrais Purchase en portent un | Rapprocher l’horodatage de chaque événement d’une commande |
| Purchase déclenché sur l’URL d’une page produit | Il se déclenche à chaque rechargement de la page | N’a jamais eu lieu : il ne se reproduit pas et aucune commande ne correspond | Recharger la page avec le panneau réseau ouvert |
| Valeur ronde ou nulle | Une règle envoie une valeur fixe ou vide | N’a jamais eu lieu : la valeur ne correspond à aucun produit | Comparer les valeurs à vos prix et à vos commandes |
| Événements navigateur uniquement, sans jumeau serveur | Votre serveur n’envoie qu’une partie des événements | N’a jamais eu lieu : votre serveur envoie chaque vrai Purchase | Comparer les méthodes de connexion dans Overview |
| Événements d’un domaine qui n’est pas le vôtre | Le domaine est un aperçu de boutique ou une session de test | N’a jamais eu lieu : le domaine n’a aucun lien avec votre entreprise | Passer en revue les domaines dans les paramètres de votre pixel |
| Nombreux Lead identiques d’un même visiteur en quelques secondes | Le formulaire s’envoie deux fois | Vraie fraude : un bot a envoyé le formulaire, des enregistrements CRM existent | Rapprocher les leads des enregistrements CRM et des horodatages |
| Pic d’AddToCart, InitiateCheckout stable | Une règle déclenche AddToCart à l’affichage de la page | N’a jamais eu lieu : des visites automatisées cliquent sur ajouter au panier | Regrouper le pic par source, page et heure |
| Nombres exactement doublés | Deux installations se déclenchent ou les clés de déduplication diffèrent | Rarement l’un ou l’autre : un doublement indique la configuration | Lire l’onglet Event Deduplication |
| Pic sur une boutique ou une campagne toute neuve | La configuration est encore en phase de test | N’a jamais eu lieu : des visites automatisées sondent le nouveau site | Comparer aux commandes et aux dates de test |
| L’EMQ baisse alors que le volume augmente | Un formulaire a cessé de transmettre un champ | Vraie fraude : les nouveaux leads portent des coordonnées inventées | Examiner les nouveaux leads dans votre CRM |
| Événements portant un test_event_code en production | Le code n’a jamais été retiré | Rarement l’un ou l’autre : un code oublié est une erreur de configuration | Chercher test_event_code dans votre charge utile serveur |
Des annonceurs ont signalé plusieurs de ces schémas dans des fils de communautés de plateformes de boutique :
- Purchase à valeur fixe. Un fil ouvert le 17 oct. 2021, intitulé d’après de faux achats à 99 dollars, décrit des événements Purchase uniquement navigateur déclenchés depuis la page produit. Une réponse ultérieure indiquait que le support de Meta voyait que les événements avaient été configurés via une intégration partenaire.
- Boutiques neuves. Un commerçant a vu de faux événements d’ajout au panier, de paiement et d’achat deux jours après l’ouverture de sa boutique (ouvert le 25 nov. 2020), et un autre a constaté la même chose sur deux boutiques de moins de 15 jours (ouvert le 19 oct. 2022).
- Domaines inconnus. Un commerçant en a trouvé environ 40 dans les autorisations de trafic, dont des sous-domaines d’aperçu de boutique, et une réponse suggérait que des sessions de test pouvaient en expliquer certains (ouvert le 10 avr. 2024).
Ce que la déduplication supprime, et ce qu’elle ne peut pas supprimer
La déduplication supprime les copies d’un même vrai événement ; elle ne fait rien contre un faux événement navigateur qui n’a pas de copie serveur. Meta fait correspondre les événements « selon leur identifiant et leur nom », c’est-à-dire l'event_id et le nom de l’événement, et ne les dédoublonne que « s’ils sont reçus dans les 48 heures » du premier événement portant cet identifiant (Deduplicate pixel and server events, Meta for Developers).
Les limites comptent davantage. Meta indique qu’elle « ne dédoublonne pas les événements lorsqu’une seule source est utilisée, c’est-à-dire navigateur seul ou serveur seul », et que deux événements navigateur consécutifs aux informations identiques sont tous deux conservés. Meta précise aussi que la méthode fbp ou external_id ne fonctionne « en général » que pour les événements « envoyés d’abord depuis le navigateur, puis par le serveur » (même page). Un script qui déclenche Purchase dans le navigateur est donc compté à chaque fois. Pour mettre en place l’identifiant d’événement, voyez comment configurer la déduplication et les conversions filtrées contre la fraude.
Comment remonter la piste d’un Purchase suspect
Choisissez un Purchase que vous ne pouvez rapprocher d’aucune commande et suivez-le jusqu’à une page, une règle ou un script. Cet exemple est illustratif, ce n’est pas un vrai compte.
- Trouvez l’écart dans Overview. Réglez la période sur le jour de l’écart et lisez la méthode de connexion (Connection Method) de Purchase.
- Relevez la valeur et la devise. Les journaux de votre API Conversions les contiennent pour les événements serveur. Un Purchase uniquement navigateur dont la valeur ne correspond à aucun produit est la piste.
- Rapprochez l’horodatage d’une commande. Aucune commande payée à quelques minutes près signifie que l’événement n’a aucun client derrière lui.
- Ouvrez le panneau réseau des outils de développement de votre navigateur et rechargez la page produit. Observez quelles requêtes du pixel se déclenchent, avec quels paramètres.
- Confirmez avec Meta Ads Data Advisor. Meta indique que l’extension, anciennement Meta Pixel Helper, affiche « le nombre d’événements Pixel déclenchés sur la page web actuelle » ainsi que leurs paramètres (Meta for Developers).
- Reproduisez-le dans Test Events. Utilisez un jeu de données de test, et ne laissez jamais le test_event_code dans votre charge utile de production. Meta prévient que les événements envoyés avec lui « ne sont pas écartés » et « alimentent le Gestionnaire d’événements et servent au ciblage et à la mesure publicitaire » (Using the Conversions API).
- Vérifiez les domaines qui envoient des événements dans les autorisations de trafic de votre pixel. La page d’aide de Meta sur ce réglage ne s’est pas chargée pour nous le 12 novembre 2026.
Un Purchase qui se déclenche quand vous rechargez la page se déclenche pour chaque visiteur. Si une règle, le code du thème ou une intégration l’explique, vous avez un bug ; si rien ne l’explique, cherchez un script injecté. S’il ne se reproduit pas et qu’aucune commande ne correspond, vérifiez son domaine et sa méthode de connexion : un appel déclenché à la main ou le script d’un autre domaine n’apparaît jamais dans votre panneau réseau.
Comment arrêter les faux événements dans Meta
Pour arrêter les faux événements Meta Pixel, limitez les domaines qui envoient des événements, corrigez les clés de déduplication, retirez le test_event_code, puis envoyez Purchase depuis votre serveur avec les données des commandes payées.
- Passez en revue les autorisations de trafic. Écartez les aperçus et les sessions de test, puis n’autorisez que vos propres domaines si vos écrans actuels le permettent. Une liste d’autorisation n’arrête pas un script placé sur un domaine qui vous appartient.
- Corrigez les clés de déduplication. Transmettez le même identifiant d’événement et le même nom d’événement depuis le navigateur et le serveur pour chaque vrai événement.
- Envoyez les événements de conversion depuis le serveur avec un identifiant d’événement partagé. Votre serveur sait quelles commandes ont été payées. Cela ne supprime pas les faux événements navigateur, qui sont toujours comptés, mais vous obtenez un nombre de Purchase confirmés par le serveur auquel les comparer.
- Retirez le test_event_code. Cherchez-le dans les charges utiles serveur avant chaque mise en production.
- Rapprochez chaque semaine. Comparez les événements Purchase et Lead aux commandes payées et aux enregistrements CRM, votre référence de vérité.
Le Black Friday tombant le 27 novembre, exportez dès maintenant les nombres quotidiens de Purchase, Lead et AddToCart par méthode de connexion, afin de juger les pics du jour des soldes par rapport à une base de référence, comme l’expose notre liste de contrôle des fêtes pour Google Ads et Meta.
Pour les leads qui sont de vraies personnes sans intention, voyez comment distinguer les leads à faible intention des bots. Si l’écart commence plus tôt, au clic, lisez clics sur un lien et vues de la page de destination.
Ce que ClickFortify fait, et ce qu’il ne peut pas arrêter
ClickFortify signale les conversions suspectes après un clic sur une publicité Meta et peut filtrer les événements serveur envoyés via son proxy CAPI ; il ne supprime pas les événements que le Meta Pixel déclenche dans le navigateur.
ClickFortify reconnaît les clics sur les publicités Meta grâce à leur fbclid et attribue un score à chaque visite à partir de plus de 100 points de données d’appareil, de réseau et de comportement sur le parcours de la page de destination. Il signale trois schémas de conversion suspecte sur l’enregistrement du clic : une conversion dans les 2 secondes suivant le clic, une conversion venant d’un visiteur déjà classé comme bot, et un appareil avec 3 conversions ou plus. Quand le proxy CAPI est activé, les conversions envoyées via ClickFortify sont vérifiées au regard du score de fraude du visiteur, et les événements signalés sont supprimés ou étiquetés avant que Meta ne les reçoive. Ce filtre ne couvre que les événements serveur envoyés via le proxy. Les événements que le Meta Pixel déclenche dans le navigateur parviennent quand même à Meta, et ClickFortify ne peut pas arrêter un script ou un bot qui déclenche le pixel à la main.
ClickFortify ne vérifie pas l’adresse e-mail ni le numéro de téléphone d’un lead : associez-le donc à des contrôles dans votre CRM. Les leads de formulaires instantanés ne sont pas des événements du pixel et ClickFortify ne peut pas les voir ; pour eux, consultez notre guide des faux leads des Lead Ads Facebook. Il ne bloque pas les adresses IP et ne crée pas d’exclusions d’audiences sur Meta. Consultez ClickFortify pour Meta Ads pour la configuration.
Vous diffusez aussi Google Ads ? Le côté actions de conversion est traité dans notre guide des fausses conversions dans Google Ads.
Notre verdict : rapprochez les événements des commandes et corrigez d’abord les bugs, car c’est la cause la plus facile à écarter. Ajoutez des contrôles de conversion lorsque l’écart suit des clics payants et survit au nettoyage. Pour le reste du cluster, parcourez tous les guides sur la fraude Meta Ads.
