mai
15

Un plan de taggage web analytics

« Dis-donc « l’analytics », tu peux nous faire un petit plan de taggage pour notre nouvelle section du site ? On t’a budgété une demi journée ça devrait te suffire non ? »

Tous les consultants web analytics en agence ont entendu ce genre de phrase. De nombreux chefs de projets ont appris par coeur ce petit refrain lorsqu’ils ont la responsabilité d’un nouveau site ou d’un nouveau projet :
1 – Tu vendras à ton client un plan de taggage
2 – Tu demanderas à ton consultant web analytics le fameux plan de taggage.
3 – Tu laisseras l’IT se débrouiller avec le livrable.

Tout ceci parait très simple en apparence, jusqu’au jour où un chef de projet junior pose la candide question à son aîné qui le forme : « Mais au fait c’est quoi un plan de taggage? Qu’est qu’on vend à notre client au juste ? ». Et bien pour être honnète j’ai rarement vu un chef de projet expérimenté bien expliquer ce qu’est un plan de taggage (ou plan de marquage).
J’ai du coup posé la question à Google et j’ai trouvé des petites explications très intéressantes mais je voulais ici ajouter quelques précisions et partager un peu mon expérience.

Pourquoi un plan de taggage ?

Souvent la première question que l’on se pose, surtout si l’on a un peu touché au web analytics avec Google Analytics, c’est : « pourquoi est-ce que l’on a besoin d’un plan ? »
Après tout le marqueur est un petit bout de code JavaScript que l’on colle dans une page et a priori on a envie de tracker toutes les pages, donc il suffirait de coller le tout dans une partie commune à toutes les pages, comme le footer, et on aurait pas besoin de s’embéter avec un plan…
Seulement la réalité est légèrement plus complexe si l’on souhaite enregistrer correctement tous les comportements des visiteurs sur son site. En fait il existe un certains nombres de cas pour lesquels le marqueur automatique ne suffit pas ou n’est pas précis.

Pour rappel un marqueur automatique prend en général par défaut l’URL de la page sur laquelle il se trouve.

- Deux pages différentes ont la même URL. Cette situation peut arriver notamment avec les formulaires dont les données sont envoyées par une méthode POST. Le résultat de l’action se trouve à la même URL que le formulaire de départ. Dans l’outil web analytics on ne pourra pas distinguer l’audience arrivant sur le formulaire de celle qui l’a validé.

- L’URL de la page n’est pas facilement déchiffrable. En fait souvent dans une optique d’optimisation du référencement naturel on se retrouve avec des URLs facile à lire pour l’utilisateur comme pour l’analyste mettant le nez dans un outil d’analyse, mais il arrive aussi que certaines pages qui n’ont pas pour vocation d’être indexées dans Google suivent juste la logique technique du framwork ou du CMS qui régit la construction des pages. Dans ce cas, on se retrouve au moment de l’analyse avec des noms de page que l’on ne comprend pas et qu’il faut aller vérifier manuellement.

- La logique de répertoire de l’URL ne correspond pas à la logique hiérarchique du site. Disons que dans le cas de Google Analytics, le séparateur hiérachique de l’URL (le « / ») est transformé naturellement en niveau hiérarchique dans le site par l’application, cependant il arrive fréquemment que cette logique de regroupement ne corresponde pas au regroupement que l’on souhaite appliquer aux visiteurs qui visitent le site. J’ai l’exemple extrême d’un site contenant quelques dizaines de produits avec des URLs du type : monsite.fr/nomduproduit.aspx . Au moment de l’analyse si l’on veut savoir rapidement combien de visiteurs ont vu au moins une page produit avant de mettre un article au panier, il faut passer par de laborieuses manipulations.

- On veut suivre des évènements particuliers qui n’ont pas d’URL propres : validation d’un mini formulaire AJAX, vue d’une vidéo, clic sur un bouton de notation, navigation dans une animation Flash, etc. Il faudra dans ce cas lancer un tag particulier au moment du clic.

- La page, le visiteur ou la visite possède un attribut particulier qui n’est pas enregistré automatiquement par l’outil web analytics et que l’on souhaite suivre.

- Les cannaux d’acquisition de traffic et les campagnes sont particuliers à chaque site et entreprise, il faut donc plannifier et classifier toutes les actions marketing afin qu’elles remontent avec le bon libéllé dans l’outil web analytics.

