Logdateien und Logdienste auswerten

Zu einem gelungenen Webauftritt gehören nicht nur die inhaltlichen und konzeptionellen Aspekte, sondern auch die konsequente Wartung und Verbesserung der Seiten. Dies erfordert sowohl die Kenntnis des Besucherinteresses als auch eine schnelle Beseitigung vorhandener Problemstellen.

Ein umfangreicher Test von Hand ist jedoch nur in der Anfangsphase praktikabel, und auch eine Bewertung durch Testpersonen ist nur begrenzt realistisch. Der Anteil an nützlichen Hinweisen in Gästebüchern und E-Mail ist ebenfalls gering. Dagegen stehen mit automatisch im Hintergrund laufenden Diensten nützliche Hilfsmittel bereit, deren Leistungsfähigkeit, aber auch deren Tücken man kennen sollte.

Inhalt:

  1. Server-Logdateien
  2. Lokale Skripte
  3. Externe Dienste
  4. Fazit, Quellenverzeichnis

1. Ouvertüre

Die direkteste Methode zur Ermittlung der Seitennutzung ist die Auswertung der Logdateien, die von den meisten Webservern standardmäßig generiert und mittlerweile auch von Anbietern im unteren Preissegment zur Verfügung gestellt werden.

1.1. Logdateien auswerten

Exemplarisch für Logdateien wird das extended common log format [1.1.] beschrieben, das auch von vielen anderen Servern als Quasi-Standard verwendet wird: Der Webserver schreibt für jede Anfrage eine neue Zeile mit folgendem Aufbau in die Logdatei:

# Besucheradresse, Loginname Zeitangabe Anforderung (mit HTTP-Version) Status
1 65.233.168.7 - - [25/Feb/2002:01:35:24 +0100] "GET /ulkugel.gif HTTP/1.1" 304
2201.131.20.22 - - [25/Feb/2002:01:36:13 +0100] "GET /wasmfaq.htm HTTP/1.0" 200

- Fortsetzung der Beispiel-Zeilen:

# Übertragene Bytes Referrer Browserkennung
1 - "http://www.deinmeister.de/wasmtute.htm" "Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)"
2 38574 "http://www.google.com/search?q=tasm4&
hl=zh-CN&start=10&sa=N"
"Mozilla/4.0 (compatible; MSIE 6.0b; Windows NT 5.1)"

Je nach Serverkonfiguration können weitere Einträge hinzukommen oder entfallen. [1.2.]

Nehmen wir nun die einzelnen Einträge genauer unter die Lupe:

Besucheradresse

An dieser Stelle wird die IP-Adresse des abrufenden Rechners gespeichert. Je nach Serverkonfiguration wird auch der DNS-Name zu dieser IP aufgelöst (Ident), wodurch sich der Zugangsanbieter (Provider, Firma, Universität,...) und oft auch das Herkunftsgebiet ermitteln läßt. In Verbindung mit der Abrufzeit und der jeweiligen Anfrage kann man hiermit den Ablauf eines Seitenbesuches nachvollziehen.

Zeitangabe

Die einzelnen Einträge liegen zwar schon in chronologischer Reihenfolge vor, der genaue Zeitpunkt der Anfrage wird jedoch explizit gespeichert. Anhand der Verteilung der Abrufzeiten kann man erkennen, wann die Seite bevorzugt besucht wird (und dementsprechend daraus schließen, zu welchem Anteil Heimanwender, Werktätige und Schüler vertreten sind). Ebenso kann verfolgt werden, wie lange auf einer Seite verweilt wird und wie lange der Besuch insgesamt dauert. Hinweise darauf, wie schnell einzelne Dateien übertragen werden und ob der Browser mehrere Dateien parallel lädt kann man ebenfalls gewinnen, allerdings nur mit sehr begrenzter Genauigkeit.

Aufrufstyp

Die Art der Anfrage gibt wichtige Hinweise auf den Besuch [1.3.]: Per GET oder POST werden die Dateien normal geladen, während mit HEAD nur Informationen über die Datei abgefragt werden. Letzteres ist typisch für Suchdienste, Browser und Downloadprogramme, die die Dateien schon bei einem vorhergehenden Besuch geladen haben und nur prüfen, ob die Datei sich in der Zwischenzeit geändert hat. Auch Programme und Onlinedienste, die Webseiten auf Aktualisierungen überprüfen, verraten sich durch HEAD-Anfragen.

