Flux RSS, pages vues, évènements et mesure

J’utilise Google Feedburner pour gérer les inscriptions à mes flux RSS. Google feedburner automatise le suivi des sources de trafic en provenance de mes flux RSS dans Google Analytics. Une fois qu’il est installé et paramétré, le nombre d’articles qui sont consultés en provenance de cette source de trafic apparaissent sous l’onglet campagnes de Google Analytics.

Le problème est que feedburner n’indique pas la provenance des gens qui s’inscrivent à votre flux RSS ou bien quel est le pourcentage des gens qui cliquent pour s’inscrire à un flux, mais qui décident de laisser tomber à l’étape du choix de l’agrégateur de flux RSS. De telles données pourraient un jour vous intéresser pour mieux comprendre comment optimiser votre site Web. Le but de cette intervention est de déterminer comment mesurer le nombre d’internautes qui cliquent sur le bouton de votre flux RSS sur votre site Web.

Le problème des liens externes

Processus d'inscription à un flux RSS

Le problème principal de cette mesure se pose à l’étape 2 : lorsqu’un visiteur clique sur le bouton d’un flux RSS, il quitte votre site. Dans mon cas, par exemple, l’internaute est redirigé vers http://feeds2.feedburner.com/kinaze. Puisque cette adresse ne comporte pas le code de suivi de Google Analytics, comment faire pour mesurer cette donnée? En cherchant un peu sur le Web, j’ai trouvé 2 réponses à cette question.

_trackPageview et le hack du fichier téléchargé

La première méthode – très populaire – consiste à utiliser le _trackPageview, comme si on téléchargeait un document. Le _trackPageview est une fonction du code de suivi de Google Analytics très utile pour mesurer les évènements qui ne génère pas de pages vues (c’est-à-dire pas de pages avec le code de suivi ga.js qui permet de mesurer ce que font vos visiteurs sur votre site), comme un évènement Flash, un évènement Javascript, un fichier téléchargé, un lien externe, etc. C’est ainsi qu’il faut ajouter un petit code de javascript en plus du lien vers le fil RSS en tant que tel. Dans mon cas, voici le code qui doit être placé sur mon lien :

<a onclick="pageTracker._trackPageview('/feed/articles');" href="http://feeds2.feedburner.com/kinaze">RSS2</a>

Dans cet exemple, /feed/articles est la page imaginaire qui me sert de référence pour mesurer chaque clique sur le lien à mon fil RSS et http://feeds2.feedburner.com/kinaze est l’adresse de mon flux RSS. Il est important de comprendre que cette page imaginaire apparaît maintenant en tant que page vue dans Google Analytics.

Pages vues des inscriptions à un flux RSS

Voici un exemple pratique de l’encodage de ce lien : RSS.

Le délai du clique externe

La deuxième méthode est un peu plus complexe. Elle consiste à insérer un code dans le <head> de votre document afin de créer un léger délai entre le clique sur un lien « externe » et l’apparition de l’objet externe désirée. Ce délai imperceptible permet d’enregistrer un lien externe en tant qu’un évènement dans Google Analytics.

Le code à insérer dans le <head>  est :

function recordOutboundLink(link, category, action) {
try {
pageTracker._trackEvent(category, action);
setTimeout('document.location = "' + link.href + '"', 100);
}catch(err){}
>}

Ensuite, il ne vous reste plus qu’à insérer ce code sur votre lien :

<a onclick="recordOutboundLink(this, 'Outbound Links', 'rss'); return false;" href="http://feeds2.feedburner.com/kinaze">RSS</a>

Dans cet exemple, ‘Outbound Links’ est le nom que j’ai décidé de donner aux liens externes que je mesure sur mon site et ‘rss’ est une sous-catégorie de ‘Outbound Links’. Ce lien externe apparaît maintenant dans les évènements de Google Analytics.

Évènement pour s'inscrire à un flux RSS

Voici un exemple pratique de l’encodage de ce lien : RSS.

Page vue ou évènement?

Les 2 méthodes précédentes fonctionnent. Je préfère cependant la deuxième méthode, car les évènements sont des méthodes qui servent à organiser et à mesurer les interactions avec des objets et ils n’ajoutent pas de pages vues dans les statistiques de consultation d’un site. Il me semble que cet avantage est important, surtout dans les sites dont le clickstream est très élevé. À quoi bon créer des pages virtuelles et faire augmenter le nombre de pages vues, quand ce ne sont pas des pages qui doivent être mesurées, mais bien l’interaction avec celles-ci? D’autant plus qu’il n’y a aucun moyen dans Google Analytics de  séparer les pages virtuelles des pages actuelles. Sur des sites à faible achalandage, la différence est insignifiante, mais sur des sites dont plus de 400 000 pages sont consultées chaque mois, cette faiblesse peut devenir très difficile à gérer.

En fait, plus j’y réfléchis, et plus je me demande quels sont les avantages de mesurer les fichiers téléchargés avec la méthode des pages vues au lieu de la méthode des évènements. Qu’est-ce que vous en pensez?

