API Conversions de Meta et paiement à la livraison : comment MyLeadDone renvoie à Meta les commandes réellement livrées

MyLeadDone envoie désormais un événement Purchase (achat) à votre dataset Meta, via l'API Conversions de Meta, lorsqu'une commande en paiement à la livraison est livrée — et non au moment où le client remplit le formulaire. Votre compte publicitaire est informé des commandes qui ont réellement atteint le client et ont été payées à la porte, au lieu de s'arrêter au lead.

Cet article explique le problème que cette fonctionnalité résout, comment elle s'intègre au parcours de commande MyLeadDone — import, confirmation par téléphone, suivi de livraison, statut du livreur — et ce qui est envoyé à Meta, précisément, et à quel moment. Il décrit l'intégration telle qu'elle fonctionne aujourd'hui et renvoie à la documentation officielle de Meta pour tout ce qui relève du fonctionnement de Meta.

En bref : ce que fait l'intégration Meta de MyLeadDone

• Déclencheur : la commande passe au statut Livrée — en COD, le moment où le client paie le livreur. Rien n'est envoyé à la création, à l'annulation, au refus ou au retour d'une commande.
• Événement : un Purchase côté serveur par commande livrée, avec le montant en MAD, envoyé via l'API Conversions vers votre propre dataset Meta — celui de votre Pixel.
• Correspondance : des informations client hachées (téléphone, nom, ville, pays), complétées par l'identifiant de clic Facebook, l'identifiant navigateur Meta, l'adresse IP et le user agent lorsque la commande les contient.
• Pixel : votre Pixel continue de mesurer ce qui se passe dans le navigateur. MyLeadDone ajoute la vente livrée, que le navigateur ne peut jamais voir. Il ne remplace pas le Pixel.
• Garde-fous : un seul Purchase par commande au maximum, des nouvelles tentatives automatiques en cas d'erreur temporaire, et un repère Meta ✓ sur chaque commande dont Meta a confirmé la réception.

Le problème caché de la publicité en COD

Tout annonceur COD connaît le parcours. Une personne voit une publicité sur Facebook ou Instagram, clique, arrive sur la fiche produit et remplit un court formulaire : nom, téléphone, ville. Pour la plateforme publicitaire, ce formulaire est généralement la ligne d'arrivée. Le Pixel se déclenche, une conversion est comptée, et la campagne retient que ce type de profil « convertit ».

En paiement à la livraison, c'est pourtant là que le vrai travail commence. La commande doit encore être confirmée, confiée à un livreur, livrée — et payée en espèces, à la porte. Plusieurs jours séparent le clic de ce moment, et beaucoup de commandes n'y arrivent jamais : numéro erroné, client qui change d'avis, colis refusé.

La plateforme publicitaire ne voit rien de tout cela. Sa boucle de retour se rompt exactement là où le COD devient risqué.

Le résultat est une distorsion discrète mais coûteuse. Une campagne qui produit beaucoup de formulaires bon marché ressemble à une gagnante, même si peu d'entre eux deviennent des colis livrés. Une campagne qui amène moins d'acheteurs, mais plus sérieux, paraît moins performante qu'elle ne l'est. Et quand la diffusion automatique du compte est orientée vers « les personnes qui remplissent des formulaires », elle est orientée vers le mauvais objectif pour un business COD.

Pourquoi un lead n'est pas une vente en paiement à la livraison

Dans une boutique à paiement en ligne, la conversion et le paiement ont lieu au même moment : la carte est débitée au checkout. Le COD les sépare, et chaque étape intermédiaire fait perdre des commandes :

• Un lead n'est pas forcément une commande. Doublons, numéros faux ou mal saisis, clics de curiosité : pour un navigateur, tout ressemble à une conversion.
• Une commande n'est pas forcément confirmée. Certains clients restent injoignables ; d'autres annulent lors de l'appel.
• Une commande confirmée n'est pas forcément livrée. Client absent, changement d'avis, colis refusé.
• Une commande livrée est ce qui se rapproche le plus d'une vente conclue en COD. Le client a le produit, le livreur a l'argent.

Autrement dit, « quelqu'un a rempli un formulaire » et « quelqu'un a rempli un formulaire, reçu le produit et l'a payé » sont deux faits très différents. Seul le second est une vente. Un système publicitaire n'apprend qu'à partir des faits qu'on lui transmet : le choix de ce que vous renvoyez à Meta compte.

