Maîtriser la qualité des données collectées — partie 2 : les outils et process pour empêcher les écarts

Audace, organisation, curiosité : comme nous l’avons vu dans un premier article, ce sont les compétences clés qui vous permettront de gérer la qualité de vos données (si vous prenez le train en marche, c’est par ici).

Mais les qualités de chacun d’entre nous s’émoussent lorsqu’il s’agit de gérer la qualité des données collectées : défaut de rigueur, lassitude face à la répétition des tâches… Malgré toute la bonne volonté du monde, les compétences ont besoin de guides pour êtres utilisées à bon escient, comme une locomotive posées sur ses rails : c’est justement dans cette deuxième partie que nous aborderons les outils et les process à mettre en place.

La qualité des données dépend directement du soin apporté aux tests

Aussi vrai que les projets ont tous (ou presque) un planning sous contrainte, la qualité des données dépend directement du soin apporté aux tests. Il est donc nécessaire de valider en amont du projet le nombre et la durée des différentes phases de test : un minimum de 3 phases de test est à attendre, soit 2 opportunités de corrections pour l’équipe de développement. Ce « détail » du planning a tendance à être trop souvent laissé de côté, sous couvert de méthodes soi-disant « agiles », ou de projet « digitaux » dans lesquels tout devrait aller très vite. Mais dans la réalité, aucun chef de projet ne peut assurer la bonne mise en place de la collecte sans avoir prévu une vérification des données.

C’est la raison pour laquelle il est important de décrire les tests réalisés, et cela dès le lancement du projet : d’abord de façon macro, puis lorsque le plan de collecte est défini, de façon détaillée ( KPI par KPI). Et même si les projets digitaux ont parfois un mode de fonctionnement révolutionnaire, les tests, eux, répondent à une logique déjà bien éprouvée : on peut notamment parler de tests unitaires (KPI par KPI), et de tests globaux (sur l’ensemble des données).

Ces tests sont donc à dérouler à plusieurs niveaux, en suivant la chaîne des données :

• Sur le site, pour valider la validité des variables mises à disposition par le développeur (Est-ce que la variable existe ? Est-ce que sa valeur est cohérente et pertinente avec les informations visibles sur la page ?)
• Sur le TMS, qui agit comme un aiguilleur des données, pour valider le retraitement de ces variables en «  hit » conformément à l’outil de webanalyse visé
• Dans l’interface de webanalyse, pour valider le bon processing des données par l’outil

Attention : la simple vérification des données dans l’interface ne suffit pas à valider la bonne implémentation des KPI ! Vous observez des événements qui comptabilisent les inscriptions à la newsletter de votre site, mais comment savoir que ces événements ne sont pas envoyés suite à une mauvaise interaction ? Lorsque l’inscription est invalidée à cause d’une faute de frappe sur l’adresse email, par exemple…

Une fois le site testé, l’implémentation validée et le tracking fonctionnel, vous pensez que tout va pour le mieux dans le meilleur des mondes. Mais votre dispositif digital évolue : nouvelles pages, nouvelles rubriques, nouvelles fonctionnalités… Il faut donc vous assurer que la qualité des données est toujours satisfaisante, et cela passe par une vérification régulière. Là aussi, elle doit se faire sur plusieurs niveaux : sur le site, et dans vos rapports de webanalyse. Il existe plusieurs outils capables d’émuler une visite sur un site, et de faire un rapport complet des informations collectées. Ces outils se basent en général sur un navigateur « fantôme ». De même, les outils analytics intègrent maintenant des systèmes d’alertes automatiques, à paramétrer : ne vous en privez pas, vous aurez le plaisir de ne perdre qu’une journée de données lorsque le tracking sera mis à mal, là où vous auriez perdu des semaines de données, s’il avait fallu attendre que quelqu’un consulte le rapport en question et se donne la peine de remonter l’alerte.

Passez autant de temps sur la documentation que sur l’implémentation elle-même

Enfin, les projets de collecte de données n’échappent pas à une règle majeure : passer autant de temps sur la documentation que sur l’implémentation elle-même. Combien d’intervenants reprenant un projet en cours de route se plaignent du manque de documentation, mais sont bien en peine de fournir les documents qui détaillent leur propre intervention ! Ces documents sont multiples :

• Plan de marquage (comprenant les spécifications fonctionnelles et les spécifications techniques) (obligatoire)
• Statut des tests (KPI par KPI, détaillés de façon à être reproduits facilement) (obligatoire)
• Détail des tags et règles dans le TMS (facultatif)

Il est vrai que dans certaines situations, la documentation peut être automatisée (à partir du plan de marquage, par exemple) afin de gagner du temps. Mais le soin qui y est apporté garantit la pérennité du projet, surtout dans un contexte où les interlocuteurs changent régulièrement (consultants, agences…).

Aussi vrai que les données sont maintenant un atout majeur pour bon nombre de secteurs d’activité, leur qualité est trop souvent encore le parent pauvre du projet. Or, c’est véritablement le nerf de la guerre, la pierre angulaire sur laquelle repose la réussite du projet sur le long terme : comment rouler sereinement dans une voiture qu’on doit renvoyer au garagiste à chaque plein ? Pour éviter cette situation, il vous faut prendre soin de vérifier la bonne implémentation de vos données, prendre le temps de vous plonger dans la mécanique de collecte pour en comprendre les tenants et aboutissants, et veiller sur la collecte tout au long de la vie du site. C’est à ce prix-là que les analyses futures auront un sens.