Base de connaissances / Knowledge base

Quelques définitions des statistiques de Webalizer, de la manière prévue par l'auteur de Webalizer:


Following are some definitions of the Webalizer statistics, as provided by the author of Webalizer:


Hits (Coups)
N'importe quelle demande faite au serveur qui est notée est considérée un "hit". Les demandes peuvent être pour n'importe quel objet : des pages en HTML, des images graphiques, des dossiers audio, des manuscrits de cgi, etc. Chaque ligne valide dans la notation du serveur est comptée "hit". Ce nombre de "hit" représente le nombre total de demandes qui ont été faites au serveur pendant la période de rapport indiquée.


Files (Dossiers)
Parfois, une demande faite au serveur implique un renvoi par le serveur au client qui a requis la demande, par exemple d'une page HTML ou d'une image graphique. Quand ceci se produit, c'est considéré comme "file" et le décompte "files" est incrémenté. La relation entre les "hits" et "files" peut être considérée en tant que "demandes entrantes" pour les "hits" et "réponses sortantes" pour les "files".


Pages (Pages)
Des pages sont... des pages (si, si... !) D'une façon générale, n'importe quel document HTML, ou quelque chose qui génère un document HTML, est considéré une page. Attention, ceci n'inclut pas les autres éléments compris dans la page, tels que des images graphiques, des éléments audio, etc. Le nombre indiqué représente le nombre de "pages" demandées par les clients. Ce qui constitue réellement une 'page 'peut changer d'un serveur à l'autre. Par défaut, n'importe quel élément avec l'extension "htm", "html", "cgi" (ndt, pour les solutions Zline by SysCo, les fichiers avec extensions standards (phpx, asp, aspx, phtml, pl, etc.) sont traitées comme "page"). Certains considèrent cette statistique comme étant le nombre de "hits" 'purs '... L'auteur anglais n'est pas complètement d'accord avec ce point de vue (ndt nous non plus, mais cela donne déjà une bonne base de référence). Quelques autres programmes (et des personnes) considère ceci en tant que 'pages vues'.


Sites (Emplacements)
Chaque demande faite au serveur vient d'un "site" 'unique, qui peut être mis en référence par un nom ou au plus haut niveau par une adresse IP.
Le nombre de "sites" montre combien de demande d''adresse IP différentes sont parvenues au serveur pendant la période d'analyse.
Ceci n'indique PAS le nombre d'utilsateur unique individuel (les vraies personnes physiques humaines et tout) qui ont visité, ceci est en effet IMPOSSIBLE à déterminer en utilisant uniquement les logs et le protocole HTTP (cependant, ce sera le plus précis que vous ne pourrez jamais obtenir).


Visits (Visites)
Chaque fois qu'une demande est faite au serveur à partir d'une adresse IP donnée (emplacement), l'espace-temps passé depuis la demande précédente de la même adresse IP est calculée (pour autant qu'une demande précédente existe). Si la différence de temps est plus grande qu'une valeur préconfigurée de timout interne au système (ou qu'aucune demande précédente existe), on le considère une "nouvelle visite". Le total est incrémenté pour le décompte de l'emplacement et de l'adresse IP). La valeur d'arrêt de défaut est de 30 minutes. Ainsi, si un utilisateur visite votre emplacement à 13:00 heures, et puis retourne à 15:00 heures, deux visites sontt enregistrée.
Note: dans la tables "Top... sites", le total de visites est groupé et doit être interprété comme "nombre minimium de visites" qui sont venues d'une adresse IP donnée (nom d'hôte).
Note: Les visites se produisent seulement sur des demandes de type "Page", c'est à dire sur n'importe quelle demande dont l'URL est un type de "page" défini. En raison de la limite du protocole de HTTP, des rotations de logs et d'autres facteurs, ce nombre ne devrait pas être pris comme absolument exact mais plutôt comme une valeur "assez proche" de la réalité.


K bytes
La valeur de K bytes (kilo-octets) montre la quantité de données, en KB, qui a été envoyé par le serveur pendant la période de report indiquée. Cette valeur est produite directement à partir du log. En général, ceci devrait être une représentation assez précise de la quantité du trafic sortant du serveur.
Note: Un kilo-octet contient 1024 bytes et non 1000 ;) 


