Controlling 21

Dr. J. Schuhmacher

Logfile-Nutzeranalysen / Nutzeranalysen der Logfiles

Logfile-Nutzeranalysen für Ihren Erfolg im Internet

Nutzeranalysen erhöhen die Transparenz für Sie als Betreiber eines Internet-Auftrittes.

Controllen Sie Ihren Auftritt und führen Sie mit neuartigen Auswertungsmethoden erfolgreich den Markt an !

Tätigkeiten bei der Logfile-Nutzeranalyse sind einmalig durchzuführende Analysen sowie regelmäßige Reports.

Durch die Be- und Auswertung der Logfile-Nutzeranalyse erfahren Sie, wer Ihre Kunden und Nutzer sind und was sie auf Ihrem Internet-Auftritt suchen.

Was bedeuten die Zahlen und was können Sie damit machen? Wissens- und Erfahrungsvorsprung durch Nutzung der Logfile-Nutzeranalyse.

Nur ca. 10% sind relevant

Da ca. 90% der Rohdaten die Auswertung stören, muss man für die Analyse die Brutto-Daten zu Netto-Daten filtern. Nur so lassen sich verlässliche Erkenntnisse gewinnen, auf denen dann Ihre Entscheidungen basieren.

Hintergründe

Nutzerdaten in Logfiles - der ungehobene Informations-Schatz

Jeder Nutzer eines Internet-Auftrittes hinterlässt Spuren. Jeder Mausklick, den er macht, wird akribisch in einer speziellen Datei vermerkt. Diese Datei nennt man Logfile.

Sie besitzen somit einen riesigen Datenbestand über Ihre Nutzer und Kunden im Internet sowie deren Verhalten. Leider wird dieser wertvolle Schatz bisher unzureichend ausgewertet.

Hier erfahren Sie, wie Sie diese wichtigen Informationen für Ihren Erfolg im Internet verwenden können.

Entwicklung der Mess- und Analyseverfahren

Der Weg zum Internet-Controlling

Am Anfang der Entwicklung des WWW fanden sich so genannte Counter auf vielen Seiten, deren Wert eher bescheiden war, da jeder hier die Zahlen einstellen konnte, wie er wollte. Auch die Zählung erfolgte unregelmäßig. Darauf folgten Logfile-Analyse-Programme, die viele Zahlen auswarfen, deren Bedeutung niemand genau erklären konnte, und mit denen viel - vermeintlich wissenschaftlicher - Schindluder getrieben wurde. Nun gelangt die Internet-Branche in die dritte Epoche des qualitativen Internet-Controllings mit aussagekräftigen und leicht verständlichen Bewertungen der Zahlen auf bereinigter Nettobasis.

Counter

Hierbei handelt es sich um auf dem Server installierte Zähler, die meist mittels CGI programmiert sind und vermeintlich jeden Zugriff zählen. In der Regel registrieren Sie jedoch nur unterschiedliche IPs. Ferner sind sie in jeder Hinsicht manipulierbar und somit völlig wertlos.

Logfile

Hierbei handelt es sich um eine Textdateien, in der jede Aktion eines Nutzers auf dem Internet-Auftritt und jede Reaktion des Servers registriert wird. Der Nachteil sind die oft riesigen Dateien, da wirklich alles aufgezeichnet werden kann.

Hiermit wurden sogenannte Zugriffsmessungen durchgeführt.

Alle Analysen mittels dieser Logfiles beruhen auf Brutto-Daten. Die daraus analysierten Ergebnisse sind unbrauchbar. Z.B. wird die Browser-Verteilung in der Regel anhand aller Einträge durchgeführt, gleichgültig, was dies auch gewesen sein mag. Aufgrund derart unbereinigter Bruttodaten kann man keine Verteilung z.B. nach Seitenabrufen erstellen. Der uns Menschen klar verständliche Begriff "sichtbare Seite" existiert im Logfile nicht! Dort gibt es nur zahllose Einzelteile, genannt Hits. So kann eine Seite aus ca. 10-50 Hits bestehen, die zu exakt dieser Anzahl an Zeilen / Einträgen im Logfile führt.

Pixel und Logfile

Bei diesem Verfahren wird eine kleine Grafik (in der Regel ein 1*1 Pixel großes transparentes GIF) in jede HTML-Seite eingebaut. Diese kleine Datei erzeugt auf einem anderen Server einen Abruf, der wiederum in einem Logfile eingetragen wird. Die dadurch erzeugten Logfile-Dateien sind als indirekte bzw. abgeleitete Daten wesentlich kleiner. Aus diesem Grund wird es z.B. vom IVW verwendet, um die Abrufzahlen eines Internet-Auftrittes zu messen.

Allerdings können bei diesem Verfahren auch wichtige Daten fehlen, da das Pixel selbst nicht immer aufgerufen werden muss. Oft wird es am Ende einer Datei eingebunden. Wenn ein Nutzer einer großen Datei bei einem langsamen Internet-Anschluss schnell weiterklickt, kommt es z.B. nicht zum Aufruf der kleinen Grafik. Ferner fehlen z.B. alle Downloads von PDFs und Exe-Dateien.
Bei diesem Verfahren besteht ferner das Problem der Übergabe der Referer. Wer hier nicht sauber programmiert, erhält als Ursprungsadresse immer nur seine eigenen Seiten, und verliert alle Angaben der Suchmaschinen und fremden Seiten, von denen der Nutzer vorher kam.

Bereinigte Nettodaten

Aus den oben geschilderten Nachteilen wurde in den letzten Jahren von mir das Verfahren der bereinigten Nettodaten konzipiert. Hierbei dienen die originalen Logfiles als Grundlage. Da sie jedoch riesige Brutto-Datenmengen enthalten, werden diese je nach Analysezweck sinnvoll auf die jeweils erforderlichen Nettodaten gefiltert. Hierbei bleiben alle wertvollen Daten erhalten und die Datenmenge wird handhabbar. Im Grunde wird erst durch die Bereinigung eine zutreffende Aussage über viele Felder möglich.

Bewertung der Zahlen

Noch wichtiger als die Lieferung solider, verlässlicher Netto-Daten ist die Bewertung derselben. Sind z.B. 10.000 Abrufe für die Datei X gut oder schlecht? Waren es überhaupt menschliche Abrufe oder Suchmaschinen oder sogar Hackertools? Liegen Sie mit diesem Wert über oder unter Ihrem Branchendurchschnitt? Gibt es Steigerungsmöglichkeiten? etc. Erst die professionelle Bewertung einer Zahl macht sie sinnvoll.

Hieraus folgen dann die ausgesprochenen Handlungsempfehlungen, die Ihren Auftritt verbessern, damit Ihre Kunden sich wohler fühlen, Ihre Kosten sinken, Ihre Gewinne steigen.

Normen für Logfile-Formate

Standards

Das Hypertext Transfer Protocol (HTTP) ist standardisiert. Die erste Version 1.0 stammt aus dem Jahr 1990, die derzeit aktuelle Version 3 ist seit 2022 in Gebrauch.

Jedes Mal, wenn ein Besucher Ihren Internet-Auftritt besucht, hinterlässt er vorher genau festlegbare Spuren, die präzise aufgezeichnet werden.

Weitere Details zum derzeitigen Internet-Standard HTTP/3.0 sowie unter Protocols beim W3C.

Es gibt zahlreiche Standard-Logfile-Formate, die jedoch im Grunde zusammengefasst sind zum üblicherweise verwendeten Combined oder Extended Logfile.

Agent Logfile

Im Agent Logfile werden nur Informationen über den Client gespeichert. Es finden sich dort Angaben zum Browser und Betriebssystem. Zu den darin befindlichen Detailinformationen siehe den Abschnitt Bestandteile: Browser und Betriebssystem.

Z.B.: "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Opera 7.22 [en]". - Die darin befindlichen Informationen helfen Ihnen somit, Ihre Seiten auf die von Ihren Nutzern verwendete Software zu optimieren.

Common-Logfile / Access-Logfile

Das Common-Logfile bietet weiter reichende Informationen. Die aufgezeichneten Blöcke umfassen die IP, den Logname, die Web-Server-Authentifizierung, das Datum, die Uhrzeit und Zeitzone, die Zugriffsmethode / Aktion, die abgerufene Datei, das verwendete Protokoll, die Server-Antwort / HTTP-Statuscodes und die Dateigröße.

Hierbei ist die Reihenfolge wie oben genormt. Z.B. "67.169.19.70 - - [16/Feb/2004:02:53:56 +0100] "GET /dateiname.htm HTTP/1.1" 200 1660". - Mit diesen Informationen kann man bereits sehr viel auswerten.
Weitere Informationen zum Common-Logfile-Format erhalten Sie bei

www.w3.org/Daemon /User/Config/Logging.html #common-logfile-format. Teilweise wird dieses Common-Logfile auch Access-Logfile genannt. Das ist nach der W3C-Regelung jedoch nicht zutreffend. Weitere Informationen zum Access-Logfile-Format erhalten Sie bei https://www.w3.org/ /Daemon/User/ Config/Logging.html #AccessLog.

Referer-Logfile

In diesem Referer-Logfile ist der Name der vorher vom Nutzer besuchten Seite und der nun besuchten angegeben. Z.B. "http://www. Herkunftsname.de/ rubrikname/ dateiname.htm" www.Zieladresse.de/ seite.htm - Teilweise befindet sich ein Pfeil (-->) zwischen den zwei Angaben und am Ende der Zeile vereinzelt auch das Datum-/Zeit-Feld. "http://www.beispiel.de/ Rubrikname/ dateiname.htm /index_1.gif? V=1&R=Ursprung.de/ Rubrikname/ dateiname.htm [01/Jun/2001:00:05:54 -0700]"

Combined Logfile

Hierbei handelt es sich ursprünglich um die Zusammenfassung des Common-Logfiles und des Agent Logfiles. Z.B. 67.169.19.70 - - [16/Feb/2004:02:53:56 +0100] "GET /dateiname.htm HTTP/1.1" 200 1660 "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Opera 7.22 [en]"

Error-Logfile

Manche Server erstellen für aufgetretene Fehler ein eigenes Logfile. In der Regel werden fehlerhafte Einträge jedoch im Common-Logfile mit eingetragen. Weiter Informationen zum Error-Logfile-Format erhalten Sie beim W3C.

NCSA Common Format

Die Abkürzung NCSA steht für National Center for Supercomputing Applications, eine Einrichtung an der University of Illinois. Dort wurde der erste Browser (Mosaic) entwickelt.

Das NCSA Common Format ist wie folgt aufgebaut: host rfc931 authuser [DD/Mon/YYYY:hh:mm:ss] "request" ddd bbbb "opt_referer" "opt_agent"
Dabei bedeuten host: Entweder der über DNS aufgelöste Name oder die IP des anfragenden Rechners, rfc931: Entweder einen Gedankenstrich -, oder die Information von identd für die Person, authuser: Entweder einen Gedankenstrich -, oder der Benutzername für die Autorisierung, DD: Tag, Mon: Monat (dreistelliger Kalendername), YYYY: Jahr, hh: Uhrzeit (im 24-h-Format, Zeitzone des Servers), mm: Minuten, ss: Sekunden, request: Die erste Zeile des HTTP requests des Clients, ddd: Status-Code, der vom Server ausgegeben wird, bbbb: Anzahl der Bytes, die gesendet wurden, aber ohne den HTTP/1.0 header, oder einen Gedankenstrich -, falls nichts angegeben ist, opt_referer: Referer, falls vorhanden und eingestellt, opt_agent: Browser und Betriebssystem des Clients, falls diese Information geliefert wird.

Microsoft IIS (Internet Information Server)

Microsoft setzt ein proprietäres, d.h. völlig eigenständiges, Logfile-Format ein. Der Hauptunterschied liegt in den Kommata als Trennzeichen. Allerdings liefert es einige zusätzliche Informationen: Die IP-Adresse des Clients oder dessen Domain-Name, den Benutzername (falls es sich um eine geschützte Seite handelt), das Datum, die Uhrzeit, die Dienste (wie W3SVC: HTTP, MSFTPSVC: FTP oder GopherSvc: Gopher), den Name des eigenen Firmen-Servers, die IP-Adresse des eigenen Firmen-Servers, die Zeit, die der Server zur Beantwortung der Aktion / Anfrage benötigte, die Dateigröße_1 (Anzahl der Bytes, die der Browser an den Server versandte), die Dateigröße_2 (Anzahl der Bytes, die der Server an den Browser versandte), den HTTP-Status-Code, dies wird an den Client geliefert, den NT-Status-Code, das Ausführungsergebnis des Servers, den HTTP-Befehl samt Pfad der angefragten Information.
Z.B. in der Art "122.116.255.255, anonymous, 03/20/98, 23:58:11, MSFTPSVC, SALES1, 192.168.114.201, 60, 275, 0, 0, 0, PASS, datei.htm"

Weiter Informationen zum IIS-Logfile-Format erhalten Sie bei IIS Log File Formats.

W3C Extended Format

