Ensemble des articles pour le mot clé méthodologie web analytics
juin
11

Cas pratique Google Analytics : introduction aux expressions régulières

Les expressions régulières ou expressions rationnelles (ou encore RegExp) sont très utiles avec certains outils web analytics, notamment avec Google Analytics. Leur utilisation et leur compréhension est recommandée voire indispensable pour utiliser des fonctions avancées.

J’ai remarqué que bien souvent, lorsqu’on lit un article sur une astuce Google Analytics impliquant les expressions régulières, leur signification n’est pas ou peu expliquée. Je comprends qu’on ne le fasse pas quand on s’adresse à un public averti mais une petite piqûre de rappel fait toujours du bien.

Introduisons donc les expressions régulières à travers un exemple simple. Le but ici n’est pas d’être exhaustif sur la définition des caractères et des cas d’utilisation. Je cherche simplement à introduire la chose avec quelques explications.

Utilisons la technique du « Pourquoi » enseignée par mon Analytics Jedi et avant de passer à la pratique, posons nous cette question essentielle :

A quoi sert l’utilisation des expressions régulières dans Google Analytics ?

  • Créer des filtres avancés.
  • Améliorer la création de tunnels de conversion et la définition d’objectifs.
  • Créer des filtres spécifiques directement dans les rapports ou lors de la création de segments avancés.
  • Impressionner ses collègues parce que savoir utiliser les expressions régulières, ça fait geek :)

La compréhension par l’exemple : Comment définir plusieurs pages pour une même étape de tunnel de conversion dans Google Analytics ?

Je vais vous parler de tunnel ou entonnoir de conversion Google Analytics. J’invite les néophytes à lire l’aide Google concernant ce point avant de commencer.

Cette question concerne chacune des étapes mais également l’url qui définit l’objectif de conversion.

Le tunnel de conversion que je souhaite créer doit être composé de trois étapes en plus de ma page d’objectif. La troisième étape est un formulaire dont l’url est différent selon l’origine géographique de la visite.

Exemple de tunnel de conversion complexe

Il existe trois versions de cette page mais j’aimerais toutes les inclure dans la même étape pour ne pas créer trois tunnels de conversion et utiliser inutilement plusieurs « slots » d’objectifs.

Tout d’abord, il faut se rendre dans la page de paramètres de l’objectif à créer. Dans la partie détail de l’objectif, le type de correspondance doit être configuré en tant que « Correspondance d’expressions rationnelles ». Cela permet de signifier à l’outil de prendre en compte les expressions régulières lors de l’édition des champs d’objectif et d’étapes.

Configuration d'un entonnoir de conversion Google Analytics - Détail de l'objectif

La valeur du champ d’objectif est l’url complète de la page d’objectif, jusque là tout va bien.

Une fois cela fait, il faut entrer les valeurs dans les champs d’étapes dans la partie « Entonnoir de conversion vers l’objectif » :

Détail des étapes de conversion

Les valeurs de l’étape 1 et 2 sont faciles à trouver, ce sont les urls des pages que j’ai voulu insérer dans l’entonnoir.

Comment faire pour l’étape 3 qui peut être atteinte via trois pages aux urls différentes ?

Je pense que vous l’aurez compris, il suffit d’utiliser une expression régulière. Bien entendu, plusieurs solutions sont possibles, chacun son style. Je propose tout de même trois variantes possibles :

  • La brute

^/categorie/form$|^/categorie/form\-us$|^/categorie/form\-af$

  • La « c’est presque ça mais… »

^/categorie/form$|\-us$|\-af$

  • La variante que je propose

^/categorie/form($|\-us$|\-af$)

Ce qui est bien dans ces trois propositions, c’est qu’on y retrouve les mêmes métacaractères (caractères spéciaux des expressions régulières).

Reprenons les définitions de Google et ajoutons y quelques exemples :

^ : correspond au début du champ

Lorsque l’on met ce métacaractère au début du champ, cela signifie qu’aucun caractère ne peut être mis devant ce que l’expression va définir.

Par exemple :

  • test correspond à : « test », « pretest », « super test », « le test de fou » ou « test de fou »
  • Alors que ^test correspond à : « test », « test de fou »

Associé à d’autres métacaractères, la signification du « ^ » peut légèrement changer. On abordera peut-être ça dans un prochain article.

$ : correspond à la fin du champ

L’explication est similaire à celle du métacaractère précédent mais appliquée à la fin de l’expression. C’est à dire, que dans la correspondance à l’expression régulière, aucun caractère ne peut suivre l’élément ou le groupe d’élément terminé par $.

  • test$ correspond à : « test », « pretest », « super test »