HTTP-Version

Die verwendete Version des HTTP-Protokolls ist relativ uninteressant, da nur einige alte Browser ausschließlich HTTP 1.0 können. Gegebenfalls kann man hier jedoch erkennen, ob es mit bestimmten Protokollversionen Probleme gibt.[1.4.]

Status

In Verbindung mit dem Dateinamen ergeben sich viele wertvolle Informationen [1.5.]. Mit Code 200 werden erfolgreich abgearbeitete Anfragen vermerkt. Interessanter sind jedoch die Codenummern 300-500:

  • Code 301,302 und 303 markieren Umleitungen auf andere interne und externe URLs. Vor allem interessant um nach einem Seitenumbau zu verfolgen, wie lange die alte Adresse noch verwendet wird.
  • Code 304 wird übermittelt, wenn sich eine Datei in der Zwischenzeit nicht verändert hat.
  • Code 404 kennzeichnet Dateien, die nicht auf dem Server vorhanden sind. Einerseit erfährt man hier, ob nach speziellen Dateien wie z.b. favicon.ico [1.6.], robots.txt [1.7.],... gesucht wird, andererseits geben sich defekte interne und externe Verweise ebenfalls durch 404-Fehler zu erkennen. An dieser Stelle sollte man auch daran denken, eine sinnvolle error.html o.ä. zur Verfügung zu stellen. Aber auch Versuche, auf versteckte Inhalte (.htaccess, Administrationsskripte, Verzeichnislisten, Paßwortlisten,...) zu gelangen verraten sich hier.
  • Code 403 wird zurückgegeben, wenn eine Paßwortabfrage fehlerhaft beantwortet wurde. Neben Tippfehlern erzeugen auch defekte Links und Einbruchversuche diesen Fehlercode.
  • Code 410 wird für die Markierung absichtlich entfernter Seiten verwendet. Ansonsten mit einer Umleitung vergleichbar.
  • Code 401 markiert einen nicht autorisierter Zugriff, häufig verursacht durch fehlende Index- oder Fehlerseiten oder durch ungünstige Serverkonfigurationen.
  • Code 500 bedeutet "Server Error". In diesem Fall sollte man dringend die Server- und Skriptkonfiguration überprüfen.

Dateiname

Daß sich hiermit die Abfragehäufigkeit und somit auch die Begehrtheit einer Seite ermitteln läßt, dürfte jedem offensichtlich sein. Aber der Dateiname verrät indirekt noch mehr Informationen: Daran, daß nach dem Abruf einer Datei die darin eingebundenen Bilder, Frames, Stylesheets, Skripte, Applets oder per Object-Tag eingebundene Bestandteile abgerufen werden oder nicht, erkennt man, ob diese vom Besucher überhaupt verwendet wurden. Wird nur ein Teil dieser Daten geladen, können Verbindungsprobleme, evtl. durch zu große Dateien, die Ursache dafür sein.

Abgerufene favicons deuten auf vom Besucher gesetzte Bookmarks in neueren Versionen des IE, und mehreren Mozilla-Ablegern hin.

Übertragene Daten (ohne Header)

Primär dient die Angabe der übertragenen Daten zur Ermittlung des übermittelten Datenvolumens als auch die Spitzenzeiten der Serverauslastung. Weicht die Angabe jedoch von der Größe der übermittelten Datei ab, so deutet dies entweder auf Verbindungsabbrüche oder auf Downloadclients mit mehreren Verbindungen bzw. nach einem Abbruch fortgesetzte (=Resume) Übertragungen hin.

Referrer

In der Referrer-Angabe wird die Adresse der zuvor besuchten Seite gespeichert. Dadurch läßt sich die Reihenfolge der besuchten Seiten nachvollziehen als auch die vorher besuchte Seite feststellen. Auf diese Weise findet man externe Links, die nicht nur von anderen Webseiten, sondern auch von Bookmarks oder auf dem Rechner des Besuchers gespeicherten Seiten stammen können. Die Häufigkeit, mit der ein Referrer vorkommt, ist auch ein gutes Indiz für die Verlinkung und die Popularität einer Seite. Externe Referrer finden sich aber auch, wenn andere Seiten unerlaubterweise eigene Inhalte in Frames einbinden oder Bilder und Downloads ohne Genehmigung verlinken.

