Article invité proposé par Thomas Hubert

Travaillant dans l’univers des web analytics depuis 5 ans, j’ai eu l’occasion de passer (et faire passer à mes équipes) plusieurs fois le GAIQ, celui-ci ayant une durée de vie de 18 mois après réussite.

Voici quelques bases à connaitre sur le fonctionnement de l’outil, l’utilisation de fonctionnalités avancées.

L’ensemble de cet article est directement lié aux questions dont je me souviens lors de mon dernier passage.

Fonctionnement de l’outil Google Analytics

Google Analytics est un outil utilisant le JavaScript. Cette technologie, dite front-end, est exécutée par le navigateur de l’internaute visitant le site, et non pas par le serveur web. Cela a plusieurs incidences.

Tout d’abord, les utilisateurs désactivant le JavaScript ne seront pas comptabilisés. Ainsi il n’y a pas, de manière native, de reports concernant les crawlers, ceux-ci n’exécutant généralement pas le JavaScript. On peut aussi rater des informations sur visiteurs, notamment ceux qui bloquent les cookies.

Ensuite, puisque les requêtes sont faites par le navigateur vers les serveurs Analytics, une page en cache envoie bien des informations.

Les cookies

Google Analytics actuel (ça va changer avec Universal) utilise, par défaut, 4 cookies, qui, pour rappel, sont de petits fichiers textes enregistrés sur le device du visiteur :

• Utm_a pour la visite, durée de vie de 2 ans, modifiable avec la fonction _setVisitorCookieTimeout()
• Utm_b pour la session, durée de vie de 30 minutes après inactivité, modifiable avec la fonction _setSessionCookieTimeout()
• Utm_c aussi utilisé par la session et qui ne contient en général que le hash du domaine. C’est un cookie temporaire, supprimé lorsque le navigateur est fermé.
• Utm_z qui contient la source de visite, par défaut sur 6 mois, modifiable avec la fonction _setCampaignCookieTimeOut()

L’utm_z est d’ailleurs intéressant. En effet, le fait que la source ait une durée de vie de 6 mois ne veut pas dire qu’une première source va rester la même pendant 6 mois quel que soit l’endroit par lequel revient un visiteur.

Celui-ci est en effet réactualisé à chaque visite sauf si c’est du direct. En effet, lors d’une deuxième (ou plus) visite en direct, Google check quelle était la source précédente via ce cookie. S’il y en a une dans les 6 mois précédente, qui n’est pas du direct, alors Google ne met pas à jour l’utm_z et considère que le visiteur vient de la source précédente.

Ce modèle, utilisé aussi par l’attribution, est celui dit du last-action non-direct. Il se justifie par le fait qu’une personne ne revient en direct que grâce à la source précédente.

Au passage, les cookies analytics par défaut sont des first party, la seule exception étant ceux des listes de remarketing.

Un cookie first party est implémenté par le site que l’on visite, tandis qu’un cookie third-party est implémenté par un autre.

Les campagnes non Adwords

En parlant d’utm, l’ensemble des campagnes non Adwords doivent être trackées par un ajout de paramètres dans les URLs de destination. Il y a 5 paramètres en tout, dont 3 obligatoires :

• utm_source
• utm_medium
• utm_campaign
• + factulatifs utm_content, utilisé pour différencier des annonces et utm_keyword. Pour cela, Google met à notre disposition un outil, l’URL builder, que l’on peut trouver dans la section d’aide.

Si je dis campagne non Adwords, c’est tout simplement car la meilleur façon de s’assurer d’un bon tracking Adwords est d’activer l’auto-tagging.

Celui-ci nous donne au passage plus d’informations que le tracking manuel.

Quelques méthodes de tracking avancé.

Tout d’abord, deux méthodes à connaître quasi par cœur, puisqu’elles vont revenir un régulièrement.

TrackEvent

• _trackEvent qui sert, vous vous en doutez, à traquer un événement tel qu’un téléchargement de fichier pdf, un clic sur un bouton spécifique, un lien externe etc …..

Le format des _trackEvent est le suivant:

• trackEvent(category, action, opt_label, opt_value, opt_noninteraction)

Vous devez remplir au minimum la catégorie de l’événement et l’action de celui-ci.

Passons au concret, si vous souhaitez traquer les clics sur un lien externe, votre format de lien va devenir le suivant :

• <a href=”/www.google.com” onClick=”_gaq.push([‘_trackEvent’, ‘LienExterne’, ‘Clic’, ‘$NomduLien’]);”> Google </a>

Ce code est assez simple à comprendre je pense, à chaque fois qu’une personne cliquera sur le lien Google de votre site, un événement onClick déclenche le fameux _trackEvent. Celui-ci a pour Category ‘LienExterne’, pour Action ‘Clic et pour Label Optionnel ‘le nom du lien’

Une façon plus intelligente, à mon sens, de déclencher un trackEvent est de passer par un listener jQuery. Ce listener devra écouter les clicks sur la page et déclencher un trackEvent si nécessaire.

Ainsi dans Analytics, vous n’aurez plus qu’à vous rendre dans Contenu / Evénements / Vue d’ensemble et vous pourrez voir tous les gens qui ont actionné cet event et quel a été leur parcours avant.

En effet, lorsque l’on segmente des données sur Analytics par des segments avancés, il agrège l’ensemble des sessions qui, au moins une fois pendant cette session, correspondent au critère de segmentation

TrackPageview

• _trackPageview qui sert à faire remonter des stats de pages sans que l’URL change, donc très utile pour le flash et l’ajax

• Le format des _trackPageview est le suivant: _trackPageview(opt_pageURL)

