Avant de vous présenter les nouveautés, un petit rappel au sujet des stats et de la façon dont elles sont calculées.
Comme vous le savez, WMaker vous permet d'utiliser plusieurs systèmes pour mesurer l'audience de votre site. Le système interne WM, ou bien des systèmes externes tels que Google Analytics.
Il existe naturellement des écarts entre les résultats donnés par les différents systèmes de mesure. Et c'est normal car les méthodes de calcul ne sont pas les mêmes. Les stats WM sont calculées à partir de l'analyse des logs sur les serveurs. A chaque fois qu'un élément d'une page de votre site est appelé (une image par exemple), nous comptabilisons un "hit", c'est-à-dire une sollicitation du serveur. Toutes les nuits, en fonction des hits enregistrés, un calcul est lancé pour reconstituer le nombre de pages vues, de visiteurs, de visiteurs uniques, etc.
Comme vous le savez, WMaker vous permet d'utiliser plusieurs systèmes pour mesurer l'audience de votre site. Le système interne WM, ou bien des systèmes externes tels que Google Analytics.
Il existe naturellement des écarts entre les résultats donnés par les différents systèmes de mesure. Et c'est normal car les méthodes de calcul ne sont pas les mêmes. Les stats WM sont calculées à partir de l'analyse des logs sur les serveurs. A chaque fois qu'un élément d'une page de votre site est appelé (une image par exemple), nous comptabilisons un "hit", c'est-à-dire une sollicitation du serveur. Toutes les nuits, en fonction des hits enregistrés, un calcul est lancé pour reconstituer le nombre de pages vues, de visiteurs, de visiteurs uniques, etc.
Concernant les systèmes externes comme Google Analytics, la mécanique est différente. Pour que le système fonctionne, il est nécessaire de placer sur toutes les pages du site quelques lignes de code javascript. Ce code est appelé à chaque affichage de page, et l'info est envoyée au service externe qui applique ensuite son mode de calcul.
Pour en savoir plus, je vous renvoie à cette excellente note sur le sujet :
http://www.devonwebdesigners.com/2567/awstats-vs-webalizer-vs-google-analytics/
Pour en savoir plus, je vous renvoie à cette excellente note sur le sujet :
http://www.devonwebdesigners.com/2567/awstats-vs-webalizer-vs-google-analytics/
Google Analytics dans la version mobile
Lorsqu'un visiteur consulte votre site depuis un téléphone, WMaker le renvoie automatiquement vers la version mobile. Aujourd'hui, vous avez la possibilité de comptabiliser dans un outil externe (Google Analytics ou similaire) le trafic de la version mobile.
Pour cela, un nouveau champ fait son apparition dans le back office. Il s'agit du champ "Version mobile" dans la page Statistiques > Google Analytics. Le bout de code que vous allez écrire dans ce champ sera automatiquement ajouté à toutes les pages de la version mobile de votre site.
Plusieurs possibilités s'offrent à vous concernant l'ajout du code de suivi Analytics:
1/ Vous pouvez utiliser le même code que celui utilisé pour le site. L'information sera alors consolidée dans un seul rapport. Vous aurez à créer des rapports personnalisés pour isoler l'info concernant le trafic mobile, en plus des rapport proposés par défaut par Google.
2/ Vous pouvez créer un nouveau profil et ajouter un code de suivi uniquement pour la version mobile. Le trafic de la version mobile sera isolé dans les rapports liés à ce profil.
Pour cela, un nouveau champ fait son apparition dans le back office. Il s'agit du champ "Version mobile" dans la page Statistiques > Google Analytics. Le bout de code que vous allez écrire dans ce champ sera automatiquement ajouté à toutes les pages de la version mobile de votre site.
Plusieurs possibilités s'offrent à vous concernant l'ajout du code de suivi Analytics:
1/ Vous pouvez utiliser le même code que celui utilisé pour le site. L'information sera alors consolidée dans un seul rapport. Vous aurez à créer des rapports personnalisés pour isoler l'info concernant le trafic mobile, en plus des rapport proposés par défaut par Google.
2/ Vous pouvez créer un nouveau profil et ajouter un code de suivi uniquement pour la version mobile. Le trafic de la version mobile sera isolé dans les rapports liés à ce profil.
Disparition du sitemap mobile
WMaker a été un des premiers CMS à proposer une version mobile pour vos sites. Souvenez-vous, c'était en 2006, nous lancions officiellement la version mobile de vos portails et blogs, avec dans le même temps le sitemap mobile. L'iPhone n'existait pas et chez Google, il y avait un index spécifique pour le mobile et pour le web. C'est à dire que lorsque l'on allait sur Google Mobile et sur Google, les résultats de recherche provenaient de 2 index différents.
Désormais, avec l'avènement des smartphones et des tablettes, on peut dire qu'il n'y a maintenant plus qu'un seul index. Lorsque vous allez sur Google depuis votre iPhone, les résultats sont issus du même index que lorsque vous faites une requête depuis un ordinateur. Je vous en ai déjà parlé après avoir participé à la conférence SMX Paris en juin 2011. Pour renvoyer ses résultats, l'algorithme de Google tient compte du terminal depuis lequel est fait la requête. Cela veut dire que la priorité pour vous, c'est que votre version web soit bien référencée car l'utilisateur sera renvoyée automatiquement vers votre version mobile.
Les plus anciens utilisateurs de WM se souviennent surement qu'à une certaine époque, leur version mobile était mieux référencée que leur version web. C'était vraisemblablement au moment de la fusion de l'index mobile avec l'index web. Les utilisateurs impactés étaient ceux qui avaient soumis dans Google Webmaster Tools leur sitemap mobile. Cela n'a plus trop d'intérêt aujourd'hui de soumettre ce sitemap. Aussi, pour vous éviter le perturber l'index de Google avec les pages de votre version mobile, nous ne fournissons plus dans le back office l'url du sitemap mobile.
Désormais, avec l'avènement des smartphones et des tablettes, on peut dire qu'il n'y a maintenant plus qu'un seul index. Lorsque vous allez sur Google depuis votre iPhone, les résultats sont issus du même index que lorsque vous faites une requête depuis un ordinateur. Je vous en ai déjà parlé après avoir participé à la conférence SMX Paris en juin 2011. Pour renvoyer ses résultats, l'algorithme de Google tient compte du terminal depuis lequel est fait la requête. Cela veut dire que la priorité pour vous, c'est que votre version web soit bien référencée car l'utilisateur sera renvoyée automatiquement vers votre version mobile.
Les plus anciens utilisateurs de WM se souviennent surement qu'à une certaine époque, leur version mobile était mieux référencée que leur version web. C'était vraisemblablement au moment de la fusion de l'index mobile avec l'index web. Les utilisateurs impactés étaient ceux qui avaient soumis dans Google Webmaster Tools leur sitemap mobile. Cela n'a plus trop d'intérêt aujourd'hui de soumettre ce sitemap. Aussi, pour vous éviter le perturber l'index de Google avec les pages de votre version mobile, nous ne fournissons plus dans le back office l'url du sitemap mobile.
Code de suivi asynchrone
Lorsque vous ajoutez un code de suivi javascript sur vos pages web, celui-ci discute avec le serveur du service tiers dont il dépend, à chaque fois qu'une page de votre site est appelée.
Historiquement, Google Analytics fournissait un code de suivi dit synchrone. Je simplifie mais retenez que le code synchrone bloquait l'affichage dans le navigateur de toute partie du code source située en dessous de lui, et ce tant qu'il n'obtenait pas une réponse de la part de Google. Les serveurs de Google sont rapides et puissants, mais néanmoins, afin de ne pas ralentir l'affichage de vos pages, Google préconisait de placer le code de suivi synchrone à la fin des pages. C'est cette bonne pratique que nous avons utilisée pendant des années.
Puis, le code de suivi de Google s'est perfectionné. Il est maintenant asynchrone, c'est à dire qu'il communique avec les serveurs de Google une fois que toute la page web est chargée dans le navigateur. La communication entre le code de suivi et les serveurs de Google ne risquent donc plus de perturber l'affichage de vos pages.
La préconisation pour le positionnement d'un code de suivi asynchrone sur une page change elle aussi. Il est recommandé de placer le code asynchrone au début de la page, dans la balise <head>. Cela permet d'obtenir une information plus précise concernant le taux de rebond des pages de votre site.
Historiquement, Google Analytics fournissait un code de suivi dit synchrone. Je simplifie mais retenez que le code synchrone bloquait l'affichage dans le navigateur de toute partie du code source située en dessous de lui, et ce tant qu'il n'obtenait pas une réponse de la part de Google. Les serveurs de Google sont rapides et puissants, mais néanmoins, afin de ne pas ralentir l'affichage de vos pages, Google préconisait de placer le code de suivi synchrone à la fin des pages. C'est cette bonne pratique que nous avons utilisée pendant des années.
Puis, le code de suivi de Google s'est perfectionné. Il est maintenant asynchrone, c'est à dire qu'il communique avec les serveurs de Google une fois que toute la page web est chargée dans le navigateur. La communication entre le code de suivi et les serveurs de Google ne risquent donc plus de perturber l'affichage de vos pages.
La préconisation pour le positionnement d'un code de suivi asynchrone sur une page change elle aussi. Il est recommandé de placer le code asynchrone au début de la page, dans la balise <head>. Cela permet d'obtenir une information plus précise concernant le taux de rebond des pages de votre site.
Le taux de rebond (bounce rate) est une information très intéressante. Elle indique le pourcentage de personnes qui, dès qu'elles arrivent sur une page, la quitte dans les 5 secondes en cliquant sur le bouton retour de leur navigateur. Si le taux de rebond d'une page est élevé (plus de 50%), cela signifie que la page n'est pas pertinente aux yeux de ceux qui y attérissent. A vous de décortiquer le chemin des visiteurs qui rebondissent pour identifier ce qui ne va pas ... et corriger.
Je referme la parenthèse sur le bounce rate pour revenir à la position du code de suivi asynchrone sur la page. Lors de la mise à disposition du code asynchrone par Google, nous avons hésité à le positionner en haut de page. D'une part parce qu'à l'époque, Google mettait à disposition dans Google Analytics à la fois le code synchrone et le code asynchrone. D'autre part parce que la majorité des utilisateurs de WMaker disposaient d'une code synchrone sur leur site.
Par la suite, Google a définitivement abandonné le code synchrone, si bien que lorsque vous générez un code de suivi dans votre interface Google Analytics, vous n'avez pas d'autre choix que d'utiliser un code asynchrone. Comment le reconnaitre ? Il suffit de le regarder et d’identifier l'attribut ga.async = true. Si cette instruction figure dans votre code de suivi, alors c'est un code asynchrone.
Une rapide requête sur nos bases de données nous a indiqué qu'une faible minorité d'utilisateurs disposent encore d'un code synchrone sur leurs pages. La majorité d'entre vous a mis à jour son code de suivi et utilise un code asynchrone. Aussi, désormais le code de suivi Google Analytics est positionné dans la balise <head>
J'invite les irréductibles qui utilisent encore le code synchrone à opter pour le code asynchrone, afin d'éviter tout risque de ralentissement des performances d'affichage de leurs pages.
Je referme la parenthèse sur le bounce rate pour revenir à la position du code de suivi asynchrone sur la page. Lors de la mise à disposition du code asynchrone par Google, nous avons hésité à le positionner en haut de page. D'une part parce qu'à l'époque, Google mettait à disposition dans Google Analytics à la fois le code synchrone et le code asynchrone. D'autre part parce que la majorité des utilisateurs de WMaker disposaient d'une code synchrone sur leur site.
Par la suite, Google a définitivement abandonné le code synchrone, si bien que lorsque vous générez un code de suivi dans votre interface Google Analytics, vous n'avez pas d'autre choix que d'utiliser un code asynchrone. Comment le reconnaitre ? Il suffit de le regarder et d’identifier l'attribut ga.async = true. Si cette instruction figure dans votre code de suivi, alors c'est un code asynchrone.
Une rapide requête sur nos bases de données nous a indiqué qu'une faible minorité d'utilisateurs disposent encore d'un code synchrone sur leurs pages. La majorité d'entre vous a mis à jour son code de suivi et utilise un code asynchrone. Aussi, désormais le code de suivi Google Analytics est positionné dans la balise <head>
J'invite les irréductibles qui utilisent encore le code synchrone à opter pour le code asynchrone, afin d'éviter tout risque de ralentissement des performances d'affichage de leurs pages.