Utilisés dans la même expression régulière, les métacaractères « ^ » et « $ » permettent d’isoler une chaîne de caractère.

  • ^test$ correspond à « test » uniquement

\ : insère un caractère d’échappement avant un métacaractère

Grâce à « \ » on peut transformer un métacaractère en caractère normal.

  • ^test\$$ correspond à « test$ »

() : mémorise le contenu de la parenthèse comme élément

Les parenthèses fonctionnent un peu comme dans une expression mathématique. Elles permettent d’isoler un élément non par rapport à sa correspondance (tel que le permettent « ^ » et « $ » associés) mais par rapport à l’expression régulière.

Elle permettent également la mémorisation de leur contenu dans une variable qui pourra être utilisée dans les filtres avancés de Google Analytics, mais là n’est pas le sujet.

Difficile de faire un exemple simple de leur utilisation sans utiliser un autre opérateur (ce qui est fait juste en dessous).

| : ou

Le métacaractère « | » correspond à l’opérateur « ou ».

  • ^test$|^super test$ correspond à « test » et « super test »
  • (^super |^)test$ correspond également à « test » et « super test »

On a désormais tous les outils nécessaires au déchiffrage des trois variantes d’expressions rationnelles qui apportent une solution à notre problème.

Reprenons avec des explications :

  • La brute

^/categorie/form$|^/categorie/form\-us$|^/categorie/form\-af$

Cette expression répond parfaitement à notre problème. Si on la traduit littéralement, elle donnerait :

J’isole « /categorie/form » ou j’isole « /categorie/form-us » ou j’isole « /categorie/form-af ».

Pourquoi y a-t-il un « \ » devant les « - » ? Parce que « - » est un métacaractère. Je n’ai pas détaillé sa signification puisqu’on ne l’utilise pas dans ces exemples.

  • La « c’est presque ça mais… »

^/categorie/form$|\-us$|\-af$

Cette expression répond également à notre problème, puisque chacune les trois urls en sont une correspondance. Cependant, d’autres urls lui correspondent également, elle n’est pas « propre ». Si on la traduisait littéralement :

J’isole « /categorie/form » ou je capte toute expression finissant par « -us » ou je capte toute expression finissant pas « -af ».

Cela signifie que « /categorie/form », « /categorie/form-us » et « /categorie/form-af » correspondront mais « idheizhozih-us », « 9248qdh qizhd-af » aussi et beaucoup d’autres.

  • La variante que je propose

^/categorie/form($|\-us$|\-af$)

Comme je vous l’ai déjà dit, chacun son style. Je propose cette solution qui est courte et facilement compréhensible.

La traduction littérale :

Je capte une expression commençant par « /categorie/form » et finissant soit par rien, par « -us » ou par « -af ».

Bien entendu, libre à vous de modifier cette solution en modifiant l’expression régulière proposée. Si par exemple, vous souhaitez capter des variables qui sont à la fin de l’url, enlevez les $.

J’espère que cette petite introduction vous a plu ! L’analyse web est un domaine vaste et même si vous n’êtes pas encore un Jedi des expressions régulières, sachez qu’elles peuvent être utiles.

Si mes exemples ne vous plaisent pas, si vous avez des remarques, si vous voyez des anomalies, ou alors si vous avez des questions, commentez cet article ou utilisez le formulaire de contact.

Quelques ressources très utiles pour les RegExp (qui ont également été mes sources) :

Pour aller un peu plus loin, un cas d’utilisation de filtres avancés Google Analytics (il date de 2008 mais peut vous faire comprendre beaucoup de choses).

Google+
mai
14

WA Fail #1 : Un max d’infos sur les visites !

Author Romuald    Category WA Fail     Tags

Vous êtes en train de vous demander ce que signifie ce titre ? Rassurez-vous, nous n’allons pas vous exposer les subtilités de la métrique « visites ». Cet article est un WA Fail ! Le WA Fail est un événement qui exaspère l’analyste web. Il peut prendre la forme d’un mail, d’un bug, d’une discussion, bref, de tout ce qui nous fait rire, nous surprend voire nous fait pleurer.

Le but de ce type d’article n’est pas uniquement de constater et de se moquer. Nous allons essayer de décrypter les causes et les conséquences de ce genre d’événement afin de proposer une méthode permettant de les éviter à l’avenir.

Ce premier WA Fail est un mail envoyé par un collègue. S’il se reconnaît, la suite de l’article lui sera sûrement utile.

« Salut,
J’aurai besoin d’un max d’info sur les visites du site et éventuellement les dépots de dossiers.
En début d’aprem c’est possible ? »

Pourquoi est-ce un Web Analytics Fail ?

