Reconstruction des sessions et Processus de prétraitement en WUM

By 4 May 2013

3.5.2 Reconstruction de sessions

Afin d’aboutir au fichier des sessions et après la phase de nettoyage des données d’usage, le processus de prétraitement en WUM inclut une étape de reconstruction des sessions. Cette dernière est en réalité constituée de trois sous tâches. Elle comprend l’identification des utilisateurs, l’identification des sessions et la complétude des parcours de navigation (Cooley et al., 1999),(Markov et al., 2007).

3.5.2.1 Identification des utilisateurs

Si on se place du coté serveur, l’étape d’identification des utilisateurs est dans la majorité des cas très difficile à résoudre. En effet, il est en général presque impossible d’identifier à partir des activités de navigations, enregistrées dans les fichiers logs au format (E)CLF souvent incomplets et incohérents, celles appartenant à un utilisateur physique donné. Ces logs peuvent, de plus, ne pas refléter exactement la navigation des utilisateurs sur un site Web, et couramment une partie des demandes d’un client n’arrive jamais au serveur, en raison de plusieurs machines proxy intermédiaires utilisées, et niveaux de cache implémentés dans le web (Cooley, 2000).

Le mécanisme de cache-proxy demeure le plus crucial et rencontré altérant les traces de navigation, et introduisant des incertitudes dans les tentatives pour pister tous les événements qui se produisent durant une session utilisateur. Le cache est une sorte de mémoire dans laquelle seront enregistrées les pages demandées initialement par l’utilisateur. En suite, au cours des futures activités de navigation d’un utilisateur, les requêtes pour les pages déjà cachées, par exemple suite à l’appui sur les boutons : précédent, historique, favoris…etc., n’aboutiront pas au serveur, le cache relayant l’information à sa place. Ce système peut être de deux types : si le cache est implémenté au niveau du navigateur, un seul utilisateur peut en bénéficier, en parle donc de cache local. Il est dit cache global, dans le cas ou il est intégré à une machine proxy à laquelle sont connectés plusieurs utilisateurs (Murgue, 2006).

Devant cette situation, on se retrouve en face à deux principaux problèmes. Le premier est l’adresse IP de provenance erronée, qui résulte de la relation non bijective liant les adresses IP et les utilisateurs, où d’un côté plusieurs utilisateurs se voient attribuer la même adresse IP (cas de la réutilisation de l’adresse IP d’un serveur proxy), et d’un autre coté un même utilisateur peut avoir différentes adresses IP (s’il change d’environnement de navigation). Ceci rend l’utilisation des adresses IP comme identifiants pour les utilisateurs chose impossible (Cooley, 2000),(Facca et al., 2005). Le second problème concerne la perte de données relatives aux requêtes manquantes servies à partir des caches, qui sera traité dans l’étape de complétude de chemins de navigation.

Pour ces raisons, tous les travaux basés sur les logs coté serveur utilisent seulement pour l’identification des utilisateurs des approches réactives moyennant des heuristiques fondées sur les données relatives à l’environnement du client telles que la combinaison de l’adresse IP et du champ client-agent, ou du champ referrer associé aux informations sur la topologie du site (Cooley, 2000).

D’autres solutions partielles et proactives à cette question sont les cookies, les IDs dynamiques de sessions, l’inscription et l’authentification, et les méthodes coté client (Berendt et al., 2002). Nous les présentons dans ce qui suit.

Les cookies sont des chaînes de texte enregistrées par le serveur web sur l’ordinateur du client avec la possibilité de la relire plus tard1. Ce mécanisme a été introduit pour résoudre le problème du manque d’état (stateless) qui caractérise le http principal protocole du web (Kristol et al., 1997). Il a été adopté universellement par les vendeurs de serveurs et navigateurs web, et utilisé par les profileurs pour pister les utilisateurs des sites web (Kimball et al., 2000). Toutefois, outre qu’ils posent des problèmes par rapport à la vie privée des internautes (Cooley, 2000), (Murgue, 2006), les cookies sont tributaires à la coopération de l’utilisateur, qui a la faculté de désactiver leur support dans son navigateur ou de les supprimer du disque (Facca et al. 2005).

Les IDs dynamiques de sessions (embeded ID sessions), sont des identificateurs uniques générés par le serveur web et attachés à chaque processus client actif qui y accède. Un identificateur est donc valide jusqu’à la terminaison du processus suite à une déconnexion ou un timeout dépassé. Il est attaché à chaque requête émise par le client via un procédé appelé réécriture d’URL (URL rewriting), consistant à sa concaténation à cette dernière. Cette technique nécessite un contrôle rigoureux des IDs, et la génération dynamique de pages web et ne peut d’aucune façon détecter les revisites (Cooley, 2000), (Berendt et al., 2002).