Qu'est-ce que l'API Conversions de Meta ?

L'API Conversions de Meta (souvent abrégée CAPI) est une connexion de serveur à serveur qui permet à une entreprise d'envoyer ses événements de conversion directement depuis ses propres systèmes vers Meta, sans dépendre uniquement d'un code exécuté dans le navigateur du visiteur. Meta la présente comme un lien entre les données marketing d'un annonceur — événements web, d'application, de messagerie et conversions hors ligne — et les systèmes de Meta qui optimisent le ciblage publicitaire, réduisent le coût par résultat et mesurent les performances (Meta for Developers).

Trois notions sont utiles :

• Les événements. Chaque conversion est envoyée sous forme d'événement nommé. L'événement standard Purchase signifie qu'un achat a été effectué et exige une valeur et une devise ; Lead signifie qu'une inscription a été complétée (événements standard Meta).
• Les informations client pour la correspondance. Pour relier un événement à une personne sur Facebook ou Instagram, il transporte des informations client. Les données personnelles comme le téléphone, le nom, la ville et le pays sont normalisées puis hachées en SHA-256 avant l'envoi ; les identifiants du navigateur, comme les cookies d'identifiant de clic et d'identifiant navigateur, sont envoyés tels quels (paramètres d'informations client).
• Les événements hors ligne. Toutes les ventes n'ont pas lieu sur un site web. Selon Meta, l'API Conversions est la méthode d'intégration recommandée pour lui envoyer les événements hors ligne et en magasin, à des fins de mesure publicitaire, d'attribution et de ciblage (événements hors ligne).

C'est ce dernier point qui compte pour le COD. Une commande COD livrée est une vente conclue en personne, à la porte du client, plusieurs jours après le clic. C'est exactement le type de conversion qu'un navigateur ne peut pas remonter — et qu'un serveur qui connaît le résultat de la livraison peut transmettre.

Pixel Meta et API Conversions : comment ils fonctionnent ensemble

Le Pixel Meta et l'API Conversions sont complémentaires, pas concurrents. Le Pixel est un code placé sur les pages de votre boutique : il remonte ce que les visiteurs font dans leur navigateur, comme consulter un produit ou commencer une commande. L'API Conversions remonte des événements depuis un serveur — ici celui de MyLeadDone — y compris ceux qui surviennent bien après que le visiteur a quitté le site.

Meta recommande d'ailleurs d'utiliser les deux : pour des performances publicitaires optimales, elle conseille aux annonceurs de mettre en place l'API Conversions en complément de leur Pixel Meta (Meta for Developers).

L'API Conversions remplace-t-elle le Pixel Meta ?

Non. MyLeadDone n'installe aucun Pixel et ne supprime pas le vôtre. Gardez votre Pixel pour les événements de navigation et de commande ; MyLeadDone ajoute un Purchase côté serveur pour le seul événement que le navigateur ne peut pas voir : la commande livrée.

Un réglage à faire : l'endroit où votre Pixel envoie « Purchase »

Beaucoup de boutiques COD déclenchent l'événement Purchase du Pixel dès l'envoi du formulaire, parce que c'est le dernier moment où le navigateur intervient. Dès que MyLeadDone remonte un Purchase à la livraison, ce réglage compte chaque commande livrée deux fois — une fois comme formulaire, une fois comme vente — et continue de compter tous les formulaires qui ne sont jamais devenus des ventes. La déduplication de Meta ne peut pas fusionner ces deux événements : ils sont distincts et enregistrés à plusieurs jours d'intervalle.

La solution est simple : remplacez l'événement du Pixel déclenché à l'envoi du formulaire par Lead ou InitiateCheckout, et laissez le Purchase de la commande livrée venir de MyLeadDone. Chaque événement dit alors la vérité sur ce qui s'est passé.

Comment MyLeadDone ferme la boucle de conversion COD

La plupart des intégrations de l'API Conversions répondent à une seule question : comment envoyer un événement à Meta ? En COD, c'est la partie facile. La partie difficile, c'est de savoir quelles commandes méritent d'être déclarées comme des ventes — et cette information n'existe que là où les commandes sont confirmées, suivies et livrées.

