La recette de votre tracking analytics est une étape incontournable de votre Tag Management. Si ce n’est pas l’une des tâches les plus sympas pour vous web analyste, cela n’en reste pas moins un passage obligé pour valider que votre implémentation respecte bien ce que vous avez renseigné dans votre plan de marquage.

Il est inutile de rappeler que vous devez recetter votre tracking pour garantir que vos rapports d’analyses se feront sur la base de données fiables. Il est aussi inutile de remuer le couteau dans la plaie en disant qu’en plus d’être rébarbative, la recette de votre tracking analytics prend trop de temps et qu’en fin de compte elle n’est pas très efficace.

Comme tout intervenant sur le plan de marquage, vous avez forcément tenté des choses, l’utilisation d’outils ou la mise en place de process pour tenter de gagner en proactivité dans la recette de votre tracking analytics.

L’objectif de cet article est de décrypter ces différentes initiatives et de voir ce qui fonctionne ou non.

Au programme : 

• La comparaison des KPI
• Le process de recette manuelle
• Les outils de tests de non-régression,
• Le développement de solutions internes 

On a aussi pensé qu’un tableau récapitulatif des différentes méthodes pourrait vous intéresser, il est dispo ici : 

Ces tentatives infructueuses pour faire une recette de votre tracking analytics

 La comparaison des KPI entre P et P-1.

Le titre parle de lui-même, cela revient sur une période donnée (un jour, une semaine, un mois,…) , à comparer un indicateur de performance -comme le taux de conversion par exemple- avec une période antérieure équivalente. Les équipes y ont parfois recours en cas d’évolution suspecte d’un KPI. Les outils d’analytics donnent la possibilité de configurer des alertes pour être informé en cas de chute ou hausse anormale d’un KPI. En cas de déclenchement alors seulement une investigation est prévue.

Les avantages de cette méthode : 

• La démarche est initiée, il y a une volonté de s’assurer que le tracking est bon et que la qualité des données est au rendez-vous. 
• Désolé, c’est vraiment le seul avantage que l’on ait trouvé à cette méthode !

Les inconvénients:

• Cette méthode est très artisanale et prend le problème à l’envers. La finalité de vos KPI est de pouvoir vous y fier pour analyser la performance de votre site, pas pour détecter s’il y a une anomalie au niveau de votre tracking. C’est un non sens absolu !
• Le mal est fait, le constat a lieu a posteriori et l’impact sur la qualité de vos données est là. Elles sont inexploitables pour faire vos tableaux de bord.
• Vous savez qu’il y a un problème au niveau de votre tracking mais vous n’avez aucune idée de son origine, du nombre de pages concernées et de la durée depuis laquelle il est présent sur votre site.
• Il arrive que ce système d’alerting proposé par les outils d’analytics ne soit pas configuré correctement ou que les dégradations soient trop insidieuses pour faire l’objet d’une alerte.

Un process de recette manuelle

C’est incontestablement la méthode que nous rencontrons le plus auprès de nos clients: la mise en place d’un process de recette de votre tracking analytics de façon manuelle.

Prenons un cas commun, le déploiement d’une nouvelle fonctionnalité sur le site internet. En premier lieu, vous allez définir les KPI à suivre pour mesurer l’efficacité de cette feature avant de définir le tracking adéquat : l’utilisation de la dimension personnalisée cd X, la mise en place d’une nouvelle cd Y qui va récupérer la donnée Z sur les pages de type T etc. Puis s’en suit la mise à jour du plan de marquage et l’implémentation du tracking. Soit vous êtes autonome et faites directement les modifications dans votre TMS, soit vous êtes dépendants de votre IT. Dans le dernier cas, on constate très fréquemment l’utilisation d’outils de gestion de projet comme Jira, Trello, Shortcut … pour formuler et suivre les demandes d’implémentation. Les réjouissances commencent une fois le tracking analytics mis à jour en environnement de test : la recette !

Vous allez prendre la liste des éléments à recetter avant d’ouvrir une console dans votre navigateur. Si vous souhaitez des tips pour la recette manuelle -comme la mise en place d’un cahier de recette- nous vous conseillons l’intervention de notre partenaire meet your data “Les best practices pour recetter efficacement votre data” dans notre livre blanc “Mission Data Quality”. 

Reprenons, vous allez ensuite lancer un outil de debug et reproduire les différentes actions vous permettant de confirmer le bon déclenchement de vos hits, valider le recours aux bonne dimensions personnalisées de votre datalayer etc. 