Suchdienste finden sich ebenfalls im Referrer. Üblicherweise werden die Suchbegriffe als auch die Positionierung des Suchergebnisses als GET-Variablen im Referrer mitgespeichert. Man erkennt dadurch, ob man überhaupt durch Suchdienste gefunden wird und ob die Seite gut zu der jeweiligen Anfrage paßt oder nicht. Je nach Bedarf sollte man seine Stichwörter anpassen oder - wenn eine Seite nicht gefunden werden soll - die robots.txt anpassen.

Referrer von anderen Seiten verraten zudem, welche Sprachen die Besucher beherrschen und aus welcher Gegend sie stammen.

Browserkennung

Neben der Bezeichung des verwendeten Browsers und dessen Programmversion finden sich hier meist weitere Informationen, etwa zur verwendeten Sprachversion, des verwendeten Betriebssystems (teilweise mit Angabe der jeweiligen Version) oder zu angepaßten Browserversionen, wie sie von einigen Firmen und Providern verbreitet werden.

Suchmaschinen und Downloadprogramme verwenden üblicherweise eigene Kennungen, die oft auch die URL des Anbieters enthalten.

1.2. Gängige Fehler dieser Methode

Der ursprüngliche Zweck von Logdateien liegt in der Überprüfung der Serverfunktionalität. Entsprechend sind nur die direkt vom Webserver stammenden Daten zuverlässig. Vorraussetzung ist natürlich, daß die Logfunktion selbst fehlerfrei arbeitet, was auch nicht immer gegeben ist. Viele Fehler schleichen sich jedoch viel subtiler ein:

So ist zu beachten, daß Caching durch Browser, Proxies und Provider die Zahl der vom Server abgerufenen Dateien verringert [1.8.], insbesondere bei kurz nacheinanderfolgenden Aufrufen wie sie für Übersichtsseiten typisch sind. Ebenso lassen sich offline gespeicherte und ausgedruckte Seiten nicht erfassen. Im Gegensatz erhöhen aufgrund von Verbindungsproblemen mehrfach angeforderte Seiten die Zahl der Aufrufe übermäßig. Programme, die eine Datei in mehreren Stücken abrufen (z.B. Downloadaccelerator), müllen die Logdatei besonders stark mit mehrfachen Einträgen pro Besuch zu. Auch erzeugen einige neuere Versionen des InternetExplorers übermäßig viele 304-Einträge durch häufige Abfragen nach aktualisierten Dateien.

Aber auch das zeitliche Nutzungsverhalten kann stark vom Abrufverhalten abweichen. Sogenannte Webbeschleuniger laden die Seiten im voraus und täuschen einen schnellere Verwendung vor, dasselbe trifft auf offline kopierte Seiten zu. Andererseits kann ein Besucher andere Tätigkeiten parallel erledigen, so daß die tatsächliche Verweildauer geringer als vermutet ist.

Desweiteren ist nicht jedem Besucher exakt eine IP zugeordnet: So verteilen einige Provider die IP-Adressen während eines Besuches auf mehrere IPs (teilweise gar über mehrere C-Netze), andererseits können durch eine gemeinsam benutzte Verbindung mehrere Anwender hinter derselben Adresse liegen.

Der Referrer oder die Browserkennung können aus Datenschutzgründen verschleiert werden. Häufiger kommen ungültige Referrer jedoch durch veraltete Bookmarks und falsch eingetippte Adressen zustande. Auch die Verläßlichkeit der Browserkennung hat stark abgenommen, da als Reaktion auf Browser- und Suchmaschinenweichen sich mittlerweile nicht nur Browser wie Opera und K-Meleon als andere Browser tarnen können.

Schwerwiegender als technisch bedingte Fehler ist jedoch eine falsche Interpretation der Daten. So ist ein Seitenabruf durch einen Besucher anders zu werten als ein Abruf durch eine Suchmaschine. Besucher, die mehrere Seiten abrufen sind interessierter als solche, die sich nach einer Seite wieder abwenden (und meist durch einen Suchdienst auf die Seite gelangen). Ebenso ist zu beachten, daß häufig veränderte und dynamisch erzeugte Seiten ein anderes Cacheverhalten aufweisen und entsprechend häufiger abgerufen werden. Auch die Bewertung unvollständig übertragener Dateien ist mit Vorsicht zu genießen: Es ist nicht ohne weiteres ersichtlich, ob hier ein Verbindungsproblem vorliegt oder ob die Software des Abrufers dafür verantwortlich ist.