C'est précisément là que MyLeadDone intervient déjà. La plateforme importe la commande, la fait confirmer par téléphone par ses opérateurs, informe le client sur WhatsApp, suit le colis avec le livreur et enregistre la livraison. L'intégration Meta relie la dernière étape de ce pipeline opérationnel à la première étape de l'entonnoir publicitaire.

La valeur n'est pas dans l'appel à l'API. Elle est dans tout ce qui le précède : chaque Purchase envoyé par MyLeadDone est passé par un appel de confirmation, un suivi avec le livreur et une livraison enregistrée. MyLeadDone relie publicité → acquisition → confirmation → suivi → livraison → retour de conversion dans un seul et même workflow.

Le parcours complet, étape par étape

1. Acquérir : la commande arrive dans MyLeadDone

Les commandes arrivent depuis les canaux de vente que la boutique utilise déjà :

• Shopify, via un webhook de création de commande.
• YouCan, via un script ajouté à la boutique.
• Google Sheets, où un script envoie chaque nouvelle ligne.
• Une boutique personnalisée, via l'API de commandes MyLeadDone.

À l'import, MyLeadDone conserve aussi les identifiants publicitaires qui permettront ensuite à Meta de relier la vente au clic : l'identifiant de clic Facebook (fbclid), les valeurs des cookies _fbc et _fbp, ainsi que l'adresse IP et le user agent de l'acheteur lorsqu'ils sont disponibles. Sur Shopify, ils sont lus dans l'URL de la page d'arrivée et dans les attributs de note de la commande, là où de nombreuses applications de formulaire COD les enregistrent. Sur Google Sheets, vous pouvez mapper des colonnes optionnelles dédiées, et l'API de commandes les accepte comme champs. Ils sont conservés exactement tels qu'ils ont été reçus : un seul caractère modifié dans un identifiant de clic suffit à casser l'attribution.

2. Confirmer : une vraie conversation avant toute expédition

Chaque commande est confirmée par téléphone. Les opérateurs MyLeadDone appellent le client, confirment le produit, la quantité et l'adresse de livraison, puis enregistrent le résultat : confirmée, pas de réponse, injoignable, faux numéro, reportée ou annulée. Ils peuvent aussi confirmer un upsell pendant l'appel. Une nouvelle commande passée avec le même numéro dans les 48 heures est signalée, pour que les opérateurs repèrent les doublons avant qu'un colis parte deux fois. Une commande toujours impossible à confirmer à l'issue de la fenêtre de confirmation de trois jours est clôturée comme non confirmée : elle n'atteint jamais le livreur.

WhatsApp accompagne l'appel ; il ne le remplace pas. Quand un appel du premier jour reste sans réponse, l'opérateur relance le client avec un message WhatsApp préparé. Une fois la commande confirmée, le client reçoit une confirmation automatique sur WhatsApp (lorsque les notifications WhatsApp sont activées pour la boutique), et le colis est créé auprès de la société de livraison de la boutique.

3. Suivre : garder la livraison sur les rails

Les commandes confirmées passent en suivi de livraison. Au démarrage du suivi, le client reçoit un message WhatsApp automatique l'informant que sa commande a été expédiée et que l'équipe de livraison va le contacter. Les opérateurs suivent ensuite chaque commande jour après jour. Quand un statut du livreur signale un problème — par exemple un client qui ne répond pas au livreur — la commande rejoint la liste de relance des opérateurs : ils appellent le client, envoient un message WhatsApp si l'appel reste sans réponse, et se coordonnent avec la livraison jusqu'à ce que le colis soit livré ou définitivement retourné.

Pour aller plus loin sur cette étape, consultez nos guides sur la confirmation des commandes COD et la réduction des retours COD.

Le moment où la commande devient une vraie conversion

MyLeadDone est connectée à des sociétés de livraison marocaines comme Sendit, Ameex, Ozon, OLivraison ou Digylog. Les livreurs transmettent les statuts des colis soit instantanément par webhook, soit via des vérifications de statut que MyLeadDone effectue plusieurs fois par jour. Chaque statut du livreur correspond à un statut MyLeadDone, et seul un statut signifiant que le colis a été livré — en COD, remis contre paiement — fait passer la commande en Livrée. Un statut que MyLeadDone ne reconnaît pas n'est jamais considéré comme une livraison. Les opérateurs peuvent aussi enregistrer une livraison manuellement.

