Server Log Files

In den frühen Tagen des Webs (und zum Teil noch heute) wurden vor allem die Log-Dateien des Webservers ausgewertet. Diese haben ungefähr das folgende Format:

66.249.83.x − − [25/Aug/2014:05:39:15 +0200] "GET / datei . html HTTP/1.1"
200 17818 www.domain.de "http ://www.google.de/url?sa=t &rct=j&q=&esrc=s&source=web&cd=2 &ved=0CFEQFjAD&url=http%3A%2F%2Fwww.domain.de/datei.html&ei=tK_6U4nlKpzZ6APBfg &usg=AFQjCNFOJZuerl_SuAT−rLgxVjADIww6LA"
"Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident /4.0; SLCC2; .NET CLR 2.0.50727; .NETCLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; InfoPath .3)" "−"

Die Logdatei enthält in der Regel also die IP-Adresse des Benutzers (in diesem Fall wurde das letzte Oktet anonymisiert), das Datum und die Uhrzeit, die Datei, die abgerufen wurde, den HTTP-Status, die Bytes, die übertragen werden, den Referrer,5, den Browser und das Betriebssystem. Es wird nicht erkannt, ob derselbe Benutzer vorher schon einmal da gewesen ist.

Aus diesen Logdateien wurden automatisiert grafisch aufbereitete Auswertungen generiert. Hier werden die einzelnen gerade genannten Merkmale summiert und zum Teil auch weiter ausgewertet. Mitunter sieht man auch heute noch größere Unternehmen mit sol- chen Statistiken arbeiten, meistens mit Hinweis auf Datenschutzprobleme bei der Nutzung fortschrittlicherer Systeme.

Aber es gibt tatsächlich immer noch Gründe, die Webserver-Daten genauer anzusehen: Die zunehmende Anzahl von Tracking-Verweigerern zum einen sowie der Crawl-Traffic wird von den regulären Web Analytics-Systemen nicht erfasst, da die meisten Bots das von den Trackingsystemen eingebundene JavaScript nicht interpretieren. Die Daten aus den altmodischen Weblogs können also immer noch nützlich sein, und sei es nur dazu, Server-Ressourcen freizusetzen, indem unnütze Bots gesperrt werden.

Es ist als Nutzer nicht möglich, dieses Tracking zu unterbinden, auch wenn man den Do not Track-Modus des Browsers aktiviert hat.

Nächster Abschnitt: Pixel/Tagging