Thiemo Fetzer 14. September 2003

Logfiles: Auf Spurensuche im Internet

Kein Beitragsbild

Thiemo Fetzer lebt seit 2008 in London und promoviert dort im Fachbereich...

Wer seine Logfiles genau analysiert, kommt schnell zu aussagekräftigen Ergebnissen über seine Kunden im Web. Richtig eingesetzt, wird die Logfile-Analyse zu einem wichtigen Marketingtool für Ihren Web-Erfolg, mit dem Sie Ihre Zielgruppen ermitteln und Ihr Webangebot optimieren können.

Jeder Hit wird aufgezeichnet, dabei wird nicht nur die IP des Besuchers gespeichert, auch der verwendete Browser kann ermittelt werden. Logfiles sind die Speicherplätze dieser Benutzerdaten. In ihnen wird jede Anfrage an den Server protokolliert und abgespeichert. Wer auf diese Statistiken Zugriff hat, kann sehr viel über die Entwicklung des Besucherstroms und sogar die Zielgruppe ermitteln. Logfiles sind meist im selben Verzeichnis wie der ROOT selbst. Es handelt sich um einfache Textdateien, die mit jedem Editor ausgelesen werden können.

Jeder Aufruf an den Server wird protokolliert. So kann bestimmt werden, von wo der Besucher kam, welchen Browser er verwendet und wie viele Seiten er sich angesehen hat. Jeder Aufruf steht im Logfile in einer eigenen Zeile. Ein Beispiel:

 192.168.156.36
- [20/Jan/2002:19:35:09 +0100] "GET / HTTP/1.1" 200 25641 www.devmag.net
"http://www.devmag.net/" "Mozilla/4.0 (compatible; MSIE 5.5; Windows
ME; DigExt)"

Diese Zeile beschreibt den kompletten Aufruf einer Seite. Auch wenn der „Code“ eher ungeordnet erscheint, besteht er doch aus einer festen Struktur. Teil 1 enthält die IP-Adresse des Rechners, welcher den Aufruf getätigt hat. Die IP-Adresse ist eine wandelnde Nummer. Mit jeder neuen Internetverbindung erhält der Computer vom jeweiligen Internetanbieter eine neue IP-Adresse aus einem Pool. Diese IP-Adresse ist innerhalb dieser Session einmalig und erlaubt die Kommunikation zwischen den verschiedenen Rechnern.

Auf die IP-Adresse folgt ein ein Bindestrich. Weiter geht es mit näheren Informationen zum Aufruf der Seite. Zunächst kommen Datum und Uhrzeit in eckigen []-Klammern. Die Angabe folgt dem amerikanischen Standard Tag/Monat/Jahr. Getrennt von einem Doppelpunkt ist der genaue Zeitpunkt des Aufrufs im GMT Zeitformat (Greenwich Mean Time).

In unserem Beispiel stammt der Besucher aus dem Raum, in dem die MEZ gilt, deshalb muss eine Stunde addiert werden, dies geschieht durch das +0100. Die konkrete Zeit des Aufrufs war also 20:35:09 Uhr. Zur Sommerzeit kann in unseren „Gefilden“ die Zeitverschiebung auch +0200, also zwei Stunden betragen.

Die nächste Angabe spezifiziert den Aufruf. Die Methode GET legt fest, dass die Daten vom Server an den Client gesendet werden, nach dieser Angabe folgt das Protokoll, mit welchem die Daten kodiert wurden, hier also das HTTP-Protokoll.

Es kann vorkommen, dass als Methode in den Logfiles auch ein HEAD auftaucht. Diese Methode wird vor allem von Suchmaschinen verwendet, die so nur Daten zu der angeforderten Datei erhalten. Dies können das letzte Änderungsdatum des Dokumentes sein. Mit diesem Datum wird dann abgewägt, ob die Seite neu indexiert wird. Nach der Angabe der Methode und des Protokolls folgt der Rückgabecode des Servers. Ist der Seitenaufruf geglückt, dann wird als Rückgabecode 200 zurückgegeben. Hier eine Übersicht zu weiteren Rückgabecodes:

200 OK
Der Request wurde erfolgreich durchgeführt.

204 No Content
Das angeforderte Dokument enthält keine Daten.

206 Partial Content
Die Übertragung wurde unterbrochen. Dies kann vom Browser aus geschehen – oder bei einem Update der Seite.

300 Multiple Choices
Es sind mehrere (ähnliche) Dateien vorhanden. Der Server kann die Datei nicht eindeutig ermitteln und bietet mehrere Auswahlmöglichkeiten.

301 Moved Permanently
Die Datei wurde an einen anderen Ort verschoben.

304 Not Modified
Die Datei wird komplett aus dem Cache (Server und/oder Client seitig) geladen.

400 Bad Request
Der Webserver „versteht“ Ihre Anfrage nicht.

401 Unauthorized
Sie sind nicht autorisiert, diesen Bereich zu betreten.

403 Forbidden
Der Zugriff auf die angeforderte Datei wird verweigert

404 Not Found
Die Datei wurde nicht gefunden (ist nicht vorhanden), oder der URL wurde falsch eingegeben.

500 Internal Server Error
Ein unbekannter Server Fehler ist aufgetreten. Oftmals entstehen diese durch falsche Anwendung von .htaccess Dateien oder durch Fehler im CGI.

503 Service Unavailable
Der Server kann die Anfrage zeitweilig nicht bearbeiten, z.B. bei Wartungsarbeiten.

Auf den Rückgabecode folgt eine Zahl, sie gibt die genau übertragene Datenmenge in Bytes an. Diese Zahl entspricht also der Dateigröße. Danach folgt der URL zu dem Dokument, welches aufgerufen wurde. Der URL weißt auf den Root, es war also ein direkter Request. Auf diese URL folgt die URL der Seite, auf der sich der Besucher zuletzt befand. Bei einer direkten Anfrage entfällt diese Angabe. Bei einer indirekten Anfrage kommt man z.B. über einen Link einer anderen Seite zu der Seite, hier steht dann der URL der Seite, von welcher man auf die andere Seite gekommen ist. Diese Seite bezeichnet man als Referer-Seite.

Die folgenden Angaben geben nähere Informationen zu dem Client bzw. zu dem System, von welchem der Aufruf getätigt wurde. Die Angaben erstrecken sich von dem verwendeten Browser bis zu dem Betriebssystem. In dem Beispiel oben verwendet der Besucher, leicht zu erkennen, den Internet Explorer in der Version 5.5. Zudem arbeitet er mit Windows ME als Betriebssystem. Kommt der Request von einem Spider, oder von einem Robot, stünde hier der Name des jeweiligen Spider oder Robots.

Da jeder Hit nach diesem oder einem ähnlichen Muster aufgebaut ist, wird auch die Analyse fast zu einem Kinderspiel. Es gibt Analyse-Programme bzw. Skripte, die jeden Hit auslesen und in seine Bestandteile auseinandernehmen, um ihn dann in einer hübschen, übersichtlichen Statistik wieder zusammen zu setzen. Komplexere Statistiksysteme ermitteln zudem oftmals mit JavaScript von dem Besucher weitere Daten, wie beispielsweise die Bildschirmauflösung oder ähnlich. Somit lässt sich leicht ermitteln, für welche Besuchergruppe eine Seite optimiert werden sollte.

Thiemo Fetzer

Thiemo Fetzer lebt seit 2008 in London und promoviert dort im Fachbereich "Entwicklungsökonomie" an der London School of Economics. Zuvor hat er Wirtschaftswissenschaften, Mathematik und Informatik in Magdeburg und Ulm studiert.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.