Ce changement de statut est le pivot de tout le système. C'est le moment où la vente COD devient réelle, et il déclenche deux choses à la fois :

• la facturation de la commande, selon la tarification MyLeadDone à la commande livrée ;
• la mise en file d'attente de l'événement Purchase pour Meta.

Votre facturation et votre signal publicitaire partagent la même définition du succès : une commande livrée.

Comment MyLeadDone envoie l'événement Purchase à Meta

Quand une commande passe en Livrée et que l'intégration Meta de la boutique est active, MyLeadDone met l'événement en file d'attente immédiatement et l'envoie depuis ses serveurs vers le dataset Meta de la boutique. Juste avant l'envoi, la plateforme vérifie à nouveau que la commande est toujours livrée. Envoyer l'événement au moment où la vente a lieu suit d'ailleurs les bonnes pratiques de Meta, selon lesquelles partager les événements au moment où ils se produisent aide les campagnes à obtenir les meilleurs résultats (bonnes pratiques de l'API Conversions).

Ce que contient l'événement Purchase

Des garde-fous intégrés

• Uniquement les commandes livrées. Les commandes en attente, annulées, refusées, retournées ou en rupture de stock ne génèrent jamais de Purchase.
• Une seule fois par commande. Chaque commande livrée est déclarée au maximum une fois, même si son statut est enregistré deux fois ou si un envoi est relancé.
• Nouvelles tentatives automatiques. Les erreurs temporaires (problème réseau, limite de débit) sont retentées plusieurs fois, à intervalles croissants. Si Meta rejette le jeton d'accès, l'envoi se met en pause et l'intégration vous demande de vous reconnecter.
• Pas d'événement sans moyen de correspondance. Une commande sans montant, ou sans identifiant exploitable comme un numéro de téléphone valide, est ignorée et le motif est affiché.
• Vérifié, pas supposé. Une commande n'affiche Meta ✓ qu'après confirmation de réception par Meta ; une commande livrée sans cette confirmation affiche Meta —. La page Historique Meta liste chaque événement : envoyé, en attente, en échec ou ignoré.
• Un jeton privé. Votre jeton d'accès est chiffré, transmis à Meta uniquement dans un en-tête de requête sécurisé, et jamais réaffiché après enregistrement.

Mise en place

1. Dans le Gestionnaire d'événements de Meta, ouvrez le dataset (Pixel) utilisé par vos publicités et copiez son identifiant.
2. Dans les Paramètres de ce dataset, section API Conversions, générez un jeton d'accès.
3. Dans MyLeadDone, ouvrez Intégrations → Marketing & Publicité → Meta Ads, collez les deux valeurs et enregistrez.
4. Facultatif : ajoutez un code de test depuis l'onglet Tester les événements du Gestionnaire d'événements, pour que le test soit visible chez Meta sans être comptabilisé.
5. Cliquez sur Tester & activer. MyLeadDone envoie un événement à partir d'une vraie commande livrée de votre boutique et active l'envoi si le test réussit — il faut donc au moins une commande livrée au cours des deux derniers mois. Sans code de test, ce premier événement est un vrai Purchase pour votre dernière commande livrée.

Pourquoi les commandes livrées comptent pour Meta Ads

Le système publicitaire de Meta apprend des conversions qu'il reçoit et qu'il parvient à relier à des personnes. Quand la seule conversion est un formulaire, une campagne est récompensée pour produire des formulaires. Ajouter le Purchase de la commande livrée change ce que le compte publicitaire peut voir, sur trois plans :

• La mesure. Vous voyez combien d'achats livrés, et quel chiffre d'affaires livré, sont associés à vos publicités — pas seulement combien de formulaires elles ont produits.
• L'attribution. Quand une commande livrée contient un identifiant de clic ou correspond à une personne reconnue par Meta, la vente peut être créditée à la campagne et à la publicité qui l'ont générée.
• L'optimisation. Le Centre d'aide Meta Business présente l'API Conversions comme un moyen d'optimiser pour des actions qui surviennent plus tard dans le parcours client. En COD, l'achat livré est justement cette action.

