Activer Conversions API — l’interface de Meta qui envoie les conversions depuis votre serveur — n’est pas la partie difficile. N’importe quel guide vous y mène en un après-midi : créer un dataset, générer un jeton, choisir une méthode d’intégration, envoyer un événement de test. Aucun ne couvre ce qui se passe la semaine suivante — les conversions qui se mettent à compter deux fois sans bruit, le serveur que personne dans votre entreprise ne sait pointer du doigt, et un score de qualité de correspondance qui n’a rien à voir avec la performance de vos publicités. Si vous gérez déjà des publicités Facebook et Instagram et qu’on vous a dit qu’il est temps d’ajouter un suivi côté serveur, voici la partie à lire avant le guide d’installation — pas après.
Ce que Facebook Conversions API envoie réellement
Conversions API ne remplace pas le Meta Pixel — c’est un second canal vers le même dataset. La documentation de Meta la décrit elle-même comme une connexion entre les données marketing d’un annonceur — provenant de son serveur, de sa plateforme web, de son application mobile ou de son CRM — et les systèmes de Meta qui optimisent le ciblage publicitaire, réduisent le coût par résultat et mesurent les résultats. Les événements serveur atterrissent dans le même dataset ID que les événements du pixel et sont traités comme des événements envoyés par le Meta Pixel. Le navigateur continue de déclencher le pixel. Le serveur déclenche maintenant le même événement une seconde fois, par un canal qu’un bloqueur de publicité ou un réglage du navigateur ne peut pas interrompre — une différence de livraison, pas de permission. La question de savoir si vous étiez autorisé à recueillir cette donnée au départ est distincte, et elle est traitée plus loin.
Cette seconde copie, c’est tout l’intérêt — et tout le risque. Vous pouvez la brancher en intégration directe, via le connecteur intégré de votre plateforme ecommerce, ou via Conversions API Gateway, le produit de Meta qui tourne dans un compte cloud que vous provisionnez vous-même. Aucun de ces choix ne pèse autant que ce qui se passe une fois que les deux copies du même événement se mettent à arriver chez Meta à l’intérieur de la même minute.
L’événement en double que personne n’attrape avant que les chiffres aient l’air trop bons
Envoyez le même achat depuis le pixel et depuis le serveur, sans rien pour les relier, et Meta le compte deux fois. La documentation de Meta est explicite sur la correction : le eventID du Meta Pixel doit correspondre au event_id de Conversions API, et l’événement du Meta Pixel doit correspondre au event_name de Conversions API. Faites correspondre les deux dans une fenêtre de 48 heures et Meta privilégie généralement l’événement arrivé en premier, en écartant le doublon plus tardif — le libellé laisse place à des exceptions lorsque les deux événements diffèrent de façon significative dans leur contenu. Manquez complètement la correspondance, et chaque achat, chaque prospect ou chaque ajout au panier déclenché par les deux canaux se rapporte en double.
Personne ne remarque ça en fixant Ads Manager. Ça se traduit par un taux de conversion qui s’améliore sans raison la semaine où les événements serveur entrent en service, ou par un coût par résultat qui chute exactement quand rien n’a changé dans la campagne. Le système de diffusion publicitaire de Meta optimise vers ce qu’on lui dit qui convertit, alors un événement doublé ne fausse pas juste le rapport — il apprend à l’algorithme à poursuivre le mauvais signal. Google Ads a le même mode de défaillance pour une cause différente, et c’est tout aussi invisible de l’intérieur du compte — nous avons expliqué comment les doublons de conversion s’infiltrent dans Google Ads pour la même raison : personne ne vérifie la plomberie avant que le rapport cesse d’avoir du sens.
Dans le nuage de qui tourne vraiment votre Conversions API Gateway
Le produit Gateway de Meta se provisionne dans un compte cloud que vous montez vous-même — AWS ou GCP. Meta documente où ça tourne ; à qui le nom sur ce compte devrait appartenir, c’est notre recommandation, pas celle de Meta, et c’est la même que pour le compte publicitaire : à vous. Ce détail passe assez souvent sous silence pour valoir la peine d’être précisé : si la personne qui a mis en place votre suivi côté serveur a monté une passerelle ou une intégration directe dans sa propre infrastructure plutôt que dans la vôtre, ce serveur est désormais une dépendance, au même titre qu’un compte publicitaire loué. Ça n’apparaît pas comme une ligne distincte sur une facture, et ça ne se révèle qu’à la fin de la relation, quand les événements cessent d’arriver sans le moindre message d’erreur nulle part. Ça appartient à la même liste que le compte publicitaire et le pixel — ce qui vous appartient vraiment quand une agence part passe en revue lesquels de ces actifs reviennent et lesquels ne reviennent pas.
Le consentement ne se déplace pas seulement parce que l’appel est passé côté serveur
L’erreur la plus courante sur Conversions API porte sur ce que ça change au consentement. Rien. Faire passer un événement de conversion d’un appel navigateur à un appel serveur change l’origine du paquet — ça ne change pas si le visiteur avait accepté d’être suivi au départ. L’affirmation voulant que « CAPI contourne les bloqueurs de publicité » revient constamment dans les résultats de recherche et les réponses de forums, et c’est le genre d’énoncé qui sonne comme un fait technique alors que c’est en réalité une question de conformité. Un événement côté serveur construit à partir de données que vous n’étiez pas autorisé à recueillir reste construit à partir de données que vous n’étiez pas autorisé à recueillir. Les bandeaux de consentement, les règles régionales et votre propre politique de confidentialité continuent de régir ce que vous avez le droit d’envoyer — CAPI ne change que le tuyau, pas la permission.
Event Match Quality mesure votre site web, pas votre configuration CAPI
Une fois que les événements serveur commencent à circuler, Meta évalue à quel point ils peuvent être rattachés à un vrai compte — Event Match Quality, un score sur 10 qui indique, selon la documentation de Meta, à quel point l’information client envoyée depuis votre serveur est susceptible de faire correspondre les événements à un compte Meta. Il se calcule à partir des paramètres que vous envoyez, de leur propreté, et de la proportion d’événements qui correspondent réellement. Ça sonne comme une mesure de qualité du trafic. Ce n’en est pas une. C’est une mesure de votre site web, et la documentation de Meta précise elle-même qu’elle n’est actuellement offerte que pour les événements web. Une boutique avec un excellent trafic et un passage en caisse qui ne recueille jamais de courriel affichera quand même un score bas, parce qu’il n’y a rien à hacher ni à faire correspondre.
Le piège caché là-dedans, c’est le formatage. Chaque champ de contact doit être préparé d’une façon précise avant de quitter votre serveur — nettoyé des espaces, mis en minuscules, muni d’un indicatif de pays là où il en faut un, puis haché en SHA-256, parce que les systèmes de Meta sont conçus pour rejeter d’emblée toute information de contact non hachée. Une erreur sur un seul champ, et le symptôme est silencieux : un numéro de téléphone envoyé sans son indicatif de pays produit un hachage qui ne correspond à rien, et l’événement continue de se rapporter comme livré. Rien ne signale d’erreur. Le score reste simplement plus bas qu’il ne devrait, et personne ne peut dire pourquoi.
Où ça se corrige, en réalité
Chaque problème ci-dessus se retrace au même endroit : le code de votre site web, pas les réglages de votre compte publicitaire. C’est aussi là que se fait toute vérification — l’extension de navigateur qu’on utilisait pour ça a été renommée plutôt que retirée, ce qui est un petit piège à part entière, et qui mérite cette réponse séparée plutôt qu’un paragraphe ici.
C’est aussi pourquoi on traite ça comme un seul travail plutôt que deux. Nous configurons Conversions API nous-mêmes pour nos clients, et quand nous avons aussi construit le site vers lequel pointent les publicités, le code côté serveur est posé par les mêmes personnes qui ont écrit le passage en caisse, le formulaire de prospect et la page de confirmation — pas remis à un développeur qui ne l’a jamais vu. Notre propre module de suivi des demandes siège sur ce même site et surveille les mêmes formulaires, ce qui fait toute la différence entre lire un score de qualité de correspondance et pouvoir regarder ce que le formulaire a réellement envoyé. C’est un seul bloc de travail plutôt qu’un transfert entre fournisseurs.
Si vous hésitez à activer Conversions API, la première question honnête n’est pas quelle méthode d’intégration choisir. C’est de savoir si votre site recueille actuellement assez de données client propres pour que ça vaille la peine d’envoyer des événements serveur — et sur le serveur de qui ces données vont atterrir.
Demandez ce que l’API de conversions exigerait sur votre site
