Pixel Meta et CAPI : un tracking qui survit à iOS

Trois commandes tombent dans la journée. Le gestionnaire de publicités en affiche une. Ou l'inverse : dix ventes enregistrées à la caisse, six remontées par le Pixel. L'écart n'est pas une panne. Le Pixel est un morceau de code qui s'exécute dans le navigateur du visiteur. Tout ce qui empêche ce code de s'exécuter empêche l'achat d'être compté.

Depuis les restrictions d'iOS, et le durcissement progressif des navigateurs, une partie de ces signaux n'arrive plus. La réponse s'appelle Conversions API, ou CAPI : les mêmes événements, envoyés non plus depuis le téléphone du client, mais depuis votre serveur. Vous n'avez pas besoin d'être développeur pour piloter ce chantier. Vous avez besoin de savoir ce que vous commandez, et ce que vous contrôlez.

Deux voisins complètent celui-ci. Les ventes conclues dans la conversation ont leur propre logique de mesure, traitée dans WhatsApp Business comme canal de conversion. Et si la question du canal n'est pas encore tranchée, commencez par Meta Ads ou Google Ads : mesurer juste un canal qu'on aurait pas dû ouvrir ne sert à rien.

Pourquoi le Pixel seul perd des conversions

Le Pixel fonctionne en trois temps : le navigateur télécharge le script, le script s'exécute, l'information part vers la plateforme. Il suffit qu'un des trois temps manque pour que l'achat disparaisse des statistiques.

Ce qui manque, en pratique : l'autorisation de suivi refusée quand le téléphone la demande, un navigateur qui limite la durée de vie des cookies, une page fermée avant la fin du chargement, une commande passée trois jours plus tard depuis un autre appareil, un paiement effectué sur un autre téléphone que celui de la navigation.

La perte n'est pas répartie au hasard. Elle frappe surtout les cycles longs, les paniers élevés et les clients qui comparent avant d'acheter — exactement les acheteurs qui comptent le plus. Une campagne peut donc paraître non rentable alors qu'elle recrute. La conséquence est directe : vous coupez un canal qui fonctionnait.

Première chose à faire, avant de commander quoi que ce soit : mesurer votre propre écart. Prenez une journée de ventes réelles, caisse, cahier de commandes ou relevés, et comptez les achats. Comparez au nombre d'événements d'achat remontés le même jour dans le gestionnaire d'événements. La différence est votre perte actuelle. Elle se répète sur une semaine avant de conclure.

Ce que le CAPI envoie, et d'où il l'envoie

Le CAPI est un canal direct entre deux machines : votre serveur d'un côté, les serveurs de la plateforme de l'autre. Au lieu d'attendre qu'un navigateur veuille bien exécuter un script, votre système annonce l'événement lui-même, au moment où il se produit chez vous.

Le contenu de l'annonce est simple. Ce qui s'est passé, un achat. Quand, à l'heure près. Pour quel montant et dans quelle devise. Et de la part de qui, sous forme d'identifiants transformés de façon irréversible : un courriel ou un numéro de téléphone haché ne se relit pas, il sert uniquement à rattacher l'achat à une personne déjà connue de la plateforme.

S'y ajoute un identifiant unique par événement. C'est lui qui permet d'éviter le comptage en double quand la même information arrive par deux chemins. Retenez ce point : c'est le détail technique qui décide si vos chiffres sont justes ou doublés.

Reste à savoir où vit ce serveur. Trois cas de figure existent. Si votre boutique tourne sur une plateforme établie, l'intégration est souvent déjà prévue, il suffit de la brancher. Si vous avez un site sur mesure ou un WordPress, il faut soit un développement, soit un conteneur serveur de gestionnaire de balises. Si vos commandes passent par un outil métier, c'est cet outil qui doit émettre l'événement. La bonne question à poser n'est pas « faites-vous du CAPI ? » mais « par où passent mes événements, et qui peut le montrer à l'écran ? »

Ce que cela change dans vos décisions

Trois conséquences, dans l'ordre d'importance.

Vous jugez les campagnes sur un comptage plus complet. Une partie des achats revient dans le rapport. Des campagnes condamnées trop vite réapparaissent comme rentables, et l'arbitrage budgétaire change de base.

L'algorithme apprend sur de vrais acheteurs. L'optimisation se règle sur les événements que vous lui donnez. Si elle ne voit qu'une partie des achats, elle cherche des profils qui ressemblent à cette partie. Envoyez l'achat réel, et la recherche porte sur des clients qui achètent.

Vos chiffres se rapprochent des vôtres. Le coût par commande affiché reste une estimation, mais l'écart avec votre comptabilité se réduit. C'est ce qui rend possible un rapprochement mensuel sérieux entre plateforme et caisse, et évite de piloter sur un indicateur qui raconte une autre histoire que votre trésorerie.

Un quatrième effet, plus discret : la lecture du délai. Un client qui clique le lundi et commande le vendredi sortait jusqu'ici du rapport comme une visite sans suite. Quand l'achat est annoncé par le serveur, il revient au bon endroit, avec la bonne date d'entrée. Vous voyez mieux combien de temps sépare le premier contact de la décision, et donc quelle fenêtre d'attribution choisir : la période pendant laquelle un clic reste crédité d'un achat.

Une limite, pour être honnête : le CAPI ne crée aucune vente. Il ne répare pas une page qui ne convainc pas, ni une offre mal placée. Un tracking parfait sur un tunnel qui fuit reste un tracking parfait sur un tunnel qui fuit.

Pixel et CAPI ensemble, jamais l'un contre l'autre

La question revient souvent sous cette forme : « on garde le Pixel ou on le remplace ? ». Ni l'un ni l'autre. Le Pixel continue de remonter ce que le navigateur accepte encore de laisser passer, ce qui reste utile et rapide. Le CAPI couvre ce que le navigateur ne peut plus transmettre.

