L'affichage d'un indicateur au sein d'un tableau de bord, d'une interface, ou même d'une base d'information en ligne, a nécessairement été précédé par une phase de collecte de données. Les outils de gestion des balises permettent de simplifier le processus de collecte des données, en déployant au moyen d'une interface unique les codes en charge de la récupération et de la transmission des informations nécessaires au bon fonctionnement de chaque système. Reste qu'en dépit d'une mise en œuvre par un unique outil, via des règles de déclenchement mutualisées, les chiffres disponibles varient systématiquement entre les systèmes externes et internes. Faut-il y voir une fatalité ?
Les causes du problème
La cause première de l'existence d'écarts entre les systèmes externes et ceux internes à une organisation, tient la plupart du temps à l'environnement dans lequel la collecte de données est effectuée. En effet, en dehors des rares cas où l'organisation déploie son propre système de recueil d'informations côté client, la quasi totalité des systèmes internes enregistrant des données fonctionnent côté serveur. A l'inverse, la quasi totalité des outils externes collectant des données fonctionnent côté client.
S'il est possible, côté serveur, de contrôler totalement le processus de collecte, y compris de conditionner l'exécution de certaines tâches impactant l'expérience utilisateur, il n'en va pas de même côté client. La diversité des terminaux utilisés pour se connecter au Web, en terme de puissance de calcul, de navigateur utilisé, sans oublier la version desdits logiciels, leur configuration, l'existence de codes tiers pouvant potentiellement impacter celui en charge de l'enregistrement des informations et enfin l'absence de contrôle sur la qualité et le débit de la connexion utilisée rendent impossible un fonctionnement constant des codes de collecte, y compris sur un même appareil.
Par ailleurs, des écarts peuvent également exister entre deux outils qui auraient récupéré une même information nécessaire à leur bon fonctionnement, tous deux à un instant T, si les calculs et traitements effectués sur ces données brutes devaient varier d'un outil à l'autre.
Si avoir de l'emprise sur la façon dont une même donnée brute est retraitée, d'un outil à l'autre, est inenvisageable, il est en revanche possible d'agir sur les facteurs empêchant la collecte de données côté client.
De possibles remèdes au goût doux-amer
L'un des premiers facteurs explicatifs d'une absence de transmission d'informations est le recours par l'utilisateur à un logiciel bloquant les outils de mesure, tel que U-block origin ou encore Ghostery pour ne citer qu'eux. Le recours à de tels outils étant détectable, il est possible de déployer en réponse des messages invitant les utilisateurs à les désactiver.
Autre élément à prendre en considération : l'emplacement de l'appel au conteneur au sein du code source de la page. Plus l'appel au conteneur de l'outil de gestion des balises sera effectué tardivement, plus la déperdition d'informations sera importante, car les utilisateurs ne resteront pas nécessairement suffisamment longtemps sur la page afin que l'ensemble des données pouvant être collectées puissent être transmises.
Par ailleurs, l'ordre dans lequel les balises sont intégrées au sein du conteneur a également une incidence sur le moment où elles pourront s'exécuter et par extension commencer à collecter des données. Les balises les plus stratégiques doivent impérativement être positionnées le plus en amont possible au sein du conteneur.
La désactivation du JavaScript, sur la navigateur d'un visiteur, empêche purement et simplement toute information d'être transmise si la collecte de données repose sur l'exécution de codes JavaScript. Par conséquent, si le déploiement d'une version noscript de l'outil impacté est impossible, proposer aux utilisateurs ayant désactivé le JavaScript de le réactiver, peut permettre de faire progresser le volume de données collectées.
Enfin, la mise en place d'un système de collecte s'exécutant côté serveur aboutit à contourner l'ensemble des facteurs de blocage précédemment énoncés, bien que le plus souvent la vitesse des cycles de déploiement s'en trouve diminuée et que l'ensemble des outils de collecte ne soient pas pleinement compatibles avec ce mode de paramétrage.
En conclusion
L'écart entre les systèmes externes et internes est principalement lié au fait que ces outils collectent des informations côté client, ce qui les rend sujet à des blocages ou dysfonctionnements. Déporter l'exécution des codes en question côté serveur permet certes de contourner la plupart de ces blocages, mais l'ensemble des systèmes ne sont pas compatibles avec cette méthode de déploiement. Par ailleurs, il existe des paramétrages simples pouvant être mis en œuvre, côté client, afin de faire progresser le volume de données collectées. Recourir à ces optimisations semble donc incontournable.