Comment maintenir son écosystème analytics ?

Sommaire

1. Les phases d’un projet analytics
2. Qu’est-ce que la dette technique ?
3. La dette technique en analytics : apparition et impact
4. Comment maintenir la dette sous contrôle ?

Conclusion

#1 Les phases d’un projet analytics

Dans les projets de web analyse on distingue deux phases : la première est la phase d’implémentation ou de lancement et la deuxième phase est la maintenance. C’est le build and run. 

En pratique il y a souvent déjà un historique présent dans les projets analytics, on démarre rarement de zéro. Mais admettons pour l’exemple que nous lancions un nouveau site e-commerce. Lors de la phase de lancement nous allons dans l’ordre:

• rédiger un plan de mesure et un plan de marquage
• demander à nos amis développeurs de pousser les bonnes variables/valeurs dans la dataLayer
• récupérer ces informations dans notre TMS et les envoyer dans nos outils de mesure d’audience qu’on aura configuré pour recevoir cette donnée
• construire des rapports pour suivre les actions de nos utilisateurs

Très bien. Tout le monde est enthousiaste, vous avez réussi à fédérer les différentes parties prenantes du projet : développeurs, marketing, top management etc. La phase d’implémentation, le build, est terminée. Les rapports sont beaux et fonctionnels, tout roule.

Mais voilà que votre activité et votre site évoluent dans le temps. Vous allez développer de nouvelles pages, sortir de nouveaux produits, simplifier votre tunnel d’achat, faire des expérimentations etc. Et c’est là que la phase de run intervient. Pour que le produit final de vos efforts d’analytics, c’est à dire vos rapports, continue à vous apporter une information de qualité sur vos utilisateurs pour vous aider à piloter le business, alors il faut accompagner ces évolutions. 

Une évolution de votre site va se répercuter sur tous les éléments de votre phase de lancement. Il faut modifier le plan de mesure, plan de marquage, la dataLayer, les tags et les rapports pour prendre en compte la dernière évolution. C’est ainsi que votre analytics reste à la pointe et permet d’abreuver les différentes équipes de données fiables et pertinentes. 

Sauf que l’excitation du début n’est plus là. Vos soutiens initiaux estiment maintenant avoir assez investi dans l’analytics et pensent qu’avec le travail de la phase de lancement, la qualité de la donnée est garantie une bonne fois pour toutes. On veut voir les projets sortir, les nouvelles pages live sur le site, pour ce qui est des chiffres on verra après. On verra dans un deuxième temps. Après tout l’analytics ne génère pas de revenu directement, c’est une fonction support.

Et c’est là qu’apparaît la dette technique.

#2 Qu’est-ce que la dette technique ?

La dette technique est un concept venant du développement logiciel, formulé en 1992 par l’informaticien Ward Cunningham. Le principe est que le code d’un programme ne se termine pas à la mise en service du programme, car après le lancement il y aura forcément des correctifs et mises à jour à prévoir à plus ou moins long terme. 

La dette technique correspond au poids du code existant. Les correctifs et mises à jour représentent les intérêts de la dette. En respectant les règles de conception et en gardant un code clean, on limite le poids de la dette et ses intérêts. A l’inverse les quick fix et le non maintien d’un code clean augmentent la dette et ses intérêts. Comme avec un prêt bancaire, plus la dette est élevée plus ses intérêts le sont aussi. 

Souvent la dette technique se crée lorsqu’on privilégie les actions rapides aux solutions long terme. C’est le reliquat de ce qu’on a pas pu faire correctement.

La dette technique n’est pas un mal en soi. Elle est même inévitable car les impératifs business imposent souvent d’aller vite au détriment du code et de la qualité de nos données.

#3 La dette technique en analytics : apparition et impact

En analytics, comme pour les projets IT, la dette technique se creuse lorsque les mesures quick fix s’imposent comme des solutions long termes. La dette peut donc venir de tous les outils et processus dans lesquels le web analyst est impliqué : la gestion du TMS, les solutions de mesure d’audience, les documents de travail partagés, les présentations etc. 

Regardons quelques exemples concrets pour mieux comprendre l’apparition de la dette technique.

1er exemple : utiliser une fonction Javascript pour récupérer une donnée manquante dans la dataLayer

Si on souhaite récupérer le prix sur une fiche produit mais que cette donnée n’est pas présente dans la dataLayer, on peut utiliser une fonction Javascript pour capturer cette information le temps que le développeur pousse cette variable dans la dataLayer. Ce quick fix fonctionne, on collecte bien l’information. Mais si la structure de la page évolue et que l’élément contenant le prix change alors il faudra modifier notre fonction Javascript, ce qui induit un risque de perte de données le temps de faire la modification. A l’inverse, en implémentant une variable prix dans la dataLayer on se couvre contre ce type de risque et on se libère du temps pour d’autres sujets.  