- La mise en place d’objectifs, d’évènement de succès (ou d’échecs) sont aussi à planifier afin d’avoir un suivi simplifié de la performance.

Pour ces principales raisons dès que l’on a des exigences importantes en terme de mesure il faut confier cette tâche à un professionnel qui saura tirer partie de l’outil choisi.

Comment construit-on un plan de taggage ?

Et bien puisque le plan de taggage découle d’une exigence de mesure, il faut construire au préalable ce que l’on appelle en anglais les « Business Requirements » ce que je traduis maladroitement en français par « spécifications de mesure »… Si quelqu’un a une meilleure suggestion de traduction je suis preneur.
Ces business requirements sont en fait une liste de questions clés auxquelles l’analyste devra répondre a minima. Ces questions sont en général un peu toujours les mêmes et avec l’expérience il devient plus facile de construire les business requirements. Ce document est celui qu’il faut faire valider à son client (interne si chez l’annonceur ou externe si en agence) c’est celui qui délimite le périmètre de la mesure que l’on a défini. Si le client pose par la suite une question qui sort de ce périmètre il faudra dans certains cas affiner le taggage.

Une fois ce document établi, le plan de taggage en lui même n’est qu’une solution technique que le consultant web analytics ou l’expert en implémentation apporte aux questions que se pose le marketing.
Cette solution technique consiste en général en trois étapes assez simples :
- Définir la liste des variables (attributs des visiteurs, visites, pages, évènements) que l’on va utiliser dans les tags, en établissant sa nomenclature.
- Décrire rigoureusement où l’on va placer les différents tags.
- Quel paramétrage particulier on va appliquer dans l’outil de mesure : déclaration de variables personnalisées, ajustement des attributs de ces variables, définition d’objectifs dans l’outil, mise en place des entonnoirs de conversion.

Du coup c’est quoi ce fameux plan de taggage ?

Au final le plan de taggage est (souvent) un document excel dans lequel on retrouvera l’arborescence du site avec les tags à placer en face. Dans une autre partie on trouvera aussi la définition précise des différents tags (marqueurs de page, marqueurs de clics, codes de suivi) afin de documenter pour le développeur qui devra placer les tags sur le site.

On retrouve une petite description dans cet article sous la section « Ca ressemble à quoi un plan de marquage? ».

Et qui doit faire le plan de taggage ?

Il faut bien comprendre que le plan de taggage est la synthèse entre des exigences d’analyse marketing et une réalité technique de mesure sur le site. Il est donc normal que l’on retrouve soit des développeurs, des consultants techniques ou des web analystes faire des plans de taggage dans certaines entreprises.
Le web analyste n’a parfois pas tout le bagage technique pour tirer au mieux parti des possibilités des outils alors que le développeur (ou consultant technique) n’a pas toujours le recul nécessaire des réalités de l’analyse dans l’interface pour prévoir efficacement la finesse du tag à mettre en place.

On voit bien qu’il est important dans tous les cas qu’une personne ayant de l’expérience en analyse participe (ou dirige) l’élaboration des spécifications de mesure et qu’une personne comprennant très bien la technique (et notamment le JavaScript) exécute le plan de taggage. Evidemment mon avis sur la question est qu’il est parfait d’avoir un expert ayant de l’expérience des deux cotés. Il est extrèmement enrichissant d’avoir à la fois l’experience technique pour être un meilleur analyste, et l’expérience de l’analyse pour être un très bon implémenteur. (hou le joli barbarisme…)

Et ensuite on fait quoi avec le plan de taggage ?

Bon c’est là que les ennuis commencent… après le plan vient la mise en place des marqueurs et la phase de recettage. Je ferai certainement un billet à part sur les joies du recettage que j’intitulerai sobrement : « Comment perdre des amis en agence… »

Google+

