L'API Conversions de Meta : pixel, événements serveur et dédoublonnage

Pixel et API Conversions : deux chemins vers le même endroit

Le pixel Meta est un morceau de code posé sur votre site, qui s'exécute dans le navigateur du visiteur et signale ce qu'il fait : voir un produit, l'ajouter au panier, acheter. L'API Conversions fait le même travail, mais depuis chez vous. La documentation développeurs de Meta la décrit comme une connexion entre les données marketing de l'annonceur, issues d'un serveur, d'une plateforme de site, d'une application ou d'un CRM, et les systèmes de Meta.

Selon Meta, les événements serveur peuvent servir à la mesure, aux rapports et à l'optimisation comme les autres canaux. La différence tient à l'origine de l'événement : le navigateur peut en perdre, par exemple à cause d'un problème de connexion, alors que votre serveur sait avec certitude qu'une commande a été payée.

Pourquoi Meta conseille les deux ensemble

La page des bonnes pratiques de Meta est sans détour : utilisez l'API Conversions en plus du pixel Meta et partagez les mêmes événements avec les deux outils. La raison avancée : récupérer les événements que le pixel pourrait manquer. Ce montage en double ne marche que si Meta reconnaît qu'un achat vu par le navigateur et un achat envoyé par le serveur sont le même achat : c'est le rôle du dédoublonnage.

Le dédoublonnage : la règle qui évite de compter deux fois

Meta décide que deux événements sont identiques d'après leur identifiant et leur nom. L'eventID du pixel doit être égal à l'event_id de l'API, et le nom de l'événement du pixel à l'event_name de l'API. Les points clés de la documentation de Meta :

• Les événements ne sont dédoublonnés que s'ils arrivent dans les 48 heures suivant la réception du premier événement portant cet event_id.
• Quand l'événement navigateur et l'événement serveur ne diffèrent pas vraiment, Meta garde en général celui reçu en premier.
• Une autre méthode compare event_name avec fbp et/ou external_id, mais elle fonctionne surtout quand l'événement navigateur arrive avant l'événement serveur. Meta recommande la méthode par event_id.

Un exemple d'achat, pas à pas

1. Le client paie. Votre site crée un identifiant unique pour cet événement de commande, par exemple le numéro de commande.
2. La page de confirmation déclenche l'événement Purchase du pixel avec cet identifiant en eventID, plus le montant et la devise.
3. Votre serveur, une fois le paiement confirmé, envoie un événement Purchase à l'API Conversions avec le même identifiant en event_id.
4. Meta reçoit les deux, voit le même nom et le même identifiant, et compte un seul achat. Si l'événement navigateur a été bloqué, celui du serveur arrive quand même.

Les informations client : quoi hacher, quoi laisser en clair

Pour rapprocher un événement serveur d'une personne sur Facebook ou Instagram, vous pouvez envoyer des paramètres d'information client. Meta conseille des champs de bonne qualité comme l'e-mail, l'adresse IP, le prénom et le nom, le téléphone, pour améliorer la qualité de correspondance des événements (Event Match Quality), notée de 0 à 10. Les règles de hachage de Meta sont précises :

Les erreurs de montage qui faussent vos chiffres

• Des identifiants différents de chaque côté : le pixel envoie une valeur en eventID, le serveur une autre en event_id. Meta voit alors deux achats.
• Des noms d'événement différents : Purchase côté pixel, purchase_completed côté serveur. Le dédoublonnage exige le même nom.
• Des événements serveur envoyés trop tard : le dédoublonnage ne joue que dans les 48 heures suivant le premier événement portant cet event_id ; un envoi groupé de nuit qui prend du retard peut créer des doublons.
• Hacher ce qui doit rester en clair : adresse IP, agent utilisateur, fbc et fbp ne se hachent jamais.
• Ne pas normaliser avant de hacher : un e-mail avec une majuscule ou une espace en trop donne un autre hachage.
• Le serveur seul, sans pixel : Meta recommande les deux, avec les mêmes événements de chaque côté.

Le consentement et la vie privée d'abord

Côté serveur ne veut pas dire sans consentement. Ce que vous envoyez à Meta, depuis le navigateur ou depuis votre serveur, doit respecter ce que le visiteur a accepté et les règles de protection des données qui s'appliquent à votre activité. N'envoyez que les champs utiles, hachez ce que Meta demande de hacher et documentez le montage. Pour les balises Google, la même question est traitée dans notre guide Consent Mode v2.

Notre montage chez Takat

Dans nos missions Meta Ads, nous installons le pixel Meta avec l'API Conversions et des événements d'achat envoyés côté serveur, pour mesurer les campagnes sur de vraies commandes payées. Le pixel, le jeu de données et le compte publicitaire restent au nom du client, et les campagnes sont créées en pause, lancées seulement avec son accord. Voir Meta Ads et Mesure et suivi.