Die Abkürzung W3C steht für World Wide Web Consortium. Dieses Konsortium entwickelt das Internet weiter. Das W3C Format scheint eine Mischung zwischen dem NCSA Logfile Format und dem IIS Log File Format zu sein. Hier finden sich mit ca. 20 Feldern die umfassendsten Inhalte, die auf vielen Servern frei auswählbar und einstellbar sind:
Date: Datum, Time: Uhrzeit, c-ip: IP-Adresse des Clients oder dessen Domain-Name, User Name: Name des Users, in der Regel Anonymous, deshalb fehlt das Feld oft, s-sitename: Dienste (W3SVC: HTTP, MSFTPSVC: FTP, GopherSvc: Gopher), den s-computername: Name des eigenen Firmen-Servers, die s-ip: IP-Adresse des eigenen Firmen-Servers, die cs-method: Zugriffsmethode des Clients, die cs-uri-stem: angeforderte, abgerufene Datei, die cs-uri-query: Suchstring des Nutzers, in der Regel leer, den sc-status: HTTP-Status-Code. Dies wird an den Client geliefert, den sc-win32-status: NT-Status-Code, Ausführungsergebnis des Servers, das sc-bytes: Dateigröße_2 (Anzahl der Bytes, die der Server an den Browser versandte), die cs-bytes: Dateigröße_1 (Anzahl der Bytes, die der Browser an den Server versandte), die time-taken: Zeit, die der Server zur Beantwortung der Aktion / Anfrage benötigte, den s-port: Serverport, in der Regel 80, die cs-version: das eingesetzte HTTP-Protokoll, den cs(User-Agent): Browser mit Betriebssystem, das Cookie: der Browser beinhaltet ein Cookie, den cs(Referer): vorher besuchte Seite.
Ein Beispiel wäre #Fields: date time c-ip s-sitename s-computername s-ip cs-method cs-uri-stem cs-uri-query sc-status sc-win32-status sc-bytes cs-bytes time-taken s-port cs-version cs(User-Agent) cs(Referer)
2004-05-01 00:17:34 216.39.48.187 W3SVC2 WEB2 192.168.156.148 GET /rubrik/pdf/dateiname.pdf - 200 0 31310 175 5688 80 HTTP/1.1 Mozilla/4.0 +(compatible; +MSIE+5.0; +Windows+95) +VoilaBot +BETA+1.2 +(http://www.voila.com/) -

Weiter Informationen zum Extended-Logfile-Format erhalten Sie beim w3C.

Strato

Bei der Firma Strato handelt es sich um einen großen deutschen Account-Provider, der hunderttausende von Internet-Auftritten verwaltet. Der Hauptunterschied des Strato-Logfile-Formats zum Standard besteht hier in einer teilweisen Übersetzung der IPs in teilweise sprechende Herkunftsadressen (Hostnamen). Das Problem liegt in den Worten teilweise. Weder werden alle IPs übersetzt (meist nur ca. 50%), noch sind alle daraus resultierenden Namen wirklich verständlich.

1 & 1 Internet AG (ehemals Puretec)

Hier sind alle Domains in ein Logfile zusammengeschrieben. Ansonsten entspricht das Logfile-Format von 1 & 1 Internet AG (ehemals Puretec) dem Apache-Format. Seit einiger Zeit wird es am Ende der Zeile ergänzt um das Feld X-forwarded-for.

Linux / Apache

Die meisten Internet-Auftritte werden über einen Server gesteuert, der auf dem Betriebssystem Linux mit dem Apache-Server läuft. Er kann viele Formate benutzen (NCSA combined/XLF/ELF log format or common/CLF log format). Meist sind die Server-Logfiles im Normalzustand belassen und entsprechen somit dem Standard, der auf dem W3C-Extended-Logfile-Format fußt. Allerdings kann man den Apache Server mit der Datei http.conf beliebig konfigurieren.

Bei dem Apache-Server existiert der Befehl Logformat mit ca. 30 Feldern, die auswählbar und konfigurierbar sind. In der Regel sehen moderne Unix-Logfiles so aus: 80.131.239.64 - - [16/Feb/2004:09:30:02 +0100] "GET /rubrik/dateiname.htm HTTP/1.0" 200 8036 www.Firmenname.de "http://www. Herkunftsadresse.de/ rubrik/ dateiname.htm" "Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)" "10.183.53.156" - Das letzte Feld mit der zusätzlichen IP bedeutet X-forwarded-for. Dies liegt teilweise vor, wenn die erste IP ein Proxy darstellt und die letzte IP dann den Endnutzer anzeigt. Oft ist dieses Feld allerdings mit einer Leerstelle gekennzeichnet. Dann ist die erste IP bereits der Endnutzer.

Cache und Proxy - Tests

Fazit

Die immer wieder vorgebrachte Behauptung: Logfiles sind wertlos, da sie kaum etwas aufzeichnen, ist unzutreffend. Alle aktuellen Tests belegen, dass sämtliche relevanten Aufrufe eingetragen werden. Die Wirkung des Browser-Caches ist gering und die der Proxies nicht messbar. Die Server-Logfiles sind somit eine gute Grundlage für ein umfassendes Internet-Controlling.

Hintergrund / Historie

Wilde Behauptungen

Seit vielen Jahren wird immer wieder behauptet, aufgrund der Caches im Browser, der (Hard- und Software-) Proxies im Internet und in Firmen, Institutionen etc. sowie Software-Proxies im oder auf dem Betriebssystem des Nutzers würden kaum Einträge in den Server-Logfiles der Internet-Auftritte eingetragen werden, da sich angeblich die meisten Aufrufe nur auf diese Zwischenspeicher beziehen. Angeblich sollen die meisten Inhalte der Internet-Auftritte somit aus Caches und Proxies bedient werden. Wilde Zahlen kursieren von 30% bis über 70% Abweichung der realen Abrufzahlen von den im Server-Logfile festgehaltenen.

Dünne Fakten

Geht man den Angaben nach, so stößt man auf nur wenige "Belege", deren Überprüfung wiederum erstaunliches zu Tage fördert. Als Quellen werden Carsten Pohle (1999) und letztendlich Xavier Drèze, Fred Zufryden (1998) genannt. Letztere bezogen Ihre Daten wiederum von Paul Grand, Chairman of Netcount, (Vorstandsvorsitzender) einer Firma, die damals teure Dienstleistungen anbot, um die angeblich wertlosen Logfile-Daten durch ihre eigenen angeblich "hochwertigeren" Cookie-Daten zu ersetzen - eindeutig einer Partei im damals heftig ausgefochtenen Kampf um den Wert von Cookies.

Caches und Proxies dienten vor allem in den 90er Jahren, als die Bandbreite noch gering war, dazu, den Datentransfer und damit den Seitenaufbau beim Nutzer zu beschleunigen und das überlastete Internet durch geringeren Netzwerkverkehr zu entlasten.

Theorie statt Praxis

Die Studie von Drèze und Zufryden beschäftigte sich jedoch mit den Fehlern der Marketingwerte Reach, Frequency und Gross Rating Points bei Internet-Werbung.
Ferner befasst sich die Studie eher mit Details wie der damaligen Problematik der eineindeutigen Zuweisung der Benutzer zu einer IP. Dabei wird Caching anhand des Beispiels eines Banners - also eines Bildes - im Zusammenhang mit der Werbewirkung besprochen.
Es ging in der Studie somit nicht primär um Caching von HTML-Inhalten. Dass Bilder zwischengespeichert werden, ist evident und für das Internet-Controlling der meisten Firmen irrelevant! Registriert und gezählt werden für ein Internet-Controlling die Seitenabrufe im Server-Logfile.

Benutzer

Die in der Studie benutzen Zahlen beziehen sich ausschließlich auf die Unterschiede der identifizierten "Benutzer" durch Cookies gegenüber einer einfachen IP-Gleichsetzung mit Benutzern (S.13f.). Nirgends wird behauptet, dass es sich hierbei um generelle Fehlerraten eines Server-Logfiles handelt!

Behauptungen zum Cache

Beide US-Autoren behaupteten 1998 im Kapitel 3 (S.17) Cache Recovery Algorithms, dass Caching dazu führt, dass jeder Aufruf einer Datei (gleichgültig welcher) nur beim ersten Aufruf eines Besuchers im Logfile geschrieben wird. Offensichtlich wurde das nie wirklich nachgeprüft. Wie meine Untersuchungen zeigen, ist dies unzutreffend. Zur Ehrenrettung der beiden Forscher muss jedoch erwähnt werden, dass sie dabei von einem - rein theoretischen - perfekten Cache ausgingen.

Simulation

Drèze und Zufryden simulierten für ihre Theorie deshalb auch einen perfekten Cache und errechneten dann Korrekturwerte für ihre Algorithmen, um den Benutzungspfad eines Nutzers (Tracking/Tracing) besser nachvollziehen zu können. Es handelte sich somit nicht um realistische Praxiswerte. Die von beiden durchgeführten Versuche fanden anhand einer hochspezifischen Website mit fiktiven Grundannahmen bezüglich Cache und Cookies statt. Zumindest diese Kombination ist heute irrelevant.

Die USA 1998 und die Welt in den 2020er Jahren

Generell sollte man US-Ergebnisse nicht ungeprüft auf Europa anwenden. Überdies hat sich die Technik im Internet seit 1998 deutlich weiterentwickelt.

Was bedeutet dies nun für uns heute?

Neue Tests

Aufzeichnung jedes Klicks!

Mit dem Eintrag < meta http-equiv="expires" content="0" > in der HTML-Seite wird in den Browsern Opera, Firefox, Netscape und Internet-Explorer jeder erneute Klick auf einen Link als Aufruf gewertet und in das Server-Logfile geschrieben.
Bei wiederholtem Aufruf eines Links erfolgt dies mit einem Status 304, wobei keine Daten mehr vom Server herunter geladen werden. Alle Bilder und CSS werden aus dem eigenen Browser-Cache entnommen. Der Server wird somit nicht merklich belastet. Der Nutzer verspürt keine bemerkbare Verzögerung.
Heute ist dies - auch ohne obigen Eintrag - der Standard bei jeder statischen HTML-Seite. D.h. jeder Seitenaufruf, auch wiederholte, werden registriert.

Sonderfall Internet-Explorer

Beim alten Internet-Explorer tritt / trat hingegen der Sonderfall ein, dass er innerhalb einer kurzen Zeit keinen erneuten Klick auf einen besuchten Link als 304 meldet. Erst nach ca. 1 Minute wird die Seite als erneut besucht mit 304 im Logfile eingetragen. Vorher scheint der IE sie aus seinem eigenen Cache zu entnehmen.

Zurück-Taste

Beim Rücksprung mit der "Zurück-Taste" wird jedoch bei vielen Browsern kein Eintrag im Logfile erzeugt.
Manche, wie der Opera laden allerdings jedes Mal evtl. vorhandene JavaScripts nach.

Bei manchen Browsern werden nach etwa einer Minute sogar die internen Rücksprünge mit der "Zurück-Taste" im Logfile mit dem Status 304 vermerkt. Dies widerlegt auch die Behauptung, dass es an den alten Browsern lag, dass die Logfiles früher angeblich falsch aufzeichneten.

Ein Löschen des Caches im Browser (interner Zwischenspeicher) ist erfolgreich und führte in allen Fällen zum Neuladen der danach aufgerufenen HTML-Seiten mit dem Status 200.

Browser-Spezifika

Besuchte Seiten werden beim Opera auch nach dem Löschen des Caches dennoch optisch als besucht gekennzeichnet. Er scheint auch nicht alle Bilder im Cache zu löschen. Zumindest werden sie teilweise im Logfile mit Statuscode 304 vermerkt.

Google-Cache

Selbst das Cache von Google speichert bei HTML-Dateien nur die Inhaltsdatei und nicht die Zusätze, sodass man den Zugriff messen kann. Bei falscher Konfiguration des Logfile-Analyse-Programms kann dies allerdings zu einer geringeren Anzeige der Abrufe führen.
Jedoch ist die Anzahl derartiger Abrufe in der Regel gering. Die meisten Nutzer scheinen bei der Suche in Google den Link zum Internet-Auftritt anzuklicken und nicht den Cache. Dies darf auch kaum verwundern, da dort die meisten Seiten unschön bis falsch dargestellt werden und deren Inhalt meist nicht aktuell ist.

Resümee

Die Logfiles enthalten wertvolle Daten. Die Browser cachen heute nur relativ wenig HTML-Inhalte. Die Wirkung von Proxies lässt sich seit vielen Jahren nicht mehr messen. Aufgrund der Möglichkeit des Einsatzes der "Zurück-Taste" im Browser können korrekte Pfade (Tracking/Tracing) eines Nutzers nicht durch einfache Analyse einfacher Server-Logfiles durchgeführt werden. Hierbei handelt es sich jedoch um eine logische Systembedingung, die alle Analysemethoden betrifft. Selbstverständlich sind davon auch die auf der Zählung von eingebetteten Grafiken beruhenden Messverfahren bettoffen, da insbesondere Grafiken im Browser-Cache zwischengespeichert werden. Dies betrifft außer beim Opera auch die durch JavaScript nachgeladenen Grafiken.

Feststellungen

Es ist denkbar, einen Proxy oder Browser-Caches zu bauen, die tatsächlich Zugriffe auf einen Internet-Auftritt verbergen, so dass Einträge in den Logfiles geringere Zugriffe aufweisen. Dies ist jedoch die Theorie, die sich in aktuellen Praxistests nicht belegen ließ!

Gründe

Dass die neuen Praxistests die alte Theorie widerlegen, könnte an folgenden Details liegen: Da wäre zuerst einmal der dramatische Ausbau des Internets in den letzten Jahren. Die verfügbaren Bandbreiten nahmen derart zu, dass es heute für klassische HTML-Dateien keine Engpässe mehr gibt (Video-Streaming ist eine andere Anforderungskategorie) und Proxies sowie Caches überflüssig wurden. Zudem wurden Angebote im Internet zunehmend dynamisch und laufend aktualisiert. Auch dies reduziert den Wert des Zwischenspeicherns. Caches und Proxies sind bei laufend aktualisierten Inhalten sogar schädlich. Letztendlich sind angesichts von Flatrates für Endanwender und drastisch gesunken Preisen für Datenvolumina für Anbieter auch die Kosten für den Traffic (zumindest im Bereich HTML) heute vernachlässigbar. Sie rechtfertigen offensichtlich für keine Firma, Institution etc. mehr den Einsatz von "eng" konfigurierten Proxies.

Testbedingungen

Hardware

Diese Tests wurden mit diversen PCs und Laptops Baujahr 1999 bis heute mit diverser Sonderausstattung durchgeführt.

Software

Sämtliche verfügbaren Browser, aller Versionen oft sogar deutsche und englische wurden auf vielen Betriebssystemen: von Windows 98, Windows XP SP2, Home und Professional, Windows 7, Vista, 8, 10, 11 sowie Apple Macintosh. Zudem wurde die Software sowohl in der Standard-Konfiguration als auch mit individuellen Sondereinstellungen getestet.

Provider

Diverse Account- und Access-Provider wurden hierzu geprüft.

Gegenteilige Ansichten / Hilfe

Diese Untersuchungen sollen eine Diskussion anregen. Sie sind nicht als das "letzte Worte" zum Thema Cache und Proxies gedacht. Deshalb bin ich für jeden Hinweis dankbar.
Wenn Sie auch nur einen Beweis für den negativen Einfluss von Caches oder Proxies auf Server-Logfiles in der heutigen Praxis finden können, bitte ich um eine Mitteilung.

Bestandteile des Logfiles

Im Folgenden soll jeder Block eines Eintrages in einem Standard-Logfile erklärt werden. Prinzipiell handelt es sich bei einem Logfile um eine reine Textdatei mit Zeilenumbrüchen. Jede Aktion, die ein Nutzer auf dem Internet-Auftritt durchführt, ist in der Regel im Logfile in einer eigenen Zeile festgehalten. Grundsätzlich sind in einer solchen Zeile alle Großblöcke durch Leerzeichen voneinander getrennt.

IP - Internet Protokoll

Bei der IP - genau genommen der IP-Zahl - (in der derzeit meist protokollierten Version 4 des Internet Protokolls) handelt es sich um eine Zahlenkombination. Die Möglichkeiten liegen zwischen 0.0.0.0 und 255.255.255.255. Man unterteilt die Blöcke von links nach rechts in A, B, C, D. In jedem Block existieren 2 hoch 8 Möglichkeiten. D. h. es werden nur die 256 Zahlen 0 bis 255 vergeben. Insgesamt ergeben sich somit 2 hoch 32 denkbare IPs. Allerdings besitzen die amerikanischen Stellen ein derartiges Monopol bei der Vergabe, dass nur ein Bruchteil tatsächlich vergeben ist und davon wieder nur ein Teil eingesetzt wird.

Die IP ist im Prinzip mit der Postleitzahl zu vergleichen. Damit wird ein Anschluss an das Internet gekennzeichnet. Es finden sich in der Regel keinerlei Benutzernamen im Logfile. Hinter der IP verbirgt sich oft ein großer Provider, eine Universität oder eine Firma. Einzelpersonen besitzen nur äußerst selten eine feste IP. Ihnen werden vom Provider dynamisch, bei Bedarf, eine IP zugewiesen.

Bitte beachten Sie, dass das IPV6 zwar schon länger verwendet wird, aber nur in wenigen Logfiles auch eingetragen wird respektive aktiviert wurde. Dort finden sich dann auch Buchstaben und insgesamt viel mehr Felder: "2001:0db8:0000:08d3:0000:8a2e:0070:7321" ist durchaus möglich. Allerdings wird es oft verkürzt, weil man die Nullen zu einer zusammenfasst, oder ganz entfallen lässt. So ist auch "2001:db8::8d3::" als Eintrag möglich.

Logname / Geschützter Zugang

Handelt es sich bei der abgerufenen Datei um eine geschützte Seite, so findet sich hier der Eintrag des Benutzernamens. Das Feld Logname wird sehr selten benutzt. Entweder handelt es sich um öffentlich zugängliche Seiten, oder der Passwortschutz wird auf anderem Wege erreicht. Bei den meisten Auftritten finden sich deshalb keine Einträge in diesem Feld des Logfiles. Es ist dann mit einem Gedankenstrich gekennzeichnet.

Web-Server-Authentifizierung / Passwort

Handelt es sich bei der abgerufenen Datei um eine geschützte Seite, so findet sich hier der Eintrag des zum Benutzernamen gehörenden Passwortes. Bei den meisten Auftritten finden sich keine Einträge in diesem Feld des Logfiles. Das Feld Web-Server-Authentifizierung wird sehr selten benutzt. Entweder handelt es sich um öffentlich zugängliche Seiten, oder der Passwortschutz wird auf anderem Wege erreicht. Der Eintrag ist dann mit einem Gedankenstrich gekennzeichnet.

Datum, Uhrzeit und Zeitzone

Beim Feld Datum und Zeit des Logfiles handelt es sich um ein in eckigen Klammern stehendes kombiniertes Feld der folgenden Form [Tag/Monat/Jahr: Stunde:Minute:Sekunde Zone], also [29/Mar/2004:07:54:43 +0200].
Der zweistelligen Tagesangabe folgen - getrennt durch Schrägstriche - die dreistellige englischsprachige Monatsabkürzung und das vierstellig angegebene Jahr. Daran anschließend - getrennt durch Doppelpunkte - werden jeweils zweistellig Stunden, Minuten und Sekunden angegeben. Nach einem Leerzeichen folgt die vierstellige Zeitzone in Bezug auf die GMT(Greenwich Mean Time / London). Statt GMT findet sich in der Fachliteratur auch oft UTC - Universal Time Coordinate - Koordinierte Weltzeit.

Zur Umrechnung der Zeitzonen gibt es UTC-Zeitzonenrechner. Weitere Informationen zur Weltzeit, Sommerzeiten, Zeitzonen, der Uhrzeit aller Länder etc. finden Sie unter Koordinierte Weltzeit.

Die immer dreistelligen Monatsabkürzungen lauten Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec.

Bei der Zeitzone wird auch die Sommerzeit mit angegeben. MEZ ist immer Greenwich plus 1 Stunde (+0100), MESZ dementsprechend +0200.

Zugriffsmethode / Aktion, Abgerufene Datei, Verwendetes Protokoll

Das im Logfile auf das Datum folgende Feld Zugriffsmethode bezeichnet die durchgeführte Aktion und steht immer in Hochzeichen: "GET /verzeichnis/ dateiname.htm HTTP/1.0"
In diesem ebenfalls kombinierten Feld wird die Aktion, die betroffene Datei und das verwendete HTTP-Protokoll festgehalten.

Überwiegend handelt es sich bei der Aktion um ein GET, seltener ein POST oder ein HEAD. GET bedeutet, dass ein Anfrager etwas abgerufen (geholt) hat. Beim Eintrag POST hat ein Nutzer etwas geschickt oder eine Aktion z.B. in einem Interaktions- oder Transaktionsmodul ausgelöst.

Auf die Aktionsbezeichnung folgt der Name der betroffenen Datei. Dies kann ein sprechender Name oder ein teilweise kombinierter Zahlen- und Buchstabencode sein, der aus einer Datenbank stammt. In wieweit der Domainname und die Verzeichnisstruktur angezeigt werden, hängt von den jeweiligen Server-Einstellungen ab.

Am Ende des Blockes folgt die Bezeichnung des bei der Aktion verwendeten HTTP-Protokolls. Meist steht hier heute HTTP/2.0, oft HTTP/1.1, teilweise noch HTTP/1.0. Je höher die Zahl ist desto besser, da dann z.B. Grafiken schneller abgerufen werden, sich somit für den Nutzer die Ladezeit der Gesamtseite verringert. Ein hoher Anteil an HTTP 1.0 bedeutet, dass Sie viele Nutzer mit alten Browsern als Gäste besitzen, die aufgrund der ständigen Einzelanfragen an den Server für jedes Detail bei Grafiken mit einer langen Ladezeit bestraft werden.

Server-Antwort / HTTP-Statuscodes

Abgetrennt vom Aktionsfeld mit einem Leerzeichen folgt der HTTP-Status-Code - der Antwortcode des Servers. Dieser besteht aus drei Zahlen, die unterschiedliche Zustände charakterisieren. Am wichtigsten - weil häufigsten - sind hierbei: 200, 304 und 404.

1xx - Informationen - informative Antworten, Informational responses

Vorgesehen ist der Zahlenbereich 100 bis 199. Davon werden derzeit jedoch nur wenige (vier) verwendet. Im Prinzip ist alles in Ordnung. Die Bearbeitung der Anfrage dauert trotz der Rückmeldung noch an. Derartige Zwischenantworten sind selten, aber manchmal notwendig, weil manche Clients nach einer bestimmten Zeitspanne (Zeitüberschreitung) automatisch annehmen, dass ein Fehler bei der Übertragung oder Verarbeitung der Anfrage aufgetreten ist, sowie dann mit einer Fehlermeldung abbrechen.
100 bedeutet Continue - Fortfahren.
101 bedeutet Switching Protocols - Protokoll wechseln.
102 bedeutet Processing - In Bearbeitung.
103 - Early Hints - Zeitiger Hinweis, z.B. beim Vorausladen von Dateien.

2xx - Erfolgreiche Operation - Successful responses

Vorgesehen ist der Zahlenbereich 200 bis 299. Davon werden derzeit jedoch nur 10 verwendet. Die Bearbeitung der Anfrage ist /war erfolgreich.
200 bedeutet OK - In Ordnung - Der Server kann die angeforderten Daten, wie gewünscht, versenden. Dies ist der Normalfall, wenn keine Probleme auftreten. Der größere Anteil aller Anfragen an den Web-Server sollte mit diesem Statuscode enden - ansonsten liegen erhebliche Probleme vor..
201 bedeutet Created - Erstellt - Ein Objekt (z.B. eine Datei oder ein Verzeichnis) wurde auf dem Server erfolgreich angelegt. Das kann vorkommen, wenn die Anfrage des Browsers an den Server mit einer der HTTP-Übertragungsmethoden POST oder PUT erfolgte und eine Anweisung zum Erstellen des entsprechenden Objekts enthielt.
202 bedeutet Accepted - Akzeptiert. Der Server hat die Anfrage des Browsers akzeptiert, liefert aber keine Daten als Antwort. Der Server schreibt die Daten statt sie zu senden in eine Datei und teilt in der Meldung mit, wo die Daten später zu finden sein werden. Diese Meldung sagt nichts darüber aus, ob der Server die Anfrage erfolgreich behandeln kann. Er hat sie einfach nur akzeptiert und die Abarbeitung auf einen späteren Zeitpunkt verschoben.
203 bedeutet Non-Authoritative Information - Unverbindliche Informationen. Dieser Statuscode sollte von einem Server anstelle von 200 zurückgegeben werden, wenn es sich nicht um den Original-Server handelt, sondern beispielsweise um einen Proxy-Server. Der Browser erfährt auf diese Weise, dass die Daten erfolgreich gesendet werden konnten, aber nicht vom Original-Server kommen und daher keine Garantie auf deren Aktualität besteht.
204 bedeutet No Content - Kein Inhalt. Der Server hat die Anfrage erhalten, sendet jedoch keine Daten zurück. Gut einsetzbar ist dieser Statuscode in CGI-Skripten, die zwar etwas auf dem Server erledigen, aber keinen neuen HTML-Code an den aufrufenden Browser senden wollen. Aus Sicht des Nutzers bleibt der alte Bildschirminhalt bestehen.
205 bedeutet Reset Content - Inhalt zurücksetzen. Der angegebene Server existiert nicht bzw. der Server, der diese Antwort gibt, ist nicht der angefragte Server und kann den angefragten Server nicht finden. Die angeforderten Daten können deshalb nicht versendet werden.
206 bedeutet Partial Content - Der Inhalt ist nur teilweise vorhanden. Die angeforderten Daten werden in mehreren Portionen versendet (das hat aber nichts mit TCP/IP-Paketen zu tun, sondern geschieht auf HTTP-Protokollebene). Mit Angaben zu content-length (z.B.: 1024) und content-range (z.B.: Bytes 0-1023/1024) wird angegeben, wie viele Bytes von dem angeforderten Inhalt geliefert werden, und welcher Teil der Gesamtdaten. Dieser Antwortcode deutet in vielen Fällen auf eine zu große Datei hin, deren Download abgebrochen wurde.
207 bedeutet Multi-Status - Mehrere Statuscodes. Manchmal werden mehrere Meldungen zu mehreren Operationen zurückgegeben. Oft ist es eine XML-Datei einer Datenbank.
208 bedeutet Already Reported - Bereits berichtet. Dies soll vermeiden, dass z.B. interne Mitglieder einer WebDAV-Bindung mehrfach gezählt werden.
226 bedeutet IM Used - Verdacht einer Instanz-Manipulation. Der Server erhielt eine GET-Anforderung und erfüllt sie. Aber der Code weist auf eine oder mehrere Manipulationen hin.

3xx – Umleitung - Redirection messages

Vorgesehen ist der Zahlenbereich 300 bis 399. Davon werden derzeit jedoch nur neun verwendet. Um die erfolgreiche Bearbeitung der gestellten Anfrage durchzuführen, sind oder waren weitere Schritte des Clients erforderlich. Der Abruf war somit irgendwie erfolgreich, aber es gab Probleme damit.
300 bedeutet Multiple Choices - Mehrere Möglichkeiten. Die angeforderten Daten sind unter mehreren verschiedenen URIs vorhanden (Mirror). Anstelle der Daten werden die verfügbaren URIs als Liste übertragen. Der Browser kann den Nutzer anschließend in einem Dialog einen URI auswählen lassen.
301 bedeutet Moved Permanently - Dauerhaft verschoben. Die angeforderten Daten befinden sich nicht mehr unter dem URI, sie wurden dauerhaft auf eine andere Adresse verschoben. In der Statusmeldung wird angegeben, unter welchem URI sich die Daten jetzt befinden. Ein Browser, der diese Antwort vom Server erhält, kann beispielsweise gleich die neue Adresse anfordern.
302 bedeutet Moved Temporarily / Found - Die angeforderten Daten wurden vorübergehend zu einem anderen URI verschoben. In der Statusmeldung wird angegeben, unter welcher Adresse sich die Daten derzeit befinden. Ein Browser, der diese Antwort erhält, kann beispielsweise gleich die temporär gültige Adresse anfordern.
303 bedeutet - See Other - Schaue wo anders nach. Die angeforderten Daten sind unter einem angegebenen URI verfügbar und sollte von dort mit Hilfe der GET-Methode angefordert werden. Dieser Statuscode ist für CGI-Scripts gedacht, die mit der POST-Methode aufgerufen wurden und den Browser auf eine andere Ressource lenken wollen, die mit der GET-Methode angefordert werden soll.
304 bedeutet Not Modified - Unverändert. Die angeforderten Daten haben sich seit dem angegebenen Zeitpunkt nicht geändert und werden deshalb nicht gesendet. Dieser Statuscode ist neben dem Code 200 einer der häufigsten in der Praxis. Er wird verursacht durch Browser, die aufgrund ihrer Cache-Einstellungen Daten erst wieder nach einer bestimmten Zeit vom Original-Server laden. Davor fragen sie nur mit dem Zeitpunkt, zu dem die Daten zuletzt geladen wurden, an, ob die Daten auf dem Server seitdem geändert wurden.
305 bedeutet Use Proxy - Einen Proxy nutzen. Die angeforderten Daten sollen statt von diesem Server von dem in der Statusmeldung angegebenen Proxy-Server angefordert werden.
306 ist derzeit ungenutzt ist also nur reserviert. Wird derzeit nicht verwendet.
307 bedeutet Temporary Redirect - Zeitweise umgeleitet. Das ist wie Statuscode 302. Gedacht war es für Fehlreaktionen einiger Browser auf 302. Heute wird es für URL-Hijacking verwendet.
308 bedeutet Permanent Redirect - Dauerhafte Umleitung.

4xx – Client-Fehler - Client error responses

Vorgesehen ist der Zahlenbereich 400 bis 399. Davon werden derzeit mehrere Dutzend verwendet. Das sind wirkliche Fehler, die zu Problemen führten.
400 bedeutet Bad Request - Ungültige Anfrage. Die Anfrage enthält Syntaxfehler. Der Server kann die Anfrage deshalb nicht bearbeiten. Das kann beispielsweise vorkommen, wenn die Anfrage dadurch zustande kam, dass ein Nutzer versuchte, einen URI händisch in die Adresszeile des Browsers einzugeben und dabei ungültige Zeichen verwendete.
401 bedeutet Unauthorized - Unautorisiert. Die angeforderten Daten sind zugangsgeschützt. Der Server kann die Daten nur senden, wenn eine gültige Zugangskennung, bestehend aus Benutzername und Passwort, bei der Anfrage mit gesendet wird. Das geschieht in der Praxis immer dann, wenn eine Adresse aufgerufen wird, die z.B. durch htaccess zugangsgeschützt ist. Der Browser zeigt dann, nachdem er diesen Statuscode erhalten hat, einen Dialog zum Eingeben von Benutzername und Kennwort an. Mit den eingegebenen Daten startet er danach eine neue Anfrage an den Server.
402 bedeutet Payment Required - Bezahlung erforderlich. Die angeforderten Daten sind kostenpflichtig. Der Server kann die Daten nur senden, wenn eine Bestätigung der Zahlung für die Daten bei der Anfrage mitgesendet wird. Derzeit wird dies aufgrund fehlender einheitlicher technischer Grundlagen für Micropayment nicht verwendet.
403 bedeutet Forbidden - Verboten. Die angeforderten Daten sind zugangsgeschützt. Die angegebenen Daten, mit denen der Zugang erlaubt werden soll, sind ungültig. Das kann z.B. vorkommen, wenn zuvor der Statuscode 401 zurückgeliefert worden war und der Browser nun die nächste Anfrage mit den Zugangsdaten gestartet hat, die er vom Nutzer im Dialog abgefragt hat, und diese Daten aber ungültig sind. Manche Browser wiederholen den Dialog zum Eingeben der Zugangsdaten dann noch zweimal, und nach der dritten Falscheingabe wird dem Nutzer die Fehlermeldung " Forbidden" ausgegeben.
404 bedeutet Not Found - Nicht gefunden. Das ist die häufigste Fehlermeldung. Der angeforderte URI existiert nicht. Dies ist neben den Statuscodes 200 und 304 einer der häufigsten Fälle in der Praxis. Er tritt immer dann ein, wenn ein Verweis auf eine nicht oder nicht mehr existierende Adresse auf dem Server führt, oder wenn der Nutzer versucht hat, eine Adresse auf dem Server durch händisches Eintippen in der Adresszeile des Browsers aufzurufen, und diese Adresse aber nicht existiert.
405 bedeutet Method Not Allowed - Die Methode ist unzulässig. Die angegebene Übertragungsmethode ist auf dem Server nicht erlaubt. Die Daten werden deshalb nicht übertragen. Das kann beispielsweise vorkommen, wenn in der Konfiguration des Web-Servers außer der GET-Methode keine weitere Methode erlaubt ist, ein HTML-Formular aber einen CGI-Aufruf mit der POST-Methode enthält.
406 bedeutet Not Acceptable - Nicht akzeptabel. Die Anfrage ist in dieser Form nicht akzeptabel. Die Daten werden deshalb nicht übertragen. Oft liegt dies am falschen Dateiformat.
407 bedeutet Proxy Authentication Required - Proxy-Authentifizierung erforderlich. Der anfragende Client ist ein Proxy-Server. Die Daten werden an diesen Server nur übertragen, wenn er sich als gültiger Proxy-Server ausweist. Dieser Statuscode findet kaum Verwendung. Damit soll auf die Dauer ein ähnliches Handling wie mit dem Statuscode 401 etabliert werden, jedoch nicht für anfragende Browser, sondern für anfragende Proxy-Server. Auf diese Weise könnte es Web-Anbietern möglich werden, in der Serverkonfiguration unerwünschte Proxy-Server vom Zwischenspeichern der eigenen Daten auszusperren.
408 bedeutet Request Timeout - Zeitüberschreitung bei einer Anfrage. Der Server hat eine erwartete Anfrage nicht innerhalb des dafür festgelegten Maximalzeitraums erhalten. Die Verbindung zum anfragenden Browser wird deshalb abgebaut. Angeforderte Daten werden somit nicht übertragen.
409 bedeutet Conflict - ein Konflikt ist aufgetreten. Der Server kann die angeforderten Daten nicht senden, weil ein Konflikt mit einem anderen Prozess aufgetaucht ist. Das kann beispielsweise eintreten, wenn ein anderer Prozess eine angeforderte Datei gerade mit einem exklusiven File-Locking (keinerlei Dateizugriff für andere Prozesse erlaubt) versehen hat.
410 bedeutet Gone - die Datei / Ressource ist verschwunden. Die angeforderten Daten wurden zu einem anderen URI verschoben. Dem Server ist aber nicht bekannt, wohin. Deshalb kann er sie nicht senden - andernfalls würde ein Statuscode 301 oder 302 gesendet worden.
411 bedeutet Length Required - Längenangabe der Datei erforderlich. Die Daten werden nicht gesendet. Sie können nur gesendet werden, wenn die Anfrage eine Angabe zu content-length enthält. Der Browser kann versuchen, die Anfrage neu zu formulieren und dabei die Länge der an den Server gesendeten Anfragedaten mit zu übermitteln.
412 bedeutet Precondition Failed - Vorbedingungen nicht erfüllt. Der Anfrager hat Vorbedingungen gestellt, welche der Server nicht erfüllt. Eine oder mehrere Bedingungen, die bei der Anfrage gestellt wurden, treffen nicht zu. Die angeforderten Daten werden deshalb nicht übertragen.
413 bedeutet Request Entity Too Large - die Anfrage ist zu groß. Der Server kann die Anfrage nicht bearbeiten, weil diese zu viele Zeichen enthält. Die angeforderten Daten werden deshalb nicht übertragen.
414 bedeutet Request-URL Too Long - die URL ist zu lang. Der Server kann die Anfrage nicht bearbeiten, weil die angeforderte Adresse zu viele Zeichen enthält. Die angeforderten Daten werden deshalb nicht übertragen.
415 bedeutet Unsupported Media Type - der Medientyp wird nicht unterstützt. Der Server kann die Anfrage nicht bearbeiten, weil er keinen Mime-Type für den angeforderten Datentyp kennt. Die angeforderten Daten werden deshalb nicht übertragen.
416 bedeutet Requested Range Not Satisfiable - Teile der Anfrage stehen nicht zur Verfügung. Die Anfrage enthält Angaben, welcher Byte-Bereich von dem angeforderten URI übertragen werden soll. Sowohl der Anfangswert als auch der Endwert des angegebenen Bereichs liegen außerhalb des verfügbaren Bytebereichs, z.B. wenn ein Bytebereich von 1000 bis 2000 angegeben wird, die Ressource aber nur 500 Byte hat. Die angeforderten Daten werden deshalb nicht übertragen.
417 bedeutet Expectation Failed - Die sogenannte 'Erwartung' wurde nicht erfüllt. Die Anfrage enthält im expect-Feld bestimmte Wünsche, die der Server nicht erfüllen kann. Die angeforderten Daten werden deshalb nicht übertragen.
418 bedeutet angeblich "I'm a teapot" und ist ein Aprilscherz.
419 ist nicht belegt.
420 bedeutet Policy Not Fulfilled. Eine Bedingung wurde nicht erfüllt.
421 bedeutet Misdirected Request - Fehlgeleitete Anfrage. Seit Http 2.0, falls man eine Anfrage an einen Server sendet, dieser aber nicht in der Lage ist, eine Antwort darauf zu senden.
422 bedeutet Unprocessable Entity - Nicht bearbeitete Einheit. Eigentlich war es gedacht, wenn der Statuscode 415 und 400 nicht sinnvoll wäre, aber die Verarbeitung der Anfrage z.B. wegen semantischer Fehler scheiterte.
423 bedeutet Locked - gesperrte Datei. Zumindest momentan ist die Datei gesperrt und der Abruf somit unmöglich.
424 bedeutet Failed Dependency - Abhängigkeitsfehler. Zuerst muss eine andere Bedingung erfüllt werden, bevor man die Datei senden kann.
425 bedeutet Too Early - zu frühe Anfrage. Bei TLS-Verbindungen will man so das Hinein-Hacken verhindern, bevor die sichere Verbindung aufgebaut ist.
426 bedeutet Upgrade Required - höheres Protokoll erforderlich. Z.B. erscheint diese Meldung, wenn der Server das sichere TLS verlangt.
427 ist derzeit unbenutzt.
428 bedeutet Precondition Required - Vorbedingung wurde nicht erfüllt. Zumindest eine zwangsweise erforderliche Vorbedingung wurde nicht erfüllt und deshalb abgebrochen.
429 bedeutet Too Many Requests - zu viele Anfragen. Der Anfrager (client) hat in zu kurzer Zeit zu viele Anfragen abgeschickt. Diese Zahl kann man auf dem Server selbst einstellen, um z.B. DOS-Attacken (Überlastungsangriffe) zu vermeiden.
430 ist derzeit unbenutzt.
431 bedeutet Request Header Fields Too Large - Feldüberschreitung. Die Maximallänge eines sogenannten Headerfeldes oder die des Gesamtheaders oder beides wurde überschritten.
444 bedeutet No Response - Antwort verweigert. Der Server hat die Verbindung geschlossen.
449 - The request should be retried after doing the appropriate action. Dies ist eher für Antworten des Microsoft Exchange Servers gedacht.
451 bedeutet Unavailable For Legal Reasons - Aus rechtlichen Gründen nicht verfügbar. Aufgrund z.B. von gesetzlichen Bestimmungen wie dem Urheberrecht, oder Zensur wurde der Zugriff beschränkt oder ist generell nicht verfügbar.
499 Client Closed Request. Hier hat der Anfrager (Client) die Verbindung abgebrochen, obwohl der Server noch lieferte / liefern wollte.
Jedoch sind einige der 4## seit 2020 nicht mehr offiziell, werden jedoch vereinzelt noch verwendet.

5xx – Server-Fehler - Server error responses

Vorgesehen ist der Zahlenbereich 500 bis 599. Davon wird derzeit ca. ein Dutzend verwendet. Auch dies sind ernsthafte Probleme, die dazu führten, dass keine Dateien ausgeliefert wurden.
500 bedeutet Internal Server Error - Interner Server-Fehler. Der Server kann die angeforderten Daten nicht senden, weil auf dem Server ein Fehler aufgetreten ist. Beispielsweise konnte das aufgerufene CGI-Script nicht gestartet werden.
501 bedeutet Not Implemented - Nicht implementiert. Die Anfrage enthält Anforderungen, die der Server nicht bearbeiten kann, weil die Voraussetzungen dazu nicht implementiert sind respektive die dazu erforderliche Software nicht installiert ist. Die angeforderten Daten können deshalb nicht gesendet werden.
502 bedeutet Bad Gateway - Schlechtes Tor / Schlechter Zugang. Zum Bearbeiten der Anfrage musste der Server einen anderen Server aufrufen, erhielt dabei jedoch eine Fehlermeldung. Die angeforderten Daten können deshalb nicht gesendet werden.
503 bedeutet Service Unavailable - der Dienst ist nicht verfügbar. Der Server kann die Anfrage aufgrund einer Überlastung nicht bearbeiten. Es kann jedoch auch an Wartungsarbeiten liegen. Die angeforderten Daten können deshalb nicht gesendet werden. In der Statusmeldung kann stehen, wann die Anfrage frühestens wieder bearbeitet werden kann. Im Gegensatz zum Statuscode 202 verarbeitet der Server die Daten nicht, sobald er wieder Kapazitäten hat.
504 bedeutet Gateway Timeout - Zeitüberschreitung. Zum Bearbeiten der Anfrage musste der Server einen anderen Server aufrufen, erhielt dabei jedoch nach einem festgelegten Maximalzeitraum keine Antwort. Die angeforderten Daten können deshalb nicht gesendet werden. Es kann auch bei Zeitüberschreitungen von Skripten erfolgen, also, wenn Programme zu lange zum Abarbeiten benötigen.
505 bedeutet HTTP Version Not Supported - die HTTP-Version wird nicht unterstützt. Der Server unterstützt die im HTTP-Header der Anfrage angegebene HTTP-Version nicht. - Gemeint ist die Zahl vor dem Punkt (also z.B. 1. bei HTTP 1.0). Die angeforderten Daten werden deshalb nicht gesendet.
506 bedeutet Variant Also Negotiates - Zirkelbezüge.
507 bedeutet Insufficient Storage - Nicht ausreichender oder Ungenügender Speicherplatz. Die Anfrage kann nicht bearbeitet werden, weil der Speicherplatz des Servers nicht mehr ausreicht. Das trifft u.a. bei Mail-Servern oder Up-Load-Servern zu.
508 bedeutet Loop Detected - Endlosschleife. Jede Anfrage wird zuerst geprüft. Falls sie Endlosschleifen erzeugen würde, wird sie bereits vor Beginn verboten und somit auch nicht einmal ausgeführt.
509 bedeutet Bandwidth Limit Exceeded - Bandbreite überschritten. Es wird keine Antwort gegeben, weil sonst technische Vorgaben und Begrenzungen bei der Transferbandbreite überschritten würden.
510 bedeutet Not Extended - Fehlende Informationen. Dem Server fehlen erforderliche Daten in der Anfrage des Clients. Deshalb sendet er nichts aus.
511 bedeutet Network Authentication Required - eine Authentifizierung des Netzwerks ist erforderlich. Zuerst muss sich der Anfragende durch eine Anmeldung oder Bestätigung bestimmter Abmachungen identifizieren oder einloggen.
521 bedeutet Webserver Is Down - Ausfall des Webservers. Dies tritt scheinbar besonders bei Cloudflare auf. Man kann sich mit Cloudflare verbinden, aber Cloudflare nicht mit dem Ursprungs- Server.
525 bedeutet SSL Handshake Failed - der SSL-Handshake ist fehlgeschlagen. Die Begrüßung zur Kontaktaufnahme bei SSL/TLS scheiterte.

Hinweis

Es handelt sich hier nicht um einen Druckfehler. Im Zusammenhang mit Fehlermeldungen spricht man in der Regel von URI (Universal Resource Identifier / seltener: Information) statt von URL (Universal Resource Locator).

Weitere Informationen zu den Status-Codes finden Sie beim W3 unter Protocols/ sowie Mozilla und auf Deutsch.

Dateigröße

Dieses durch Leerstellen abgetrennte Feld des Logfile-Eintrages besteht aus einer beliebig langen Zahl. Sie gibt die Größe der bewegten Daten an. Bei abgerufenen Dateien handelt es sich um die Dateigröße.

Bei einem Eintrag 304 im davor liegenden Feld Server-Antwort / HTTP-Statuscodes steht hier oft ein Gedankenstrich. Hierbei handelt es sich um einen Aufruf aus dem Cache des Browsers, so dass keine Daten mehr vom Server an den Nutzer versandt werden mussten.

Zieldomain

Bei einigen Auftritten finden sich keine Einträge in diesem Feld des Logfiles. Es ist dann mit einem Gedankenstrich gekennzeichnet.

Falls dort etwas eingetragen ist, findet sich überwiegend die Domain der eigenen Firma: www.firma.de. In den Fällen, in denen mehrere Domains auf einem eigenen Server betrieben werden, können hier auch unterschiedliche Zieladressen eingetragen sein. Teilweise kann das www. davor entfallen.

Dieses Feld hat nur bei Multi-Domain-Auftritten einen Sinn und entfällt deshalb teilweise auch. Bei solchen Auftritten, die viele Internet-Adressen auf dieselben Dateien verweisen lassen, kann man die einzelnen Unter-Domainen (z.B. www.firma.de und www.firma.com) im Logfile separieren.

Referer

Dieses Feld des Logfile-Eintrages ist ebenfalls von seiner Umgebung durch Leerstellen abgetrennt. Der Inhalt besteht aus dem im Internet für die Namensvergabe zulässigen Alphabet. Der Inhalt zeigt die direkt vorher vom Nutzer besuchte Seite bzw. getätigte Aktion an. In der Regel findet sich hier nur ein Gedankenstrich. Er steht für keine Angaben.

Falls sich ein Eintrag findet, so besitzt er oft die Form http://...... Die Herkunftsadresse kann mit einem www. oder ohne oder mit der reinen IP eingeleitet werden. In anderen Fällen finden sich bis hin zur Dateibezeichnung detaillierte Angaben der Form www.Herkunft.de / Rubrikenname / Unterrubrik / Dateiname.htm

Dynamisch aus Datenbanken erzeugte Herkunftsseiten zeigen sich auch so: http://www. herkunftsname.de/ docs / index.asp?id=1028&sp =D&m1=933 &m2=936 &m3 =988 &m4=1028 &m5 =&domid=666.

Bei manchen Suchmaschinen finden sich mit zahlreichen Trennern versehene Suchworte:
http://search.msn.de / spresults.aspx? ps=ba%3d(0..10)0..... %26co%3d(0..10) 200.2.5.10.3.% 26pn%3d1 %26rd%3d0%26 &q=Suchwort_1 +Suchwort_2 +Suchwort_3 &ck_sc=1 &ck_af=1
http://suche.fireball.de/ suche.csp? mode=express &http:// suche.lycos.de/ cgi-bin/pursuit? query=Suchwort_1& amp;cat=loc& matchmode=and&pag=16 &maxhits=10 &lang=any &idx=all& SITE=de&wh=1791 &nightsurf= nornd= 13912 &ocr=on&a=b& q=Suchwort_1 +Suchwort_2& what=german_web &x=27&y=14
http://suche. web.de/search/? fromcat=true &mc=810000& su=Suchwort_1 +Suchwort_2 +Suchwort_3&smode=
http://sucheaol.aol.de/ suche/search.jsp? kw=1&q=Suchwort_1 %20Suchwort_2
http://ww.google.de/ search? hl=de& cr=countryDE&ie=UTF-8& oe=UTF-8& q=Suchwort_1 +Suchwort_2 +Suchwort_3 &spell=1
Dabei werden Umlaute und Sonderzeichen kodiert: %E4 steht z.B. für ä.

Diese im Referer mit übertragenen Suchworte der Suchmaschinen geben Ihnen wichtige Hinweise, unter welchen Stichworten Nutzer zu Ihnen finden. Allerdings heute liefern keineswegs alle Suchmaschinen und diese auch nicht immer irgendwelche Suchwörter.

Die meisten Einträge im Referer werden allerdings von Ihrer eigenen Domain stammen, da sich der Nutzer in Ihrem Auftritt von einer Seite zur nächsten weitergeklickt hat.

Browser und Betriebssystem

Dieses in Anführungszeichen stehende Kombinationsfeld bei Logfile-Einträgen kann mit einem Gedankenstrich für keine Angaben gekennzeichnet sein. In der Regel finden sich dort die Angaben zum Browser und dem Betriebssystem. Allerdings sind viele diese Angaben teilweise codiert in dem Sinne, dass sie unterschiedlich benannt sind und im folgenden Text erst weiter sich ergeben. So findet sich am Anfang der meisten Einträge Mozilla. Dies heißt jedoch keineswegs, dass es sich hierbei um den Browser Mozilla handelt. Oft steht dahinter in Klammern dann noch der kleine Zusatz MSIE 5.01, der dann erst den tatsächlichen Browser angibt. Teilweise finden sich direkt hinter dem Browser, abgetrennt durch ein Semikolon, Sonderbezeichnungen wie AOL 7.0. Dies gibt die Sonderversion des Browsers bzw. der Zugangssoftware zum Internet an.

Ähnlich verhält es sich mit dem dahinter eingetragenen Betriebssystem, das in derart vielen redundanten Abkürzungen und Codes eingetragen werden kann, dass man leicht die Übersicht verliert. Der Eintrag Windows 98 ist noch leicht zu erkennen. Schwieriger wird es bereits bei Windows NT 5.0, das für Windows 2000 steht.

Dahinter folgen, durch ein Semikolon abgetrennt, teilweise weitere codierte Bezeichnungen. Bei Großfirmen bezeichnen diese Einträge oft die Firmenversion des Betriebssystems. Daneben findet man dort auch die Provider eingetragen: DT für Deutsche Telekom, Arcor, Freenet etc.

Allerdings stehen dort manchmal auch erst die richtigen Browser-Bezeichnungen! Das betrifft vor allem die neueren kleineren Browser. Dies gilt u.a. für Opera, z.B. "Mozilla/4.0 (compatible; MSIE 6.0; MSIE 5.5; Windows NT 5.0) Opera 7.03 [de]"
Oder auch für den Avant-Browser, z.B. "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Avant Browser [avantbrowser.com])"
oder den Safari, z.B. "Mozilla/5.0 (Macintosh; U; PPC Mac OS X; de-de) AppleWebKit/124 (KHTML, like Gecko) Safari/125".

Überdies finden sich teilweise noch Plugins für einen Browser angezeigt. So z.B. Hotbar: "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98; Win 9x 4.90; Hotbar 4.3.5.0)"

Schließlich finden sich in diesem Block auch die gesamten Spider, Crawler, Robots etc. der Suchmaschinen. Ich selbst habe bisher eine Sammlung von mehreren hundert unterschiedlichen derartigen Einträgen erstellt.

Letztendlich wird diese Feld von einigen Spaßvögeln - vor allem aus dem Linux-Bereich - auch vorsätzlich missbraucht: Einträge wie Unbekannt ha! ha! gehören noch zu den höflichen. Hier wird deutlich, wo die Grenzen liegen. Im Prinzip kann man sowohl das eigene Betriebssystem als auch den eigenen Browser entweder unsichtbar machen oder sogar als eine ganz andere Software ausgeben!

Auswertung­sprogramme - Software

Inzwischen sind zahlreiche Programme zur - meist oberflächlichen - Analyse der Logfiles vorhanden. Wichtig ist, dass alle Programme nur unbereinigte Brutto-Daten auswerten und keine verbalen Bewertungen der Zahlen ausgeben!

Das hochwertigste Programm WebSuxess existiert leider nicht mehr.

Auch Webtrends ist als Stand-alone-Software nicht mehr in neuer Version erhältlich.

Ferner gab und gibt es noch zahlreiche kleinere Tools, die für den Einstieg durchaus vieles bieten.

AWStats ist ein kostenloses englisches Programm, das einen geradezu riesigen Funktionsumfang bietet. Weitere Informationen zu diesem Programm erhalten Sie bei: awstats.org

Logmeister ist ein kostenpflichtiges englisches Programm für Windows-Systeme. Weitere Informationen zu diesem Programm erhalten Sie bei logmeister.com/

Mach5 FastStats Analyzer ist ein kommerzielles Produkt, das in der grafischen Aufbereitung etwas an Mind Mapping erinnert und für manche Zielgruppen leichter zu verstehen ist als die Konkurrenzprodukte. Weitere Informationen zu diesem Programm erhalten Sie bei mach5.com

Sie Software Analog wurde zwar seit 2005 nicht mehr weiter entwickelt, ist jedoch durchaus brauchbar für den Einstieg.

Unter den folgenden Adressen finden Sie Listen und Vergleiche kostenloser Analysetools Übersicht Logfile-Analyzer, Tools zur Logfile-Analyse

Piwik

Piwik ist eine Alternative zu Google Analytics.

Google Analytics

Google Analytics ist das derzeit am weitesten verwendete Werkzeug. Der Haken liegt allerdings darin, dass Google so kostenlos und frei Haus alle Ihre Daten erhält. Sind Sie absolut sicher, dass dort niemand diese Daten an Dritte (evtl. Ihre Konkurrenten) weitergibt? Zudem ist es aus Datenschutzgründen heftig umstritten, da es alle Ihre Nutzerdaten in das Ausland liefert, ohne relevanten Datenschutz. Letztendlich funktioniert dies nur mittels Dritt-Anbieter-Cookies halbwegs verlässlich, welche allerdings von zahlreichen Browsern gesperrt oder von Plug-Ins gelöscht werden. Ohne Gegenkontrolle sollte man bei wichtigen Entscheidungen sich nicht nur auf diese Auswertungen von Google verlassen.

etracker

Der Anbieter etracker bietet eine ähnliche aber datenschutzkonforme Lösung an.

Vergleiche der Ergebnisse

Es verwundert kaum, dass alle meine Tests mit exakt demselben Logfile unterschiedliche Ergebnisse in allen getesteten Programmen ergaben. Abweichungen bei Hits und Page-Views von 5-10 % dürfen einen nicht verwundern. Bei Visits können über 100% zwischen dem geringsten und dem größten Wert liegen. Jede Software zählt anders.

Hinweis

Beachten Sie, dass es nicht auf die Software ankommt, sondern dass Sie wissen, was diese Tools auswerten und wie sie es tun. Keines ist perfekt!

Resümee

Letztendlich bleibt festzuhalten, dass diese Service-Anbieter sicherlich einiges für Personen bieten, die bisher überhaupt nichts auf dem Gebiet des Internet-Controllings getan haben - solange Sie mit den Einschränkungen leben wollen.

Spezialisten werden jedoch mit optimierter Software nicht nur genauere Zahlen liefern, sondern mit verständlichen Bewertungen samt Handlungsempfehlungen erst ein effizientes Internet-Controlling für Sie aufbauen.

Im Internet-Controlling gilt: Wissen führt zum Erfolg. Halbwissen hat meist nicht halben Erfolg zur Folge, sondern führt oft in unangenehme Situationen.

Auswertungs­möglichkeiten, Probleme und Grenzen

Zwar existieren zahlreiche (bisher oft ungenutzte) Auswertungsmöglichkeiten der Logfile-Daten. Allerdings sollten bei aller Euphorie auch die Probleme und Grenzen nicht übersehen werden.

Nur Wissen über die Fakten schützt Sie vor Fehlinterpretationen und Betrügereien unseriöser Analytiker.

Brutto- versus Netto-Daten

Alle herkömmliche Logfile-Analyse-Software wertet nur Brutto-Daten aus. Herkömmliche Analyse-Software verwendet alle Einträge in Ihrem Logfile und wertet sie ungeachtet deren Bedeutung aus. Herkömmliche Analyse-Programme unterscheiden nicht zwischen Menschen (Ihren Kunden und Interessenten), die Ihre Internet-Seiten lesen, und Hackern, die stören, sowie automatisch arbeitenden Suchmaschinen, Robotern und Spidern. Auch Monitoring-Systeme, die Ihren Internet-Auftritt ständig maschinell auf Funktionalität hin überprüfen, werden nicht ausgesondert. Hacker und andere Störenfriede werden in der Regel nicht erkannt und nicht separat aufgelistet. Herkömmlichen Rohdaten enthalten auch sonst noch viele unsinnige Abrufe, wie z.B. Bilder und Frame-Teile, welche Ihre Auswertungen verfälschen - und oft bis zur Täuschung unbrauchbar machen. Sie erhalten so immer "Brutto"-Werte.

Selbst wenn die besseren Tools eine Programmierung von Filtern erlauben, so ist dies sehr aufwändig und kann keineswegs alle Probleme lösen, da mehrere der obigen Fehler nicht auf diese Weise korrigiert werden können.

Wer verlässliche Fakten als Grundlage für Investitionen sucht, benötigt die Netto-Daten-Analyse.

Hits

Für mich steht der Fachbegriff Hits als Akronym für Hoffnungslos irrelevante Treffer-Summe. - Alle Analysen mittels Logfiles beruhen auf Brutto-Daten. Der uns Menschen klar verständliche Begriff "sichtbare Seite" existiert im Logfile nicht! Dort gibt es nur zahllose Einzelteile, genannt Hits. So kann eine Seite aus ca. 10-50 Hits bestehen, die zu exakt dieser Anzahl an Zeilen / Einträgen im Logfile führt.

Die daraus analysierten Ergebnisse sind unbrauchbar. Z.B. wird die Browser-Verteilung in der Regel anhand aller Einträge durchgeführt, gleichgültig, was dies auch gewesen sein mag. Enthält eine Seite z.B. 50 Bilder und Grafiken, dann wird jener evtl. exotische Browser 50-fach überbewertet. Aufgrund derart unbereinigter Bruttodaten kann man keine Verteilung z.B. nach Seitenabrufen erstellen.

Wer verlässliche Fakten als Grundlage für Investitionen sucht, benötigt die Netto-Daten-Analyse.

Hits wurden vor allem früher aufgrund ihrer gigantischen Größen gern für Werbezwecke missbraucht. Heute benutzen unseriöse Betreiber exakt die gleichen Zahlen (Hits), nennen sie aber Page-Impressions.

Allerdings ist der Wert für die IT / Ihren Provider wichtig. Man kann aus der Zahl der Hits die Belastung des Servers je Zeiteinheit errechnen. Dies ist für hoch belastete Auftritte durchaus relevant. Für über 95% aller Internet-Auftritte gilt jedoch, dass jeder gängige PC die im Internet auftretende Last mit Leichtigkeit erfüllen kann.

Datentransfer

Auch der Datentransfer ist eine eher für die Technik relevante Größe. Der Dateitransfer (auch Datenmenge, Datenvolumen genannt) ist in der Regel bis zu einer gewissen Menge in Ihrem Grundtarif mit enthalten.
Hierbei gilt jedoch immer häufiger der Tageswert statt des Monatswertes. Angenommen Sie erhalten ein Freivolumen von 3 TB, so sind dies nur 10 GB je Tag. Haben Sie an einem einzigen Tag einen Spitzenwert von über 10 GB Datenvolumen, so müssen Sie ggf. Strafgebühren entrichten. Diese sind je nach Provider unterschiedlich hoch.

Aus der Datenmenge kann man keineswegs auf die Anzahl der abgerufenen Seiten schließen. Dies wäre nur möglich, wenn alle Seiten exakt den gleichen Datenbedarf aufwiesen. Da jedoch in der Regel viele Details im Browser des Nutzers gecached werden, so können höhere Seitenabrufe in einem Zeitraum durchaus mit einem niedrigeren Datenvolumen einhergehen, als geringere Seitenabrufe in einem anderen Vergleichszeitraum. Somit sind diese Datentransferwerte für das Management und das Marketing irrelevant und verwirren nur.

Page-Views, Page-Impressions, PI

Der Name Page-View oder Page-Impression ist verführerisch, suggeriert die Übersetzung doch, dass es sich um Seiten handelt. Dem ist nicht so. Eine Seite kann aus zahlreichen PI bestehen. Einfachstes Beispiel ist eine mit Frames aufgebaute Seite. Der Nutzer sieht nur eine Seite. In Wirklichkeit wird das Frameset geladen und dann je nach der Konstruktion des Frames mindestens zwei weitere Seitenteile! Dies ergibt mindestens 3 PI (Page-Impressions) für eine sichtbare Seite.

Um auch nur halbwegs verlässliche Zahlen zu erhalten muss man komplexe Filter programmieren, um alle irrelevanten Seitenteile aus der Zählung der Page-Impressions herauszuhalten. Standard-Programme tun dies jedoch nicht! Dies muss Ihr Fachpersonal durchführen.

Teilweise zählen Standard-Analyse-Programme nur die HTML-Seiten als PI. So fallen z.B. PDFs weg. Andere Software zählen hingegen alle Downloads (auch Exe-Dateien etc.) hinzu.

Visits

Visit bedeutet Besuch, nicht Besucher! Allerdings ist auch ersteres nicht zutreffend, da nur die IPs gezählt werden: Eine IP wird als ein Besuch gezählt. Dies wird oft noch mit einem willkürlichen Zeitfenster von 15 Minuten versehen. Tritt dieselbe IP nach einer Pause von 15 Minuten neu auf, so handelt es sich um einen neuen Besuch.

Auch mit dieser Einheit wird viel Schindluder getrieben. Nur allzu leicht spukt beim Wort Besuch die Gleichsetzung mit Mensch im Bewusstsein herum. Da jede IP gezählt wird, kann es sich auch um einen maschinellen Zugriff der Suchmaschinen, der Roboter, der Monitoring-Systeme etc. gehandelt haben.

Die IP darf nicht mit einer Person gleichgesetzt werden. Proxies, Firewall und Router lassen viele Nutzer, die dahinter liegen, wie einen aussehen, da sie nach außen nur eine IP zeigen. Umgekehrt verändert sich die dynamische IP eines Benutzers, teilweise sogar während einer Sitzung! So existieren Provider, die eine unterschiedliche IP für GET- und für POST-Befehle vergeben. Sogar bei modernem DSL wird mindestens einmal je Tag die IP geändert. Jedoch kann dies jeder Anwender auch selbst jederzeit durchführen. Er muss dazu nur den Router / das Modem kurz vom Stromnetz nehmen.

Ein näherungsweiser Versuch der Ermittlung der Anzahl der Besucher kann m.E. bei einem relativ kurzen Zeitraum (z.B. bis zu einer Woche) mittels der heruntergeladenen CSS-Dateien durchgeführt werden. Falls der Nutzer seinen Browser-Cache in der Zwischenzeit nicht löscht oder zu gering eingestellt hat, so wird diese Datei nur einmal angefordert.

Die Zahl der wirklich an dem Auftritt interessierten neuen Besucher lässt sich annähernd über die Zahl der abgerufenen favico(n).ico ermitteln. Diese Datei wird angefordert, wenn sich ein Nutzer die Adresse bookmarked.

Browser

Inzwischen ist die Anzahl der unterschiedlichen Browser und vor allem deren Versionen im vierstelligen Bereich angekommen.

Manche Browser, wie Opera, können sich als andere ausgeben. Hinzu kommen zahlreiche Plug-Ins, welche ebenfalls die Kennung für den Browser ändern können.

Die Suchwerkzeuge der Suchmaschinen (Crawler, Spider, Robots etc.) können zwar als solche gekennzeichnet sein, besitzen teilweise jedoch auch einen fiktiv angegebenen Browser-Namen. Insbesondere trifft dies auf Hackertools etc. zu. Diese verwässern die Statistik über Browser.

Ferner analysieren einige Werkzeuge die Browser falsch und ordnen sie anderen zu oder können sie nicht auflösen.

Betriebssysteme

Im Prinzip kann man in manchen Betriebssystemen, wie z.B. Linux, das eigene Betriebssystem und den Browser entweder unsichtbar machen oder sogar als eine ganz andere Software ausgeben! Hinzu kamen zahlreiche Plug-Ins, welche ebenfalls die Kennung für das Betriebssystem abändern können.

Ferner analysieren einige Werkzeuge die Betriebssysteme falsch und ordnen sie anderen zu oder können sie nicht auflösen. So ist es wertlos nur Windows als Betriebssystem zu erhalten. Man benötigt jede Unterversion jenes Betriebssystems für eine halbwegs brauchbare Analyse.

Die Suchwerkzeuge der Suchmaschinen (Crawler, Spider, Robots etc.) können zwar als solche gekennzeichnet sein, besitzen teilweise jedoch auch ein Betriebssystem. Insbesondere trifft dies auf Hackertools etc. zu. Diese verwässern die Statistik über Betriebssysteme.

Vorgegebene Größenklassen

Normalerweise erlauben herkömmliche Analyse-Programme sowohl bei den Browsern als auch den Betriebssystemen nur die Grobauswertung oder eine Feinauswertung. Die Grobauswertung ist mit ihren großen Klassen oft zu ungenau, da wichtige Details verloren gehen. Es besteht die Gefahr, dass Sie Wichtiges übersehen und so die falschen Entscheidungen treffen. Die Feinauswertung ist hingegen oft zu aufwändig. Sie erschlägt den Betrachter mit zu vielen unüberschaubaren Details. Es besteht hierbei die Gefahr, dass die Analyse zu viel Zeit erfordert und Entscheidungen zu spät oder nicht getroffen werden.

Zur frei wählbaren Granularität (Detailanzeige) in der Auflösung siehe dort.

Verweildauer

Die Verweildauer wird seit vielen Jahren als eine der angeblich aussagekräftigsten Kenngröße im Internet gehandelt. Mit derart pauschalen Aussagen sollte man jedoch vorsichtig sein!

Zwar existieren kompliziertere technische Lösungen, die Verweildauer zu messen. Dennoch unterliegen auch diese (vor allem JavaScript-Lösungen) technischen Grenzen (siehe unten). Für herkömmliche Aufzeichnungsmethoden in Logfiles gelten jedoch erhebliche Einschränkungen.

Zu einem soliden Internet-Controlling gehört auch, auf die Grenzen des Messbaren hinzuweisen. Eine solche liegt bei der herkömmlich gemessenen Verweildauer vor:
Bereits das Wort "verweilen" ist unglücklich gewählt, da es eine aktive Handlung einer Person impliziert oder suggeriert. De facto wird kein Verweilen gemessen, sondern ausschließlich das messbare Klicken eines Links mit dem damit verknüpften Abruf von Seiten - also die Pause zwischen zwei Handlungen! Aus der Differenz des Zeitstempels der ersten auf dem eigenen Auftritt angeklickten Seite zum Zeitstempel der zweiten auf dem eigenen Auftritt angeklickten Seite wird der rein mathematische Wert ermittelt.

Da nur die Differenz zwischen zwei auf dem eigenen Server abgerufener Dateien berechnet werden kann, treten u.a. folgende Probleme auf:
Falls nur eine Seite aufgerufen wird, so ist die gemessene Verweildauer nicht messbar. Die meisten Analyseprogramme ergeben hier: 0 Sekunden. Dies betrifft vor allem die Startseite.
Angenommen, 10 Nutzer rufen Ihre Startseite auf. Fünf davon klicken eine weitere Seite bei Ihnen an, so ist die Zeitdifferenz messbar. Angenommen, es ergäben sich durchschnittlich 20 Sekunden, so wäre die Gesamtsumme 100 Sekunden. Die anderen fünf Nutzer betrachten nur die Startseite, diese jedoch im Durchschnitt 40 Sekunden und verlassen dann Ihren Auftritt. Wir wissen nun, dass die durchschnittliche Verweildauer bei 30 Sekunden liegen müsste. Leider wird diese Zeit der einmaligen Aufrufe nicht erfasst. Der von den Analyseprogrammen errechnete Gesamtdurchschnitt der Verweildauer aller 10 Seitenaufrufe ist nun 100 Sekunden dividiert durch alle 10 Aufrufe und somit völlig unrealistische 10 Sekunden.
Noch extremer wird der Wert, wenn die Nutzer eine Seite grundsätzlich nur einmal aufrufen. Dieses Phänomen kann bei Visitenkarten oder Mikro-Auftritten entstehen. Hierbei handelt es sich um Auftritte, die aus nur einer einzigen Seite bestehen. Da es keine Folgeseiten geben kann, gibt es keine Zeitdifferenz. Deshalb ist die durchschnittliche Verweildauer immer 0.
Noch verheerender wirkt sich m.E. die technisch bedingte Errechnung der Verweildauer der herkömmlichen Analysesoftware auf die letzte Seite aus. Sie kann niemals gemessen werden. In der Regel handelt es sich jedoch hierbei um die aussagekräftigste Seite. Annahme: Ein Nutzer sucht eine bestimmte Information: Hierzu geht er in eine große Suchmaschine (z.B. Google) und findet unter einem Stichwort Ihren Internet-Auftritt. Er klickt den Link an und gelangt auf Ihre Startseite. Dort klickt er nach ca. 10 Sekunden die vermutlich passende Rubrikenstartseite an und sucht das gewünschte Stichwort. Eventuell muss er nochmals einen weiteren Link anklicken, um zum erwarteten Ziel zu gelangen. Auf der Zielseite angekommen wird er entweder hoch erfreut sein und alle gewünschten Informationen finden oder enttäuscht. Im ersten Fall wird er minutenlang oder vielleicht sogar ein Stunde aufmerksam den Text lesen - und dann den Auftritt zufrieden verlassen. Er hat schließlich alles erreicht, was er wollte. - Im letzteren Fall wird er den Auftritt nach wenigen Sekunden unzufrieden verlassen. Er hat sein Ziel nicht erreicht. In beiden Fällen verlässt er in der Regel den Auftritt. Das errechnete Ergebnis für beide Fälle in allen Analyseprogrammen ist identisch: 0 Sekunden Verweildauer.

Verweilen ist auch nicht identisch mit Lesen! Es bedeutet noch nicht einmal ansehen. Ob der Nutzer nach dem Seitenaufruf den PC oder das Zimmer verlässt, einen weiteren Reiter im Browser, einen anderen Browser oder eine andere Software aufruft und mit ihr arbeitet, ist völlig unklar. Da heute jedoch die meisten Betriebssysteme multitasking-fähig sind, ist davon auszugehen, dass andere Applikationen offen sind, und fast jeder Nutzer mehrere Dinge quasi parallel bedient.

Festgehalten wird ausschließlich eine IP - eine Nummer, die mit der Postleitzahl zu vergleichen ist. Damit wird ein Anschluss an das Internet gekennzeichnet. Es finden sich In der Regel keinerlei Benutzernamen im Logfile. Das Verweilen eines bestimmten Benutzers ist somit nicht möglich.

Eine IP ist nicht identisch mit einem PC und sie ist auf keinen Fall mit einem Nutzer identisch. IPs werden aufgrund ihrer Knappheit und damit verbundenen Kosten bei den meisten Providern dynamisch vergeben. Dies bedeutet, dass jeder Nutzer des Internets bei jeder Einwahl eine neue IP erhält. Oft bleibt diese Nummer während einer Sitzung identisch. Bei allerdings rotierenden IPs erhalten Sie als Auswerter als vermeintliches Ergebnis keine oder kürzere Verweildauern für die aufgerufenen Seiten. Diesem Problem kann man teilweise mit Cookies oder Session IDs begegnen.

Eine IP bedeutete nicht, dass dahinter ein Mensch steckt. Aufrufe von Seiten können auch durch einen Spider einer Suchmaschine, ein Monitoring-System, Hacker-Tools, Download-Software etc. verursacht werden. Diese benötigen für die Auswertung der Inhalte einer Seite wesentlich weniger Zeit als jeder Mensch. Als vermeintliches Ergebnis sinken die angegebenen Durchschnittswerte der Verweildauer.

Ferner bedeutet Verweildauer auch nicht, dass sich dahinter ein einziger Benutzer verbirgt! Während eines Zeitraumes X kann z.B. beim Heimanwender zuerst der Familienvater, dann die Mutter, die Tochter oder der Sohn an den PC gegangen sein und eine andere Seite angeklickt haben.

Angenommen, eine Firma oder eine Familie besitzt einen Router oder Proxy-Server, so können mehrere Personen gleichzeitig im Internet surfen. Dies geschieht jedoch in der Regel über dieselbe IP. Angenommen, sie besuchen denselben Internet-Auftritt, so wird dies im Logfile mit einer IP dargestellt. Alle Logfile-Analyse-Programme interpretieren jedoch eine IP als einen Besucher! Das Problem hierbei liegt in der Vorgehensweise der Zählung über den Zeitstempel: Angenommen, es sind zwei Personen, so erfolgen letztendlich während eines Zeitraumes x doppelt so viele Seitenabrufe als bei einer Person. Da die Verweildauer jedoch als reine Division berechnet wird, ergibt sich de facto auf dem Papier die Hälfte der tatsächlichen Verweildauer jeder Person auf den jeweiligen Seiten!

Die meisten Analyseprogramme setzen einen willkürlichen Wert für die Analyse der zusammengehörenden IPs anhand der Zeit. In der Regel werden IPs einem Nutzer zugeordnet, solange er innerhalb von 15 Minuten eine weitere Seite anklickt. Viele Texte im Internet sind allerdings länger und erfordern mehr als 15 Minuten Verweildauer. Eventuelle Pausen oder andere Tätigkeiten des Nutzers werden nicht erkannt.

Im Übrigen sind die Werte der Verweildauer sowieso völlig wertneutral - will heißen wertlos. Angenommen, der Idealfall wäre eingetreten, und ein Nutzer hätte tatsächlich die Verweildauer dazu genutzt, den Inhalt einer Seite ausführlich zu studieren. Was sagt dann ein gemessener Wert von zwei Minuten aus? Hat er sich so lange auf der Seite aufgehalten, weil der Inhalt und die Gestaltung derart perfekt seine Anforderungen erfüllten? Oder hat er aufgrund einer miserablen Textgestaltung so lange gebraucht, um zu erkennen, dass sein Informationswunsch hier nicht erfüllt wird, und aufgrund eines chaotischen Layouts den Link zur nächsten Seite erst so spät gefunden? - Ohne dass man den Nutzer hierbei in Laborversuchen beobachten und befragen kann, ist eine gemessene Verweildauer in jede Richtung auslegbar.

Neueste Untersuchungen belegen sogar, dass die Zeit, welche Nutzer zum Erfassen von Web-Inhalten benötigen, extreme individuelle Schwankungen aufweist: Die Spitzenwerte können zwischen der schnellsten Person und der langsamstem um das 15-fache auseinander liegen. Im Durchschnitt wurde der Faktor 2,4 ermittelt.
Angenommen Sie stellen Inhalte für Personen mit extrem schneller Auffassungsgabe in das Internet - also Ihre Zielgruppe besteht aus diesen Genies -, dann werden Sie immer extrem geringe Verweilzeiten erhalten. Dies wäre dann sogar ein positives Zeichen, da Sie Ihre Zielgruppe exakt erreicht hätten. Im anderen Extremfall - falls Sie sich an den Personen mit langsamerer Auffassungsgabe orientierten, bzw. diese sich auf Ihren Seiten tummelten - würden Sie extrem lange Verweilzeiten als Ergebnis erhalten.
Letztendlich bleibt jedoch festzuhalten, dass Sie sich die Benutzer im Internet nur selten aussuchen können und - was noch viel bedeutender ist - sowohl die schnellsten als auch die langsamsten Anwender können bezahlende Kunden bei Ihnen werden!

JavaScript

Zwar kann man mit JavaScript in einer HTML-Datei die Verweildauer - auch einer einzelnen Seite - messen (Beispiel siehe unten). Im Prinzip lädt man eine weitere Datei (meist ein unsichtbares kleines Bild) am Ende des Betrachtungszeitraumes.

Aber auch hier existieren Einschränkungen: So muss der Browser des Nutzers JavaScript unterstützen. Dann muss der Nutzer JavaScript aktiviert haben. Das tun bei weitem nicht alle Nutzer. Ferner muss die Firewall JavaScript durchlassen / ausführen lassen. Sicherheitsbewusste Nutzer, viele Universitäten und noch mehr Firmen gehen damit sehr restriktiv um. Zudem muss das Browsen muss normal beendet werden. Ein Klick auf das X (Schließen-Symbol) des Browser, ein Herunterfahren des Betriebssystems etc. führt bei fast allen getesteten Systemen zu keinem Eintrag im Logfile. Überdies treten Probleme auch beim zwangsweisen Reload auf (Strg+R). Dann werden generell die Zeiten ungenau gemessen (sehr oft zu kurz). Dies darf auch nicht verwundern, da es sich bei JavaScript um ein client-seitiges Programm handelt. Es läuft auf dem Kunden-PC ab. Überdies sind weitere Zeitdifferenzen zum Server aufgrund der Distanz und somit der Laufzeit der Signale normal. Auch die Ergonomie der Seite wird verschlechtert, da sich die Ladezeit / Ausführungszeit verlängert. Ferner sind nicht alle Anwender mit dieser wässrigen Auslegung der Privacy-Politik einverstanden. Immerhin wird ein zweiter Ladevorgang erfordert, für den der Nutzer nichts erhält, jedoch seine vermeintliche Aufenthaltsdauer preisgibt. Zudem ist ohne dynamische Datenbank oder z.B. PHP der Aufwand zum Einbau des Codes und zur Pflege derartiger Seiten aufwändig. Damit sind für Firmen in der Regel auch nicht unerhebliche Kosten verbunden. Jedoch funktioniert die Messmethode auch nur zukünftig, d.h. nachdem der Quellcode in die betreffende HTML-Seite eingebaut wurde. Retrospektive Betrachtungen mit altem einfachen Datenbestand sind damit nicht möglich. Schließlich lässt sich mit herkömmlichen Analyseprogrammen das Logfile mit JavaScript-Einträgen der Verweildauer kaum auswerten. Noch komplizierter wird es, wenn daraus Gruppierungen erstellt und Durchschnittswerte errechnet werden sollen.

Letztendlich stellt sich jedoch auch bei dieser technisch durchführbaren Messung von Einzelseiten die Frage nach dem Wert der Ergebnisse: Ist eine Seite a mit durchschnittlich 20 Sekunden Verweildauer "besser" als eine Seite b mit 15 Sekunden?

Beispielcode

Da immer wieder die Frage gestellt wird, wie man die Verweilzeit bei Einzelabrufen messen kann, sei im Folgenden ein Beispiel mit JavaScript angegeben, das auch bei einfachen / statischen HTML-Seiten auf den meisten technisch einfach ausgestatteten Servern funktioniert. Mit dem folgenden Beispielcode (test1.htm) wurden diverse Tests durchgeführt.

<html><head>
<title>Testseite</title>
<script type="text/javascript">
var Start = new Date();
var Startzeit = Start.getTime();
function Aufenthalt() {
var Ende = new Date();
var Endezeit = Ende.getTime();
var Aufenthalt = Math.floor((Endezeit - Startzeit) / 1000);
document.img1.src = "1.gif?Sek="+Aufenthalt;
}
</script>
</head>
<body onUnload="Aufenthalt()">
Testseite 1
<br><a href="test2.htm">zur Seite 2</a>
<br><img src="1.gif" alt="" width="1" height="1" name="img1">
</body>
</html>

Damit man zum Testen schnell hin- und herspringen kann, existierte eine ähnlich aussehende Datei test2.htm

Das Ergebnis sieht als Eintrag im Logfile folgendermaßen aus: 217.83.170.156 - - [06/Mar/2004:13:49:21 +0100] "GET 1.gif?Sek=14 HTTP/1.1" 200 42 www.testdomain.de "http://www. testdomain.de/ test1.htm" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)" "-" - Die Zahl hinter Sek= gibt die gemessene Verweildauer in Sekunden an.