Les deux envoient les mêmes événements, marqués par le même identifiant. La plateforme reconnaît le doublon et ne compte qu'une fois. Si l'identifiant manque d'un côté, un achat remonté par les deux chemins compte pour deux. Le sens de l'erreur est dangereux : vous croyez avoir deux fois plus de ventes, vous investissez sur une base fausse.

Deuxième condition, moins connue : le dispositif doit couvrir tout le parcours, pas seulement l'achat. Un tunnel se mesure étape par étape : consultation de fiche, ajout au panier, ouverture du paiement, achat, et l'action de contact quand votre conversion est une conversation. Un achat seul, sans les étapes qui précèdent, vous dit qu'une campagne vend mais pas où les autres visiteurs s'arrêtent.

Troisième cas, à part : la vente qui ne passe pas par le site. Commande conclue au téléphone, au comptoir, par virement, ou dans WhatsApp. Là, aucun navigateur n'a rien vu. Seul un événement émis par votre système peut la déclarer, et c'est souvent ce qui manque aux commerces qui vendent pourtant très bien hors ligne. Le sujet est traité en détail dans cet article sur WhatsApp Business.

Ce que vous commandez à votre prestataire

Vous n'écrirez pas de code, mais vous devez écrire ceci, noir sur blanc, dans la commande.

1. La liste des événements couverts, nommés un par un, du premier écran jusqu'à l'achat, avec celui du canal de conversation si c'est votre cas.
2. L'endroit où tourne le serveur : intégration de la plateforme, conteneur serveur, ou développement sur votre site. Une phrase suffit, mais elle doit être dans le devis.
3. La valeur transmise à l'achat : montant réel, devise réelle, et ce qui se passe pour une commande remboursée ou annulée.
4. La méthode d'identification : quels identifiants sont envoyés, sous quelle forme transformée, et à quel moment le consentement du client est recueilli.
5. La propriété des accès : le compte publicitaire, la source de données, les jetons d'accès et les droits d'administration restent à votre nom. Un prestataire qui installe tout sous son propre compte vous laisse sans recours le jour du départ.
6. La documentation : une note d'une page décrivant ce qui a été branché, avec les identifiants des événements, remise à la livraison.
7. La réversibilité : ce qu'il faut faire si vous changez de site ou de prestataire, et combien de temps les événements continuent d'arriver.

Un devis qui ne parle que de « l'installation du Pixel » ne répond pas à la question. Demandez le détail des événements, la source serveur, et le nom de la personne qui répondra si un achat manque dans le rapport. Un prestataire sérieux accepte de mettre ces trois points par écrit. C'est un signe plus fiable que n'importe quel argument commercial.

Cinq vérifications que vous faites vous-même

Aucune de ces vérifications ne demande de compétence technique. Elles demandent trente minutes et l'accès aux comptes.

1. La source de chaque événement. Dans le gestionnaire d'événements, un événement correctement branché indique d'où il vient : navigateur, serveur, ou les deux. Si tout indique navigateur, le volet serveur n'existe pas, quelle que soit la promesse du devis.
2. Le rapprochement du jour. Comptez les achats réels d'une journée, comparez au nombre d'événements d'achat. Refaites l'opération une semaine plus tard. C'est ce chiffre, et lui seul, qui dira si le dispositif progresse.
3. La commande de test. Passez une commande réelle, à un montant symbolique, et chronométrez l'apparition de l'événement. Vous verrez en même temps si le montant transmis est le bon et si la devise est correcte.
4. L'absence de doublon. Reprenez le même test deux jours plus tard. Un achat compté deux fois est plus grave qu'un achat manquant, parce qu'il vous fait dépenser sur une illusion.
5. La cohérence de la valeur. Un événement d'achat sans montant, ou à zéro, envoie l'algorithme chercher les personnes qui achètent le moins cher. Vérifiez la valeur sur trois commandes de niveaux différents.

Ces cinq contrôles se notent dans un tableau, une ligne par mois : date, nombre d'achats réels, nombre d'événements, écart. Trois lignes suffisent pour voir si la qualité du suivi se dégrade. C'est aussi la pièce à montrer à votre prestataire quand un chiffre paraît étrange, plutôt qu'une impression.

Les erreurs qui rendent le dispositif inutile

La plus fréquente : lancer la mise en place technique sans jamais rapprocher les chiffres de la plateforme et ceux de la caisse. Un dispositif qu'on ne vérifie pas dérive en quelques semaines, et personne ne s'en aperçoit parce que le tableau de bord reste beau.

Vient ensuite la valeur mal renseignée. Un événement d'achat sans montant, une devise approximative, un montant hors livraison : dans les trois cas, l'optimisation travaille sur un objectif qui n'est pas votre chiffre d'affaires. Le détail est visible dans les rapports, encore faut-il le regarder.

Troisième erreur : envoyer des identifiants sans cadre. Ce qui part, dans quel but, et sur quelle base le client a accepté. Ce n'est pas un sujet de développeur, c'est un sujet de patron, et votre prestataire doit pouvoir répondre à la question sans hésiter.

Quatrième erreur : traiter la déduplication comme un détail de fin de chantier. Elle se teste, elle se vérifie, et elle se contrôle après chaque modification du site. Une refonte de page peut casser un branchement que personne n'a documenté.

Dernière erreur, plus politique que technique : attendre du tracking qu'il règle un problème d'offre. Si le taux de conversion de votre page est faible, aucun signal envoyé depuis un serveur ne le corrigera. Réglez d'abord ce qui se passe sur la page, ensuite la mesure.

FAQ — Ce qu'on me demande sur le Pixel et le CAPI