Pixel Facebook et API Conversions pour votre boutique en 2026 : quelle publicité a apporté la commande en paiement à la livraison ?

Quelle est la différence entre le pixel Facebook et l'API Conversions dans une boutique ?

Le pixel Facebook (Meta Pixel) est un code qui s'exécute dans le navigateur du visiteur et indique à Meta ce qu'il fait dans votre boutique. L'API Conversions envoie les mêmes événements directement depuis le serveur de la boutique : aucun bloqueur de publicités ni aucune restriction du navigateur ne l'arrête. Faire fonctionner les deux est le mieux : le pixel capte le détail de la navigation, le serveur garantit l'arrivée de l'achat.

Où s'exécute chacun

PixelDans le navigateur du visiteur

API ConversionsSur le serveur de la boutique

Bloqueur de publicitésBloque seulement le pixel

Un achat confirmé des heures plus tardSeul le serveur le remonte

À faire fonctionner ensemble avec un identifiant d'événement partagé

Quand un visiteur ouvre une page produit, son navigateur charge le code du pixel, qui envoie à Meta un événement comme « a consulté un produit » avec le cookie de Meta et l'identifiant de clic si le visiteur vient d'une publicité. Cette voie est simple et précise sur la navigation, mais elle dépend du navigateur lui-même : un bloqueur de publicités arrête le code, certains navigateurs raccourcissent la durée des cookies, iOS demande aux utilisateurs l'autorisation d'être suivis dans les applications, et celui qui ferme la page avant son chargement n'enregistre rien.

L'API Conversions comble cette lacune : quand la commande est écrite dans la base de données de la boutique, le serveur envoie directement l'événement d'achat à Meta, avec des données de correspondance hachées comme le numéro de téléphone, pour que Meta puisse le relier au compte qui a vu la publicité. Le serveur n'a pas besoin que le visiteur reste sur la page, ce qui en fait le seul moyen de remonter un achat confirmé plus tard.

La question n'est donc pas « lequel ? » mais « comment faire fonctionner les deux sans que l'achat soit compté deux fois ? » — c'est le rôle de l'identifiant d'événement.

Comment event_id empêche-t-il un achat d'être compté deux fois entre le pixel et l'API Conversions ?

Quand le navigateur et le serveur envoient tous deux le même achat, les deux événements portent le même nom (Purchase) et le même identifiant (event_id) : Meta les compte donc comme un seul achat. Meta indique que la fusion a lieu quand le second événement arrive dans les 48 heures suivant le premier événement portant cet identifiant, au sein du même pixel.

Voyez event_id comme le numéro de commande écrit sur deux exemplaires d'une facture : quel que soit l'exemplaire qui arrive en premier, le comptable sait qu'il s'agit d'une seule facture. C'est pourquoi l'identifiant se construit généralement à partir du numéro de commande lui-même, pas d'un nombre aléatoire qui diffère entre le navigateur et le serveur. Trois conditions doivent être réunies :

• Le nom correspond exactement : Purchase des deux côtés, pas Purchase d'un côté et un nom personnalisé de l'autre.
• L'identifiant correspond et est envoyé par les deux : le pixel l'envoie sous la forme eventID, le serveur sous la forme event_id.
• Un seul pixel : un événement envoyé à deux pixels différents n'est pas fusionné ; chaque pixel compte ce qui lui est parvenu.

TikTok applique la même règle entre son pixel et l'API Events : le même type d'événement et le même event_id, dans les 48 heures suivant le premier événement.

De quels événements du pixel Facebook une boutique en ligne a-t-elle besoin ?

Quatre événements standard décrivent le chemin vers l'achat : ViewContent quand un visiteur consulte un produit, AddToCart quand il l'ajoute au panier, InitiateCheckout quand il commence le paiement, et Purchase quand il achète. La publicité apprend de chaque étape, mais c'est Purchase sur lequel reposent les campagnes de ventes et le calcul du retour.

