Toutes nos stats seraient-elle fausses ?

En fouillant dans les stats, les logs serveur et autres, Laetitia Maraninchi, notre high level SEO girl, constate que nous recevons des visites depuis plusieurs sources de trafic, sur des pages qui ne devraient pas en recevoir. Notamment en SEO. En l’occurrence, des pages interdites à l’indexation.

Perturbés par ce phénomène, nous sommes allé regarder un peu plus loin dans les logs quel était le cheminement de l’utilisateur de son arrivée sur le site jusqu’à sa sortie, pour essayer de comprendre a quel moment ce dernier arrivait sur une page interdite et pourquoi.

Voici un extrait du log en question : (Les url’s et IP sont masquées, vous imaginez bien pourquoi).

 xxx.xxx.xxx.xxx - - [04/Nov/2014:15:16:45 +0100] "GET http://www.site-exemple.com/c/femme-pret-a-porter-vestes+et+manteaux HTTP/1.1" 200 36370 "http://www.google.fr/search?client=safari&rls=en&q=manteau+d'hiver&ie=UTF-8&oe=UTF-8&gws_rd=cr&ei=Dt9YVNXtG8qv7Aau7IGAAw" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/534.57.2 (KHTML, like Gecko) Version/5.1.7 Safari/534.57.2" miss
[...]
xxx.xxx.xxx.xxx - - [04/Nov/2014:15:17:00 +0100] "GET http://www.site-exemple.com/c/femme-pret-a-porter-vestes+et+manteaux/f/manteaux/fc/noir?_=1415110605334 HTTP/1.1" 200 26729 "http://www.site-exemple.com/c/femme-pret-a-porter-vestes+et+manteaux/f/manteaux" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/534.57.2 (KHTML, like Gecko) Version/5.1.7 Safari/534.57.2" miss
xxx.xxx.xxx.xxx - - [04/Nov/2014:15:18:30 +0100] "GET http://www.site-exemple.com/p/+manteau+mi-long+en+laine-avant+premiere/16918690/320 HTTP/1.1" 200 10922 "http://www.site-exemple.com/c/femme-pret-a-porter-vestes+et+manteaux/f/manteaux/fc/noir/fv/s/pr:80-150" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/534.57.2 (KHTML, like Gecko) Version/5.1.7 Safari/534.57.2" miss
xxx.xxx.xxx.xxx - - [04/Nov/2014:15:19:07 +0100] "GET http://www.site-exemple.com/c/femme-pret-a-porter-vestes+et+manteaux/f/manteaux/fc/noir/fv/s/pr:80-150 HTTP/1.1" 200 23674 "http://www.google.fr/search?client=safari&rls=en&q=manteau+d'hiver&ie=UTF-8&oe=UTF-8&gws_rd=cr&ei=Dt9YVNXtG8qv7Aau7IGAAw" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/534.57.2 (KHTML, like Gecko) Version/5.1.7 Safari/534.57.2" miss

Que voit-on avec ces logs :

  • L’utilisateur arrive sur le site depuis Google, avec une requête « Manteau d’hiver » (ou https://www.google.com/ si not provided).
  • Ce dernier parcours quelques pages
  • D’un coup, une page dans sa navigation répond avec la page qui avait initialement généré la visite

Après avoir regardé quelques cas, le schéma était toujours le même : Notre utilisateur revient a une page précédente !

Ni une ni deux, un chrome en navigation privée affiché sur l’écran, nous faisons le test sur plusieurs sites.

  • On tape une requête sur Google
  • On parcours quelques pages
  • On utilise le bouton précédent

Et là, hop ! Le referer redevient le premier qui a apporté la visite sur la page initiale.

En voyant ça, nous nous sommes retrouvé quelque peu désemparés. Une petite voix dans ma tête commençait a résonner : Toutes nos stats sont fausses… Toutes nos stats sont fausses…

Ce comportement, nous l’avons constaté dans les logs, sur Google Analytics et sur d’autres outils analytiques encore.

Ce phénomène touche, au final, l’intégralité des navigateurs.

Conclusion, regardez de près vos statistiques, il y a de fortes chances qu’elles soient fausses.. en partie du moins. Le fait qu’un utilisateur ait ce comportement dans la visite peut éventuellement minimiser le problème. Mais dans notre cas, nous constatons quand même un bon 5% de données de visites fausses liées a ce problème dans l’analytique.

Je vous tiendrais au courant de mes investigations sur les stats et des potentielles pistes de résolution. En attendant, j’ouvre un ticket !

P.S. : Pour la petite explication technique

L’utilisation du bouton back implique le chargement en cache de la page précédente qui a été visitée. De ce fait, le referer envoyé par le navigateur n’est pas la page que l’on vient de consulter, mais la page précédent la page que vous aviez consulté.

Ce phénomène s’aggrave quand une partie de vos pages sont rechargées en Ajax. En effet, si un utilisateur tombe sur une page, et qu’une partie des liens qu’il consulte sont simplement des rechargement ajax de la page, alors, après 4 ou 5 actions, le navigateur de l’utilisateur peut vous renvoyer le referer de la toute première page sur laquelle il est arrivé (ou autre, dépend des cas).

Que faire ?

En réalité, pas grand chose. Je n’ai pas de solution miracle au problème. Tout ce que j’imagine, c’est que plus il y a d’ajax pour la gestion du front et de la navigation utilisateur, plus le phénomène s’aggrave.
Sinon, il faut militer auprès des autorités qui définissent les standards RFC pour que la notion d’history intègre le bouton back / next…

Vous aimerez aussi...