Datum und Uhrzeit

Das Datum stimmt heute fast immer in Logfiles. Stichprobenartig nachprüfen sollte man es jedoch trotzdem. Es wurden in manchen Marketingabteilungen schon die seltsamsten Interpretationen ausgedacht, nur um zu erklären, dass an einem Feiertag die Zugriffe besonders hoch/tief waren. Der wahre Grund lag darin, dass ein Systemadministrator sich beim Einrichten des Servers um einen Tag im Datum geirrt hatte.

Noch größer ist die Gefahr der Fehlinterpretation bei den Uhrzeiten. Dass viele Server in Deutschland nach GMT statt nach MEZ oder sogar MESZ eingestellt sind, führt zu einer bzw. zwei Stunden Zeitverschiebung.
Noch gravierender wird das Problem falls Ihr Server in einer anderen Zeitzone steht. Diese Zeitverschiebungen müssen im Analyseprogramm korrigiert werden. Leider ist dies nur extrem selten möglich. Es reicht nicht aus, unter die falsche Zeitkurve zu schreiben, der Leser möge bitte geistig selbst die Zeit um x Stunden in eine Richtung korrigieren. Das kann kaum jemand, wenn er den erklärenden Text überhaupt liest.

Noch schwieriger wird es bei internationalen Auftritten. Hier treten im Idealfall Zugriffe aus verschiedenen bis allen Zeitzonen auf. Es mag auf den ersten Blick logisch erscheinen, dass ein Kunde sich um 20 Uhr für viele Seiten ernsthaft interessierte. Falls diese Zugriffe jedoch aus Japan stammten, so liegt der Zugriff tief in der Nacht, so dass Sie sich das einmal genauer ansehen sollten. Um hierbei die Zeitkurven noch auswerten zu können, muss man sie nach Herkunft des Zugriffes separieren. Dies wird in herkömmlicher Analyse-Software kaum durchgeführt.