Chaque événement porte des données avec son nom : l'identifiant du produit (content_ids), la valeur et la devise. Deux conditions sont souvent oubliées : la devise doit être la vraie devise de la boutique, livres ou riyals plutôt que dollars, et l'identifiant du produit dans l'événement doit correspondre à son identifiant dans le fichier produits (catalogue) que vous avez téléversé chez Meta ; s'ils diffèrent, les publicités catalogue ne peuvent pas savoir quel produit le visiteur a vu.

Quand informer la publicité d'un achat en paiement à la livraison : à la commande ou à la confirmation ?

Avec le paiement à la livraison, appuyer sur « Commander » n'est pas encore une vente : la commande peut être un doublon, une fausse, ou refusée à la porte. Si la publicité est informée d'un achat au moment de la commande, elle apprend à trouver des gens qui commandent, pas des gens qui acceptent la livraison. La remontée à la confirmation lui apprend à partir de vrais acheteurs.

Votre boutique

Votre commande n°1043 est prête à être expédiée. Vous la confirmez ?

Oui, je confirme

C'est seulement maintenant que le serveur envoie Purchase à Meta

Remontée à la commande

• Signal instantané, plus d'événements
• Compte les commandes annulées et fausses

Remontée à la confirmation

• Ne compte que ce que l'acheteur a confirmé
• Le signal attend la confirmation

Chaque option a quelque chose qu'elle fait bien : le choix dépend donc de la façon dont votre boutique est payée :

Le délai ne fait pas perdre l'événement : Meta accepte un événement serveur dont l'heure remonte jusqu'à sept jours avant son envoi, si bien qu'une commande confirmée une heure ou un jour plus tard arrive à temps. La confirmation elle-même vient de la réponse du client à un message WhatsApp, d'un appel, ou d'un bouton dans le panneau de la boutique — l'essentiel est qu'elle ait lieu avant l'expédition. Pourquoi la confirmation vaut l'effort en elle-même, et pas seulement pour la publicité, se trouve dans le guide pour réduire les retours en paiement à la livraison.

Comment savoir quelle publicité a apporté la commande, avec les liens UTM et l'identifiant de clic fbclid ?

Le Gestionnaire de publicités ne voit que ce que Meta attribue à ses propres publicités, avec ses propres fenêtres d'attribution. Pour connaître la source de chaque commande depuis votre boutique, ajoutez au lien de la publicité des paramètres UTM qui nomment la campagne et la publicité, et gardez avec chaque commande ces paramètres plus l'identifiant de clic fbclid que Meta ajoute automatiquement au lien.

1. Ouvrez la publicité dans le Gestionnaire de publicités

   Au niveau de la publicité, dans la section de suivi, il y a un champ de paramètres d'URL. Les paramètres se règlent par publicité, et plusieurs publicités peuvent être modifiées ensemble.

2. Collez les paramètres dynamiques

   utm_source=facebook&utm_medium=paid&utm_campaign={{campaign.name}}&utm_term={{adset.name}}&utm_content={{ad.name}}

   Les doubles accolades sont remplacées à la diffusion par les noms de la campagne, de l'ensemble de publicités et de la publicité : vous ne tapez donc pas les noms à la main dans chaque publicité.

3. Nommez les campagnes de façon à les comprendre dans un mois

   Le produit, l'offre et l'audience en un seul nom court, pour que le rapport des sources se lise sans retourner dans le Gestionnaire de publicités.

4. Revoyez chaque semaine le rapport des sources

   Comparez les commandes confirmées de chaque publicité à ce que vous y avez dépensé — pas les clics, ni les commandes avant confirmation.

Première visite ou dernière visite ?

