J’ai souvent des personnes qui me contactent en me disant :
J’ai des erreurs sur mon tag Google Analytics, spécialement sur le tunnel de conversion et les données e-commerce.
Dans 90% le problème est le même. Dans la majorité des cas, la personne est sous magento…. Alors comme j’ai du scrupule à facturer 1500 euros pour sortir un audit dont je connais déjà l’issue, je vous propose de lire le billet suivant.
L’histoire que je vais vous compter remonte à une époque (pas si lointaine) où Google décida de proposer, en beta, une version asynchrone du tag Google Analytics. Révolution est bonheur dans le milieu du web analytics, il n’était plus indispensable de mettre le tag en fin de page et en outre, l’outil de webanalytics ne pouvait plus bloquer le chargement de la page. Enfin, peu importe que l’appel au ga.js soit en bas de page, cela ne bloque plus les events tracking etc…
Le monde du web a donc collé du tag asynchrone en pagaille pendant quelques semaines sans s’apercevoir que, dans certains cas de figure, cela avait un vrai impact sur les stats. Baisse des ventes, tunnel de conversion incompréhensible etc…
Je me suis aperçu du problème un beau jour de décembre (là c’est de la romance) lorsqu’un client a superposé tag synchrone en haut de page et tag asynchrone en bas de page. Nous nous sommes donc retrouvé dans la situation où le ga.js se trouvait avant la déclaration du _gaq. En clair, on se retrouve avec qq chose qui ressemble à la capture d’écran ci-dessous :
En réalité, le bloc 1 doit se situer sous le bloc 2. Pourquoi? Parce que sinon, il y a une mauvaise mise en cache qui est faite par certaines versions d’Internet Explorer. Cette mise en cache a pour effet de ne pas envoyer les informations à Google à chaque chargement de page. Je vous invite donc à regarder avec attention votre code et à inverser ces deux blocs s’ils sont à l’envers ! Et voilà 1500 euros d’économisé.
Articles pouvant vous interesser:
)