Wochentagauswertung

Diese von allen Programmen angebotene Analyse ist nur bei Siebenergruppen an Tagen durchführbar. Da die meisten Logfiles jedoch im Monatsrhythmus ausgewertet werden, funktioniert dies nur mit dem Monat Februar mit 28 Tagen zuverlässig. Bei allen anderen Monaten weisen mehrere Tage zu viele bzw. zu wenige Abrufe auf! Noch gravierender wird dieses Problem, falls man versuchen sollte, die Monate miteinander zu vergleichen. In jedem Monat sind in der Regel andere Tage bevorzugt oder benachteiligt. Gleiches gilt bei Quartals-, Halbjahres oder Jahresauswertungen.

Vor allem bei größeren Perioden werden jahreszeitliche Schwankungen nivelliert und sind dann nicht mehr erkennbar. Ideal ist ein Wochenzyklus. Meist wird jedoch aus üblichen Reporting-Gründen ein Monatszeitraum gewählt.

Abgerufene Datei / Seiteninhalt

Bei sprechenden Dateinamen fällt die Zuordnung relativ einfach. Hier treten oft nur Schwierigkeiten bei Namensgleichheit auf. Insbesondere findet sich dieses Phänomen bei den verschiedenen index.html, die sich in unterschiedlichen Verzeichnissen befinden können, da nicht immer der gesamte Pfad angezeigt wird. Dies tritt insbesondere auf, wenn Domains auf Unterrubriken umgeleitet werden.