Même si vous ne vous en êtes jamais servis, vous connaissez _trackPageview, il s’agit en effet de la 3ème ligne du tag de base Analytics. Tout ce qu’il faut faire est de le remplir quand nécessaire, c’est à dire quand Google n’est pas capable de voir par lui-même que la page est différente … ce qui est le cas d’une page rechargée en Ajax.

Imaginez que vous ayez un formulaire en 3 étapes et que chaque étape est appelée en Ajax. L’URL ne changera pas, pourtant vous souhaiteriez tracker chacune de ces étapes une par une et même ajouter un tunnel de conversion…

Et bien tout ce que vous avez à faire est d’appeler la fonction _trackPageview dans le code rafraichit en Ajax. par exemple: _gaq.push([‘trackPageview’,’/formulaire/etape1′]); Vos pages Ajax seront alors traquées comme des pages normales et apparaitront sous Analytics dans le même rapport que les pages normales

Le tracking du flash

Pour traquer du flash, il faut que votre flasheur intègre une librairie Analytics dans le flash, c’est assez simple pour n’importe quel flasheur, li trouvera tout le nécessaire ici.

Ensuite vous devez faire un plan de taggage afin de lui demander d’implémenter des trackEvent sur chaque bouton de votre fichier (si vous voulez le faire bien) et des trackPageview sur chaque “page” de votre flash.

La principale difficulté côté plan de taggage réside dans l’organisation des trackEvent. N’oubliez pas que les noms que vous donnez (category, action, libelle) seront ceux que vous retrouverez dans l’interface. Donc si vous avez plusieurs boutons du même type, donnez-leur la même catégorie par exemple

Evidemment, comme on ne peut pas voir le code source pour un fichier flash, on va passer par une console de développement. Allez sur votre site flash et ouvrez la console de dev (shift+maj+I sous Chrome) et allez sur l’onglet Network

Maintenant cliquez n’ importe où sur votre flash, vous voyez alors que pas mal de fichiers apparaissent dans Network. Cherchez ceux nommés _utm.gif et ouvrez les. Si c’est le fichier trackPageview vous verrez dans les Query String Parameters le paramètre utmp (comme page), il s’agit de la page virtuelle qui est envoyée à Google. Vérifiez alors qu’elle correspond bien à celle que vous aviez demandée dans le plan de taggage.

Maintenant effacez le tout (bouton situé en bas) et cliquez sur un bouton censé déclencher un événement, et chercher le nouveau fichier _utm.gif. Vous verrez alors un paramètre utme (comme event) avec, normalement, les infos que vous aviez demandés dans le plan … voilà vous n’avez plus qu’à tout vérifier. Oui, c’est bien un fichier gif que l’on cherche, analytics utilisant la méthode du pixel de tracking.

Le tracking de l’ajax

Il est tout simple, je n’ai rien besoin de vous réexpliquer normalement. Tout ce que vous avez à faire est d’ajouter un trackPageview dans la portion de code de chaque page appelée en Ajax, ainsi vous pourrez les traquer comme des pages normales

Le tracking de l’e-commerce:

Tout simple aussi. Tout ce qu’il faut faire est modifier le tag de la page de confirmation du paiement afin qu’il respecte le format donné par Google. 3 méthodes à ajouter dans le code de tracking:

• _addItem (orderId, sku, name, category, price, quantity) qui sert ajouter des informations sur le produit acheté
• _addTrans (orderId, affiliation optionnel, total, tax optionnel, shipping optionnel, city optionnel, state optionnel, country optionnel) qui sert ajouter des informations sur la transaction elle-même
• _trackTrans() qui envoie les infos à Google

Les infos de ces 3 méthodes doivent évidemment être des variables. En général c’est assez simple à récupérer, par exemple, elles viennent d’un formulaire rempli sur la page d’avant, vous pouvez les faire passer par des variables aussi voire par cookies, les solutions ne manquent pas.

La segmentation personnalisée:

L’utilité est donc bien évidemment de créer des segments. Vous pourrez traquer les différences de comportement d’un visiteur simple et d’un client et les croiser avec des données sociaux-démographiques (âge, genre …)

• 3 types de segments sous Analytics: Visiteur / Session / Page

Un segment visiteur enverra le cookie utmv, qui a une durée de 2 ans par défaut (q), c’est ce qui est utilisé pour savoir qui est déjà client ou non par exemple.. En effet, tout ce qu’il faut faire est, sur la page de confirmation de paiement de votre site, appeler la méthode.

Concrètement: _gaq.push([‘_setCustomvar, 1, ‘Client’, ‘Yes’, 1]); sur la page de confirmation de paiement servira à faire en sorte que ce visiteur, lorsqu’il reviendra sur votre site sera tracké en tant que client.

Vous pourrez alors aller dans Analytics / Audience / Données démographiques / Variables Personnalisées et voir ce que fait exactement un visiteur qui a déjà acheté quand il revient sur votre site, et comparer aux visiteurs prospects mais non clients

Un segment session dure évidemment le temps d’une session. L’intérêt principal réside dans le fait de tracker les visiteurs logués contre les non logués, mais pas que. Mettez cette méthode sur la page de confirmation de login par exemple et vous pourrez voir les différences entre membres et non membres.

Enfin, un segment page ne dure que le temps de la visite de la page. Il peut être intéressant si votre URL rewriting est mal fait et que vous ne pouvez pas classer vos pages dans Analytics .

Vous créerez alors des groupes de pages avec ce segment mettant un _setCustomvar comportant le même name sur toutes les pages de la catégorie. Il peut aussi servir si vous voulez créer des catégories de pages qui sont différentes de la structure de votre site.

Bon courage pour le GAIQ ! Si vous avez aimez l’article, vous pouvez me suivre sur Twitter ! A bientôt !