2ème exemple : déployer une nouvelle fonctionnalité sans tracking

Il peut arriver qu’on ait besoin de déployer en production une fonctionnalité le plus rapidement possible : un correctif de bug, un nouveau moyen de paiement, voir le lancement d’une application en retard par exemple. Dans ce cas là, on peut comprendre que le tracking soit considéré comme venant après le plus important qui est de sortir la fonctionnalité pour améliorer l’expérience de nos utilisateurs. 

Mais la dette technique se creuse chaque jour qui passe entre la sortie de la fonctionnalité et l’implémentation de tracking pour collecter des données sur les interactions de nos visiteurs avec la fonctionnalité. Ce manque d’information retarde l’analyse ainsi que les itérations et les expérimentations possibles pour une deuxième version améliorée de la fonctionnalité.

Autres exemples de création de dette technique en analytics :

• L’utilisation de sélecteurs CSS pour palier à l’absence d’une donnée dans la dataLayer.
• Une solution d’AB test qu’on utilise comme patching pour pousser une modification sur 100% de notre trafic mais qui ralentit le temps de chargement de la page.
• Des modèles d’attribution non documentés et donc difficiles à comprendre.
• Un changement de nom de dimension ou de métrique qui casse la cohérence dans le temps.

Une dette technique analytics non maîtrisée va avoir plusieurs impacts comme : 

• Complexifier la collecte de données 
• Dégrader la qualité de la donnée
• Ralentir la production d’analyses et de tableaux de bords
• Compliquer la prise de décisions des équipes métiers 
• Complexifier la montée en compétences de nouveaux analystes dans l’équipe

Tous ces impacts rendent la tâche du web analyst plus dure à accomplir et l’organisation dans son ensemble subit le contrecoup. Lorsque la dette technique devient trop grande, on peut avoir l’impression d’être dans une partie de Jenga : si notre dernière modification ne casse pas tout, on soupire de soulagement et on ne touche plus à rien. 

#4 Comment maintenir la dette sous contrôle ?

Le maître mot pour éviter l’emballement de la dette technique est la rigueur. Plus facile à écrire qu’à mettre en pratique !

La dette technique est inévitable mais il y a des bonnes pratiques pour limiter sa croissance. Il faut de la discipline dans ses actions au quotidien et se donner le temps de faire les choses proprement. Ce qui peut-être difficile quand on est seul à gérer tout l’analytics d’une entreprise, et un peu plus simple quand on évolue dans une équipe de web analysts car le besoin de collaboration nous pousse à mieux nous organiser. 

Avant d’énumérer les points que j’essaye d’appliquer (idéalement) pour limiter la dette technique, je précise que cette liste n’est pas exhaustive et que je suis preneur de toute information complémentaire. 

Et maintenant voyons quelques bonnes pratiques pour garder en analytics clean.

Dans Google Tag Manager  (GTM) :

• Nommer ses versions lors de la publication et y ajouter une description. Cela permet d’avoir rapidement un aperçu des changements effectués, sans avoir à regarder le détail de chaque modification. C’est un grand gain de temps quand on cherche quelle version a fait sauter un élément de tracking par exemple.
• Respecter une nomenclature type pour :
  • Ses tags
  • Ses triggers
  • Ses variables
  • Ses folders
  • Ses workspaces

Cela peut paraître évident mais lorsqu’on range ses affaires on s’y retrouve mieux, et dans GTM le même concept s’applique. Tout devient plus simple avec une nomenclature standardisée. Le choix de la nomenclature importe moins que la stabilité avec laquelle on l’applique. Dans le cas où je travaille sur un container avec une nomenclature déjà existante je me cale dessus, sans chercher à réinventer la roue.

Pour aller plus loin sur les nomenclatures possibles dans GTM, je vous recommande cet article de Bounteous.

• Nettoyer régulièrement son container. Dans l’utilisation quotidienne de GTM il arrive souvent qu’on teste et modifie nos tags, triggers et variables. Il arrive aussi que ces éléments ne soient plus utilisés ou que des tags soient mis en pause depuis une éternité. Dans ces cas-là, mieux vaut supprimer les éléments inutilisés pour garder notre nombre de tags, trigger et variables le plus petit possible. 

Dans Google Analytics (GA) :

• Respecter une nomenclature type pour :
  • Ses propriétés et ses vues
  • Ses évènements
  • Ses paramètres de tracking UTM

