Verfahren zur Analyse des Nutzerverhaltens im WWW: Clickstreams, Cookies, IP Adressen,…

Inhaltsverzeichnis:

1 Die Notwendigkeit der Datensammlung

2 Datensammlung
2.1 Grundlegende Technik im WWW
2.2 Logfiles
2.2.1 Logfile Informationen
2.3 Auswertung eines Logfiles
2.3.1 Hits
2.3.2 Verfahren der IVW
2.3.3 Clickstreams
2.4 Cookies
2.5 Dynamische Seiten

3 Webmining und der Prozess des Web Log Minings

4 Zukünftige Entwicklungstendenzen

5 Literaturverzeichnis

1 Die Notwendigkeit der Datensammlung

In den letzten Jahren hat sich das Internet zu einem der wichtigsten Kommunikations- und Informationsmittel für viele Firmen und Privatpersonen entwickelt. Dabei spielen Punkte wie Geschwindigkeit, Informationen usw. eine große Rolle. Aufgrund der weltweiten Erreichbarkeit ist mit der Pflege, dem Aufbau und der Erweiterung einer Präsenz ein sehr großer Aufwand verbunden. Denn durch die enorme Geschwindigkeit, in der eine Anwendung aufgerufen werden kann, kann der Besucher sie bei nicht gefallen auch wieder verlassen. Durch die Anstrengungen der Firmen ihr Angebot interessant und aktuell zu halten, fehlen für einen wichtigen Aspekt Ressourcen: Die Analyse des Nutzerverhaltens. In den folgenden Kapiteln werden Techniken und Möglichkeiten aufgezeigt, eine solche Analyse durchzuführen.

2 Datensammlung

Die Datensammlung ist ein zentraler Punkt bei der Analyse des Nutzerverhaltens. Diese Daten können auf unterschiedliche Weise gesammelt werden. Ein geeigneter Sammelpunkt ist z. B. das Logfile eines Webservers, aber auch mit Cookies oder mit der aktiven Speicherung der Nutzeraktivitäten durch dynamische Seiten in Datenbanken können wichtige Daten über Besucher gesammelt werden. Auf Basis dieser Daten kann analysiert werden, ob in einer eCommerce - Anwendung die Web-Useability gegeben ist und somit der Internet-Shop oder Marktplatz von den Besuchern als angenehm und übersichtlich empfunden wird.

2.1 Grundlegende Technik im WWW

Um alle Verfahren verständlich erklären zu können, müssen zuerst die grundlegenden Techniken, die einem Nutzer ermöglichen, eine Internetseite zu besuchen, erläutert werden. Der durchschnittliche User benützt einen Browser, wie z. B. den Internet Explorer von Microsoft oder den Netscape Navigator, mit dem er eine TCP/IP Verbindung zu einem Webserver aufbaut und über das sog. Hypertext Transfer Protocol (HTTP) eine HTML-Seite anfordert. Der Server liefert nun über die gleiche Verbindung die angeforderte Seite zurück. Um detaillierter in diesen Vorgang einsteigen zu können, muss man die einzelnen Schritte, die bei einem derartigen Aufruf entstehen, erklären.

Nachdem eine TCP/IP Verbindung zwischen dem Browser und dem Server aufgebaut wurde, schickt der Browser eine Anfrage, einen sog. Request. Diese Anfrage beinhaltet in der ersten Zeile die Methode, mit der angefragt wird, die Identifikation der Quelle und welches Protokoll verwendet werden soll. Ein Beispiel für die erste Zeile eines Request würde folgendermaßen aussehen [FMFB97, S. 33]:

Abbildung in dieser Leseprobe nicht enthalten

Zusätzlich können noch sog. Request-Header-Fields mit übertragen werden, die dem Benutzer die Möglichkeit geben, zusätzlich Informationen über die Anfrage oder über den Client (Browser) selbst an den Server zu übertragen. Mögliche Zusatzinformationen wären zum

Abbildung in dieser Leseprobe nicht enthalten

Beispiel:

Wie ersichtlich, können schon durch die Speicherung dieses Request einige Informationen über den Anwender herausgefiltert werden, im obigen Beispiel, dass der User den Internet Explorer 5.0 verwendet und auf seinem Rechner das Betriebssystem Windows 98 installiert ist. Des weiteren kann man herauslesen, dass es sich hier um einen deutschen User handelt, da er nur die Ländersprache Deutsch akzeptiert. Dieser Request wird auch von den Logfiles der Webserver verwendet [FMFB97, S. 37].

Nachdem der Server eine Anfrage bekommen hat, antwortet er mit einer Response Meldung. Die erste Zeile einer Response Nachricht ist die Status-Line. In ihr wird die Protokoll Version gefolgt von einem Status-Code und dessen verbale Erklärung übermittel. Eine Status-Line könnte wie folgt aussehen [FMFB97, S. 37]:

Abbildung in dieser Leseprobe nicht enthalten

