Suivi des conversions en paiement à la livraison et checkouts externes

Le suivi des conversions en paiement à la livraison consiste à envoyer chaque achat à vos plateformes publicitaires à partir de la commande elle-même, sur le serveur, plutôt que de compter sur un pixel navigateur placé sur une page de remerciement. Les commandes issues d’applications de paiement à la livraison, de checkouts externes, de formulaires de commande et de tunnels de vente se terminent souvent en dehors du checkout habituel : le pixel les rate donc ou les déclare au mauvais moment.

Ce guide explique pourquoi ces commandes disparaissent et pourquoi le statut de paiement compte. Il compare trois moments pour envoyer l’achat : à la création de la commande, à sa confirmation et à son paiement. Il aborde aussi les commandes refusées et les remboursements, ainsi que la façon dont ROASaurus gère les checkouts externes.

Pourquoi les pixels ratent-ils les commandes en paiement à la livraison ?

Un pixel navigateur déclare un achat quand l’acheteur arrive sur une page qui l’exécute. C’est en général la page de remerciement de votre checkout. Tout parcours de commande qui saute cette page, ou l’exécute sur un autre domaine, perd l’événement d’achat ou le clic publicitaire qui lui correspond.

La commande elle-même n’est jamais perdue. Elle arrive dans votre boutique en ligne ou votre outil de tunnel de vente avec un identifiant de commande, un montant, une adresse e-mail et souvent un numéro de téléphone. C’est pourquoi la solution fiable consiste à envoyer l’achat à partir des données de commande, côté serveur, et à transporter le clic publicitaire jusqu’à la commande. Le suivi côté serveur sur Shopify explique la méthode générale. Cet article traite des commandes qui demandent une attention particulière.

Certaines applications de paiement à la livraison déclenchent aussi leurs propres événements de pixel. Si elles utilisent le même pixel que votre suivi côté serveur mais un identifiant d’événement différent, la plateforme compte la commande deux fois. Désactivez ces événements d’application, ou suivez les étapes pour éviter le double comptage.

Pourquoi le statut de paiement compte

Un paiement par carte est capturé dans le checkout : la commande est donc payée dès qu’elle existe. Une commande en paiement à la livraison est différente. Shopify range le paiement à la livraison parmi les modes de paiement manuels, et ces commandes restent en Payment pending jusqu’à ce que vous les marquiez comme payées. En pratique, cela arrive après l’encaissement par le livreur, ce qui peut prendre des jours. Certaines commandes ne sont jamais payées, car l’acheteur refuse le colis ou n’est pas chez lui.

De nombreuses configurations de suivi envoient l’achat quand la commande est payée, car pour les commandes par carte, c’est le moment le plus sûr. Pour une commande en paiement à la livraison, la même règle fait arriver l’achat des jours trop tard, voire jamais. Le journal ci-dessous montre un cas typique sur une boutique qui envoie les achats au paiement.

WooCommerce fonctionne à l’inverse. Il met les commandes en paiement à la livraison en Processing jusqu’à l’encaissement, sauf les commandes contenant un produit téléchargeable, qui passent en On hold. Une configuration qui envoie les commandes en Processing les envoie donc dès qu’elles sont passées. Vérifiez quel statut votre plateforme donne à ces commandes avant de décider quoi que ce soit d’autre.

Créée, confirmée ou payée : quand envoyer l’achat ?

Trois moments sont possibles. Chacun arbitre entre rapidité et exactitude.

Pourquoi les événements d’achat tardifs posent problème

Les plateformes publicitaires n’attribuent un achat à une publicité que s’il a lieu dans la fenêtre d’attribution suivant le clic. Avec un réglage d’attribution au clic de 7 jours sur Meta, un achat est attribué à une publicité jusqu’à 7 jours après le clic. La Conversions API de Meta refuse aussi les événements dont l’event_time date de plus de 7 jours, et rejette toute la requête dès qu’un événement est trop ancien. Un achat envoyé au paiement n’a donc que deux mauvaises options :

• L’envoyer avec l’heure de la commande. Si le paiement est arrivé plus de 7 jours après, Meta le rejette.
• L’envoyer avec l’heure du paiement. Meta l’accepte, mais le clic publicitaire peut alors dater de plus de 7 jours : l’achat n’est donc pas attribué à la publicité.

La rapidité compte aussi pour l’optimisation. Les campagnes qui optimisent pour les achats apprennent à partir des achats que vous envoyez. Un signal qui arrive avec une semaine de retard renseigne l’algorithme sur l’audience de la semaine dernière.

Quel moment choisir