Les outils les plus fréquemment utilisés sont : 

• Data Slayer pour vérifier que le datalayer contient les bonnes données
• Omnibug pour s’assurer que les tags se déclenchent bien
• Le plugin chrome Google Analytics Debugger pour vérifier le comportement des tags Google 

Pour plus d’infos sur les différentes méthodes pour débugger votre tracking analytics, nous vous conseillons ce guide de Simo Avaha “Debug guide for web analytics and Tag Management”
On retrouve ce process de recette manuelle dans 2 contextes : 

– De façon ponctuelle : le tracking est déployé et recetté lors de la création de la feature et ne sera plus vérifié par la suite.

 – De manière régulière : un temps hebdomadaire ou mensuel est alloué aux équipes pour faire une recette plus ou moins aléatoire des parcours stratégiques.

Les avantages de la recette manuelle du tracking: 

• Qu’ils concernent la vérification du Tag Management à proprement parler (outil de debug) ou la gestion de projet (système de ticketing), les logiciels utilisés pour une recette manuelle du tracking sont nombreux sur le marché et bien souvent gratuits. De plus, ils sont faciles à prendre en main et ne nécessitent aucune configuration. 
• Cette méthode peut s’avérer efficace pour un périmètre de vérification très restreint (quelques pages, un parcours stratégique …)

Les inconvénients de la recette manuelle:

• Ce process n’est pas tenable sur un volume important de pages ou de variables de datalayer. Cela est trop long et trop chronophage. Et pour cause, la réalité du terrain nous montre que plus de 75% de nos clients ne sont pas à même de faire une recette complète avant chaque mise en production mais uniquement en cas de régression du tracking constatée a posteriori.
• Ce qui nous amène au point suivant. Seules les pages concernées par une mise à jour sont recettées lors d’une recette manuelle. Pour autant, les effets de bord sont fréquents, ces fameuses modifications du tracking sur une fonctionnalité A qui ont des répercussions sur la fonctionnalité B sans raison apparente. C’est à ce moment que survient le risque d’exploiter des données erronées. 
• La réelle force des web analysts n’est pas exploitée. Leur mission est de mettre en place un tracking pertinent et de produire des web analyses pour permettre aux différentes équipes (Feature team, e-commerce, marketing, médias …) de piloter efficacement leurs actions. Hors tout ce temps consacré à la recette n’est pas mis à profit d’action à plus forte valeur ajoutée comme l’évolution du tracking.

Nous accompagnons une équipe qui a fait le choix d’abandonner la recette manuelle au profit de l’automatisation. Elle a ainsi réduit son temps de recette de 95%.

Le recours aux outils de tests de non-régression

Les outils de tests de non-régressions permettent de faire des vérifications automatisées du périmètre fonctionnel d’un site web ou d’une application mobile par exemple. Mais pas que. Certains tests vont au-delà du périmètre fonctionnel en contrôlant par exemple les temps de chargement d’une page ou la présence d’un tag par exemple. C’est pourquoi, on les rencontre parfois au sein des équipes métiers et IT en ce qui concerne la recette du tracking analytics. 

Dans les faits comment ça marche ? Depuis un outil, vous établissez des scripts qui reproduisent des parcours. Ils sont ensuite exécutés, parfois sur des plages horaires dédiées et à des fréquences bien définies. Ils vont alors confirmer que vos exigences fonctionnelles sont bien respectées. Dans le cas contraire, certains outils disposent d’un système d’alerting permettant de vous informer.

Et en termes de process ?

L’équipe métier définit ses exigences fonctionnelles avant de les transmettre à l’équipe  IT voire à l’équipe QA s’il y en a une. Cette dernière a alors la charge de concevoir les tests de non régression nécessaires, de les automatiser puis de les lancer. A la fin de cela, un rapport d’exécution est bien souvent restitué. Il permet alors de donner un Go /No pour le déploiement en environnement de production. 

Sur le marché des outils de tests de non-régressions, on trouve notamment : Cerberus testing, Testsigma, Appsurify,

Les avantages:

• Les outils de tests de non régression sont faciles à prendre en main par les équipes IT et les tests automatisés peuvent rapidement être déployés. 
• Il est possible de gagner du temps en s’appuyant sur les tests fonctionnels de l’IT. Il suffit alors de les compléter avec des points de contrôles supplémentaires et relatifs au datalayer voire au tag analytics.

Les inconvénients: 

