Mesure des conversions en e-commerce : d’une couverture des événements de 35 % à un niveau presque complet

Le client et son problème

Une boutique en ligne du secteur de la beauté investissait chaque mois un budget conséquent dans la publicité sur Meta. Le problème sautait aux yeux : le nombre d’achats remonté par le pixel ne correspondait pas aux chiffres de la boutique. Meta ne voyait qu’environ un tiers des conversions. Le reste disparaissait.

Il ne s’agit pas seulement d’avoir de jolis rapports. L’algorithme de Meta apprend à partir des événements qu’il reçoit réellement. S’il n’en reçoit qu’un sur trois, il optimise les campagnes sur une vision partielle de la réalité et dépense là où personne ne choisirait consciemment d’investir. Le client payait donc deux fois : d’abord pour les données manquantes, puis pour les mauvaises décisions de l’algorithme.

Trois autres problèmes devaient être résolus ensemble. Le pixel se déclenchait avant que la personne ait fait son choix dans la fenêtre de consentement. C’est à la fois un risque de sanction et des données que Meta ne peut de toute façon pas utiliser : le pire des deux mondes. Ensuite, les événements du navigateur et du serveur devaient partager des identifiants ; sinon, un même achat est compté deux fois et le chiffre d’affaires des rapports n’augmente que sur le papier. Enfin, les événements serveur contenaient trop peu de données, ce qui faisait sous-estimer par le tableau de bord Meta la qualité de correspondance.

Ce que nous avons fait

Nous avons commencé par mesurer le taux réel de consentement de la boutique. La couverture des événements s’est révélée pratiquement égale à ce taux. Le problème ne venait donc pas du code des événements, mais de leur ordre d’exécution : le pixel se déclenchait trop tôt et Meta rejetait ces événements.

Nous avons mis en place un contrôle du consentement sur les deux canaux. La couche navigateur repose sur Google Tag Manager ; la couche serveur utilise server-side GTM hébergé sur Stape. Consent Mode v2 et la plateforme de consentement déterminent ce qui peut être envoyé et à quel moment. Une fois le consentement donné, les événements antérieurs à cette décision sont renvoyés sous la même forme par le pixel et par Conversions API.

Pour éviter de compter deux fois un même événement, nous avons configuré des identifiants stables et communs. Un achat est reconnu grâce au numéro de transaction de la boutique, et non à une chaîne aléatoire générée à chaque actualisation de page. Meta peut ainsi dédupliquer la paire navigateur-serveur et le chiffre d’affaires des rapports correspond à la réalité.

Enfin, nous avons amélioré la qualité des données. Nous avons ajouté aux événements serveur les identifiants utilisateur déjà détenus par la boutique et supprimé les événements parasites : trafic des robots, aperçus et rechargements accidentels du panier.

Le fonctionnement aujourd’hui

La mise en place a pris environ une semaine. La boutique traite désormais six événements Meta standard en parallèle dans le navigateur et sur le serveur. La mesure ne démarre pas avant que la personne ait fait son choix dans la fenêtre de consentement ; une fois son accord donné, aucune donnée de sa visite n’est perdue : nous transmettons les événements en attente.

Chaque événement possède un identifiant commun aux deux canaux. Meta supprime donc elle-même les doublons et ne compte le chiffre d’affaires qu’une fois. Les données utilisateur sont enrichies et le flux est nettoyé : le tableau de bord Meta attribue désormais une meilleure note à la qualité de correspondance. Le marketing consulte les mêmes chiffres que la comptabilité. C’est une exigence modeste, mais elle n’était pas satisfaite auparavant.

Résultats

La couverture des événements Meta standard est passée d’environ 35 % à un niveau presque complet. Les six événements standard fonctionnent désormais simultanément sur les deux canaux. La mesure est conforme au RGPD, car aucune donnée ne part sans consentement. La qualité de correspondance dans le tableau de bord Meta s’est améliorée.

Ce que nous ferions autrement

Nous avons perdu la première journée à chercher une erreur dans le code des événements, car nous pensions qu’une couverture incomplète signifiait simplement que certains événements ne partaient pas. Il suffisait de comparer immédiatement le taux de couverture au taux de consentement : les chiffres étaient pratiquement identiques et indiquaient tout de suite la cause. C’est désormais la première vérification de chacun de nos audits de mesure.

Au début, nous avons considéré le filtrage des événements parasites comme un détail et l’avons gardé pour la fin. Or, ce sont précisément eux qui faisaient le plus baisser la note de qualité de correspondance. Pour la prochaine mise en place de ce type, nous commencerons par examiner le flux brut d’événements avant de toucher à la configuration du consentement.