Ce mail est la conséquence d’une demande non prévue du client à qui on a laissé croire que les analystes de l’agence peuvent sortir des chiffres à la demande… Je pourrais m’arrêter là mais continuons d’analyser ce WA Fail.

Cette requête est bien trop vaste :

  • « un max d’info sur les visites du site » est une phrase qui n’a pas de sens. Des indicateurs auraient dû être prévus afin de savoir clairement le type de données qui doivent être fournies au client. Qu’est ce qu’une info sur les visites ? Leur provenance ? Leur caractère entrant ? Leurs pages d’arrivée ? Peut-être simplement leur nombre…
  • « éventuellement les dépôts de dossiers ». Pourquoi cet indicateur doit-il être éventuel ? Le site est un site concours sur lequel on doit déposer des dossiers…
  • « En début d’aprem c’est possible ? ». Cette demande était-elle prévue ? validée ? « budgétée » ?

Comment doit réagir l’analyste web dans une telle situation ?

Il ne doit surtout pas s’énerver. Le chef de projet qui a fait cette demande n’est pas forcément fautif, il fait juste partie d’un système dans lequel le web analytics n’est pas bien compris et donc mal intégré.

La cause principale de ce genre de mails impromptus est le manque de méthodologie et de process liés au web analytics dans certaines agences web.

L’analyste web doit dialoguer avec le chef de projet. Il faut cerner et préciser les indicateurs qui pourraient être les plus utiles au client.
Pourquoi a-t-il fait cette demande aujourd’hui ?
Est-ce juste pour savoir si son site marche ?
Ou bien peut-être du « nice to know ». Dans ce cas, pourquoi ne se connecte-t-il pas à son outil de web analyse ?

Passez du temps à éduquer les gens qui vous entourent ! Expliquez leur ! Faites leur comprendre que sans objectifs clairs et que sans indicateurs définis en amont, l’extraction de données brutes est dénuée de sens.

Que doit faire le chef de projet pour éviter cette situation ?

Le chef de projet doit penser à l’analyste et intégrer à son planning les rapports à transmettre au client… S’il ne connaît pas les objectifs du site et donc les indicateurs qui en découlent, ce n’est pas normal.

  • Soit ils n’ont jamais été évoqués en amont, auquel cas, l’analyste doit y réfléchir.

Cela sous-entend une perte de temps non rémunérée. Cette réflexion aurait dû être faite en amont du projet. D’autant plus que seul le client est capable d’énoncer clairement les objectifs business de son site / sa marque.

  • Soit ils existent avec les indicateurs associés mais le chef de projet voire le client lui même n’est pas au courant.

Dans ce cas, il y a un sérieux problème d’intégration de la culture analytics dans le process du conseil client… Un document existe mais personne ne l’a lu ou présenté à l’équipe et au client. C’est malheureusement souvent le cas encore aujourd’hui.

Trop souvent, le consultant Analytics est considéré comme un extracteur de chiffres à la demande. On ne lui donne pas les moyens de prévoir, de réfléchir et de mettre en place une solution automatique pour les rapports.

Je ne dis pas que nous sommes au dessus de ce genre de tâches. Je dis simplement qu’avec une méthodologie bien définie, l’extraction de données peut être simple et automatique.

On ne demande pas à un développeur d’implémenter un slider en javascript sans spécifications fonctionnelles et techniques pour le « début d’aprem ». On ne le fait pas travailler sans que son travail n’ait été planifié, validé et vendu ! L’analogie est peut-être rapide mais pourquoi réagir différemment avec les analystes web ?

La méthode à mettre en place pour transformer ce WA Fail en WA Win

Dans un cadre sain, accompagné de l’équipe et du client, intégrer un consultant analytics en amont d’un projet est important. La méthode suivante est une bonne base pour l’amorçage de la mesure, première étape du fameux cycle de l’analyse web :

  • Ecouter les objectifs business du client
  • Formaliser des objectifs SMART
  • Définir des KPI (indicateurs clés de performance)
  • Définir des indicateurs secondaires à compiler dans un tableau de bord en plus des KPI
  • Planifier des rapports réguliers
  • Configurer des alertes afin d’être informé des variations fortes de certains indicateurs

N’oubliez pas que l’essence du web analytics n’est pas le savoir mais l’action. C’est pourquoi le temps passé sur l’extraction et la compilation de données brutes devrait être moindre par rapport au temps passé à l’analyse et aux recommandations d’optimisation.

La méthode est extrêmement simple et évidente pour les personnes habituées aux articles théoriques du web analytics mais la réalité est bien différente de ce que l’on trouve dans les livres.

N’hésitez pas à nous envoyer vos WA Fail ou à nous faire partager vos expériences via les commentaires. Si certains sortent du lot, nous en ferons des articles ;)

Google+