La photo de Aeon Flux provient du site designersparty.com.

  • http://www.blog-webanalytics.fr Romuald Deloumeaux

    Sympathique la technique du délai du clic externe.

    Je me demandais pourquoi je ne voyais pas les _trackEvent() dans les en-têtes http de certains sites lors des tests sur les liens menant vers l’extérieur. Pourtant les données remontaient dans Google Analytics. Je ferai des essais avec cette méthode.

    Vos articles sont très complets. Merci !

    • http://www.kinaze.org kinaze

      Bonjour Romuald! Merci pour le bon commentaire. Moi aussi je vais prendre un peu plus de temps pour tester tout ça. Les différences entre la consultation d’une page réelle et d’une page virtuelle ne sont pas encore toutes claires pour moi.

      De plus, je pense qu’il serait intéressant de centraliser l’utilisation du _trackEvent() et _trackPageview() avec jQuery pour mieux gérer le « portefeuille digital » des sites comprenant de nombreuses pages. Un bon article là-dessus ici : http://www.carronmedia.com/extend-google-analytics-with-jquery/ .

  • http://juliencoquet.com/ Julien Coquet

    Dans l’absolu, pas de différence flagrante entre l’utilisation d’une page vue virtuelle et d’un évènement

    Le gros avantage de la page vue virtuelle (déclenchée avec _trackPageview) est de pouvoir intégrer ce type de clics comme point de conversion.

    Pour revenir à la question de la rapidité, l’utilisation du code asynchrone aide grandement 😉

  • http://www.kinaze.org kinaze

    Merci Julien pour ce commentaire. C’est vrai que le fait que les évènements ne peuvent pas être utilisés pour mesurer une conversion peut devenir un désavantage. Et que la rapidité du code asynchrone peut être un avantage du point de vue de l’expérience utilisateur et éventuellement du point de vue du SEO. À ce propos, même si la rapidité est un facteur recommandé par Google pour favoriser le SEO, il ne semble pas que ce soit encore vraiment déterminant. Mais bon, c’est toujours bon de se préparer pour le futur…

  • http://www.kinaze.org kinaze

    Merci Julien pour ce commentaire. C’est vrai que le fait que les évènements ne peuvent pas être utilisés pour mesurer une conversion peut devenir un désavantage. Et que la rapidité du code asynchrone des évènements peut être un avantage du point de vue de l’expérience utilisateur et éventuellement du point de vue du SEO. À ce propos, même si la rapidité est un facteur recommandé par Google pour favoriser le SEO, il ne semble pas que ce soit encore vraiment déterminant. Mais bon, c’est toujours bon de se préparer pour le futur…

  • http://www.kinaze.org kinaze

    Nouveau questionnement par rapport à cette méthode de mesure. Pourquoi ne as tout simplement utiliser la méthode utm et créer des liens à l’aide du tool URL builder de Google? (http://www.google.com/support/googleanalytics/bin/answer.py?hl=en&answer=55578) La méthode utm est normalement utilisée pour mesurer la performance des campagnes externes d’un site Web (cpc, bannière, infolettres), mais rien ne nous empêche de l’utiliser pour une campagne interne, c’est-à-dire pour un lien placé directement sur son propre site Web.

    Même si cette méthode pourrait aussi fonctionner, elle comporte un désavantage majeur : si un internaute vient sur votre site en provenance d’un lien externe utm et qu’il clique à nouveau sur un lien interne utm, Google Analytics effacera le premier enregistrement au profit du second. C’est donc dire que l’utilisation de la méthode utm pour taguer les liens internes de votre site Web peut potentiellement cannibaliser les données de suivi de vos campagnes externes. Cannibalized data ain’t good.

  • http://www.kinaze.org kinaze

    Nouveau questionnement par rapport à cette méthode de mesure. Pourquoi ne as tout simplement utiliser la méthode utm et créer des liens à l'aide du tool URL builder de Google? La méthode utm est normalement utilisée pour mesurer la performance des campagnes externes d'un site Web (cpc, bannière, infolettres), mais rien ne nous empêche de l'utiliser pour une campagne interne, c'est-à-dire pour un lien placé directement sur son propre site Web.

    Même si cette méthode pourrait aussi fonctionner, elle comporte un désavantage majeur : si un internaute vient sur votre site en provenance d'un lien externe utm et qu'il clique à nouveau sur un lien interne utm, Google Analytics effacera le premier enregistrement au profit du second. C'est donc dire que l'utilisation de la méthode utm pour taguer les liens internes de votre site Web peut potentiellement cannibaliser les données de suivi de vos campagnes externes. Cannibalized data ain't good.

  • Pingback: En quoi consiste un site Internet | analyse()

  • Pingback: Variables personnalisées et Google Analytics | Pourquoi et comment les créer?()

  • Pingback: Google Analytics : Variables personnalisées _setCustomVar | Optimisation Conversion()