Problematischer wird die Angelegenheit der Namenszuweisung bei aus Datenbanken dynamisch generierten Seiten. Sie tragen oft nur noch Buchstaben und oder Zahlenschlüssel: z.B.: "GET /start.jsp?COMPONENTID=20"

Hier ist eine Mapping-Liste oder Matching-Liste erforderlich. Sie sollten sich die Lösung nicht allzu einfach vorstellen. Oft existieren hochkomplexe mehrdimensionale Zuordnungen. Ideal ist es, wenn einer sichtbaren Seite nur ein Zahlencode zugeordnet werden kann. Diese eineindeutige Zuordnung existiert jedoch oft nicht. Häufig existieren sowohl internal als auch external IDs für dieselbe Seite. D.h. zwei Codes verweisen auf einen Inhalt. Diese müssen zusammengefasst werden. Ferner existieren oft Codekombinationen, aus denen sich erst ein Inhalt ergibt. Mir selbst lagen bereits bis zu sechsdimensionale Verknüpfungen vor. Hierbei ergibt sich aus ID_1=A, ID_2=B, ID_3=C, ID_4=D, ID_5=E, ID_6=F erst der (kombinierte) Inhalt der angezeigten Seite.

Schwierig wird die Angelegenheit bei dynamischen Datenbanken, weil spätestens nach einem Jahr kein Techniker mehr weiß, was wie zusammenhängt. Noch schwieriger wird die Erstellung der Matching-Liste, falls externe Firmen die Datenbank und Seitenkombination für Sie konzipiert und programmiert haben. Hier reicht oft bereits der Weggang eines zentralen Ansprechpartners und Sie besitzen keine Matching-Tabelle mehr.
Selbst wenn die Zuordnung der Code zu den Inhalten - meist in der Konzeptionsphase des Projektes - einmal schriftlich festgehalten wurde, so existieren über die während der Entwicklung und vor allem der weiteren Wartung erstellten bzw. veränderten Seiten meist keine sauberen Aufzeichnungen.
Eine Matching-Liste aller Seiten eines Portals mit mehreren Tausend Inhalten zu erstellen, erfordert nicht nur geistigen Aufwand, sondern auch Zeit.