Aus den Logdateien ist im allgemeinen auch nicht ersichtlich, ob ein Besucher die Seite zum ersten mal aufsucht oder schon Stammgast ist, und wie gezielt er die Seite aufsucht. Ebenso sollte man nicht aus der Beliebtheit einzelner Teilseiten oder gar der Suchmaschinenposition auf die Beliebtheit der gesamten Seite schließen.

Während sich mit Logdateien qualitativ ein guter Eindruck über die Seitennutzung ermitteln läßt sind quantitative Auswertungen nur sehr begrenzt möglich. Einerseits sind die Daten für weitergehende Analysen nicht genau genug, andererseits erschwert die Vielfalt der Nutzertypen und ihrer technischen Ausrüstung und Vorlieben weitergehende Interpretationen: Wenn 60% der Besucher einen bestimmten Browser verwenden und 40% der Besucher ein bestimmtes Dateiformat auswerten können folgt daraus noch nicht, daß im Endeffekt 24% der Besucher beide Vorrausetzungen erfüllen. Es können im Extremfall ebensogut auch 40% oder 0% sein.

Zur komfortablen Auswertung von Logdateien existiert eine breite Auswahl an Logfile-Analyseprogrammen. Diese sind gut geeignet, um einen schnellen Überblick über das aktuelle und vergangene Geschehen zu erhalten, nutzen aber auch nur einen kleinen Teil der Möglichkeiten aus. Die erzeugten Statistiken sind zudem den oben genannten Fehlerquellen unterworfen. Es lohnt sich also, von Zeit zu Zeit oder bei Unklarheiten einen direkten Blick in die Logdateien zu werfen.

2. Ouvertüre

Im ersten Teil dieses Beitrages gingen wir davon aus, dass uns Log-Files zur Verfügung stehen. Was ist aber, wenn dies nicht der Fall ist? Dann sind Alternativen gefragt. Aus diesem Grunde widmen sich die beiden folgenden Teile alternativen Möglichkeiten zur Beschaffung relevanter Besucher-Daten.

2.1. lokale Zählskripte

Viele Webaccounts verfügen über die technischen Voraussetzungen für den Einsatz von lokalen Zählskripten. Besonders starke Verbreitung finden hier in Perl oder PHP geschriebene Applikationen, die meist kostenlos zur Verfügung stehen. Dabei differieren die einzelne Skripte in ihrem Funktionsumfang und dementsprechend in ihrer Größe.

In den gängigen Skript-Archiven, beispielsweise auf den Seiten des renomierten "CGI Resource Index" [2.1.], werden dutzende von Applikationen angeboten, mit denen sich mühelos Informationen über das Publikum einer Website sammeln lassen. Dabei reicht das Spektrum vom einfachen Counter bis zum ausgeklügelten "Monitoring-System".

Von besonderem Interesse ist hier ähnlich wie bei den Log-Files die Häufigkeit von Besuchen, verwendetem Browser, das Betriebssystem und die Herkunft des Besuchers. All diese Informationen lassen sich ohne weiteres loggen und statistisch auswerten.

Exemplarisch für all die guten, umfangreichen und variierenden Applikationen soll an dieser Stelle das Perl-Skript "Access Stats" [2.2.] von Chi Kien Uong betrachtet werden, dass unter der "GNU General Public License" genutzt werden darf.

2.2. Skript-Beispiel

Die zum Zeitpunkt der Artikel-Erstellung vorliegende Version 1.12 besteht aus dem Log-Programm, einer Auswertungs-Applikation und einem IP-Log-File. Die Daten werden monatsweise in separaten Dateien nach dem Muster "03-2002.txt" gesammelt. Am Log-Skript selbst müssen maximal 8 Veränderungen vorgenommen werden. Dann ist dieses im einsatzbereiten Zustand und kann in das "cgi-bin"-Verzeichnis hochgespielt werden.