Der Status-Code, der hier 404 lautet, wird in 5 Gruppen eingeteilt. Die Eingliederung erfolgt anhand der ersten Stelle. Mögliche Gruppen sind: 1xx = Informativ: Request empfangen, Prozess wird weitergeführt; 2xx = Aktion wurde vollständig empfangen, verstanden und akzeptiert; 3xx = Redirection - weitere Aktionen müssen empfangen werden, um die Aktion abzuschließen; 4xx = Client Error - Die Anfrage beinhaltet eine falsche Syntax oder kann nicht abgeschlossen werden; 5xx = Server Error - Die Aktion des Servers schlug fehl, die gültige Anfrage durchzuführen [FMFB97, S. 38].

Nach der Status-Line wird dann die eigentliche Internetseite übermittelt. Auch hier können zusätzlich Informationen über den Server und die Zugriffsgenehmigungen an den Client übertragen werden. Hier werden zum Beispiel auch die Befehle zum schreiben von Cookies gesendet.

Nachdem die Request - Response Aktion durchgeführt wurde, wird die TCP/IP Verbindung zwischen Server und Client wieder abgebaut [FMFB97, S. 42]. Diese Vorgehensweise erklärt die Zustandslosigkeit des Protokolls HTTP, was zur Folge hat, dass man nicht ohne zusätzliche Methoden den Besuch eines Benutzers auf seiner Webseite verfolgen kann, da immer wieder eine neue Verbindung auf und abgebaut wird. Man nennt den Besuch, also die Zeit, die sich ein Benutzer auf einer Webseite aufhält, auch Session.

Es gibt zwar eine Erweiterung in HTTP/1.1, den sog. Keep-Alive Header, der den Browser und Server dazu zwingt, eine Verbindung aufrecht zu erhalten. Aber auch dieser wird nach einer bestimmten Zeit wieder abgebaut und man kann somit diesen Mechanismus nicht verwenden, um eine Session eindeutig zu identifizieren [FMFB97, S. 159].

2.2 Logfiles

Um nun die Daten einer HTTP-Transaktion zu speichern, erzeugt der Webserver ein Logfile und trägt hier für jede Transaktion einen Eintrag ein. Das Aussehen eines solchen Logfiles ist stark abhängig von der Konfiguration des Webservers. Jeder kann seinen Webserver so konfigurieren, dass das Logfile seinen Wünschen entspricht. Es haben sich jedoch verschiedene Standards herausgebildet, die häufig eingesetzt werden.

Ein einfacher Standard ist das Common Log Format [FNIEa95]. Der Abruf einer Seite oder Datei entspricht hier genau einer Zeile. Die einzelnen Informationen werden in Spalten aufgeführt und durch ein Leerzeichen getrennt. Ein Eintrag in diesem Format könnte folgendermaßen aussehen:

Abbildung in dieser Leseprobe nicht enthalten

2.2.1 Logfile Informationen

Die erste Spalte enthält die Adresse des Computers, der einen Request an den Server gesendet hat. Bei dem ersten Eintrag liegt die Adresse in Form einer IP-Adresse (Format x.x.x.x) vor, bei dem zweiten als FQDN (Fully Qualified Domain Name) [MALK96, S. 21]. In den meisten Fällen werden aber nur die IP-Adressen registriert, da zur Erzeugung eines FQDN ein Reverse DNS-Lookup notwendig ist, der den Server zusätzlich belastet. Grundsätzlich kann dieser aber auch später durchgeführt werden [FNIEb95]. Durch den FQDN kann man oft erkennen durch welchen Provider der Benutzer ins Internet gelangt. Im obigen Beispiel ist der Benutzer durch den Anbieter T-Online ins Internet gekommen. Anhand der Top Level Domain (TLD) ist ersichtlich, aus welchem Land die Anfrage stammt. Hier kommt die Anfrage aus Deutschland. Leider trifft dies nicht auf die gTLD (generic Top Level Domains, z. B. .com oder .net) zu. In der nächsten Spalte steht dann die sog. ident-Information, die die Angaben über die Identität des Nutzers enthält. Diese wird von einem ident-Serverprozess auf dem Computer des Besuchers geliefert. Tatsächlich stehen aber diese Informationen nur selten zur Verfügung, da aus Sicherheitsgründen in den wenigsten Fällen ein ident-Server auf dem Rechner des Benutzers aktiv ist [JOHN93].

In der folgenden Spalte wird der Benutzername gespeichert mit dem sich ein Besucher auf der Webseite angemeldet hat. Dieser ist nur verfügbar, wenn es sich bei der Webseite um eine passwortgeschützte Seite handelt. Der Vorteil von passwortgeschützten Seiten für die Analyse ist, dass man den Benutzer eindeutig identifizieren kann.

Die Informationen über Datum und Zeit befinden sich in der nächsten Spalte. Zu beachten ist hier vor allem, dass es sich nicht um das Datum und die Zeit des Benutzers handelt, sondern um die Zeitangaben des Computers, auf welchem der Webserver sich befindet. Wenn sich der Benutzer in einer anderen Zeitzone befindet als der Server, greift er zu einem anderen Zeitpunkt auf die Seite zu als protokolliert. Falls man die genaue Zeit eines Zugriffs bestimmen möchte, ist dies meist mit der Information aus der ersten Spalte, also aus welchem Land der Zugriff erfolgte, möglich.