Post-Befehle (Interaktionen mit dem Server, z.B. Absenden eines Kontaktformulars) werden von vielen gängigen Analyseprogrammen oft nicht oder nicht richtig gezählt.

Seitenauflistung

Schwierig wird eine Analyse der Inhalte in fast allen Logfile-Analyse-Programmen, da sie nur aufgerufene Dateien anzeigen. Man spricht hier von der Positivauflistung. Nicht aufgerufene Inhalte Ihres Auftrittes werden nicht aufgezeigt. Es fehlt die Negativauflistung: die Anzeige der Seiten, die nicht aufgerufen wurden. Weitere Informationen zur Negativauflistung.

Als Folge wird in herkömmlichen Analysetools jedes Mal eine andere Reihenfolge aller Dateien entstehen (gleichgültig wie Sie sortieren). So kann man nicht oder nur schwer Details aus Periode eins mit Periode zwei vergleichen. Hier helfen nur Panel-Studien mit konstanten Grundmengen. Weitere Informationen zu Panels.

Insbesondere lassen die herkömmlichen Analysetools keine feststehende individuelle Seitenauflistung zu. Dies funktioniert nur mit einem Spezialprogramm. Weitere Informationen zur individuellen Auflistung.

Herkömmliche Analysen bieten nur wenige Auflistungsmöglichkeiten. Überwiegend werden die gefundenen Dateien nach Größenklassen oder alphabetisch sortiert. Sie müssen selbst mühsam suchen, wo sich diese Datei in Ihrem Internet-Auftritt befindet. So wird Ihnen jeglicher Überblick über die Realität unmöglich gemacht. Individuelle und stabile Sortierreihenfolgen erhalten Sie nur mit Spezialprogrammen. Weitere Informationen zur individuellen Auflistung.

