Meta Conversions API pour PrestaShop : en avez-vous besoin ?

Si vous faites de la publicité sur Meta et gérez une boutique PrestaShop, on vous a probablement dit d'« ajouter la Conversions API » sans explication claire de ce qu'elle fait ni de votre réel besoin. La réponse honnête est : la plupart des boutiques qui font du social payant en ont besoin aujourd'hui, mais pas parce que c'est à la mode. Elle existe pour récupérer les conversions que le pixel basé sur le navigateur ne peut plus voir.

Ce guide explique ce qu'est Meta CAPI, qui en profite réellement, comment le pixel et la Conversions API fonctionnent ensemble plutôt qu'en concurrence, et les détails techniques — déduplication, jetons côté serveur et correspondance d'identité — qui séparent une configuration utile d'une autre qui compte discrètement vos ventes en double.

Ce qu'est vraiment la Conversions API

Le pixel Meta est un morceau de JavaScript qui s'exécute dans le navigateur de l'acheteur et remonte des actions comme purchase et l'ajout au panier à Meta. Il a été l'épine dorsale de la publicité Facebook et Instagram pendant des années. Le problème est qu'il vit entièrement dans le navigateur, précisément là où les bloqueurs de publicités, les extensions de confidentialité et l'App Tracking Transparency d'Apple l'interceptent désormais.

La Conversions API (CAPI) est la contrepartie côté serveur. Au lieu de s'appuyer sur le navigateur, votre serveur envoie les mêmes événements de conversion directement à Meta via une connexion serveur à serveur. Comme rien dans le navigateur du client ne peut annuler cette requête, les événements que le pixel aurait perdus arrivent tout de même.

Voyez la CAPI non pas comme un remplacement du pixel mais comme un second chemin de livraison plus fiable pour la même information. Les meilleurs résultats viennent de l'utilisation des deux, ce que nous expliquons en détail sous côté serveur vs côté client.

Qui en a réellement besoin

Toutes les boutiques n'ont pas à se précipiter. Si vous ne dépensez rien en publicités Meta, la CAPI ne vous apporte pas grand-chose — il n'y a pas d'optimisation de campagne à améliorer ni d'attribution à récupérer. Votre effort est mieux dépensé ailleurs.

Mais si vous faites de la publicité Meta significative, le calcul s'inverse vite. Plus votre audience penche vers iOS, Safari et les utilisateurs soucieux de leur vie privée, plus le pixel sous-déclare — perdant souvent 30 à 50 % des conversions. Chaque événement purchase perdu est une vente dont l'algorithme de Meta n'apprend jamais, ce qui signifie une moins bonne constitution d'audience, une optimisation plus faible et un retour sur dépense publicitaire qui paraît artificiellement médiocre.

Les boutiques avec un budget publicitaire conséquent, une clientèle très mobile ou des campagnes dépendant de valeurs de conversion précises (comme les enchères basées sur la valeur) tirent le bénéfice le plus net de la CAPI. Si cela vous décrit, elle a cessé d'être optionnelle.

Pixel et CAPI ensemble, pas l'un à la place de l'autre

Une idée fausse courante est que la CAPI remplace le pixel. Ce n'est pas le cas, et cela ne devrait pas l'être. Le pixel capte toujours un riche contexte côté navigateur — les cookies _fbc et _fbp, les paramètres du navigateur et le comportement sur la page — qui améliore la correspondance. La CAPI apporte la fiabilité et des données côté serveur que le navigateur n'a jamais eues.

Faites tourner les deux et vous obtenez le meilleur de chacun : la richesse comportementale du pixel plus la résistance de la Conversions API au blocage et à l'ITP. Meta indique explicitement que la configuration recommandée est redondante, avec le même événement envoyé à la fois depuis le navigateur et le serveur.

Le mot « redondant » est le piège. Si vous envoyez naïvement le même achat depuis le pixel et la CAPI, Meta pourrait le compter deux fois. C'est là que la déduplication devient essentielle, et bien la réussir est la partie la plus importante d'une configuration hybride.

Déduplication via un event_id partagé

La déduplication est la façon dont Meta reconnaît qu'un événement navigateur et un événement serveur décrivent la même vente, pour la compter une seule fois. Le mécanisme est un event_id partagé : quand le pixel et la CAPI se déclenchent tous deux pour un achat, ils envoient le event_id identique, et Meta fusionne la paire en une seule conversion.

Le piège est d'utiliser un identifiant aléatoire. Si le pixel génère un event_id aléatoire et le serveur un autre, Meta voit deux ID différents et compte deux achats. La solution est une identité déterministe : dérivez le event_id de la référence de commande PrestaShop, afin que les deux chemins calculent indépendamment la même valeur, et qu'une page de confirmation rechargée ne puisse gonfler vos chiffres.

C'est exactement ainsi que PrestaSignal le gère — un seul event_id déterministe par commande, réutilisé sur le pixel, la CAPI et même votre tracking GA4, afin que rien ne soit compté en double nulle part. Voyez notre glossaire pour les termes associés.

Le jeton reste sur le serveur

La CAPI s'authentifie avec un jeton d'accès Conversions API. Ce jeton est puissant — il peut envoyer des données de conversion à votre compte Meta — il ne doit donc jamais apparaître dans le navigateur, dans le code source de la page ou dans un script côté client. S'il fuit, n'importe qui peut polluer vos données de conversion.

C'est l'un des arguments les plus forts en faveur d'une vraie configuration côté serveur plutôt que d'un raccourci basé sur le navigateur. PrestaSignal garde le jeton CAPI à l'intérieur du conteneur sGTM auto-hébergé, côté serveur uniquement, là où le navigateur ne le voit jamais. La balise Meta dans le conteneur détient le jeton ; l'appareil du client jamais.

Garder le jeton côté serveur n'est pas qu'une bonne hygiène de sécurité — c'est la seule façon correcte d'exploiter la CAPI. Toute approche qui l'expose dans le navigateur a mal compris à quoi sert la Conversions API.

external_id et une meilleure correspondance

Une livraison fiable n'est que la moitié de la valeur de la CAPI. L'autre moitié est la correspondance — la capacité de Meta à relier une conversion à une personne qui a vu votre publicité. Plus vous envoyez d'identifiants de qualité, plus votre qualité de correspondance d'événements est élevée, et mieux Meta peut attribuer et optimiser.

Côté serveur, vous pouvez envoyer des données client hachées — e-mail, téléphone, nom — et un external_id, qui est typiquement un hachage SHA-256 de l'ID client. L'external_id donne à Meta un ancrage stable et inter-appareils : le même client sur son téléphone et son ordinateur portable se résout en une seule identité, améliorant à la fois l'attribution et la constitution d'audience.

Toutes ces données personnelles sont normalisées et hachées avec SHA-256 avant de quitter votre boutique, donc Meta reçoit des empreintes irréversibles plutôt que des détails lisibles. Pour voir combien Meta sous-déclare actuellement sur votre compte, réservez un audit et nous le mesurerons face à vos vraies commandes PrestaShop.