Mesurer avant d’arbitrer

La collecte avant le tableau de bord

Un rapport bien présenté ne dit rien de la qualité de ce qu’il agrège. Avant de regarder une courbe, il faut savoir ce qui est envoyé, depuis où, avec quelle clé d’identification, et ce qui se perd en route : bloqueurs, navigations abandonnées, événements dupliqués.

C’est la raison pour laquelle je pose la mesure dans le code plutôt qu’à côté : balisage serveur quand la fiabilité l’exige, envoi direct côté serveur pour les événements qui comptent vraiment, et un plan de marquage écrit avant la première implémentation. Une mesure ajoutée après coup mesure ce qu’elle peut, pas ce qu’on voulait savoir.

Le consentement n’est pas une formalité de fin de projet

Le consentement change ce que la donnée contient, donc ce qu’on a le droit d’en conclure. Un dispositif conforme se conçoit avec la mesure, pas après : quels événements partent sans consentement, ce qui reste anonyme, ce qui est reconstitué et ce qui est simplement perdu, et assumé comme tel.

Traiter le sujet à la fin donne toujours le même résultat : une bannière posée sur un dispositif qui n’a pas été pensé pour elle, des rapports qui bougent sans qu’on sache pourquoi, et une conformité qui tient sur une capture d’écran.

Décider : couper, garder, réallouer

Quand la collecte est saine, l’arbitrage devient possible : quelle source d’acquisition s’arrête le mois prochain, quelle étape de parcours disparaît, quel segment de clients justifie qu’on dépense davantage pour l’atteindre. Le coût par clic n’est pas la question ; ce que rapporte un client dans la durée, si.

Deux repères de mon parcours : un budget publicitaire et de référencement de 100 000 €, piloté et justifié devant des dirigeants ; et une refonte de parcours d’achat menée à la mesure (tests A/B, cartes de chaleur, taux de rebond) qui a fait progresser le panier moyen de 50 %. Dans les deux cas, la décision a suivi le chiffre, et c’est la même personne qui l’a ensuite implémentée.