Pareil que pour GTM, garder une nomenclature standardisée va vous faire gagner un temps précieux dans votre utilisation de GA. Là aussi essayez de vous caler sur la nomenclature existante pour garder une cohérence dans le temps.

Je vous invite à lire cet article pour voir des exemples de nomenclature GA et GTM.

• Utiliser les annotations pour retenir les mises à jour : 

Lorsque votre site évolue, on garde en mémoire la dernière fonctionnalité ou le bug du moment. Mais un an après, difficile de s’en souvenir. Les annotations dans GA permettent de noter directement ces évolutions dans l’outil et sont ainsi très utiles pour éviter les pertes de mémoire. 

Un petit tutoriel vidéo pour comprendre comment annoter dans GA (1 min).

Dans ses rapports et présentations :

• Ajouter un glossaire. Certains indicateurs sont évidents pour nous analystes, mais ce n’est pas forcément le cas pour les autres métiers. Difficile de comprendre ce qu’est un taux de rebond sans explication de l’indicateur. Pour éviter que nos rapports soient mal interprétés ou que nous ayons à expliquer maintes fois à l’oral ce que veulent dire nos indicateurs, il est bon d’avoir recours à un glossaire. 

Poser à l’écrit les définitions des KPIs dans un glossaire vous permettra de rendre les clients du rapport plus autonomes et vous aidera également dans vos présentations orales. A l’inverse, un analyste qui a du mal à expliquer les KPIs de son rapport perd en crédibilité et en confiance.

•  Préciser le périmètre dans les rapports ou présentations :
  • Quels sont les sites et applications concernés
  • Quel pays ou zone géographique
  • Quelle période de date
  • Quel device, etc

Souvent nos analyses et présentations sont ponctuelles, concentrées sur un sujet en particulier. Dans ce cas, il est bon de rajouter en bas de slides le périmètre de l’analyse. Cela va permettre aux futurs lecteurs de comprendre le contexte de l’analyse et ainsi d’éviter les mauvaises interprétations et/ou de vous solliciter pour vous demander sur quelle période ou site porte l’analyse.

Dans son organisation et documents partagés:

• Tenir son plan de marquage à jour. Avec chaque nouvelle fonctionnalité le tracking évolue, des nouveaux évènements et/ou variables sont poussés dans la dataLayer, d’autres disparaissent. Là encore difficile de tout garder en mémoire. Une bonne pratique est de créer une nouvelle copie du plan de marquage à chaque évolution et d’y indiquer : la date de mise en production, les modifications apportées, les définitions des nouvelles variables etc. 

Cela va vous permettre d’avoir un historique détaillé de vos plans de marquage et d’avoir également une dernière version à jour. 

• Schématiser vos flux de data engineering. Cela peut paraître un peu poussé mais d’expérience faire un schéma de vos flux de données aide vos utilisateurs à comprendre d’où vient la donnée. 

Par exemple, une slide indiquant les étapes de collecte de données de Google Analytics, l’export de cette donnée dans BigQuery et sa visualisation dans Tableau, cela rend la chose plus concrète. Et c’est aussi très utile pour onboarder des nouvelles personnes dans votre équipe d’analystes.

Si on récapitule tout ça :

Dans tout projet analytics il y a une phase d’implémentation et une phase de maintenance, le build and run. La phase de maintenance est souvent sous-estimée dans les organisations et cela engendre progressivement la détérioration de votre configuration analytics. Cette détérioration a des répercussions en cascade : la donnée collectée est de moins bonne qualité, moins fiable, il faut plus de temps pour sortir des analyses, celles-ci peuvent comporter des erreurs et amener à des mauvaises prises de décision dans le pire des cas.

La raison de cette baisse de qualité est la dette technique. Celle-ci se crée naturellement au cours des évolutions de votre site, de vos outils, de votre équipe. La dette technique est inévitable dans tout projet IT ou analytics. Elle n’est pas forcément mal en soi, parfois il faut opter pour un quick fix pour répondre à une priorité business. Mais c’est son accumulation dans le temps qui est dangereuse. Les intérêts de la dette technique se paient cash et plus la dette est importante plus les intérêts le sont aussi.

Le maître mot pour maintenir la dette technique sous contrôle est la rigueur. L’analyste ne contrôle pas toutes les évolutions de son organisation mais il contrôle ses outils comme GTM, GA, ses tableaux de bords ou encore ses présentations. Dans ce périmètre il faut être consistant dans ses nomenclatures et dans l’organisation de ses outils de travail. L’idée est que si un nouvel analyste devait rejoindre votre équipe, il pourrait s’y retrouver rapidement dans votre configuration. 

L’écrire sur papier est facile, le mettre en pratique est plus compliqué. Soyons rigoureux amis analystes !