Accueil Recherche | Plan Technique | Liens | Actualités | Formation | Emploi | Forums | Base
logo CERIG NOTE TECHNIQUE cerig.efpg.inpg.fr 
Vous êtes ici : Accueil >Technique > Internet et le web > Mesurer l'audience d'un site web           Révision : 03 mars 2002
Note précédente Liste des notes     Mesurer l'audience d'un site web     Page technique Note suivante
 
Jean-Claude Sohm (CERIG / EFPG)
(22 octobre 2001)
 

La mesure de l'audience des pages d'un site web à partir du fichier journal du serveur, est pratiquée depuis 6 ans environ. La séparation des accès dus aux internautes de ceux dus aux robots pose parfois des problèmes. De plus, la mesure des accès attribués aux internautes est entachée d'une erreur due à la présence de mémoires caches (navigateur, serveur proxy, web-cache). La mesure d'audience à l'aide d'une "image de comptage" (cas particulier de marqueur) donne généralement un résultat plus proche de la réalité. On se sert souvent de l'image monopixel transparente, et on utilise une image distincte pour chaque page HTML du site. La présente note décrit l'introduction de cette nouvelle méthode au CERIG, et discute les résultats obtenus à la lueur du comportement de certains dispositifs (robots, aspirateurs de site, serveurs proxy et DHCP).
 

Introduction

En savoir plus sur la mesure d'audience :

Mesurer l'audience d'une page web consiste à déterminer son taux de consultation par les internautes en fonction du temps. L'application la plus connue consiste à déterminer le niveau de redevance des bannières publicitaires, en concurrence avec la "rémunération au clic". Mais la mesure d'audience sert également de guide aux webmestres pour orienter, modifier et mettre à jour le contenu rédactionnel du site dont ils assurent la gestion.

Chaque requête adressée à un site web donne naissance à un enregistrement dans le fichier journal du serveur (encore appelé fichier log, du nom de son extension, et access log file en anglais). L'analyse de ce fichier permet de mesurer l'audience d'un site pris dans son ensemble, voire même l'audience de chacune des pages qui le composent. Cette technique est pratiquée depuis 1995.

Rappelons que l'on appelle :

    requête (en anglais : hit) la demande d'un fichier (ou "ressource") au serveur web. Ce fichier peut contenir une page HTML, une image, une animation, etc. A chaque requête correspond une ligne dans le fichier journal ;
  accès (en anglais : pageview) la demande d'une page HTML (ou texte, ou PDF) au serveur web. Le nombre d'accès est inférieur au nombre de requêtes, la différence croissant avec le nombre d'images présentes dans chaque page du site.

En général, on ne décompte que les requêtes et/ou les accès effectivement satisfaits (code HTTP inférieur à 400) en éliminant les erreurs dues soit au client (code 4nn), soit au serveur(code 5nn). La variation (en fonction du temps) du nombre des requêtes donne une idée des performances du serveur web ; celle du nombre des accès mesure l'intérêt que les internautes portent aux informations contenues dans le site. 

Une première question naît du fait qu'un serveur web sert deux sortes de clients :

    les robots et les agents, d'une part. Les premiers parcourent le web à des fins d'indexation, les seconds recherchent une information précise. Les robots les plus connus sont ceux des moteurs de recherche, mais il existe également des robots "privés" ;
  les internautes, d'autre part, qui interrogent les sites web directement via leurs navigateurs, ou indirectement via leurs aspirateurs de sites.

On définit :

    le trafic du site comme le nombre total d'accès satisfaits dans un laps de temps donné ;
  l'audience comme le nombre d'accès satisfaits dûs aux internautes seuls, dans un laps de temps donné.

