Le pixel installé dans le navigateur ne voit plus qu’une partie de vos conversions. Bloqueurs de publicité, refus de consentement, restrictions des navigateurs sur les cookies tiers : la déperdition est structurelle et elle s’aggrave. L’API Conversions existe pour la compenser, à condition de la mettre en place correctement.
Les deux canaux
Le pixel navigateur s’exécute chez le visiteur. Il capte le contexte complet : identifiants publicitaires, cookies, comportement de navigation. Il est bloqué dès qu’un bloqueur, une extension ou un refus de consentement intervient.
L’API Conversions envoie l’événement depuis votre serveur vers la plateforme, sans passer par le navigateur. Elle n’est pas bloquée, mais elle ne dispose que de ce que vous lui transmettez, et elle est aveugle au parcours de navigation.
Les deux ne sont pas alternatifs. La configuration recommandée les fait fonctionner ensemble sur les mêmes événements, avec un mécanisme de déduplication.
La déduplication
C’est le point technique central, et celui que les implémentations ratent le plus souvent.
Si un achat est envoyé par le pixel et par l’API sans mécanisme de rapprochement, la plateforme compte deux conversions. Vos rapports affichent un doublement du volume, votre coût par acquisition apparaît divisé par deux, et vos décisions d’arbitrage publicitaire reposent sur des chiffres faux.
Le rapprochement repose sur deux valeurs, qui doivent être strictement identiques dans les deux envois : le nom de l’événement, et un identifiant unique généré pour cette occurrence.
Trois règles pratiques. L’identifiant doit être généré côté serveur puis transmis au pixel, pas l’inverse. Il doit être stable si la page est rechargée, ce qui exclut un tirage aléatoire à chaque affichage : la référence de commande est le meilleur candidat pour l’achat. Et il doit être unique par occurrence, pas par produit ni par session.
Facebook Dynamic Ads + Pixel PRO — Flux produits, Pixel & API Conversions (PrestaShop 8 & 9)Vendez vos produits sur Facebook & Instagram, et mesurez chaque conversion€89.00
Ce que l’API attend
Contrairement au pixel qui devine beaucoup, l’API ne connaît que ce que vous envoyez. Trois familles d’informations.
Les données de correspondance client. Email, téléphone, prénom, nom, ville, code postal, pays. Elles servent à rattacher la conversion à un utilisateur de la plateforme. Elles doivent être normalisées puis hachées avant envoi, jamais transmises en clair.
Les données d’événement. Nom, horodatage, valeur, devise, contenu de la commande avec les identifiants produits.
Les données de contexte. Adresse IP et agent utilisateur du visiteur, plus les identifiants de clic publicitaire s’ils sont présents dans l’URL d’arrivée. Ces deux derniers améliorent nettement la correspondance et sont souvent oubliés.
La qualité de correspondance
La plateforme calcule un score qui mesure sa capacité à rattacher vos événements à des utilisateurs. Ce score conditionne directement la performance de vos campagnes, et il est bien plus déterminant que le volume d’événements envoyés.
Trois leviers pour l’améliorer. Envoyer plus de paramètres de correspondance : chaque champ supplémentaire augmente la probabilité de rattachement. Normaliser correctement avant hachage : minuscules, suppression des espaces, format international pour les téléphones. Et transmettre les identifiants de clic, qui sont les signaux les plus fiables.
Un score faible ne se voit pas dans vos rapports de conversion, il se voit dans la performance de vos campagnes. C’est ce qui le rend difficile à diagnostiquer.
Le consentement
Point à traiter sérieusement, parce que l’envoi serveur ne dispense de rien.
Le fait que l’événement parte de votre serveur plutôt que du navigateur ne change pas sa nature juridique. Si le visiteur a refusé les traceurs publicitaires, vous ne devez pas transmettre ses données à une plateforme publicitaire, quel que soit le canal technique.
L’API Conversions compense la perte due aux bloqueurs et aux limitations techniques des navigateurs, pas celle due au refus de consentement. Présenter l’inverse est une lecture erronée qui circule beaucoup.
Concrètement, votre implémentation serveur doit connaître l’état du consentement du visiteur et conditionner l’envoi.
Les événements à couvrir
Cinq suffisent pour piloter des campagnes e-commerce : consultation de contenu, ajout au panier, initiation du paiement, achat, et inscription si vous en avez l’usage.
L’achat est le seul qui doive impérativement passer par les deux canaux avec déduplication. Les autres peuvent se contenter du pixel dans un premier temps, la couverture serveur venant ensuite.
Un point de cohérence à surveiller : les identifiants produits envoyés dans les événements doivent correspondre exactement à ceux de votre flux produit. Une divergence empêche le fonctionnement des campagnes dynamiques, qui reposent sur ce rapprochement.
Vérifier
Trois contrôles, dans cet ordre.
L’outil de test de la plateforme, qui affiche les événements reçus en temps réel avec leur source. Passez une commande complète et vérifiez que l’achat apparaît une fois, avec la mention indiquant qu’une déduplication a eu lieu.
Le score de qualité de correspondance, à relever après quelques jours d’activité et à comparer aux repères de la plateforme.
Le rapprochement avec votre back-office, sur une semaine. Un écart de 10 à 20 % en moins reste normal. Un écart positif, la plateforme comptant plus d’achats que vous n’en avez enregistrés, signale un échec de déduplication.
Le module Facebook Dynamic Ads et Pixel PRO pour PrestaShop met en place cette double couverture sur PrestaShop 8 et 9 : pixel navigateur et API Conversions avec déduplication par identifiant d’événement, hachage des données de correspondance, prise en compte du consentement et génération du flux produits pour les campagnes dynamiques.