Pour la plupart des boutiques en paiement à la livraison, envoyer à la création est le meilleur choix par défaut. Le signal est immédiat, le clic est encore dans la fenêtre et rien n’est rejeté. Le prix à payer : les commandes refusées comptent comme des achats dans Ads Manager. Vous le corrigez dans vos objectifs, comme le montre la section suivante.

Si votre équipe confirme chaque commande par téléphone ou par message avant l’expédition, la confirmation est un bon compromis. Elle écarte les fausses commandes et intervient en général dans la journée. Utilisez-la quand votre propre système peut envoyer l’achat à ce moment-là, par exemple via une API. Les fausses commandes comptent plus qu’il n’y paraît : si la plateforme publicitaire apprend à partir d’elles, elle cherche davantage de personnes qui passent commande sans payer.

Comment gérer les commandes refusées, les annulations et les remboursements

Une fois un achat envoyé, il reste dans Ads Manager. Un colis refusé à la livraison ne le supprime pas. ROASaurus n’envoie pas non plus les remboursements ni les annulations à Meta, TikTok et la plupart des autres plateformes publicitaires : le chiffre d’affaires qu’elles affichent inclut donc des commandes que vous n’avez jamais encaissées. Seules les valeurs Google Ads et Microsoft Advertising peuvent être corrigées après un remboursement, lorsque les corrections de valeur sont activées. La solution consiste à mesurer votre taux de refus et à ajuster les chiffres auxquels vous comparez.

Voici un exemple chiffré sur un mois. Pour faire simple, les prix sont hors TVA.

Avec $3,000 de dépenses publicitaires, le même mois paraît très différent selon le chiffre d’affaires utilisé :

Le taux de marge brute sur le chiffre d’affaires livré est de $3,878 ÷ $8,200 = 47.3%, donc le ROAS d’équilibre est de 1 ÷ 0.473 = 2.11. Ce seuil s’applique au chiffre d’affaires livré. Ads Manager compte aussi les commandes refusées : il faut donc le convertir avant de comparer. ROAS d’équilibre explique la formule de base.

Vous pouvez vérifier le résultat directement. Les publicités sont à l’équilibre quand les dépenses publicitaires égalent le bénéfice brut de $3,878, et $10,000 de chiffre d’affaires déclaré ÷ $3,878 = 2.58.

Les taux de refus varient souvent selon la région, le produit et la campagne. Calculez-les par campagne quand vous avez assez de commandes, et utilisez le calculateur de POAS pour vérifier le résultat sur le bénéfice brut.

Remboursements et annulations dans vos propres chiffres

Sur Shopify, les annulations et les remboursements parviennent à ROASaurus par webhook : l’analyse du bénéfice déduit donc les remboursements du chiffre d’affaires. Vous choisissez si les commandes annulées qui n’ont jamais été expédiées comptent, et par défaut elles sont exclues. Une commande annulée déjà expédiée reste comptée, car son expédition vous a quand même coûté de l’argent. Pour les commandes récentes qui peuvent encore revenir, le réglage Predicted returns met de côté une part attendue des ventes jusqu’à l’arrivée des vrais remboursements.

Comment ROASaurus gère le paiement à la livraison et les checkouts externes

Shopify

Chaque boutique Shopify a un Checkout type dans Store settings, avec deux options :

• Shopify checkout : l’achat est envoyé quand Shopify signale la commande comme payée, via le webhook orders/paid.
• External / COD checkout : l’achat est envoyé à la création de la commande, via le webhook orders/create. Utilisez-le pour le paiement à la livraison et pour les checkouts externes, comme CheckoutChamp ou Checkify, qui créent eux-mêmes la commande Shopify.

Le réglage s’applique à toutes les commandes de la boutique. Les commandes par carte, payées dans le checkout, sont créées et payées presque au même moment : le choix change donc surtout le moment où les commandes impayées sont envoyées. Chaque commande n’est envoyée qu’une fois. Quand la mise à jour « payée » d’une commande en paiement à la livraison arrive plus tard, aucun second achat n’est envoyé.

L’achat utilise les données propres à la commande : le montant, la devise, les produits, ainsi que l’e-mail, le téléphone et l’adresse de l’acheteur, hachés avant de partir. ROASaurus associe la commande au clic publicitaire grâce à l’identifiant visiteur que son script enregistre sur le panier. Quand une commande ne le porte pas, ROASaurus essaie, dans cet ordre : les jetons de panier et de checkout, l’événement d’achat du checkout, un e-mail que le visiteur a donné plus tôt sur votre site, et la même adresse IP et le même navigateur peu avant la commande, quand un seul visiteur correspond. La page intégration Shopify détaille la configuration complète.