Un client peut voir votre publicité aujourd'hui et revenir des jours plus tard depuis une recherche Google pour commander. La dernière source dit « Google » ; la première source dit « la publicité ». Les deux ont raison car elles répondent à des questions différentes : la première dit qui vous a fait connaître au client, la dernière dit ce qui l'a fait revenir acheter. C'est pourquoi une bonne boutique garde les deux avec chaque commande, et pas l'une d'elles.

Si votre publicité ouvre une conversation WhatsApp au lieu de la boutique, la source de la commande est la conversation, mesurée d'une autre façon que nous expliquons dans le guide du suivi des publicités qui ouvrent WhatsApp.

Et le pixel TikTok, Snapchat et GA4 à côté du pixel Facebook ?

La logique est la même sur chaque plateforme : un événement depuis le navigateur, une copie depuis le serveur là où c'est disponible, et un identifiant partagé qui empêche les doublons. TikTok rejoint Meta avec un pixel et l'API Events ; Google mesure avec GA4 et la balise de conversion Google Ads. Connectez les plateformes sur lesquelles vous dépensez réellement, pas toutes celles qui existent ; chaque pixel supplémentaire est un poids sur la page et un endroit de plus pour les erreurs.

• TikTok : un pixel dans le navigateur et l'API Events depuis le serveur, fusionnés par type d'événement et event_id comme ci-dessus.
• Snapchat : sur ArabyBot Store, il fonctionne avec le pixel du navigateur seulement : ses événements sont donc plus exposés aux bloqueurs de publicités que ceux de Meta et de TikTok.
• GA4 : il ne vous construit aucune audience publicitaire, mais il voit toutes les sources plutôt que celles d'une seule plateforme. Si vous lui envoyez l'achat, envoyez le numéro de commande comme transaction_id pour qu'une page de remerciement rechargée ne soit pas comptée deux fois.
• Google Tag Manager : utile pour les balises personnalisées, mais la source de doublons la plus courante : ajoutez le pixel dans le champ de la boutique et à nouveau dans GTM, et chaque événement part deux fois.

Comment tester les événements du pixel et de l'API Conversions avant de lancer des publicités ?

Ouvrez le Gestionnaire d'événements de Meta, choisissez le pixel, puis l'outil Événements de test, saisissez le lien de votre boutique et naviguez comme un acheteur : ouvrez un produit, ajoutez-le au panier, commencez le paiement, puis passez une commande test. Vous devez voir chaque événement arriver avec sa valeur et sa devise, et l'achat apparaître une seule fois.

Événements de test

ViewContentArrivé avec la valeur et la devise

AddToCartArrivé

InitiateCheckoutArrivé

PurchaseExactement une fois

Qualité de correspondance de 6 ou plus

Retirez test_event_code quand vous avez fini les tests

1. Ouvrez l'outil Événements de test

   Dans le Gestionnaire d'événements, choisissez la source de données (le pixel), puis l'onglet Événements de test, et ouvrez votre boutique depuis le navigateur indiqué par l'outil.

2. Parcourez le chemin vers l'achat

   Une page produit, puis le panier, puis le paiement. Vérifiez que ViewContent, AddToCart et InitiateCheckout sont arrivés, avec la bonne valeur et la bonne devise.

3. Passez une commande test avec votre propre numéro

   Si votre boutique envoie la confirmation de commande sur WhatsApp, le message part réellement vers le numéro de la commande ; ne tapez pas un numéro inventé, il peut appartenir à une vraie personne. Annulez la commande après le test.

4. Vérifiez le serveur et la fusion

   Meta indique que les événements serveur apparaissent dans le Gestionnaire d'événements environ 20 minutes après leur envoi. Ouvrez ensuite « Détails de l'événement » pour l'événement d'achat depuis la page Vue d'ensemble, puis l'onglet Déduplication des événements, qui montre la part d'événements fusionnés, et vérifiez le score de qualité de correspondance des événements, que Meta recommande de maintenir à 6 ou plus.

