Ich habe am 18. Mai mal den Zähler von Blogcounter.de auf diesem Blog eingebaut. In erster Linie, weil ich neugierig war, wie die Darstellung sein würde. Denn schon seit einiger Zeit beschäftige ich mich gedanklich mit einem Statistik-/Auswertetool speziell für Blogs.
Parallel zu Blogcounter habe ich dann die Webalizer-Ausgaben des Hosters dieses Blogs (domainfactory.de) angeschaut und mir ein paar Tageslogfiles von olbertz.de runtergeladen.
In den Apache-Logfiles steht natürlich elendig viel Müll drin, der in erster Linie von (im Mai) insgesamt mehr als 20.000 Zugriffen auf Kommentar- und Trackbackskripte herrührt! Captcha und ein paar andere Tricks helfen aber dabei, dieses Blog frei von Spam zu halten.
Durch die technischen Gegebenheiten von Blogcounter fallen diese Zugriffe also schonmal weg, was aber auch ganz in meinem Interesse liegt: Da Blogcounter nur als HTML-Code in Seiten eingebettet wird, kann er Zugriffe auf nicht-existierende Seiten, oder auf Seiten, die den HTML-Code nicht eingebaut haben, nicht zählen.
Das ärgerliche ist aber, dass der Blogcounter auch ganz andere Sachen nicht zählt. Im Logfile und in Webalizer habe ich jezt für die ersten 30 Stunden im Juni Suchanfragen über Google & Co. (30 Stück), wohingegen Blogcounter nur 5 aufführt.
Die Zeilen im Apache-Logfile weisen nichts besonderes auf, so dass ich nicht davon ausgehe, dass Blogcounter einen Anlaß hatte, diese Besucher zu ignorieren. Natürlich habe ich die Zielseiten auch überprüft und den Code des Zählers dort gefunden.
Um es deutlich zu machen: ich glaube nicht, dass Blogcounter irgendwas manipuliert, die Serverlast, die durch die dauernden Zählcode-Aufrufe verursacht wird, scheint Blogcounter aber zu überfordern. Wenn man sich den Code von Blogcounter anschaut, stellt man fest, das ganz klassisch entweder über das Image selbst (http://track.blogcounter.de/log.php?id=dirk) oder über JS-Code, den Referer und andere Statistikdaten ausliest und dann das Image aufruft: http://www.blogcounter.de/bc/log.php?id=dirk&referer=&r=1280×1024&c=32&showme=y&st=img&title=The%20blog%20that%20never%20sleeps%20-%20&style=4&url=http://www.olbertz.de/&b=589
Auch wenn die URLs unterschiedlich aufgebaut sind und die Rückgabe von http://track.blogcounter.de/log.php?id=dirk total unsinnig ist und nichts mit einem Bild zu tun hat, scheint Blogcounter diese Anfragen korrekt zu zählen und auch darzustellen.
Ich kenne jetzt die Architektur hinter Blogcounter nicht und kann so nur zwei Vermutungen aufführen: entweder wird jeweils in dem PHP-Skript direkt in die Datenbank gezählt, oder die Aufrufe dieser Zeilen wird regelmäßig aus den Logfiles gescannt und dann in die Datenbank geschrieben. Der zweite Fall wäre sinnvoller, weil dann auch zu Peakzeiten keine Verzögerung beim Aufruf des Skriptes durch das Warten auf die Datenbank auftreten sollte. In beiden Fällen verschluckt Blogcounter aber relevante Informationen.
Wenn ich mich nämlich mit solchen Tools beschäftige, dann aus dem Grund, um herauszufinden, wo Besucher landen, die über Suchmaschinen oder andere Links reinkommen und was ich an den entsprechenden Artikeln vielleicht noch ergänzen und/oder verbessern kann. Ich habe den Counter inzwischen wieder ausgebaut und werde mich wohl doch an dem eigenen Tool zu schaffen machen müssen.
Ich habe bei mir auch ein paar unterschiede festgestellt. Statcounter zählt fast doppelt so viel wie blogcounter zum Beispiel.
Also generelle tracking lösung denke ich ist das IVW im Moment wirklich nicht schlecht. Besonders da es skalierbar ist. Hierbei scheint eine box für das zählenzuständig zu sein und das eigentlich einfach über eine error page zu machen. z.B. liefert diezählbox.de/CGI-BIN/Track/blahblahblah_undblah einfach einen fehler zurück und redircted auf ein 1×1 pixel. Der Server kann sich so voll selber darum kümmern. Der Logfile wird dann noch ein wenig aggregiert und dann von einem collector abgerufen und weiter aggregiert. Der Collector kann dann natürlich auch 34 zählboxen abfragen und aggregieren.
Ja, die Sache mit dem Redirect zum Zählen ist eigentlich Standard. Eine Error-Page müsste die IVW-Box aber trotzdem nicht zurückliefern. Das Schöne an so einer Redirect-Lösung über den Webserver ist, dass nur dieses Logfiles ausgewertet werden muss und das Image auf das redirected wird, ruhig aus dem Cache kommen kann. Somit fällt der Zählvorgang kaum ins Gewicht.
Sorry. Den temporarily moved fehler liefert die Box nur zurück um das bild zu liefern. Ich nehme an das du so besser mit den caching headers spielen kannst als wenn das bild von der seite geliefert wird. Aber das ist nur unter der annahme das die sich da schon was bei gedacht haben. So kannst du das bild halt als bild einbinden obwohl was davor liegt. Kann man aber bestimmt auch anders regeln.