Top Entry and Exit Pages (Top pages d'entrée et de sortie)
Les tables Top pages d'entrée et de sortie donnent une évaluation grossière du dernier URL employs pour entrer dans votre emplacement, et ce quelles ont été les dernières pages ont consultées avant le départ de votre site. En raison de la limite du protocole de HTTP, des rotations de logs et d'autres facteurs, ce nombre ne devrait pas être pris comme absolument exact mais plutôt comme une valeur "assez proche" de la réalité. Ceci donnera une bonne indication de la tendance globale du flux à l'entrée et à la sortie de votre site.




Vous trouvez ci-dessous un commentaire avisé au sujet des statistiques :
source : http://fplanque.net/2003/Articles/stats/stats.html

Le Web et les Statistiques...

Le problème des stats web est extrêmement complexe. Surtout parce que ce qui nous intéresse le plus c'est de savoir:

• combien de personnes sont venues,
• d'où elles sont venues,
• qu'est-ce qu'elles ont regardé,
• pendant combien de temps,
• quand sont elles parties,
• et vers où sont elles parties.

Ceci est en TOTALE CONTRADICTION avec la nature même du web et de son protocole HTTP!

HTTP a été prévu pour demander des simples pages, en dehors de tout contexte. Je demande telle URL, je la reçois, fin de la discussion! En aucune manière il n'a été prévu pour interagir avec un serveur plusieurs fois de suite, en demandant une autre page dans le contexte de la précédente, etc...

En conséquence, les seules statistiques naturellement récupérables depuis un serveur Web sont les suivantes:

• Quelles pages ont été demandées,
• quand,
• à partir de quelle adresse, avec quel browser, etc...

En aucune manière, les stats HTTP brutes ne permettent de savoir qui a demandé quelle page après telle autre...

Bienvenue à bidouilleland!

Evidemment, ceci est le théatre, depuis 1995 au moins, de nombreuses bidouilles, toutes plus tordues les unes que les autres, visant à regrouper ces pages par session et par visiteur unique.

Il serait totalement déraisonnable d'utiliser les adresses IP pour tenter d'identifier un utilisateur unique (ce qui n'empêche pas certains outils de stats de le faire, comme si on étant en 1990...) En effet, les adresses IP sont depuis longtemps devenues non uniques dans le temps (allocation dynamique) ni même à un instant donné (proxies, NAT...). Par exemple, lorsque deux collègues de bureau surfent simultanément sur un même site, la probabilité qu'ils utilisent tous deux la même adresse IP frise les 100% (enfin, j'exagère, mais à peine! :) )

Finalement, le moyen aujourd'hui le plus communément utilisé pour identifier un même utilisateur lorsqu'il demande plusieurs pages consécutives est le cookie... Et ça c'est quand l'utilisateur le veut bien! (Est-il nécessaire de rappeler les incessantes polémiques - largement injustifiées au demeurant - sur les cookies?)

Mais il y a pire: les serveurs web n'attribuent pas automatiquement de cookie aux utilisateurs lorsqu'ils "arrivent" (c'est à dire lorsqu'ils demandent une page pour la première fois). Il est donc nécessaire de plugguer une "saloperie" (pardonnez moi l'expression) quelque part pour poser ce cookie sur tout nouvel utilisateur. Ce cookie (s'il a été accepté par l'utilisateur) est alors renvoyé systématiquement vers le serveur web pour chaque nouvelle page demandée sur ce serveur (et ceci jusqu'à l'expiration du cookie). Il peut ainsi être enregistré avec les stats HTTP ou encore être traité directement par le plugin qui l'a posé au départ.

Tant que le browser de l'utilisateur accepte les cookies, celà fonctionne à peu près bien. Le problème, c'est que tout le monde ne les accepte pas et que de nombreux agents ne les supportent pas (browsers lights sur appareils mobiles, robots d'indexation, aspirateurs, aggrégateurs RSS, etc...)

Une autre solution, plus robuste mais aussi beaucoup plus complexe à mettre en oeuvre, consiste à inclure un identifiant utilisateur dans les URL. C'est ce qu'utilisent les plus gros sites de commerce électronique, de services bancaires etc... Le soucis étant dans ce cas d'éviter que quelqu'un d'autre n'utilise l'URL suite à un bookmark ou à un envoi d'une "adresse intéressante" par mail... Afin de se prémunir contre ça, on en vient à sécuriser le procédé avec un cookie... Par ailleurs, on perd les bénéfices des caches et des proxies... (Ces sujets mériteraient des développements plus poussés dans des articles à part entière...)

Dans tous les cas, il est impossible de savoir que l'utilisateur est parti voir ailleurs, surtout si il se contente tout simplement de fermer son browser. La seule chose qu'on peut détecter c'est que ça fait x minutes que le cookie x n'est pas revenu, donc on considère que l'utilisateur est "parti du site" mais on ne sait pas vraiment quand...

Concrêtement...

Alors, on pourrait rêver à des solutions élégantes telles qu'un protocole HTTP connecté... mais celà nécessite des modifications à l'échelle du web entier, rien que ça...

Avec les moyens du bord d'un site web lambda, les solutions disponibles se répartissent globalement dans les trois catégories suivantes:

• N'utiliser que des pages dynamiques (type PHP, JSP, ASP, CFML etc...), poser des cookies et/ou personnaliser les URLs et traiter les statistiques au fur et à mesure, en contrôlant aussi le Referer pour détecter les clients sans cookies.
• Inclure des "plug-ins" dans les pages web (type eStat, Xiti, etc...) afin d'assurer la pose et l'analyse des cookies.
• Traiter du mieux possible l'analyse des fichiers de log du serveur web avec un logiciel spécialisé (type WebTrends...)

Pages dynamiques

Cette solution est la plus adaptée pour qui veut des statistiques extrêmement précises. Bien développée cette solution permettra d'obtenir virtuellement n'importe quel type de statistique dont on peut rêver... enfin dans les limites des informations disponibles! N'espérez pas obtenir l'âge de l'utilisateur sans qu'il ne vous le donne ;)

Toutefois, développer un site 100% dynamique en PHP, JSP ou autre constitue une charge de travail sans commune mesure avec l'assemblage plus ou moins progressif de simples pages HTML.

Finalement, l'énorme inconvénient de cette solution est qu'elle requiert une puissance de traitement très largement supérieure au niveau du serveur web. Les coûts d'exploitation s'en ressentent très largement. Cette solution se réserve donc plutôt aux sites disposant d'un budget de fonctionnement assez consistant.

Plugs-ins HTML

Cette solution est utilisable à peu de frais. Très peu de frais! C'est probablement même la plus économique puisque des services tels que eStat ou Xiti vous la proposent gratuitement.

Il vous suffit de vous inscrire et de placer le morceau de code HTML fourni dans vos pages web. Ce petit morceau de code sert à la fois à poser le cookie et enregistrer les statistiques comme il sert à afficher une petite icône de publicité pour le service concerné. Si vous ne voulez pas de cette icône sur vos pages vous devez payer... ce qui vous donnera également accès à des statistiques plus poussées.

Le petit morceau de code que vous insérez dans vos pages est en fait un morceau de code JavaScript. Celui-ci se charge de récupérer un certain nombre d'informations telles que le Referer, les caractéristiques de l'écran (résolution, couleurs...) et de les envoyer au service de stats. En retour le service de stats renvoie l'icône de pub (ou un simple pixel dans la version payante) et pose le cookie si nécessaire. Au passage la consultation de la page en cours est enregistrée et les statistiques sont consultables sur le site du service.

Toutefois, au delà de l'icône que vous pouvez faire disparaitre en utilisant la version payante,les inconvénients de ce type de solution sont nombreux:

• Seules les pages dans lesquelles vous avez incorporé le code sont logguées. Vous ne pouvez donc pas suivre l'audience d'une image, d'un fichier ZIP, d'une animation Flash ou encore d'un feed RSS.
• Si le browser n'exécute pas le Javascript (soit parce qu'il ne sait pas le faire - browser light - ou parce que l'utilisateur l'a désactivé, le système ne fonctionne pas, ou bien a moitié: tag noscript avec référencement direct de l'image sans Referer ni caractéristiques écran...)
• Le code Xiti ne fonctionne pas dans Mozilla (et donc pas non plus dans Netscape...).
• Si le browser ne charge pas les images (soit par incapacité - browser texte - soit par choix utilisateur), le service de stats ne fonctionne plus du tout.
• Si l'utilisateur n'attend pas la fin du chargement de la page et que l'image de stats n'a pas encore été demandée au serveur, la page n'est pas comptabilisée.
• Pratiquement aucun robot d'indexation ne va charger les images, leurs requêtes resteront donc également invisibles.
• Finalement, certains logiciels servant à bloquer les publicités indésirables, bloquent également les images de stats et donc les stats sur les utilisateurs concernés!

Analyse des fichiers de logs

Cette solution nécessite plusieurs choses:

• Avoir accès aux fichiers de log (tous les hébergeur ne les fournissent pas) et idéalement à des logs assez exhaustifs!
• Acquérir un logiciel d'analyse (type Webtrends)
• Idéalement: pouvoir installer le plug-in serveur sur le serveur web afin que celui-ci pose automatiquement un cookie chez les utilisateurs. Les hébergeurs mutualisés ne vous permettront pas une telle manipulation. Ceci nécessite donc un serveur dédié. Si vous ne pouvez pas installer ce plug-in, vous vous retrouvez dans la situation la plus basique, décrite au début de cet article: vous n'aurez pas de statistiques fiables sur les sessions et les visiteurs uniques.

Cette solution est la plus légère en termes de charge au niveau du serveur et par là aussi la plus élégante. C'est un bon compromis à partir du moment où vous disposez d'un serveur dédié et d'un bon logiciel d'analyse (WebTrends est très limité!)

Il n'y a donc pas de bonne solution en terme de statistiques web. Juste une "moins pire" à choisir en fonction de votre situation...

-François PLANQUE
Avril 2003