5. En mode remontée à la confirmation

   Confirmez la commande test depuis le panneau, puis attendez que l'achat arrive depuis le serveur. Rappelez-vous que les événements envoyés avec un code de test (test_event_code) ne sont pas écartés par Meta mais entrent dans la mesure et le ciblage : retirez donc le code de test une fois le test terminé.

Les erreurs courantes qui ruinent la mesure du pixel

• Le pixel installé deux fois : dans le champ de la boutique et dans GTM, ou des restes d'une ancienne extension. Chaque événement arrive en double, et la fusion ne peut pas vous sauver car les deux identifiants diffèrent.
• Un identifiant d'événement différent dans le navigateur et le serveur : un achat est compté comme deux, et le retour affiché dans le Gestionnaire de publicités double.
• Remonter les commandes refusées comme des achats : avec le paiement à la livraison, la publicité apprend alors à partir de la commande, pas de l'acceptation de la livraison.
• Sauter la vérification du domaine : la vérification auprès de Meta prouve que le domaine appartient à votre compte professionnel et vous donne le contrôle des aperçus de vos liens. Vous vérifiez un domaine qui vous appartient : faites-le donc quand vous transférez votre boutique sur votre propre domaine, et de nouveau si vous passez à un nouveau.
• La mauvaise devise ou valeur : une valeur nulle, ou des dollars dans une boutique qui vend en livres, et le retour calculé ne veut plus rien dire.
• Des liens de publicités sans UTM : les commandes apparaissent alors dans le rapport des sources comme des visites directes ou inconnues.
• Changer de pixel pendant une campagne en cours : cela coupe l'historique d'événements dont apprend la publicité.

Comment fonctionnent la connexion du pixel et la source des commandes sur ArabyBot Store ?

Vous collez l'identifiant du pixel et le jeton de l'API Conversions dans les réglages de suivi, et la boutique envoie les événements de navigation depuis le navigateur et envoie aussi l'achat depuis le serveur, avec le même identifiant d'événement. Vous choisissez quand l'achat est remonté : à la commande ou à la confirmation. Chaque commande garde sa source : les paramètres UTM, l'identifiant de clic, le site référent, la page d'atterrissage et la première visite.

• Quand l'achat est remonté : un seul réglage — à la commande, ou à la confirmation. La confirmation elle-même est un message WhatsApp auquel le client répond avant l'expédition, quand un numéro WhatsApp Business est connecté au bot, ou un bouton dans le panneau pour les boutiques sans WhatsApp.
• Un pixel par produit : un produit peut porter son propre pixel Meta à côté de celui de la boutique.
• La vérification du site : des champs pour les codes de vérification de Meta, Google et Bing.
• La source des commandes : avec chaque commande, plus des rapports par source et par campagne.
• « Les visiteurs de votre boutique » : les visiteurs en ce moment, les pages, la durée et la profondeur de défilement de chaque visite, sa source et sa publicité, si elle s'est ouverte dans le navigateur d'une application, où l'acheteur s'est arrêté au paiement, et une carte des clics. Elle s'active et se désactive dans les réglages, n'enregistre aucune vidéo, et ne conserve ni ce que tape le visiteur ni son adresse IP.
• Les flux de produits : pour Meta, TikTok, Snap et Google, pour les publicités catalogue — leur utilisation se trouve dans le guide pour vendre sur Facebook et Instagram depuis la boutique.

Ce qu'elle ne fait pas : elle n'envoie rien à Snapchat depuis le serveur, et ne promet aucun retour publicitaire particulier. La boutique s'assure que l'événement arrive correct, une seule fois, au moment que vous avez choisi ; la performance de la publicité dépend du produit, de l'offre et de l'audience. Vous créez le jeton de l'API Conversions dans votre propre compte Meta : les données restent donc entre votre boutique et votre compte publicitaire. Toute la boutique est décrite sur la page ArabyBot Store, et sa partie suivi dans la source des commandes et le pixel.

Questions fréquentes