WooCommerce et les autres boutiques en ligne

Le plugin WooCommerce envoie une commande dès qu’elle passe en Processing ou Completed. Les commandes en paiement à la livraison passent en Processing quand elles sont passées : elles sont donc envoyées immédiatement. Les commandes par virement bancaire sont envoyées quand elles passent en Processing. Les autres connecteurs de boutiques en ligne envoient une commande à ces moments :

• Wix, Squarespace, Ecwid, Lightspeed, CCV Shop et Shopware : quand le statut de paiement de la commande est payé.
• BigCommerce : quand la commande atteint un statut tel que Awaiting Fulfillment, Awaiting Shipment, Shipped ou Completed.
• Magento : quand l’état de la commande est Processing ou Complete.
• PrestaShop : quand la commande est marquée comme valide.
• Webhook personnalisé et API de commandes : quand votre propre système envoie la commande.

Vérifiez comment votre plateforme marque les commandes en paiement à la livraison. Si elles restent impayées jusqu’à ce que le livreur reverse l’argent, leurs achats arrivent en retard.

Tunnels de vente et votre propre checkout

1. Ajoutez le script aux pages du tunnel

   Utilisez la même clé de boutique que pour votre boutique en ligne, afin qu’un visiteur garde un seul identifiant visiteur sur les deux domaines.

2. Listez vos domaines

   Dans Store settings, ajoutez les domaines du tunnel et de la boutique sous Linked domains. Les liens entre ces domaines transportent alors l’identifiant visiteur et les identifiants de clic.

3. Envoyez les commandes via l’API de commandes

   Si le tunnel prend lui-même la commande, envoyez chaque commande en POST à /api/v1/orders avec le cookie _tl comme visitor_id. Votre système décide du moment : à la création, à la confirmation ou au paiement.

4. Vérifiez l’Event log

   Quand les premières vraies commandes arrivent, ouvrez l’Event log et vérifiez que chacune a été envoyée à toutes les plateformes connectées.

POST /api/v1/orders
X-Roasaurus-Key: <store key>
Authorization: Bearer <API key>
Content-Type: application/json

{
  "order_id": "F-20931",
  "created_at": "2026-10-20T14:05:00Z",
  "total": 50.00,
  "currency": "USD",
  "email": "buyer@example.com",
  "phone": "+15555550123",
  "country": "US",
  "visitor_id": "<value of the _tl cookie>",
  "click_ids": { "fbc": "<_fbc cookie>", "fbp": "<_fbp cookie>" },
  "client_ip": "203.0.113.7",
  "user_agent": "Mozilla/5.0 ...",
  "items": [{ "variant_id": "SKU1", "quantity": 1, "price": 50.00 }]
}

L’API de commandes conserve la première copie de chaque identifiant de commande. Si votre système l’appelle à la création puis au paiement, seul le premier appel envoie un achat. Plus de détails dans tunnels de vente et domaines multiples.

Erreurs courantes à éviter

• Attendre le statut payé sur une boutique en paiement à la livraison. Les achats arrivent avec une semaine de retard ou jamais, et les événements tardifs sont rejetés ou sortent de la fenêtre d’attribution.
• Comparer le ROAS d’Ads Manager à un seuil d’équilibre calculé pour les commandes payées. Divisez d’abord le seuil d’équilibre par votre taux de paiement.
• Deux sources pour un même achat. Le pixel propre d’une application de formulaire et vos événements serveur comptent la même commande deux fois. Voir événements d’achat en double.
• Perdre le clic entre les domaines. Un tunnel sur un autre domaine a besoin du script et des domaines liés, faute de quoi ses commandes arrivent sans clic publicitaire.
• Laisser de côté les commandes manuelles. Les commandes par téléphone ou par chat n’ont pas de session navigateur, mais elles ont quand même une adresse e-mail ou un numéro de téléphone. Envoyées à partir des données de commande, elles donnent à la plateforme publicitaire de quoi les associer.

Sources

1. Meta for Developers: Server Event Parameters
2. Shopify: WebhookSubscriptionTopic (GraphQL Admin API)
3. Shopify Help Center: Manual payment methods
4. Shopify Help Center: Understanding your order statuses
5. WooCommerce: Cash on Delivery documentation

Dans ROASaurus

• Intégration Shopify
• Intégration WooCommerce
• Aide : tunnels de vente et domaines multiples
• Analyse du bénéfice dans ROASaurus

À lire aussi