8 commentaires pour “Un plan de taggage web analytics”

  • Benoit 16 mai 2012 à 7 h 58 min

    AH un nouvel article , cool :)
    Personnellement je fait mes plans de taggage sous powerpoint avec le wireframe ou les templates sur lesquels je rajoute des numéros et dans les commentaires je détaille le code de tracking à installer sur chaque élement + celui de la page si besoin.

  • Julien Coquet 16 mai 2012 à 10 h 36 min

    Bel article pour ton retour, François ;-)

    C’est clair qu’il faut marteler ce message: le marquage est encore qu’on le veuille ou non la pierre angulaire de la performance analytics. Qu’on utilise un tag container, tag manager et autres: même combat!

    Chez Hub’Sales on a les deux approches:
    - un document descriptif du marquage (PPT ou PDF)
    - un doc plus structuré (Excel) contenant une nomenclature exhaustive des éléments de marquage à mettre en place. C’est ce genre de document que nous utilisons avec Hub’Scan pour valider le marquage d’un site par exemple.

    J’espère que ton nouveau job te laissera le temps d’écrire? ;-)

    (concernant le marquage, tu verras, chez VP c’est rigolo :D)

  • JB Gabellieri 16 mai 2012 à 13 h 37 min

    Chouette tu retrouves le temps d’écrire !
    A quand les vidéos ? :-)

  • Florian Giudicelli 16 mai 2012 à 18 h 39 min

    Excellent billet ! Ca fait plaisir de voir de nouveaux articles sur ce blog !

    Pour la traduction de « business équipements », je dirais peut-être « cahier des charges » mais c’est vrai que ça toujours mieux en anglais .

    Au sujet de la recette c’est clair qu’ on ne ne sait pas toujours des amis :)

    J’ai hâte de lire la suite :) !

  • François 17 mai 2012 à 9 h 48 min

    Merci pour vos messages ! Après une longue absence, je vois que le blog est toujours visité.

    @Benoit Je vais essayer d’être plus présent cette année.

    @Julien 2 heures de métro en moins par jour avec des horaires respectant la vie personnelle, j’ai pour le moment plus de temps en effet.

    @JB Tu veux quoi comme vidéo ? :-)

    @Florian Cahier des charges, oui c’est intéressant, mais je trouve que c’est toujours un peu moins spécifique que l’expression en anglais.

  • JB Gabellieri 18 mai 2012 à 13 h 58 min

    Pour les vidéos je vais y réfléchir :)

    Mais pour ce qui est des articles, je veux bien :

    - Est-il possible de concevoir un dashboard qui corresponde à la fois au exigences de simplicité du client et aux souhait d’exhaustivité du web-analyst (en agence), et quelles sont les bast-pratice pour y pervenir ?

    - Quelles sont les conditions pour que l’intégration d’un web analyst chez un pure-player se passe bien, lorsque ce poste était auparavant « négligé » ? ;) Comment débarquer dans un nouvel environnement et poser les bases d’une « stratégie web analytics » ?

    - Avec qui est comment partager ses données en entreprise ? (en direction du management / en faire profiter l’opérationnel). Comment concrètement faire en sorte que l’information fonctionne bien et soit comprise par tout le monde ?

  • Carole Da Silva 18 mai 2012 à 14 h 53 min

    Quel plaisir de te lire à nouveau (non pas 1 fois mais 3 fois en quelques jours !).

    Bien vu pour les précisions que tu apportes sur les objectifs et le contexte qu’il est toujours bon d’évoquer avant d’aborder véritablement la phase de marquage et ses « outils ».
    Au passage, dans la case traduction, je tente un « Expression de besoins de mesures Métier » à rallonge ;-)

    Sinon, tout comme toi, mes plans de marquage sont généralement composés de 2 documents type : un excel, concret via l’arborescence, et un document, qui précise à quoi servent et comment fonctionnent les différents marqueurs.
    J’essaie d’y être le plus exhaustive possible, dans la mesure où ils constituent ensuite ma première base de travail pour les recettes à effectuer, et le pv de recette qui va avec.

    Mes plans de marquage sont aussi accompagnés de longs échanges téléphoniques avec la personne en charge de l’implémentation. Car même avec des documents qui semblent complets, si la personne n’est pas un tant soi peu familière avec du « taggage analytics », ils ne sont pas toujours suffisants …

    Enfin, je suppose que tu développeras ces points prochainement :)

    PS : Et merci pour la mention !

  • Plan de marquage : La clé de voûte de vos analyses web | TAKACLIKE // 3 avril 2013 à 16 h 31 min

    [...]  http://www.blog-webanalytics.fr/pratique/un-plan-de-taggage-web-analytics/ ImprimerFacebookTwitterLinkedInWordPress:J’aime Chargement… [...]

Poster un commentaire