Die Modifikationen am Auswertungs-Skript sind ein wenig umfangreicher. Die Einbindung des Log-Skriptes erfolgt im Html-Dokument mit Hilfe des Image-Tags. Dabei wird die Größe des Bildes mit 1x1 Pixel definiert. Zusätzlich kann mittels JavaScript oder via SSI der Referrer ermittelt und geloggt werden.

Im o.g. Log-File werden konkret folgende Daten festgehalten: der Wochentag, das Datum, die Uhrzeit, die IP-Adresse bzw. der Host, der Client und der Referrer des Besuchers.

Das Auswertungsskript stellt die gesammelten Daten für den jeweiligen Monat in übersichtlicher Weise dar. Es erscheint zunächst eine allgemeine Übersicht, dann werden die tägliche Besuche, die Besuche nach Wochentagen, die Referrer, die stündlichen Besuche, die häufigsten Länder, die häufigsten Browser, die gängisten Betriebssysteme und häufige "Hosts" präsentiert.

2.3. Kritikpunkte

Meist sind die Skripte nur für den Einsatz auf einer einzelnen Seite geeignet. Das heißt, Bewegungen innerhalb der Website sind nicht nachzuvollziehen. Will man umfangreiche Informationen zu jeder einzelnen Seite eines Webprojektes gewinnen, dann kann der Einsatz von Zähl-Skripten zu einer aufwendigen Arbeit mutieren und zudem wird die Aktion ressourcen-fressend (Platten-Platz, Rechenzeit).

Vorteilhaft ist, dass die Skripte auf dem jeweiligen Account laufen. Ist dieser erreichbar, das ist bei manchem Hoster nicht selbstverständlich, dann wird auch geloggt. Das Problem von Ausfällen ist bei externen Diensten u.U. bedeutsam und wird im dritten Teil des Artikels gesondert betrachtet.

Zählskripte sind eher eine sinnvolle Ergänzung als ein wirklicher Ersatz für Log-Files. Für die Verwendung auf der Startseite oder auf beliebten Seiten des Web-Projektes eignen sie sich hervorragend, insbesondere um tägliche oder gar stündliche Aktivitäten zu beobachten.

2.4. Fehlerquellen

Bei der Messung der Daten können ähnlich wie bei der Log-File-Auswertung Verzerrungen und Fehler auftreten. Um nicht zuviele Fakten aus Teil 1 zu wiederholen, seien an dieser Stelle stichpunktartig signifikante Fehlerursachen und -quellen genannt:

  • Browserkennung kann falsch sein (Opera, Mozilla ...)
  • Verschleierung der Client-Kennung durch Software, anonyme Proxies etc.
  • Referrer kann absichtlich oder unbeabsichtigt falsch sein
  • Caching (Browserseitig sowie durch Proxies)
  • Suchmaschinen vs. echte Besucher

2.5. weiteres lokales Material

Für die Auswertung von Besuchen und zur Gewinnung von Informationen über die Besucher steht i.a. noch mehr Daten-Material zur Verfügung. Je nach Organisation und Umfang eines Web-Projektes lassen sich weitere Informationen anhand von Log-Ins in Mitgliedsbereichen, durch Postings in Foren und durch den Einsatz von Cookies gewinnen.

Dabei können die hier gewonnenen Daten u.U. wesentlich genauere Informationen über einen Besucher bzw. eine Besucherin liefern. Werden diese Bereiche einer Website intensiv genutzt, dann wird dem Projekt meist ein hohes Maß an Vertrauen entgegen gebracht.

Nach meinen Beobachtungen reduziert sich hier in gewissem Umfang das im deutschen bzw. europäischen Raum stark ausgeprägte "Datenschutzdenken". Dies mag auch im mangelndem technischen Verständnis vieler Webnutzer begründet sein. Bemerkenswert finde ich diese Feststellung allemal.

Wie solch gewonnenes Datenmaterial ausgewertet und genutzt werden kann, soll an dieser Stelle nicht weiter betrachtet werden. Erwähnt sei nur eine kleine Anekdote aus meinem Netzleben: In einem monatlich erscheinenden Newsletter wies der Herausgeber seine Abonnenten darauf hin, dass ein Großteil der Community-Mitglieder leicht erratbare Passwörter für ihren Foren-Account nutzen.

3. Ouvertüre

