Projet Web analytics : les 10 erreurs à éviter pour prendre un bon départ

Le démarrage d’un projet Web Analytics est une phase critique au cours de laquelle il ne faut surtout pas se rater ! Nous vous proposons aujourd’hui une liste (non exhaustive) des points à ne surtout pas négliger au lancement d’un projet digital analytics. Pour l’établir, nous avons interrogé plusieurs de nos consultants experts. A noter, les points #6 et #7 sont des erreurs qui reviennent le plus souvent. Elles doivent donc faire l’objet de toute votre attention…

#1 – Choisir son outil Web Analytics à la légère, sans l’avoir testé

L’outil web analytics ne doit pas être choisi à la légère sans avoir réalisé une étude auparavant. En effet, l’outil doit être sélectionné en fonction des ressources techniques et de la maturité de l’entreprise dans le domaine de la webanalyse. Pour évaluer votre niveau de maturité vous pouvez utiliser le modèle développé par AT Insight : « Modèle de maturité, pourquoi, pour qui, comment ». Inutile de mettre en place un outil très avancé, qui sera complexe à implémenter, si les équipes n’ont pas le temps ou les compétences pour pouvoir l’exploiter. De plus, une mauvaise implémentation, ne permettra pas de tirer profit de l’outil aussi performant soit-il, et le risque est d’obtenir des données qui ne sont pas fiables.  A l’inverse il ne faut pas choisir une solution facile à implémenter mais qui ne répond pas à tous les besoins des utilisateurs finaux. Lors de la sélection de l’outil, il faut prendre en compte les besoins utilisateurs mais aussi d’autres éléments comme la gestion de la propriété des données, le niveau de support et d’accompagnement de vos équipes, la disponibilité des données en temps réel…

Autre point capital : le test. Tous les éditeurs ne vous proposeront pas un test grandeur nature. Soyez vigilants sur le fait que cet essai se déroule dans les conditions du réel, avec un marquage opérationnel et sur une période suffisamment probante.

Retrouvez plus d’informations pour vous aider à choisir votre outil dans notre article « 12 critères pour choisir votre solution web analytics ».

#2 – Ne pas penser « utilisateurs finaux » au moment d’implémenter la solution

Vous pouvez mettre en place la meilleure des solutions avec toutes les analyses, les plus intéressantes soient-elles, si les utilisateurs n’ont pas le temps de les consulter, ou les équipes ne sont pas assez matures pour les exploiter, vous aurez gaspillé votre temps sur l’intégration d’une solution complexe. Ce temps passé sur l’intégration, vos équipes auraient pu le passer sur d’autres urgences. Pire ! Vous avez engagé une agence pour l’intégration qui vous a facturée de nombreux jours de développement. Cela marche également dans l’autre sens, la solution a été mise en place mais les utilisateurs n’ont que la moitié des informations désirées. Effet déceptif assuré, il peut même y avoir une remise en cause de la solution Web Analytics sélectionnée par la direction.

#3 – Vouloir tout mesurer… à tout prix

Cela ne sert à rien de tout mesurer sur le site, et de collecter de la donnée qui ne sera pas analysée. Les outils proposent une multitude d’analyses permettant de tout tracker sur votre site, il est donc tentant de collecter un maximum de données. Prenons un exemple concret avec la solution AT Internet : mettre en place le clickzone sur toutes les pages du site est inutile, par contre il est intéressant de l’implémenter sur certaines pages clés du site que l’on aura déterminées. De même, marquer tous les liens présents sur le site peut s’avérer un travail long et fastidieux alors que les utilisateurs finaux n’auront pas besoin de tous les mesurer. L’implémentation du marquage doit donc bien être en relation avec les besoins exprimés par les utilisateurs finaux.

#4 – Ne pas tenir compte des contraintes de vos équipes techniques

Une étude de besoin utilisateurs n’est pas une liste de souhait au père noël. Aussi intéressants, poussés et avancés que peuvent être vos besoins si les équipes d’intégrations ont des contraintes trop importantes (liés au CMS, à un intranet ou encore à d’autres éléments inhérents à la technologie utilisée sur le site), le marquage ne pourra pas être mis en place. Là encore, un effet déceptif est à craindre, car vous ne répondez pas à l’intégralité des besoins (de la liste de noël :)) utilisateurs.

#5 – Ne pas prendre en compte les spécificités techniques du site

La rédaction du plan de marquage et l’intégration des marqueurs dépend des éléments techniques du site. Posez-vous les questions suivantes : mon site est-il optimisé pour différents devices (desktop, mobile, tablettes… ?) ? Si oui, est-ce un site en responsive design ou est-ce que le site est décliné en plusieurs versions avec des urls bien spécifiques ? La technologie AJAX est-elle utilisée ? Y-a-t ’il des vidéos ? Est-ce que le site est géré via un CMS, ou est-ce que le contenu est généré dynamiquement par ce CMS ?

