17 août 2017

Forensics en analytics (cybermétrie)

Ça fait longtemps que je n'ai rien publié! Je me dis toujours que je manque de sujet, de temps, que j'ai de la difficulté à bien raconter. On m'a aussi dit que c'est en écrivant que ça devient plus facile. Que la meilleure façon de s'améliorer c'est de pratiquer. C'est donc ainsi que je m'y mets.

Forensics
Le terme Forensics ou Médecine légale en français désigne l'ensemble de tâches servant à déterminer la cause d'un crime. En analytics et en intelligence d'affaires, il arrive parfois (toujours) que les données ne soient pas telles qu'attendues. C'est en analysant qu'on trouve des anomalies. On veut par exemple, trouver les sources d'une variation et on s'aperçoit qu'on n'a plus de données pour une certaine page.


On ne parle pas ici d'une page qui avait 4 visites en 2 semaines et plus aucune durant la période suivante. Une vraie variation.

Ma technique de forensics analytics
J'utilise pour l'explication le cas de figure très réel mentionné plus haut d'une page dont les données arrêtent d'entrer dans Google Analytics. Dans toutes les implémentations de Google Analytics que j'ai fait récemment, j'utilise un framework maison qui me permet plus facilement de créer un guide de tags à implémenter par l'utilisation du dataLayer et de dataLayer.push(). Le click listner, une technique alternative populaire demeure, selon ma faible expérience, bourrée de problèmes techniques qui dépasse ma compréhension de JavaScript.

Partir de la source
Je repars toujours à la source de la création des données un peu comme dans l'adage trouver la "source du problème".

      Visite sur le site > requête à la base de données (via dataLayer + GTM) > traitement (filtres GA)

Il serait aussi possible de faire le chemin inverse, soit de partir des filtres, mais il me semble plus logique de partir du début.

Étape 1: Taper l'URL de la page. 
Utilisez l'icône  de Google Analytics pour vous y rendre directement ou copiez-collez-la. On cherche à reproduire le comportement de l'utilisateur. Notez si la page est redirigée vers une autre URL. Si c'est le cas, assurez-vous qu'il s'agit bien d'une redirection de type 301. C'est le seul type de redirection qui n'entraine pas la perte des paramètres UTM ou gclid (AdWords). Si effectivement, la page est redirigée, validez que la nouvelle page est suivie et repartez votre analyse avec la nouvelle page tout en gardant en tête que l'analyse longitudinale doit être faite en combinant les deux URL.


Étape 2: Code source et DataLayer
La deuxième étape consiste à valider dans le code source que l'objet JavaScript dataLayer est bien renseigné. Dans le framework que j'utilise, l'URL de la page est toujours réécrite. L'objectif est de pouvoir changer quelque chose si le besoin s'en fait sentir plus tard durant l'implémentation ou durant la maintenance.

Il faut donc s'assurer que le dataLayer soit déclaré à la bonne place et avant le premier script de Google Tag Manager. Si les positions sont respectées, les valeurs dans le dataLayer seront pour Google Tag Manager lorsque son script est exécuté après. Dans le cas d'un élément suivi qui est "au clic" ou un autre type d'événement, il faut le retrouver dans le code source ou la console.

Étape 3: Valider la requête au serveur
Si le dataLayer est populeux adéquatement, il faut valider que GTM envoie les données. La façon la plus facile de le faire est d'ouvrir son outil d'analyse de tag préféré (WASP, Fiddler, Http Fox dans Firefox, Google Tag Assistant).
Si le tag est exécuté normalement, on passe à l'étape 4. Sinon, il faut vérifier que les identifiants GTM et GA utilisés sont les bons. L'addon Chrome de Google Tag Assistant est la plus rapide des façons que je connaisse pour faire cette validation.
S'ils sont bons, il faut aller dans GTM et retracer quelle(s) balises est(sont) devraient exécuter le tag.

En cliquant sur "Prévisualiser", on entre en mode de vérification des balises et déclencheurs.
On retourne dans le site et exécute l'action qui devrait être suivie. Dans le cas d'hyperliens, un simple contrôle + clic va ouvrir l'hyperlien dans une nouvelle fenêtre permettant de conserver les traces de l'action. Si l'action, n'a pas entrainé de log dans le sommaire à droite du panneau GTM, c'est qu'il y a un problème avec le tagging (code) ou le listner (GTM).

Dans le panneau GTM au bas de la fenêtre, on clique sur le log représentant l'action devant être suivie dans le sommaire à droite et on clique sur la balise devant envoyer le tag. On défile vers le bas jusqu'à ce qu'on atteigne la partie "Firing trigger". Dans ce bloc, GTM explique pourquoi le tag est parti ou non. Il faut adapter le déclencheur en fonction des informations recueillies.

Étape 4: Filtres Google Analytics
La dernière étape consiste simplement à réviser tous les filtres du profil qui est affecté. Il est à noter que leur ordre peut impacter les données. Ils sont exécutés selon l'ordre affiché dans la section admin de Google Analytics.

Yéééééé!
Vous devriez avoir identifié la source du problème et devriez être mieux orienté pour le corriger ou faire corriger. Si vous avez suivi le chemin et que le problème demeure un mystère, appelez-moi et on pourra réviser le tout ensemble.

En terminant, j'aimerais remercier Arnaud St-Germain pour m'avoir incité à écrire sur le sujet.

Bonne recherche!