Le guide du tracking server-side explique l'architecture ; les CAPI de plusieurs plateformes comparent les destinations. Ici, on traite le chemin Meta d'un événement achat, de la boutique jusqu'au diagnostic dans Events Manager.
Choisir l'intégration et vérifier un achat test
Dans Events Manager, identifiez la source de données utilisée par le site, puis choisissez une intégration partenaire compatible avec votre boutique ou une implémentation directe si vous maîtrisez l'envoi serveur. Meta documente ces deux voies. Vérifiez d'abord qu'un autre connecteur n'envoie pas déjà les mêmes achats : deux intégrations serveur actives peuvent compliquer le diagnostic.
Sur une commande test, faites remonter Purchase avec event_time, un event_id stable, puis value et currency cohérents avec la commande ; ajoutez les ID produit si le catalogue en dépend. Dans les événements de test d'Events Manager, contrôlez la réception, les diagnostics, la qualité de correspondance des événements (Event Match Quality) et, si le Pixel envoie aussi l'achat, la déduplication. Les écrans et champs disponibles varient selon la plateforme et le connecteur ; une alerte de correspondance n'autorise pas à collecter des identifiants contre le choix du visiteur.
Définir l'événement achat à transmettre
Choisissez un événement déclenché une seule fois lorsque la commande est confirmée, avec un identifiant métier stable. Associez nom Purchase, heure, valeur et devise cohérentes avec la boutique. Pour les annonces catalogue, vérifiez également les identifiants des articles ; le catalogue Meta n'apparie pas une variante si les ID ne coïncident pas. Documentez qui contrôle l'envoi serveur et à quel moment le consentement est vérifié.
Éviter les doublons Pixel et CAPI
Lorsque le même achat part du navigateur et du serveur, Meta documente une déduplication fondée sur la paire event_name et event_id. Générer un identifiant différent dans chaque canal annule ce rapprochement. Faites trois essais : achat test, recharge de la page de confirmation et nouvelle commande. Un second chargement ne doit pas devenir une nouvelle vente.
Faire défiler le tableau →
| Point de contrôle | Attendu |
|---|---|
| Pixel | Achat et event ID visibles si autorisés |
| CAPI | Même nom et même event ID pour cet achat |
| Boutique | Une commande et une valeur de référence |
| Diagnostics | Pas de doublon compté et pas d'erreur de paramètre |
Garder les limites en vue
La CAPI ne reconstitue pas les interactions d'une personne qui refuse la collecte. Elle ne rend pas non plus toutes les ventes attribuables à la publicité. Limitez les données personnelles, respectez les préférences et surveillez les erreurs après chaque modification du checkout ou du Pixel. Comparez les événements reçus aux commandes réelles, pas uniquement au tableau publicitaire.
Questions fréquentes
La CAPI remplace-t-elle le Pixel Meta ?
Pas nécessairement. Les deux canaux peuvent fonctionner ensemble, mais les événements identiques doivent être dédupliqués. La décision dépend de votre architecture et des données que vous pouvez transmettre légalement.
Comment éviter deux achats pour une commande ?
Envoyez le même nom d'événement et le même identifiant unique pour l'achat côté navigateur et côté serveur, puis vérifiez la déduplication dans les diagnostics Meta. Une simple égalité de montant ne suffit pas.
Faut-il envoyer l'adresse email du client ?
Les données de correspondance sont optionnelles selon l'intégration et doivent être minimisées, protégées et envoyées seulement lorsque la base applicable le permet. Ne collectez pas un identifiant pour contourner un refus.
La CAPI garantit-elle un meilleur ROAS ?
Non. Elle peut améliorer la qualité de certains signaux, mais le ROAS dépend aussi des campagnes, de l'attribution, de l'offre et de la mesure. Comparez les commandes réelles avant et après changement.
On regarde vos chiffres ensemble ?
45 minutes, vos données sous les yeux, et une lecture de là où se cache la marge dans votre acquisition.
Réserver un appel