Mesurez ce qui paie vraiment.

Presque chaque dispute de reporting est vraiment une dispute de mesure. Meta revendique une conversion, Google revendique la même, GA4 n’en montre aucune, et la réunion devient un débat sur quel tableau croire. C’est un problème de suivi, et ça se corrige.

Nous reconstruisons la couche de mesure pour qu’il y ait une seule définition de conversion et que chaque canal soit évalué selon ce même critère. Cela passe par un suivi des conversions côté serveur : nous avons développé et exploitons les points de terminaison Conversions API de Meta, TikTok, X et LinkedIn sur notre propre infrastructure, avec des importations d’événements hors ligne pour que les algorithmes apprennent à partir des étapes du CRM.

Nous nous auditons de la même façon. Un audit de frontière de suivi sur notre propre analytique a trouvé que 56 % du trafic enregistré était localhost de nos propres machines de développement, et qu’une copie clonée d’un site client tirait nos balises. Les deux ont été corrigés en déplaçant la porte de suivi vers une liste d’autorisation. C’est exactement la classe de défaut qui invalide en silence une année de décisions.

La même discipline va plus loin pour les apps. Pour un client, nous maintenons un pipeline d’entrepôt avec huit marts qui produisent le ROAS de cohorte et les courbes de recouvrement, le niveau de mesure que l’analytique d’apps exige. Côté Web, ce travail s’inscrit sous l’optimisation de site et nourrit directement les décisions de publicité payante.

Kelsey Sarasqueta-Allen, ingénieure données et analytique, conçoit la couche sur laquelle repose chaque autre chiffre : la conception des événements, le suivi côté serveur, les chaînes qui déplacent les données et l’infrastructure qui doit rester en ligne pour que ces chaînes aient un sens.