Implémentation Analytics : utiliser un debugger

On l'a déjà dit et redit, en web analytics : la solution technologique de mesure importe peu (tant qu'elle répond à un besoin business, bien entendu).

Quel que soit l'outil cela dit, le déploiement de la solution choisie est entre les mains de votre informatique et/ou de vos prestataires. Il s'agit juste de placer un bout de Javascript dans vos pages Web après tout, n'est-ce pas ? 😉

Ce n'est pas aussi simple que çà en fait puisqu'on se rend compte qu'Hub'Sales est de plus en plus sollicitée justement pour s'assurer que les équipes techniques ont bien fait leur travail d'implémentation, conformément à un plan de marquage - qui répond lui-même à une expression de besoin de mesure formalisée par des indicateurs clé de performance ou KPIs.

Comment s'assurer donc que les données remontent bien dans votre outil de mesure ?

Il existe trois méthodes :

  • l'analyse des données capturées a posteriori dans l'outil
  • l'examen du marquage dans les pages HTML une fois générées
  • l'analyse des informations envoyées à l'outil

Pour le billet d'aujourd'hui nous nous focaliserons sur la 3ème méthode : l'analyse des informations envoyées à l'outil, grâce à l'utilisation d'un debugger.

Pour rappel, un debugger est un outil initialement conçu pour la détection d'erreurs lors de l'exécution de logiciels. Appliqué au langage Javascript, la notion de debugger s'applique à tout outil de capture d'information gérée par un navigateur Web : contenu HTML, images, Javascript, feuilles de style CSS, applications Flash, etc.

Pour commencer, vous aurez besoin d'un de ces outils:

Pour les besoins de ce billet, nous nous concentrerons sur Charles et je tiens à préciser qu'Hub'Sales n'est pas affilié avec ce logiciel ou son éditeur 😉

Fonctionnalités de Charles :

Charles agit comme un intermédiaire (proxy) entre votre connexion Internet, votre système d'exploitation et, plus spécifiquement, des applications telles que vos navigateurs. Il intercepte les requêtes faites aux serveurs Web ainsi que les informations qu'ils vous envoient en réponses à vos requêtes. Dans cette perspective, Charles dépasse le simple debugger Javascript et peut vraiment vous permettre d'analyser le comportement du navigateur.

On peut voir ces informations de façon groupée (par site) ou de manière séquentielle:

Groupe de requêtes pour les requêtes hub-sales.fr

Groupe de requêtes pour les outils Google Analytics et Adobe SiteCatalyst

Séquence de requêtes pour le chargement de http://www.hub-sales.fr

On voit par exemple dans la dernière capture d'écran que l'information du cadre inférieur contient les informations passées à utm.gif, le pixel de tracking de Google Analytics

 

 

 

Filtrage : comme Charles capture une quantité d'information considérable sur le trafic réseau, il devient vite difficile de retrouver l'information qu'on y cherchait. La barre de filtre permet d'isoler certaines requêtes. L'exemple ci dessous isole avec le mot-clé "utm" les requêtes liées à Google Analytics et Website Optimizer:

Cet autre exemple ci-dessous montre qu'une chaîne de filtrage "/b/ss" isole les requêtes faites à Adobe SiteCatalyst :

Quand on examine la requête, on peut voir passer le résultat du marquage : la requête de mesure envoyée chez l'éditeur, avec tous les paramètres associés! Sur des outils à marquage riche comme WebTrends, SiteCatalyst, WebTrekk, ou Yahoo!, on a vraiment besoin de jongler avec une quantité importante de paramètres et donc de mesurer si chacun de ces paramètres sont bien mesurés - et s'ils contiennent la valeur qu'ils sont sensés contenir! Par exemple, un SiteCatalyst peut gérer jusqu'à 150 paramètres par requête de mesure : vous vous doutez bien que la conformité à un plan de marquage est cruciale!