Session-Tracking / Tracing

Im Prinzip bedeutet Session-Tracking / Tracing die Verfolgung einer Sitzung eines Nutzers. Technisch kann jedoch auch hier nur der PC verfolgt werden und nicht eine Person. Gelöst wird dies entweder mit einem Cookie oder einer Session-ID. Bei beiden Verfahren handelt es sich um eine lange Textcodierung. Bei Cookies wird die Signatur auf dem PC des Nutzers abgelegt, sofern er dies erlaubt! Bei den Session-IDs erhält der Browser des Nutzers auf der ersten Seite eines Auftrittes diesen Code an den Seitennamen angehängt, und er schleppt diesen sichtbaren, sehr langen Schlüssel dann auch auf jede weitere Seite mit, die der Nutzer aufruft.

Cookies sind vor allem in Deutschland aus Datenschutzgründen heftig umstritten. Bei Session-ID tritt oft das Problem mit dem Bookmarken der Seite auf. Oft lässt sich der Seitenname nicht mehr verwenden, da der Server eine Fehlermeldung zurückliefert, weil der Schlüssel zeitlich abgelaufen ist!

Erstaunlich viele Analyse-Programme können die Session-IDs jedoch nicht auswerten bzw. werden durch sie sogar in der Gesamtanalyse gestört.