1 Un cookie peut être permanent conservé sur le disque ou temporaire liée à la session enregistré dans la mémoire mais non conservé quand le navigateur est fermé.

De loin, l’approche la plus triviale à la question de l’identification des utilisateurs demeure incontestablement l’inscription et l’authentification des usagers des sites web. Néanmoins, l’inscription n’est pas toujours fiable et possible, car la majorité des internautes préfèrent rester anonymes ou fournir des informations erronées (Kimball et al., 2000).

En fin, et selon (Cooley, 2000) l’utilisation des techniques d’acquisition de données d’usage coté client, par un agent software ou un navigateur modifié, élimine l’ensemble des difficultés liées à l’identification des utilisateurs et, en général, à la phase de préparation des logs, et donne des résultats plus fiables et précis (Shahabi et al., 2001).

3.5.2.2 Détermination des sessions

Une fois l’utilisateur identifié, l’étape suivante consiste à repérer au sein des données de trafic des plages d’activités cohérentes de cet utilisateur. C’est-à-dire de regrouper les activités appartenant à la même visite.

Ce découpage appelé sessionizing (Berendt et al., 2002) représente une autre difficulté pour la construction du fichier des sessions. En effet, dans les traces de navigation l’utilisateur ne donne pas d’indications pour dire quand il commence et finit d’utiliser Internet, on observe des traces d’activités entrecoupées de périodes plus ou moins longues d’inactivité. L’enjeu est de définir qu’elle période d’inactivité on retient pour déclarer qu’une session est terminée et que les traces suivantes appartiennent à une autre session.

Pour déterminer les limites des sessions, on fait ici également recours à des heuristiques fondées sur le principe d’un timeout1, en examinant le temps passé dans la session ou entre les requêtes de l’utilisateur, ou encore en se référant à la structure du site2 comme expliquées et évaluées dans (Berendt et al., 2002). (Kimball et al., 2000) propose 30 minutes comme borne d’une session. Cette valeur a été retenue dans plusieurs travaux centrés serveur (Cooley, 2000), (Beauvisage, 2004), puis adoptée comme standard industriel (Markov et al., 2007).

3.5.2.3 Complétude des parcours de navigation

L’étape finale dans la phase de reconstruction de sessions se focalise sur la résolution des références manquantes dans les fichiers logs à cause du phénomène des caches. Ce problème concerne seulement l’approche d’acquisition de trace de navigation coté serveur, pour laquelle Cooley dans (Cooley et al., 1999) est le premier qui a proposé des algorithmes pour retrouver les pages absentes. Ces heuristiques reposaient sur les informations véhiculées par le champ referrer et les données afférentes à la topologie du site.

Après avoir reconnu les pages omises, il ne reste qu’à les insérer dans le fichier des sessions et d’en inférer ensuite des temps de consultation. La durée d’affichage de chaque page est fixée selon sa classification à une valeur courte si elle est de navigation, ou un peu plus longue s’il s’agit d’une page de contenu (Cooley, 2000).

1 Il peut être local ou global : pour séparer deux sessions consécutives, on considère soit la durée de la session, soit la durée entre deux requête successives, qui ne doit pas dépassée un seuil donné
2 Une page q est considérée dans la session s si le referrer(q) est déjà dans s.

Références manquantes dues au mécanisme de cache
Figure 6. Références manquantes dues au mécanisme de cache

Notons que certains serveurs web utilisent, afin de résoudre le problème de masquage opéré par les caches, une technique dite le cache-busting consistant à désactiver la mise en cache de manière à forcer le navigateur à toujours obtenir ses objets du serveur et non pas du cache. Ceci est effectué en se servant des directives prévues à cet effet dans le protocole http (PRAGMA dans http1.0, ou CACHE-CONTROL dans la version 1.1 plus élaborée). Arrêter la mise en cache en activant ces directives rend donc inexistant le problème des requêtes manquantes. Néanmoins, cette technique augmente artificiellement le trafic réseau, ce qui n’est pratiquement pas envisageable si on veut assurer certains critères de performances (Cooley, 2000), (Murgue, 2006). .

Lire le mémoire complet ==> (Prétraitement & Extraction de Connaissances en Web Usage Mining)
S2WC2 : un WUM Framework Centré Utilisateur
Mémoire En vue de l’obtention du diplôme de Magister – Option : Informatique et Communication Electronique
Département des Mathématiques et d’Informatique – Spécialité : Informatique
Université Kasdi Merbah de Ouargla – Faculté des Sciences et Sciences de l’Ingénieur