L'avantage de cette fonction de filtrage, par rapport -par exemple- au debugger proposé par un éditeur, c'est qu'elle intercepte toutes les requêtes et donc celles dont vous avez besoin car les rafraîchissements de page et changement d'état des variables sont pris en compte.

Map Local/Remote : on peut faire correspondre un fichier local à une URL distante. C'est particulièrement utile quand on teste une nouvelle version de site en environnement de développement, intégration, pré-production - ou même en audit d'un site en production.

Exemple : je teste un fichier Javascript sur le site d'un client (http://www.monclient.fr/js/s_code.js) et j'ai besoin de tester le comportement de ce script sur un environnement sur lequel je n'ai pas forcément la main. Evidemment, je pourrais copier une version HTML de la page et utiliser des éléments locaux mais je ne vais pas m'amuser à faire çà pour chaque page du site à tester! La fonction Map Local me permet d'utiliser un ou plusieurs fichiers sur mon poste de travail comme s'il s'agissait des fichiers distants.

Pour se servir de Map Local : on définit l'URL du fichier ciblé

puis on choisit un fichier local :

Et le tour est joué! Je peux maintenant faire mes modifications sur mon fichier local, tester différents réglages de marquage et constater le comportement de ce nouveau code sur une page réelle. Vous remarquerez aussi qu'on peut aussi utiliser des repertoires entiers.

Je peux étendre le mécanisme avec la fonction Map Remote qui elle permet de remplacer un fichier distant par... un autre fichier distant ou, comme on l'a vu avec Map Local, remplacer un serveur par un autre.

Cette méthode est particulièrement efficace lors de tests de regression, lors de passages d'un environnement inférieur vers un environnement supérieur, si on suit le schéma classique DEV > INT > PREPROD > PROD. On peut pointer sur une version antérieure ou ultérieure d'un fichier et observer la différence produite.

Historique en mode log

On peut enregistrer l'ensemble des requêtes gérées par Charles dans un fichier log. On peut traiter ce log pour retracer une historique de navigation, ce qui est très efficace pour de la mise en conformité par rapport à un use case, un schéma fonctionnel ou un cahier de test.

En conclusion:

Vous l'aurez compris, ce genre d'outil est très puissant et permet de capturer une quantité d'information considérable sur les métriques envoyées à votre solution de web analytics. Cela dit, son utilisation est restreinte à quelques pages à la fois. On ne peut pas s'en servir de façon automatisée. C'est pourquoi, avec des solutions d'assurance qualité web analytics telles que Hub'Scan, les besoins en utilisation de debuggers tel que Charles ou Firebug vont diminuer mais ne disparaîtront jamais complètement!

Si vous avez besoin d'un tiers de confiance pour établir la qualité des données récoltées par votre solution de web analytics, contactez-nous!

Dans l'intervalle, vos commentaires constructifs sont les bienvenus!

0 réponses

  1. […] Ce billet était mentionné sur Twitter par Éric NIAKISSA ODIMAT, Hub'Sales. Hub'Sales a dit: Blog: Implémentation Analytics : utiliser un debugger http://bit.ly/hY0hIc […]

  2. […] Julien l’écrivait dans un article sur l’utilité d’un debugger HTTP, nous sommes chez Hub’Sales presque tous adeptes de Charles et évidemment […]

  3. […] que les données remontent bien directement dans GA. Notez que vous pouvez également vous aider d’un contrôleur/debugger HTTP (Charles, par exemple, est très simple d’utilisation), afin de contrôler la requête du […]

  4. […] Vous pouvez maintenant consulter les pages sujettes à votre container et vous observerez le déclenchement de vos tags. Utilisez Hub’Scan ou un outil de debug. […]

  5. […] (validé) pour établir un rapport de conformité du marquage. Sur un site de quelques pages HTML, cette vérification peut se faire manuellement. Pour site à gros volume de pages, il faut automatiser. C’est justement dans ce cas que les […]

Ajouter un commentaire