Cookies können heute automatisch (noch während der Sitzung) von entsprechenden Browser-Plug-Ins gelöscht werden. Zudem existieren seit Jahren sogenannte Cookie-Börsen, auf denen in Echtzeit die Kekse unter allen beteiligten Nutzern vertauscht werden. Usw. - Nur, weil kommerzielle Anbieter Ihnen für viel Geld weißmachen wollen, dass mit Cookies die Zählung funktioniert, trifft dies heute kaum mehr zu.

IP-Auflösung

Viele Analyse-Programme versuchen heute, die IP in sprechende Namen umzuwandeln. In der Regel gelingt dies nur zu einem gewissen Prozentsatz und erbringt in der Regel nur für den Spezialisten verständliche Inhalte. Meist liefern diese Automatismen weder den genauen Firmennamen noch das Land oder den Ort. Details kann man z.B. manuell nachschlagen unter RIPE - Réseau IP Européens, APNIC - Asia Pacific Network Information Centre, LACNIC - Latin American and Caribbean Internet Addresses Registry, ARIN - American Registry for Internet Numbers, AFRINIC - African Registry for Internet Numbers INTERNIC (International Registry for Internet Numbers) - nun ICANN - Internet Corporation for Assigned Names and Numbers, KRDNIC - Korea Registry for Internet Numbers.

Für die geografische Lokalisierung einer IP eignen sich besonders der Online-Dienst Traceroute, oder die herunterladbare Software NeoTrace sowie weitere Varianten.

Für die Auflösung respektive Zuordnung der Länder- IPs eignet sich besonders ip2location.

Externe Marktvergleiche, Benchmarks

Standard-Analysen können nur Ihren Internet-Auftritt untersuchen. Da Daten von anderen Internet-Auftritten fehlen, ist ein Vergleich mit der Branche oder dem gesamten Markt unmöglich. Man sollte sich deshalb von steigenden Zahlen nicht in Sicherheit wiegen, und fallende Werte bedeuten keineswegs immer eine Katastrophe.

Sie benötigen für eine aussagekräftige Bewertung hingegen den Marktvergleich. Weitere Informationen zu Marktvergleichen.

Bewertung, Handlungs­empfehlungen

Herkömmliche Analyse-Programme sind in der Regel einstufige Software. Es findet nur eine Ausgabe aller Daten statt. Eine Bewertung - die Interpretation dieser Daten - erhalten Sie nicht. Das müssen Sie selbst leisten.

Letzteres verwundert auch nicht, da keine Maschine und keine noch so intelligente Software die hochkomplexen Datenmengen Ihres Internet-Auftrittes selbst logisch interpretieren können.
"Die Zahlen nützen meist wenig - auf die richtige Interpretation kommt es an!"

Auch Handlungsempfehlungen kann eine Software nicht aussprechen. Weitere Informationen zu Bewertungen.

Vielleicht wird dazu in ein paar Jahren sündhaft teure KI-Software mittels künstlicher Intelligenz in der Lage sein. Aber bis dahin benötigen Sie eigenes Fachwissen oder externe Hilfe.

Zum Seitenanfang

• Startseite
  • Controlling im Internet
  • Nutzeranalyse
  • Ergonomie
  • Gutachten
  • Suchmaschinen-
      Optimierung
  • Beratung
  • Firma
    • Dienstleistungen
    • Presse
    • Artikel
      • Wasserkühlung am PC
      • Suchmaschinen-
        gerechte Programmierung
      • PC-GAU
      • Neuer PC
      • Passwort-Generator
      • DSGVO
      • VVT
      • Auskunftspflicht
      • Interne Suchmaschinen
      • Sicherheit
      • Schnelle SSD
      • Schutz
      • Mobiltauglich ?
      • Korrektes Impressum
      • Ergänzungen zum Impressum
      • Logfile-Nutzeranalysen
      • Kosten senken
      • Internet-Projekte
      • Gestaltung
      • Eintragen
      • Protokolle
      • Spionage
      • VPN
      • Rasterfahndung
    • Lebenslauf
    • Referenzen
    • Beruf & Karriere
    • Broschüren
    • Anfahrt
    • Impressum
    • Kontakt
    • Erklärung
    • Kurse
  • Impressum
  • Datenschutz
  • Artikelliste
  • Inhalt
  • Interne Suche
  • Kontakt

Controlling21.de - Dr. J. Schuhmacher
Internet und Multimedia in Perfektion