#6 – Faire l’impasse sur les phases de recette

Un des principaux écueils lors d’un projet Web Analytics est de se contenter de réaliser l’implémentation du plan de marquage et de ne pas programmer du temps pour la recette. Malheureusement si aucune vérification n’est réalisée suite à l’intégration des marqueurs, il y a des fortes chances que les conclusions que vous tirez des données soient complètement erronées, car pas fiables. Au-delà de disposer de temps, il faut disposer des compétences techniques pour effectuer la recette. Vous pouvez si besoin vous faire accompagner pour cette phase. Si des problèmes sont constatés lors d’une première recette, il est bien sur conseillé de corriger ces problèmes et d’effectuer de nouveau une recette pour vérifier que tout est désormais correct et que cela n’a pas engendré de régression sur les autres points.

#7 – Oublier le marquage lors de l’évolution du site

Le projet web analytics ne doit pas s’arrêter lors de la première implémentation de l’outil. Le plan de marquage n’est pas quelque chose de fixe, il doit évoluer dans le temps, en fonction de l’évolution du site. Avec ces changements fonctionnels, ergonomiques, mais aussi techniques, le marquage peut vite devenir obsolète.  Les audits de marquage permettent d’en prendre rapidement conscience, et permettent ainsi de réagir à temps pour continuer à fournir des données de qualité. Ne pas prendre en compte l’analytics lors d’une refonte du site par exemple, s’avère être une grave erreur, car les utilisateurs seront par la suite dans l’incapacité d’évaluer le bénéfice de cette refonte. Il est important de réaliser de nouveau une expression de besoin avec les utilisateurs finaux de la solution et avec les équipes techniques lors d’un changement sur le site, pour adapter le plan de marquage aux nouveaux besoins si nécessaire. Dans l’idéal, un processus doit être définit pour que l’analyste web et l’interlocuteur technique en charge du marquage soient intégrés aux échanges lorsque qu’une évolution du site est envisagée. Pour faciliter ces évolutions de marquage, il est possible d’utiliser des solutions de soft tagging comme Datamanager.

#8 – Ne pas choisir les bons indicateurs clés de performance

Il est nécessaire de définir les KPI en amont du projet web analytics, faute de quoi, l’outil de web analytics ne vous permettra peut-être pas de suivre la performance digitale de votre entreprise. Il faut que ces indicateurs découlent de votre stratégie et soient adaptés à votre secteur d’activité et à votre site. L’analyse de ces indicateurs doit vous permettre de vous situer par rapport à votre objectif et d’évaluer des points d’amélioration. Le choix de ces indicateurs clés conditionnera le plan de marquage, c’est pourquoi il est essentiel de les connaitre avant. Attention trop de KPI tue le KPI ! Avec l’évolution du site et de la stratégie d’entreprise, les KPI peuvent être amenés à changer. Il faut alors définir de nouveaux KPI si nécessaire.

#9 – Ne pas définir les tableaux de bord en amont

Après avoir défini les KPI, il faut penser à la restitution de ces KPI pour vous aider à prendre vos décisions. Il est important de créer un modèle de tableau de bord et de reporting. Le tableau de bord et le reporting n’ont pas la même finalité, le tableau de bord est vraiment un outil de pilotage et d’aide à la décision alors que le reporting est une synthèse de l’activité pour mesurer votre performance au quotidien. Le tableau de bord doit être adapté en fonction du destinataire, et répondre aux questions suivantes : quel est son niveau hiérarchique ?, quelle périodicité d’envoi (quotidien, hebdomadaire, mensuel, trimestriel… ?) ?

Pour plus de conseils sur la création d’un tableau de bord vous pouvez consulter notre article « Pourquoi un vrai tableau de bord ne doit pas être conçu comme une synthèse de votre activité. »

Il est également important d’anticiper la diffusion des informations sur le long terme. Est-ce que tous mes collaborateurs doivent avoir accès aux données dans l’interface de l’outil web analytics ? Est-ce que je souhaite que certains services aient accès seulement à certaines informations ? Ces questions doivent être posées en amont, car les réponses auront un impact sur le plan de marquage et la configuration des droits d’accès dans l’outil.

#10 – Dans le cadre d’un projet web analytics international, oublier la politique de gestion des données

Lors de la mise en place d’un projet web analytics dans un groupe qui détient plusieurs entités distinctes, ou d’un projet pour un site international, Il faut penser à la façon dont on souhaite agréger les données dans l’outil. Cela va dépendre de la gouvernance au sein du groupe. Est-ce qu’une unique entité va gérer l’outil et aura la responsabilité de la diffusion des données au sein de tout le groupe ou est-ce que chaque entité, par exemple dans chaque pays, devra gérer ses propres données de manière indépendante etc. ? Cela aura un impact sur les choix lors de la création du plan de marquage.