Ce que cela ne fait pas, c'est garantir un résultat. Meta ne promet pas d'amélioration chiffrée grâce à l'API Conversions, et nous non plus. Le bénéfice pour une boutique dépend de son volume de commandes, de la part des commandes qui contiennent des identifiants de clic ou correspondent à un compte Meta, et de la configuration de ses campagnes. Ce qui change à coup sûr, c'est la qualité de l'information : Meta est informée des ventes qui ont eu lieu, et plus seulement des intentions. C'est le même principe que celui qui consiste à piloter vos publicités sur le taux de livraison par source d'acquisition plutôt que sur le coût par commande.

Un exemple COD concret

Les chiffres ci-dessous sont une illustration hypothétique, pas des résultats MyLeadDone. Ils montrent comment la lecture change quand Meta reçoit des achats livrés plutôt que des formulaires.

Une boutique dépense 30 000 MAD en publicités Meta sur un mois. Ses campagnes génèrent 1 000 formulaires de commande. Une fois les doublons, faux numéros et demandes inexploitables écartés, il reste 700 commandes valides. Les opérateurs en confirment 500. Les livreurs en livrent 320.

Si le Pixel déclare chaque formulaire comme un Purchase, Meta croit que la boutique a réalisé 1 000 ventes à 30 MAD l'unité. En réalité, elle en a réalisé 320 à environ 94 MAD chacune : le signal surestime les ventes de plus de trois fois. Répartissons maintenant ce même mois entre deux campagnes au budget identique :

Jugée sur les formulaires, la campagne A l'emporte nettement : ses leads coûtent un tiers de moins. Jugée sur les ventes livrées, c'est la campagne B qui gagne : elle a produit plus de clients payants pour le même budget. Un signal limité aux leads pousse le budget vers A. Un signal d'achat livré donne à Meta — et à vous — l'information nécessaire pour voir que B est la meilleure campagne.

Ce que les e-commerçants doivent vérifier avant de commencer

• Connectez votre propre dataset. Utilisez le dataset (Pixel) avec lequel votre compte publicitaire travaille réellement. MyLeadDone n'utilise jamais de pixel partagé.
• Renommez l'événement du formulaire. Si votre Pixel envoie Purchase à l'envoi du formulaire, passez-le en Lead ou InitiateCheckout pour ne pas compter les ventes deux fois.
• Faites remonter les identifiants de clic jusqu'à la commande. L'attribution est la plus solide quand la commande contient le fbclid, _fbc ou _fbp. Les commandes Shopify issues d'applications de formulaire COD qui enregistrent l'URL d'arrivée ou ces valeurs dans les attributs de note sont captées automatiquement ; sur Google Sheets, mappez les colonnes optionnelles ; avec l'API de commandes, envoyez les champs. Sur YouCan, seul un identifiant de clic encore présent dans l'URL de la page peut être récupéré aujourd'hui. Sans identifiant de clic, la correspondance repose sur le téléphone haché et les informations client.
• Vérifiez que le dataset accepte les événements hors ligne. Meta n'accepte les événements hors ligne via l'API Conversions que sur un dataset éligible (consolidé). L'intégration MyLeadDone affiche un avertissement lorsque ce n'est pas le cas.
• Testez d'abord. Un code de test permet de voir l'événement dans le Gestionnaire d'événements avant que de vrais Purchase soient comptabilisés.
• Sachez ce qui n'est pas envoyé. Les commandes annulées, refusées et retournées n'envoient rien, et les commandes livrées avant l'activation de l'intégration ne sont pas envoyées rétroactivement.

FAQ : l'API Conversions de Meta et le paiement à la livraison

Sources

Cet article décrit l'intégration Meta de MyLeadDone telle qu'elle est déployée en septembre 2026. Les éléments propres à Meta s'appuient sur sa documentation officielle (en anglais) :

• Meta for Developers — Présentation de l'API Conversions
• Meta for Developers — Événements hors ligne via l'API Conversions
• Meta for Developers — Paramètres des événements serveur
• Meta for Developers — Paramètres d'informations client
• Meta for Developers — Déduplication des événements Pixel et serveur
• Meta for Developers — Bonnes pratiques de l'API Conversions
• Meta for Developers — Événements standard du Pixel Meta
• Centre d'aide Meta Business — À propos de l'API Conversions