Plusieurs techniques sont utilisables pour séparer les accès dûs aux internautes, de ceux dûs aux robots et aux agents :

    utiliser une liste de robots et d'agents connus pour opérer sur le web. Cette méthode est difficilement praticable, parce que de nouveaux robots et/ou agents font leur apparition tous les jours, ou presque ;
  faire l'hypothèse que seuls les internautes utilisent un navigateur signalé par le code "mozilla" dans le champ "user-agent". Cette méthode donne des résultats erronés, parce que certains robots uilisent le même code, tandis que certains aspirateurs ne l'utilisent pas ;
  utiliser le fait que les robots et les agents requièrent les pages HTML, mais pas les figures ni les animations (on notera que le cas inverse existe, mais qu'il est extrêmement rare).

La technique basée sur cette dernière distinction constitue à notre avis le moins mauvais choix. On la pratique en introduisant le fichier journal dans une base de données, et en utilisant des requêtes spécifiques pour isoler les demandes des internautes de celles des robots. Depuis quelques années, divers auteurs attirent l'attention sur le fait que cette méthode (basée sur les accès) donne des résultats systématiquement inférieurs à la réalité. En effet, la requête d'un internaute peut parfois être satisfaite par une mémoire cache, et non par le serveur web lui-même, et que de ce fait elle ne laisse pas de traces dans le fichier journal. L'erreur qui en résulte a été chiffrée de manière extrêmement variable (entre 0 et 50 %), à partir de simulations plus ou moins représentatives de la réalité. La défiance vis à vis de la mesure d'audience basée sur la simple analyse des fichiers log ne cesse de croître depuis quelques années.

L'introduction, il y a un an, d'un nouveau serveur au CERIG, nous a conduit à repenser la mesure d'audience des pages de notre site. Depuis quelques mois, nous comparons les résultats de mesure d'audience obtenus à l'aide des anciennes procédures (mesure des accès) avec ceux obtenus grâce à la méthode des "images de comptage", dont le principe est connu depuis 1998.
 

Le problème des caches

Lorsqu'un internaute formule une requête ("je veux voir une page web dont voici l'URL"), cette dernière peut être satisfaite par le serveur web concerné ou par un dispositif contenant déjà ladite page dans sa mémoire cache (on dit aussi "son cache"). Un tel dispositif peut être :

    le navigateur lui-même, qui met en cache toutes les informations qu'il reçoit ;
  un serveur proxy, qui relaie les requêtes de navigateurs dépendant de lui (les fournisseurs d'accès utilisent tous un serveur proxy) ;
  un web-cache, dispositif de mémoire cache à grande échelle, placé à des endroits stratégiques du réseau Internet ;
  le serveur web lui-même ;
  et enfin la mémoire cache d'un moteur de recherche, si la page demandée provient d'une requête adressée à ce dernier.

Il est donc possible que la requête de l'internaute soit satisfaite sans que le serveur web en soit averti. La consultation de la page web correspondante n'induira aucune inscription dans le fichier journal. Ce dernier reflète donc la consultation du site web par défaut. Certains auteurs ont publié sur le web des chiffres inquiétants, affirmant que l'erreur correspondante atteindrait facilement 50 %, qu'elle serait principalement due aux serveurs proxy, et qu'elle serait inévitable. Cette dernière affirmation parait erronée.

Avant d'aller plus avant, rappelons qu'un cache présente l'avantage de servir l'information plus rapidement, mais l'inconvénient de servir une information qui n'est peut-être plus à jour. Tout cache doit donc faire l'objet d'un réglage réalisant un compromis entre ces deux aspects. Les caches de certains dispositifs (web-cache, serveur proxy) sont en général configurés de manière complexe ; pour conserver l'information, ils tiennent du nombre de consultations, du temps écoulé entre deux consultations, du taux d'encombrement de la mémoire, etc.

Le cache du navigateur. L'expérience semble indiquer que c'est le cache du navigateur qui joue le rôle principal, et que ce rôle dépend de sa configuration. Prenons l'exemple d'Internet Explorer (version 6). Dans le menu, choisissons "Outils", puis "Options Internet...". La boite de dialogue "Options Internet" s'ouvre. Dans la zone "Fichiers Internet temporaires", appuyons sur le bouton "Paramètres...". La boite de dialogue "Paramètres" s'ouvre à son tour. Elle est représentée sur la figure 1 ci-dessous, dans sa configuration par défaut.


Figure 1 - Réglage du cache du navigateur Internet Explorer 6

Examinons, pour chacun des quatre réglages, ce qui se produit si nous requérons une page web qui se trouve déjà dans le cache du navigateur :

    si nous optons pour le premier réglage ("A chaque visite de la page"), le navigateur adresse une requête conditionnelle au serveur ("l'information a-t-elle changé ?"). Si oui, le serveur renvoie l'information ; si non, le serveur répond par un code HTTP 304 ("Ressource non modifiée"). Dans les deux cas, la fourniture de l'information (encore appelée "ressource") s'inscrira dans le fichier journal du serveur ;
  si nous optons pour le second réglage ("A chaque démarrage d'Internet Explorer"), le navigateur n'interroge pas le serveur tant qu'on ne le redémarre pas. La requête d'une page cachée ne s'inscrit pas dans le fichier journal, et le comptage est faussé ;
  si nous optons pour le troisième réglage ("Automatiquement"), le navigateur ne réclame que deux fois l'information au serveur. Le comptage est faussé si l'internaute repasse plus de deux fois par la même page ;
  si nous optons pour le quatrième réglage ("Jamais"), le navigateur ne réclame l'information au serveur que si la mémoire cache a été vidée, pour une raison ou pour une autre (débordement, intervention de l'internaute, effacement automatique lors de l'arrêt du navigateur, etc.). Le comptage est faussé si l'internaute consulte plus d'une fois la même page.

Les internautes ne modifiant généralement pas le réglage du cache de leur navigateur, c'est l'option "Automatiquement" qui prévaut. Supposons qu'un internaute, au cours de sa navigation dans un site, repasse dix fois par la page d'accueil : dans le fichier journal, ce passage ne sera enregistré que deux fois (une avec le code 200 et une avec le code 304). Le défaut de comptage est important pour les pages que l'on est naturellement amené à consulter plusieurs fois (page d'accueil, plan du site, sommaire d'un dossier, glossaire, page contenant un moteur de recherche, etc.).

Les serveurs proxy. Ces dispositifs ont un triple rôle : mise en cache, enregistrement et filtrage. On ajoute parfois à cette liste une fonction de sécurité, mais cette dernière est plus efficacement remplie par un firewall. Le rôle de cache des serveurs proxy a été monté en épingle, mais il est probablement moins efficace qu'on ne le dit. Quand on peut examiner le contenu du cache du proxy d'un établissement (exemple : le cache académique de Grenoble), on y trouve essentiellement les pages d'accueil de sites à forte fréquentation :

    portails grand public, généralistes ou spécialisés (ex : multimania, msn), sites de nouvelles ;
  opérateurs de publicité sur le web (ex : double-click), organismes de mesure de trafic, dispositifs miroirs (ex : Akamai) ;
  sites de voyages, de cartes et d'itinéraires, de météo, sites de mail gratuit, etc. ;
  sites de sports, de blagues, de jeux et d'autres distractions (lorsque le personnel étant est autorisé à surfer à titre personnel en dehors des heures de travail).

Mais dès que l'on entre dans le domaine professionnel spécialisé, les caches des serveurs proxy ne stockent plus grand'chose. C'est la raison pour laquelle nous pensons que les serveurs proxy ne faussent probablement pas beaucoup le comptage des accès au CERIG -- à l'exception, peut-être, des caches des serveurs proxy des fournisseurs d'accès.

Les web-caches. Ces dispositifs sont installés sur les grandes artères d'Internet, à des emplacements stratégiques. Il s'agit de machines puissantes, qui sont traversées par un trafic considérable, et possèdent une mémoire cache de très grande capacité. Leur rapport service/coût est sujet à forte discussion, et il semble qu'on utilise de moins en moins ces dispositifs onéreux (ex : le réseau Renater a arrêté son web-cache national il y a un an environ).

Le cache du serveur web. Ce dernier ne modifie en rien le comptage. Il a pour rôle unique d'accélérer la fourniture de l'information, et tout fichier expédié par le serveur est enregistré dans le fichier journal, qu'il provienne de son cache ou de son disque dur.

Le cache des moteurs de recherche. Certains moteurs (ex : Google) mettent en cache le texte des pages HTML qu'ils indexent (mais pas les figures ni les animations). A l'internaute qui leur pose une question, ils proposent une "copie cachée" des pages web dont ils fournissent les adresses. Si, pour une raison ou pour une autre, l'internaute requiert la page cachée au lieu de la page originelle, le comptage s'en trouve faussé.
 

Le comptage par marqueur

Le remède à ce problème de cache est connu : il consiste à utiliser un "tag" (étiquette en traduction littérale -- mais on utilise plutôt le terme "marqueur"), dispositif qui signale au serveur que la page est requise par l'internaute. Le marqueur peut prendre différentes formes :

    une image dont la durée de validité est déclarée nulle en tête du paquet qui la transporte. Ce marqueur est le plus simple et le plus utilisé ;
  un script côté client ;
  une combinaison d'image et de cookie.

Le script côté client (généralement écrit en javascript) permet non seulement de mesurer l'audience d'une page web, mais aussi de déterminer quels sont les réglages utilisés par l'internaute en matière de résolution d'écran et de profondeur de couleur. C'est grâce à ce procédé que l'on peut suivre la disparition progressive des affichages médiocres chez les internautes --  résolution VGA (640 x 480) et faible profondeur de couleur (256). Cela conduit les concepteurs de sites à construire des pages web plus larges (pour affichage sur 800 pixels), et à créer des images plus belles et de meilleure qualité, qui seront vues comme telles par 95 % des internautes.

La combinaison d'image et de cookie semble utilisée uniquement pour déterminer le nombre de "visites", une notion assez arbitraire, et dont l'utilité parait discutable. Un internaute qui ne se manifeste plus pendant au moins 20 (ou 30) minutes est censé avoir terminé sa "visite". Celui qui boit son café lentement, en rêvant devant son moniteur, peut ainsi effectuer deux visites du même site, tout en ne consultant que deux pages web.

Mais le marqueur de loin le plus utilisé est l'image de durée de validité nulle. Dans l'en-tête d'un paquet IP, la durée de validité des informations véhiculées est effectivement inscrite, et les caches (sauf réglage contraire assez rare) ne conservent pas d'information immédiatement périssable. Cependant, déclarer nulle la durée de validité de toutes les pages d'un site web, pour éviter qu'elles ne soient mises en cache, est considéré comme contraire à la déontologie du web (la "nétiquette"). Si tout les webmestres agissaient ainsi, les caches ne serviraient plus à rien, ce qui augmenterait la charge du réseau Internet, et ralentirait inutilement les navigateurs. C'est pourquoi on attribue une durée de validité nulle à un seul élément de la page, une petite image appelée "image de comptage". On utilise en général une image monopixel transparente, ou de même couleur que le fond de page. Elle ne modifie en rien l'aspect de la page, elle est légère à transporter (elle pèse 43 octets, et la taille du paquet IP correspondant varie de 140 à 260 octets). Cette technique est utilisée par un nombre croissant d'organismes spécialisés dans la mesure d'audience des pages web, afin de déterminer le taux de rémunération des bandeaux publicitaires, ou de fournir des statistiques aux webmestres. La tendance récente consiste à placer l'image en bas de page web, pour éliminer du comptage les cas où l'internaute quitte rapidement la page, avant qu'elle ne soit complètement affichée.

Le CERIG utilise effectivement cette technique depuis quelques mois. L'internaute curieux trouvera dans chaque page (ou presque) du site une "image de comptage" provenant de l'un des trois répertoires suivants : imgcpt ou imgcpt2 ou imgcpt3. Cette image se trouve en haut et à droite de la bannière située en début de page. Voici comment se présente le code HTML correspondant à l'image de comptage de la présente page web :

<td bgcolor="#FFFFFF" width="60%">
 <img
border="0" src="../../../../Imgcpt/note_mesure-audience.gif" width="1" height="1">
</td>

Vous pouvez constater la présence de cette image par vous-même, en éditant le code source. Pour ce faire, utilisez la commande "Affichage" du menu, puis cliquez sur "Source". L'adresse de l'image (attribut src) est indiquée en mode relatif, ce qui montre que l'image réside sur le même serveur web que la page qui la contient.

Chaque fois qu'une page du CERIG est requise, l'image de comptage est réclamée par le navigateur, et  renvoyée à ce dernier par le serveur, même si les autres informations de la page ne le sont pas. La mesure du trafic s'effectue, pour chaque page, en comptant l'occurrence de l'image de comptage correspondante dans le fichier journal. Rappelons que les robots, qui requièrent les pages HTML mais pas les images, ne sont pas comptés par cette méthode ; le comptage par images mesure donc bien l'audience du site, et non son trafic.

Ce système de détermination de l'audience semble parfait... mais la perfection n'est pas de ce monde ! Signalons quelques défauts :

    l'image de comptage n'étant pas placée en tout début de page, l'accès n'est pas compté si l'internaute se ravise et quitte la page rapidement. Sauf effet de cache, la page est par contre enregistrée dans le fichier log ;
  introduire une image de comptage dans chaque page web d'un site qui en comporte des centaines (près de 500 actuellement au CERIG) n'est pas une sinécure -- d'autant que ces images doivent toutes être distinctes, pour une raison que nous expliquerons plus loin. De fait, certaines pages peu consultées du CERIG ne possèdent pas encore d'image de comptage ;
  les internautes qui naviguent sans demander les images (pour aller plus vite lorsque le réseau Internet est encombré) sont décomptés comme des robots, quelle que soit la méthode utilisée. Ils sont, heureusement, de plus en plus rares ;
  la méthode ne s'applique pas aux pages dont le format est différent du HTML. C'est en particulier le cas des pages PDF, qui doivent être décomptées à part. Les pages dynamiques (générées à la volée par le serveur) posent également un problème particulier (le CERIG n'en possède pas, sauf pour la base de données) ;
  quelques fournisseurs d'accès (le plus connu étant AOL) perturbent fortement la mesure d'audience par image de comptage. On a beaucoup mis en cause le serveur proxy correspondant, mais le problème semble provenir plutôt du serveur DHCP, qui change fréquemment l'URL du client en cours de session ;
  la présence d'une image qui ne sert apparemment à rien inquiète certains internautes.

Il peut donc arriver que le comptage par image donne un résultat moindre que le comptage par accès. Le phénomène est assez rare, mais nous en verrons des exemples plus loin (figure 5).
 

Les "web bugs"

Une campagne de presse a été déclenchée l'année dernière aux États-Unis contre l'usage des images de comptage, allègrement confondues avec des "tags" plus élaborés, baptisées "web bugs" et accusées de tous les maux. Le sommet de l'hystérie a été atteint dans un page publiée par une journaliste de C/Net, qui dote les images de comptage de pouvoirs quasi surnaturels :

    elles font de la toile "an Orwellian Big Browser";
  elles traquent le visiteur dans le cyber espace sans qu'il le sache (et elles ont été développées pour cela, bien entendu) ;
  elles envoient des messages au serveur web ;
  elles peuvent dialoguer avec les cookies déjà présents sur la machine cliente ;
  elles sont diaboliques ou démoniaques (the "evil" of Web bugs) ;
  elles sont utilisées sur les sites pornographiques, etc. etc.

Une association de protection de la vie privée s'est engouffrée dans la brèche, en créant un plug-in pour navigateur qui détecte les images monopixels. Bien entendu, ce petit programme ne chôme pas : depuis leur invention par le graphiste américain D. Siegel il y a 4 ans environ, les images monopixels sont très utilisées pour la présentation des pages web, et on en trouve partout. Elles servent à caler des marges, à régler des distances entre images, à fixer des interlignes, à obliger le navigateur de Netscape à afficher les couleurs de fond de cellule, etc. L'affaire Bugnosis aurait dû sombrer dans le ridicule, mais l'association a réussi un joli coup de pub en présentant son fameux plug-in... au Sénat américain !

A notre époque, il devient difficile d'être une start-up et de survivre sur le net. Une jeune pousse a trouvé le moyen d'exploiter la peur des web bugs de manière astucieuse. Sur son site, elle propose un "white-paper" sur le sujet. Vous pouvez l'obtenir gratuitement, à condition de remplir un questionnaire où l'on vous demande votre nom, votre adresse, votre numéro de téléphone, l'activité de votre entreprise -- tous renseignements qu'une image de comptage ne pourra jamais vous extorquer. La ficelle est tellement grosse, que les journalistes auraient dû en faire des gorges chaudes... et bien non ! Les articles se suivent, et ressemblent à celui de C/Net. Une lueur de bon sens apparaît cependant dans une page récente de ZDNet, où l'auteur remarque que la principale menace sur la vie privée ne vient pas des web bugs. À l'heure où nous écrivons ces lignes, l'émotion suscitée par les web bugs semble être complétement retombée. De plus, on réserve désormais ce terme à la combinaison d'une image de comptage et d'un cookie. Calmons-nous !

Rappelons, pour mettre un peu de bon sens dans cette affaire, que le seul but de l'image de comptage est de s'affranchir du rôle des caches ; cette image ne renseigne pas plus sur l'internaute que les autres enregistrements du fichier journal. Voici, à titre d'exemple, comment se présente (figure 2 ci-dessous) l'enregistrement d'une image de comptage dans le fichier journal du serveur du CERIG, du moins en ce qui concerne les principaux champs. L'enregistrement relatif à une image de comptage est surligné en jaune. Comme on peut le constater, cet enregistrement ne se distingue en rien de ses voisins.


Figure 2 - Extrait du fichier journal du serveur web du CERIG
 

La mise en oeuvre du comptage

Depuis un an, le nouveau serveur du CERIG utilise le logiciel IIS (version 4) de Microsoft. Ce dernier offre la possibilité de fixer la durée de validité des informations contenues dans un répertoire donné, et en particulier de la rendre nulle. La figure 3 ci-dessous illustre le cas particulier du répertoire Imgcpt, qui contient une partie des images de comptage.


Figure 3 - Réglage de la durée de validité du contenu d'un répertoire dans IIS4

Supposons qu'une page web contienne une image stockée dans le répertoire Imgcpt. Si un internaute requiert cette page via son navigateur, l'image sera automatiquement réclamée au serveur web, car elle ne figure dans aucun cache (sa validité expire immédiatement). Il suffit de compter, dans le fichier journal, le nombre de requêtes relatives à cette image, pour connaître le taux de consultation de la page correspondante par les internautes.

Il nous a paru intéressant de totaliser les comptages relatifs à toutes les pages d'une même entité -- un même dossier, par exemple. Pour ce faire, il suffit d'utiliser la même image de comptage pour toutes les pages HTML du dossier. Comme nous allons le voir ci-dessous, cette procédure n'est pas recommandable.

Deux mots de technique : les données du fichier journal sont exploitées grâce à des requêtes effectuées à l'aide du SGBD Access de Microsoft, après mise en forme du fichier journal dans le tableur Excel du même éditeur. La procédure est automatisée à l'aide de macros.
 

Les résultats

La figure 4 ci-dessous montre comment varie la consultation de la page d'accueil du CERIG en fonction du temps au cours des semaines 37 à 41. La courbe bleue est obtenue en comptant directement les accès dans le fichier journal, et en éliminant les robots (ces derniers étant caractérisés par le fait qu'ils ne requièrent pas d'images). La courbe violette résulte du comptage par image. Comme on peut le constater, l'effet de cache est important. La page d'accueil constitue le meilleur exemple pour le mettre en évidence, car un internaute qui explore un site est tenté de repasser plusieurs fois par la "home page". On notera au passage que le CERIG est peu visité durant les week-ends, ce qui va de pair avec son contenu à orientation essentiellement professionnelle.

Accès de l'accueil du cerig
       Figure 4 - Taux de consultation journalier de la page d'accueil du CERIG
par les internautes (robots exclus)

On vérifie également sur la figure 4 que le comptage par image fournit systématiquement une valeur supérieure à celle du comptage direct, ce qui est logique. Mais il n'en est pas toujours ainsi, comme le montre la figure 5, qui représente le trafic global du serveur principal (c'est à dire hors forums et base de données, lesquels sont mis en ligne à l'aide d'un serveur auxiliaire). Les conventions de couleur sont identiques à celles de la figure 4.


Figure 5 - Taux de consultation journalier des pages du CERIG
par les internautes (sauf forums et base de données -- robots exclus)

Trois points particuliers issus de la figure 5 ont retenu notre attention :

    l'effet de cache est nettement moindre pour le trafic global que pour la page d'accueil ;
  le comptage par images donne parfois un résultat légèrement inférieur à celui du comptage classique ;
  le 02 octobre dernier, le comptage classique donne un résultat considérablement plus grand que celui du comptage par image, et hors de proportion avec les chiffres habituels.

 

Les causes d'erreur

Les cas pour lesquels le comptage traditionnel donne un résultat très supérieur à celui du comptage par image sont rares, mais ils méritent une explication. Nous avons entrepris de les examiner systématiquement, et nous avons pour l'instant recensé six causes :

    les aspirateurs de site optimisés ne réclament qu'une seule fois la même image, même si cette dernière intervient dans plusieurs pages HTML. Ainsi, si les dix pages d'un même dossier utilisent la même image de comptage, l'aspirateur de site ne la requiert qu'une seule fois. Si l'aspirateur parcourt une grande partie du site, la différence peut être importante ;
  l'expérience montre que les aspirateurs de site ne requièrent pas toujours la totalité des images contenues dans une page web. De ce fait, l'image de comptage peut n'être pas demandée ;
  les aspirateurs de site ne sont pas tous très au point, et les internautes qui les utilisent ne les maîtrisent pas toujours complètement. De ce fait, un aspirateur peut se bloquer sur une page donnée, et la réclamer sans cesse (sans son image de comptage). Il crée ainsi un comptage artificiellement élevé dans le fichier journal, artefact que l'on ne retrouve pas par la méthode de l'image de comptage ;
  certains robots prennent une image pour une page web, lorsqu'un lien hypertexte est créé en direction de cette image. Ayant requis une image, ils sont décomptés par le logiciel comme internaute ou aspirateur de site, et non plus comme robot ;
  les redirections (vers un autre répertoire ou un autre serveur) provoquent l'écriture d'une ligne dans le fichier journal. Mais, la page initialement demandée n'ayant pas été servie, aucune image de comptage n'est appelée ;
  enfin, lorsqu'un site comporte près de 600 pages, il est difficile de ne pas en oublier quelques-une lors de l'insertion des images de comptage !

Le premier point nous amène à modifier notre système de comptage par images. Désormais, nous utiliserons une image distincte pour chaque page HTML, ce qui supprimera cette cause d'erreur.

Le second point provient des possibilités de réglage que présentent certains aspirateurs de site. L'internaute qui aspire un site qu'il ne connaît pas encore peut donner comme consigne à son logiciel de ne pas requérir les images au-delà du premier ou du deuxième niveau (par exemple), afin de réduire les frais de communication. Dans d'autres cas, les images ne sont requises que si la page a été modifiée récemment, ou bien les images qui n'occupent qu'un seul pixel sont exclues, etc. C'est ainsi que, dans un exemple récent (29/10/2001), nous avons dénombré 21 images de comptage pour 306 pages web, sur un total de 520 requêtes (aspirateur WebCopier). Il parait difficile de trouver une parade efficace à de tels comportements, qui peuvent entraîner des erreurs de comptage importantes. Mais... doit-on compter des pages qui sont aspirées sans leurs images ?

La très forte pointe de trafic du 02 octobre illustre le troisième point. Elle provient du fait qu'un aspirateur de site déréglé a demandé plusieurs milliers de fois la même page, sans pour autant requérir les images qu'elle contenait. Parfaitement artificiel, le trafic correspondant ne mérite pas d'être décompté.

Le quatrième point correspond au cas rare où un lien hypertexte est créé en direction d'une image seule, et non d'une page web la contenant. Un tel cas existe sur le site du CERIG, dans le dossier consacré à la typographie du web (chapitre 2), où l'on montre qu'une page web peut être présentée sous forme d'une image gif. Le lien hypertexte vers cette image est alors effectué à l'aide de la balise <a href="...">. Il arrive qu'un robot mal conçu prenne cette image pour une page web et la requiert (le cas est rare, mais nous le rencontrons de temps en temps). Les pages web demandées par ce robot apparaissent dans le décompte des internautes par la méthode des accès, et pas dans celui utilisant la méthode des images de comptage. On peut modifier la méthode d'analyse des fichiers log de telle sorte qu'elle corrige cette anomalie : il suffit d'éliminer la page en question des fichiers log dès le début de la procédure.

En ce qui concerne le cinquième point, le remède normal consiste à ne pas comptabiliser les redirections (code HTTP 301 ou 302) lors de l'analyse du fichier journal. Aucune page, en effet, n'est servie à cette occasion.
 

Conclusion

S'il n'est pas possible de s'affranchir complètement de l'effet de cache lors de la mesure d'audience des pages d'un site web, la technique de l'image de comptage fournit une solution plus satisfaisante que le simple dépouillement du fichier journal.

Mais si le problème posé par l'existence des caches parait ainsi à peu près résolu, celui posé par le mode de fonctionnement de certains aspirateurs ne l'est pas. Faudra-t-il en venir à déclarer nulle la durée de validité des pages web elles-mêmes pour réaliser un comptage efficace ? Cette mesure extrême ne parait pas souhaitable, car elle ralentit le fonctionnement des navigateurs, et peut indisposer l'internaute. Bref, le problème de la mesure d'audience progresse, mais la solution parfaite n'est pas encore en vue.

Page technique
Note précédente Liste des notes Page technique  Note suivante 
 
Accueil | Technique | Liens | Actualités | Formation | Emploi | Forums | Base
 
Copyright © CERIG/EFPG 1996-2002
Mise en page : J.C. Sohm