Im dritten Teil beschäftigen wir uns mit der "externen" Informations-Beschaffung. Diesen Weg beschreiten i.d.R. kleine Homepage-Bastler, die ihre Website bei einem der bekannten Kostenlos-Anbieter parken.

3.1. externe Dienste

Insbesondere im Jahr 1999 schossen Anbieter von ausgeklügelten Countern bzw. Counter-Systemen aus dem Boden. An dieser Stelle sei "thecounter.com" [3.1.] erwähnt, die für die damalige Zeit einen ausgeklügelten Zähldienst mit wohltuender unsichtbarer Messung anboten.

Bis dahin war es eher Usus, dass Counter wild blinkende und überproportional mit Werbung versehene Schandflecken einer Homepage waren. Mittlerweile haben sich externe Dienste zu einem etablierten und gern genutzen Gimmick für kleine Websites entwickelt.

Momentan scheinen die Counter von "Sitemeter" [3.2.] und "Nedstat" [3.3.] sehr beliebt zu sein. Aus diesem Grunde sei auf sie kurz und abschließend verwiesen.

3.2. Technik

Zunächst muss ein Account beim jeweiligen Anbieter eingerichtet werden. Das ist für den Homepage-Betreiber meist kostenlos, kann sich aber mehr oder weniger problematisch gestalten. Der Umfang der anzugebenden persönlichen Daten für einen Account und die Anmelde-Prozedur sind gelegentlich verwirrend.

Nachdem der Account erfolgreich eingerichtet wurde, muss ein bestimmter Html-Code in das jeweilige Dokument eingefügt werden. Meist handelt es sich um eine Kombination aus einem Image-Tag und JavaScript.

Sofern die modifizierte Seite erfolgreich hochgeladen wurde, beginnt die Messung i.d.R. ohne weitere Verzögerungen. Der Webmaster gewinnt ab sofort interessante Daten über seine Besucher.

3.3. gewonnene Informationen

Bei einem guten Dienstleister ist das Spektrum der ermittelten Informationen erstaunlich breit. Die Daten werden übersichtlich aufbereitet und strukturiert präsentiert.

Man erhält Informationen über die Zahl der Besucher am heutigen Tage und im jeweiligen Monat, sowie Vergleiche mit früheren Zeiträumen. Ferner gibt es Daten über verwendete Browser, Betriebssysteme, Referrer und Hosts.

Mit Hilfe von JavaScript lassen sich Informationen über die Bildschirmauflösung, Farbtiefe, vorhandene Plug-Ins sowie aktiviertes Java und JavaScript gewinnen. Je nach Anbieter werden diese Daten kumuliert, archiviert und sortiert angeboten. Abgerundet wird die Darstellung mit ergänzenden Balken- oder Torten-Diagrammen.

3.4. Kritikpunkte

Wie es der Name schon sagt, werden externe Dienste von externen Servern genutzt. Allzu häufig verwenden kleine Homepage-Ingenieure diesen Service in ihrer Hauptkonstruktion. Da es sich dabei meist um Tabellen handelt, hängen sich die Seiten bei älteren Browsern im Falle eines Dienstleister-Ausfalls auf.

Neben der fehlenden Messung - inklusive fehlender Daten - kann es daneben also auch noch zu Besucherverlusten kommen. Dies sollte also bei der Einbindung externer Dienste unbedingt bedacht werden.

Nachteilig ist ebenfalls, dass die Betrachtung der Informationen generell via Web erfolgt und das bei einigen Anbietern die Auswertung von jedem eingesehen werden kann. Lokal lassen sich die Daten selten sinnvoll verwalten oder bearbeiten. Lediglich gespeicherte Seiten mit eventuell veralteten Daten können analysiert werden.

Positiv erwähnenswert ist die unabhängige Messung, die mittlerweile ausgereiften Systeme und der relativ geringe Aufwand, den man bei der Verwendung eines externen Anbieters hat.

Wie bei den lokalen Zähl-Skripten sind die externen Dienste kein adäquater Ersatz für Log-Files. Wer die Logs nicht zur Verfügung hat, kann trotzdem mit einem externen Dienst interessante und brauchbare Informationen gewinnen.

3.5. Fehlerquellen

