Ich habe eine Woche laenger als geplant Urlaub gemacht. Ueber den Laptop und ein Uralt-Modem im Buero habe ich den Kontakt mit der Aussenwelt nicht ganz verloren, obwohl der Besuch mehrerer historischer Festungen, eingerichtet zur Verteidigung der britischen Kueste waehrend der letzten 900 Jahre, dem Sprung in die Realitaet nicht gerade dienlich war.
Da mir unterwegs der Lesestoff ausging, und Amazon nicht ins Wohnmobil liefert, habe ich mir ueber das Modem ein altes Log-File meines Web Servers beschafft [anderthalb Stunden mit 9600 Baud].
Vor etwa zwei Monaten erwaehnte ich, dass ich vorhabe, ein meinen Anforderungen entsprechendes Log-Auswertungsprogramm zu schreiben und als Open Source-Projekt abzugeben.
Zunaechst die schlechten Nachrichten.
Sie haben weniger Pageviews, als bisher angenommen. Alle bekannten Log-Auswertungsprogramme uebertreiben. Nicht bewusst. Sondern, weil Server-Aufzeichnungen von Natur her nur festhalten, "was passiert". Die Interpretation dieser Aufzeichnungen laesst generell aber sehr zu wuenschen uebrig.
Netzwerkstoerungen und Bugs in zahlreichen Anwendungen sorgen fuer deutliche Ueberrepraesentation. Netzwerkstoerungen, gegen die wir alle machtlos sind, fuehren zu sog. Reloads. Der Server hat eine Seite zwar geschickt, der Abrufer hat diese aber nicht [oder nicht vollstaendig] erhalten, weil es an Bandbreite oder an Geduld mangelte.
Fast alle Log-Auswertungsprogramme zaehlen Reloads, die im Log _nicht_ als solche gekennzeichnet sind, mit.
Eine Krankheit fuer sich die zahlreiche Suchmaschinen-Spider. Wer eine Seite bei AltaVista anmeldet, findet bis zu vier Abrufe in seinem Log: /robots.txt und dann bis zu 3 aufeinander folgende Abrufe der angemeldeten Seite.
Grosses Geschrei gab es auf einer deutschsprachigen Liste kuerzlich, weil Acoon - wie die Eule [und andere] auch - den Robot Exclusion Standard ganz ignoriert und damit wie ein Elefant im Porzellanladen auftritt.
Schlimmer ist, wenn das robots.txt-File abgerufen, dann aber ignoriert oder fehlinterpretiert wird. Bei manchen klappt es einfach nicht.
Auch Seitenaufrufe nicht existierender Seiten werden u.U. als Pageview gezaehlt. Je nach Konfiguration gibt der Web Server eine eigene oder eine vom Betreiber kontrollierte Meldung aus. Wenn diese Meldung mit dem HTTP-Status 200 [d.h. OK] statt 404 [Nicht gefunden] retourniert wird, bleiben solche Seiten in den Suchmaschinen und werden auch bei der Auswertung mitgezaehlt.
Ein solches Beispiel sehen Sie, wenn Sie bei www.go.com, der momentanen Adresse der amerikanischen Infoseek-Suchmaschine, nach Fussball suchen.
Verhindern koennen Sie das, indem Sie dafuer sorgen, dass bei fehlerhaften Aufrufen auch der entsprechende Fehler-Code an den Abrufer uebermittelt wird. Zumindest theoretisch. Selbst AltaVista hat Seiten im Bestand, die nicht existieren, die trotz regelmaessigem Spidern und trotz korrekter Fehler-Meldung nicht aus der Datenbank geloescht werden - Groesse war schon immer Synonym fuer Potenz.
AltaVista befindet sich dabei in Gesellschaft. Ein sog. Crawler fordert auf meiner Site von Zeit zu Zeit Seiten an, die ich Anfang '98 geloescht habe. Manche rufen gar Seiten ab, die ich noch nie gehabt habe. Dann gibt es noch solche, die zwar spidern - und wie - aber den Anschluss an den Datenzug verpassen. Infoseek.com ist eine solche Suchmaschine. Alle von Inktomi belieferten Suchmaschinen gehen ebenfalls sehr selektiv vor.
Wer angesichts dieser Zustaende daran glaubt, dass das sog. Bandbreitenproblem irgendwann geloest wird, verkennt, was mit Perl gemacht werden kann. Ein fehlerhafter Spider ist in Perl schneller zusammengeschraubt, als sich Verkehrsstaus bilden.
Die gute Nachricht:
Die Geschaefte laufen besser, als Sie dachten. Nicht, dass Ihre Web Site dadurch mehr Umsatz ausloest. Aber der bisher erzielte Umsatz basiert auf ca. 20 bis 25% weniger Pageviews, als bisher angenommen.
Das nahezu fertiggestellte Log-Auswertungsprogramm zeigt Ihnen u.a.:
O Wieviele Seiten, CGI-Aufrufe, Texte, komprimierte Dateien und Grafiken abgerufen und wieviele davon uebermittelt werden O Verbrauchte Bandbreite nach Dateityp O Zahl der Direktzugriffe, Lesezeichen-Zugriffe, externer Referer und Zahl der Besucher, die Ihre Site in den Suchmaschinen finden. O Zahl der Besuche, Anteil der Besucher, die Grafik aktiviert haben, Zahl der Besucher und Zahl der Hosts O Wieviele MSIE-Anwender ein Bookmark setzen O Seiten mit den hoechsten Aufrufzahlen O Entry-Seiten, d.h. die Seite, die von Ihren Besuchern als erste aufgerufen wird O Exit-Seiten, d.h. welche Seiten zuletzt aufgerufen werden [und die das Ziel, den Besucher zum Weiterlesen aufzufordern, nicht erreicht haben] O Zahl der bestfrequentierten Verzeichnisse, falls Sie Seiten thematisch in Verzeichnisse aufteilen O Wer Ihnen die meisten Besucher schickt O Welche Suchmaschinen die meisten Besucher schicken O Welche Suchbegriffe in den Suchmaschinen den Besuch Ihrer Site ausloesen O Wer die meisten Fehler ausloest und, falls Sie durch Passwort geschuetzte Seiten haben, wer die meisten unbefugten Zugriffsversuche ausloest O Durchschnittliche Zahl gezeigter Seiten pro Besucher
Bisher erfolgt die Ausgabe als Text-Datei. Im Laufe der Woche wird dies auf HTML-Ausgabe umgestellt und Portabilitaet auf mehreren Betriebssystem getestet. Wenn nichts dazwischenkommt, kann ich naechste Woche an dieser Stelle einen Link zum Download bieten.
Dubletten in Suchmaschinen sind ein Aergernis. Die Betreiber kosten Dubletten nur Geld in Form von Bandbreite, CPU-Zeit und Plattenplatz. Den Suchenden stoert's mehr, weil er nicht findet, was er wirklich sucht. Ein Leser berichtete kuerzlich, wie der Lycos-Spider aus ein paar Seiten einer Praesenz mehr als 17,000 [siebzehntausend] machte.
Der "Trick": die Site liefert - wie meine auch - dynamische Seiten, bei denen jeder Link um eine User-ID erweitert wird, ohne die effizientes User Tracking nicht moeglich ist. Das heisst bei jedem "neuen Besucher" wird eine andere ID vergeben, eine neue URL aus der Luft zaubernd. Da diese neue ID offensichtlich auch vergeben wird, wenn Spider Seiten abrufen, ist der Lycos-Spider mit dieser Site, sagen wir mal, vorerst beschaeftigt.
Wer dynamische Seiten austeilt, muss natuerlich darauf achten, dass IDs nach Moeglichkeit Wiederverwendung finden, sodass jedem korrekt erkannten Besucher immer die gleiche ID zugeteilt wird. Bei Suchmaschinen ist dies besonders einfach, da jede einen eigenen "User-Agent", d.h. Name des Programms, das spidert, uebermittelt. Aber davon abgesehen bietet eine Datenbank, die ausgeteilte IDs auf dem Server fuer z.B. drei Monate speichert, Vorteile:
Wiederkehrende Besucher erhalten die gleiche ID. Bereits gesehene URLs werden in vielen Browsern gesondert dargestellt, wodurch die Navigation fuer den Besucher vereinfacht wird.
Obendrein laesst sich so auch ueber groessere Zeitraeume ermitteln, welche Seiten welche Besucher besonders interessant finden.
Und letztendlich vermeiden Sie "wrap", d.h. wenn die groesste in 4 Bytes darstellbare Nummer durch das Anheben um eins ploetzlich zur negativen Zahl wird und Ihre Software dadurch moeglicherweise aus dem Gleichgewicht kommt.
Meine Statistik, mit der ich monatlich messe, wieviele Besucher JavaScript aktiviert haben, deckt sich nicht mit mindestens einer anderen solchen Untersuchung. Gruende fuer moegliche Abweichungen:
Auf meiner Site wird der Test nur einmal pro Besucher gemacht und nicht bei jedem Seitenaufruf. Die Zahl der Seitenaufrufe pro Besucher hat daher auf das Ergebnis keinen [verfaelschenden] Einfluss.
Meine Site richtet sich ueberwiegend an reifere Besucher [weil ich Online verkaufe]. Juengere Besucher sind vielleicht strapazierfaehiger, so dass die Browser-Konfiguration nicht angepasst wird.
Wie bei jeder Statistik, ist der Aussagewert mit Vorbehalt zu geniessen. Viele meiner Besucher sind Verantwortliche professioneller Praesenzen. Zeit fuer Hyperaktivitaet und meist auch Grafik ist meist vertane Zeit. Die Entwicklung des eingangs erwaehnten Log-Auswertungsprogramms zeigt uebrigens, dass ich nicht der einzige bin, der den Browser ohne Grafik benutzt.
© Copyright 1998 - 2009 Klaus Schallhorn.