• Les outils de TNR fonctionnent sur la base de scripts qui testent des parcours. Il n’est donc pas possible de contrôler l’entièreté des fiches produits par le biais d’un crawl. Du coup, dans le cas d’un site e-commerce par exemple, il faudrait prévoir autant de tests que d’articles proposés.
• L’objectif premier de ce type d’outil est de faire des tests fonctionnels. Les possibilités de contrôles sont alors limitées au niveau des JS, de la validation de la présence des dimensions personnalisées ou encore des ressources des pages par exemple.
• Tous les outils de tests de non régressions ne permettent pas de mettre en place des tests réguliers et donc d’être alertés en cas d’anomalie. 
• Ils ne donnent pas la possibilité de suivre des KPI permettant de juger du niveau de qualité des données. On ne peut pas leur reprocher, ce n’est pas leur vocation première.
• Au-delà de la simple exploitation d’un logiciel de test de non-régression, on retrouve également des contraintes en termes d’agilité. En effet, ces outils sont souvent sous la coupe de l’IT, créant une dépendance du métier lorsque les tests doivent être créés ou évoluer.
• Sur le plan budgétaire, un coût d’infrastructure technique est à prévoir pour le lancement des tests, le stockage des données, les tests sur différentes navigations etc. Sans compter le coût lié au temps de création et de maintenance par les équipes.

Le développement de solutions internes 

Il n’est pas rare de voir naître en interne la volonté de développer un outil home made pour éviter de faire appel à un prestataire externe. Si cette alternative semble avantageuse notamment sur le plan budgétaire, elle montre toutefois certaines limites:

Les avantages :

• Ces outils sont développés sur mesure pour répondre à un besoin spécifique des équipes qui ne peut potentiellement pas être assouvi par un autre outil du fait des spécificités ou contraintes propres à l’entreprise. 
• Puisque ces outils sont développés par l’entreprise, ils sont supposés s’intégrer parfaitement dans son organisation.
• Ils permettent une certaine maîtrise budgétaire. Il n’est pas nécessaire de s’équiper et de payer pour un outil.

Les inconvénients: 

• Ce sont des outils qui naissent bien souvent à la suite d’une initiative personnelle, c’est-à-dire par un collaborateur qui décide de porter le projet. Le revers de la médaille est qu’en cas de changement de mission ou de départ, il y a des risques de déperdition de l’information. Dans le meilleur des cas, il faudra trouver et former un nouveau collaborateur sur le projet. Dans le pire des cas, celui-ci sera abandonné.
• En cas d’évolution, la mobilisation de l’IT est requise. Tout comme les outils de TNR, une dépendance du métier est constatée. De plus, il y a fort à parier que la mise à jour de ce type d’outil ne fera pas partie des priorités de l’équipe informatique. 
• Il leur est d’ailleurs impossible d’allouer le temps nécessaire en termes de R&D comme le ferait un éditeur. Partant de ce principe, il faut s’attendre à ce que les développements restent limités. 
• Il n’est pas rare que ce type d’outil soit à un moment donné détourné de sa fonction première pour répondre à un autre besoin. On peut vite arriver à une usine à gaz qui n’est plus exploitable.
• Aussi, ces solutions “maison” ne permettent pas de bénéficier de l’accompagnement de l’éditeur et de son expertise du sujet.
• Le développement de solutions internes demande du temps pour arriver à un outil exploitable contrairement à un produit d’éditeur qui se déploie très rapidement.
• Enfin, la confiance dans les outils internes reste relative. Est-ce que le problème constaté est avéré ou est-ce un dysfonctionnement de l’outil ? Le temps d’investigation peut être important et aboutir à une perte de productivité. 

Comment entreprendre efficacement une recette de votre tracking analytics ?

Bien que les solutions évoquées ci-dessous présentent quelques avantages, elles restent toutefois artisanales pour contrôler efficacement votre tracking. Par contrôle efficace il faut comprendre: à chaque évolution du tracking et/ou en amont de chaque mise en production, sur l’ensemble des pages du site, pour l’intégralité des tags et variables de datalayer.

C’est en ce sens que notre équipe a développé seenaptic, pour permettre un contrôle automatisé de votre plan de taggage. Vous programmez des tests récurrents, sur vos parcours utilisateurs ou sur toutes les pages de vos sites ou applications mobiles. Vous êtes alertés en cas d’anomalies de régression du tracking ou de détection de tags non prévus dans votre référentiel.

Vous voulez plus d’infos pour savoir comment recetter efficacement et automatiquement votre tracking ? 

Parlons-en 🙂