Neben den üblichen Fehlerquellen bei Datenerhebungen über das Publikum einer Website, die bereits im ersten und zweiten Teil ausführlich geschildert wurden (siehe u.a. 2.4.), ergeben sich bei externen Diensten noch weitere Möglichkeiten Daten mangelhaft zu interpretieren.

Größtes Manko ist bei dieser Form, dass die externen Dienste browserseitig aufgerufen werden müssen. Dies erfolgt nicht immer, da es u.U. zu Verzögerungen oder Ausfällen beim Anbieter bzw. beim Besucher kommen kann. Ferner muss berücksichtigt werden, dass die Gewinnung zusätzlicher Informationen meist auf browserseitigem Skripting basiert. Dieses ist nicht immer bzw. bei Download-Clients und Suchmaschinen-Spidern generell nicht verfügbar.

Außerdem muss kritisch hinterfragt werden, ob beispielsweise gewonnene Informationen über die Bildschirmauflösung mit der Größe des Browserfensters gleichzusetzen sind. Bei einer Darstellung von 1280 x 1024 Pixel scheint dies wenig realistisch. Dazu seien noch 2 weitere Aspekte kurz genannt: beim Ausdrucken einer Seite gelten andere Maße und Webseiten lassen sich mittels Browser ohne weiteres manipulieren (Schriftgröße etc.).

Zu dem zuvor genannten Gedanken sollten ergänzende Überlegungen erfolgen, ob die Gestaltung der Website für eine bestimmte Bildschirmgröße aufgrund der Auflösung X sinnvoll ist. Verwiesen sei in diesem Zusammenhang auf ergonomische Aspekte und die begrenzte menschliche Wahrnehmung. [3.4.]

Abschließend sei kritisch erwähnt, dass i.a. keine Details zur Form und Art der Auswertung der Daten durch den externen Dienstleister veröffentlicht werden. Wie die dafür nötigen Daten tatsächlich zu Stande kommen, ist ebenfalls ungewiß. Was ist beispielsweise mit Besuchern bei denen nicht "alle" Daten aufgezeichnet werden konnten?

4.1. Fazit / Zusammenfassung

Qualitativ und quantitativ variieren die 3 vorgestellten Methoden im Detail erheblich. Allen gemein ist, dass der ambitionierte Webmaster Informationen über die Aktivitäten auf seiner Website erhalten möchte.

Aus Sicht des Autoren-Teams ist die Log-Datei die zuverlässigste Informationsquelle. Allerdings steht die Datei nicht jedem Webmaster zur Verfügung. Darum wurden in Teil 2 und 3 alternative Möglichkeiten der Daten- und Informationsbeschaffung aufgezeigt.

Eine umfassende kritische Würdigung der einzelnen Methoden schien aus unserer Sicht zwingend notwendig. Hier flossen insbesondere unsere Erfahrungen ein, die wir beim Betreiben diverser Webseiten gewonnen haben. Diese Seiten werden und wurden auf Web-Accounts mit variierendem Ausstattungsgrad gehostet.

4.2. Quellen

[1.1.] W3C HTTPD common log format
[1.2.] Apache-HTTP-Server Dokumentation
[1.3.] Beschreibung des HTTP-Protokoll
[1.4.] Java and HTTP/1.1 http://httpd.apache.org/info/jdk-102.html (offline)
[1.5.] HTTP-Protokoll-Statuscodes
[1.6.] favicon.de (offline)
[1.7.] The Web Robots Pages
[1.8.] Caching Tutorial

[2.1.] The CGI Resource Index
[2.2.] Access Stats

[3.1.] TheCounter.com (offline)
[3.2.] Sitemeter
[3.3.] Nedstat (offline)
[3.4.] KommDesign Texte - Aufmerksamkeit (6): Fallstudien II: über das Textlayout

Dieser Artikel entstand in Zusammenarbeit mit Tibor Schütz (www.deinmeister.de). Er hat die Einleitung und den 1.Teil geschrieben. Teil 2, 3 und 4 habe ich verfasst.

Linktipp: Claudia Reiser hat einen sehr informativen und interessanten Artikel zur Thematik "Besucherstatistiken auswerten" auf www.creisi.ch zur Verfügung gestellt.

Erstveröffentlichung: 01.05.2002



URL: http://www.schmager.de/logfiles.shtml aktualisiert: 01.01.2017
© 1998 - 2017 Jan Schmager
0.0119 s