In der darauf folgenden Spalte werden die Informationen aus der ersten Zeile des Request abgespeichert. Sie stehen meistens in Anführungszeichen. Mitprotokolliert werden die Request-Methode, der URI (Uniform Resource Identifier), der die angeforderte Resource spezifiziert, und die verwendete HTTP Version.

In der vorletzten Spalte wird der Status-Code abgespeichert, der durch den Response gesendet wurde.

Zu guter Letzt wird noch die Größe der gelieferten Ressourcen in Bytes angegeben, wobei hier die Header-Informationen nicht mit hineingerechnet werden.

Ein weiteres Format, in dem Logfiles gespeichert sein können, ist das sog. Extended Log Format. Hier werden noch zusätzliche Informationen protokolliert, wie das Referer Feld und die Webbrowser-Kennung.

Unter Referer versteht man die zuvor besuchte Webseite. Die gängigsten Webbrowser schicken die Referer Information mit, falls der Benutzer von einer anderen Webseite per Link zu dieser gekommen ist. Das Referer Feld ist sehr wichtig, da es die Bestimmung des Clickstreams erleichtert [FMFB97, S. 141].

Bei der Webbrowser-Kennung handelt es sich um eine Zeichenkette, die den Hersteller und die Version des verwendeten Browsers sowie das verwendete Betriebssystem beinhaltet. Ein Logfile Eintrag im Extended Log Format würde wie folgt aussehen [WWWC01]:

Abbildung in dieser Leseprobe nicht enthalten

2.2.2 Probleme

Die Verwendung des Logfiles als Basis der Analyse kann unter bestimmten Umständen zu Fehlern und damit zu Problemen führen. Zum Beispiel wird bei dem Mitprotokollieren der Adresse nicht der Benutzer sondern der Computer, von welchem die Anfrage aus gestartet wurde, identifiziert. Handelt es sich nun um einen öffentlichen Computer, wie z.B. in den CIP- Pools, kann nicht davon ausgegangen werden, dass es sich bei einem zweiten Eintrag um dieselbe Person handelt. Die gleiche Problematik tritt auf, wenn der Provider, über welchen sich die Benutzer einwählen, dynamische IP Adressen aus einem ihm zu Verfügung stehenden Adressen-Pool verteilt. So kann eine bestimmte IP-Adresse an zwei Tagen an unterschiedliche Benutzer vergeben werden.

Des weiteren kann es auch dazu kommen, dass unter der gleichen IP-Adresse mehrere Benutzer auf eine Webseite zugreifen. Dies geschieht immer dann, wenn die Netzwerke der Unternehmen oder Privatpersonen mit einer sog. Firewall oder mit einem Proxy ausgestattet sind. Firewalls „verstecken“ die Rechner, die an ihnen angeschlossen sind und ersetzen die IPAdresse einer Anfrage durch die eigene. Dadurch besteht nur noch eine Verbindung zwischen Firewall und Webserver und dieser kann nicht feststellen, was sich hinter der Firewall befindet. Firewalls dienen zum Schutz von Lokalen Netzwerken [FMFB97, S. 11].

Das gleiche Phänomen tritt bei Proxys auf. Ein Proxy dient dazu Datenvolumen, das durch das „surfen“ entsteht, so gering wie möglich zu halten, um Kosten zu sparen. Dies wird realisiert, indem jede Seite, die aufgerufen wird, in dem Proxy gespeichert wird. Es erfolgt also ein Request an den Proxy, dieser vergleicht ob er die Seite in seinem Speicher hat und sendet diese, falls vorhanden, an den Anfrager zurück. Falls die Seite nicht vorhanden ist, stellt der Proxy einen Request an den Webserver und speichert diese Seite [FMFB97, S. 11]. Hier tritt also das gleiche Problem auf wie bei den Firewalls, da der Webserver nur die Adresse des Proxys sieht und nicht die des eigentlichen Anfragers. Dieses Problem lässt sich abschwächen, da RFC 2068 von dem Proxy für derartige Zugriffe verlangt, einen „VIA-Header“, der anzeigt, dass die Anfrage nicht von dem Proxy sondern von einem anderen Computer gestartet wurde, zu senden [FMFB97, S. 135]. Um eine Identifikation des Ursprungscomputers zuzulassen, fügen einige Proxy-Server dem Request einen zusätzlichen Header „X_Forward-For“ ein. Problematisch ist dies, da dieser Header nicht in RFC 2068 vermerkt ist und damit nicht als Standard anzusehen ist. Aufgrund der Sicherheitsrisiken, die dadurch entstehen können, ist diese Eigenschaft in den meisten Fällen deaktiviert. Falls sie nicht deaktiviert ist, enthält der Header die IP-Adresse des ursprünglichen Anfragers [WESS01, Abs. 4.17].

Ein weiteres Problem entsteht dadurch, dass für jede einzeln abgerufene Ressource ein Zugriff und damit ein Eintrag erzeugt wird. Man muss beachten, dass unter Resourcen nicht nur die HTML-Dokumente sondern auch jedes Bild, jede Flash-Animation usw. zu verstehen ist.

[...]