Benutzer-Interaktionen loggen - Besucherzähler & Besucherstatistik

Besucherverhalten messen und auswerten. Dazu dient eine Besucherstatistik - Logging von Benutzer-Interaktionen.

Abstract: Ob nur ein einfacher Hit-Counter auf der Homepage implementiert ist, oder ob professionelle Besucherstatistiken mitsamt Besucherverhalten zur Verfügung stehen, das Webcontrolling wird heutzutage von Webmaster mehrheitlich konsequent betrieben und hängt weitgehend von den Ambitionen der Webmaster ab. Jedoch wird ein Aspekt im Umfeld des Webcontrollings oft vernachlässigt: das Logging von Benutzer-Interaktionen.

Webmaster wissen - einmal abgesehen vom Interpretationsspielraum bei den Benutzerkennzahlen 'Hits', 'Visits' und dergleichen - recht genau, wie stark frequentiert ihre Websites sind. Neben dem Google-PR ist die Höhe der Visits pro Monat unter Webmaster eine der beliebtesten Vergleichsgrössen für den Erfolg einer Website. Wer nicht nur einen kostenlosen Counter einbaut, sondern gleich professionelle Webcontrolling-Dienstleistungen in Anspruch nimmt, erhält neben den nackten Besucherzahlen auch Angaben zum Besucherverhalten, wie z.B. die Klickpfade der Surfer. Etwas liefern jedoch selbst diese Angebote nicht: Eine übersichtliche Zusammenfassung aller Benutzer-Interaktionen auf der Website, wie sie insbesondere in Benutzerdialogen und der Validierung der Benutzereingaben auftreten.

Wer bei der Validierung von Formulareingaben Fehleingaben oder Kennzahlen von korrekten Eingaben (wie z.B. die Länge einer Texteingabe) nicht erfasst, dem entgehen nützliche Informationen zur Usability seiner Website. So haben Auswertungen des 'Webgreenhorn.com' Benutzer-Logs ergeben, dass bei der Anmeldung zum Newsletter unnötige Fehleingaben entstanden sind, weil im Feld für die e-Mail Adresse das '@' Zeichen stand. Eingaben wie 'hans@muster.com@' wurden (erstaunlicherweise) nicht selten vorgenommen - weil e-Mail Felder von gewissen Leuten offensichtlich mit Copy-Paste ausgefüllt werden. Aus Formulareingaben lassen sich aber nicht nur Rückschlüsse auf die Benutzerfreundlichkeit der Userdialoge schliessen, auch gescheiterte (oder erfolgreiche!) Missbräuche wie HTML-Injection sind daraus ersichtlich.

Ein Logfile für Benutzer-Interaktion lässt sich sehr einfach erzeugen, indem für ausgewählte Ereignisse, resp. Benutzeraktionen ein Eintrag in einem Textfile auf dem Webserver vorgenommen wird (z.B. mit Server-seitigen Skriptsprachen wie PHP). Geloggt werden kann grundsätzlich vieles, hier nur einige wenige Ideen: Anmeldungen neuer Newsletter-Abonnenten, Benutzer-Logins, Fehleingaben aus Formularen, Fehlermeldungen des MySQL-Datenbank Servers. Auch Besuche der wichtigsten Suchmaschinen-Spider und Besuche von Partnerseiten sind unter Umständen von Interesse, obwohl diese natürlich auch in den Access Logs stehen. Solche Einträge in das Logfile werden ausgelöst, wenn der URL der Partnerseite im HTTP Refferer oder der Name des Suchmaschinen-Bots im User Agent erkannt wird. Wer's gerne übersichtlich und bequem hat, der lässt einen Cron-Job auf dem Server um Mitternacht noch eine Tagesmarkierung einfügen und sich das Logfile täglich oder wöchentlich - je nach Aktivitätsniveau auf der Website - per e-Mail zuschicken. Auf diese Weise erhält der Webmaster einen im Vergleich zu Access Logfiles oder reinen Besucherstatistiken wesentlich verdichteten und übersichtlicheren Wochenüberblick über die Aktivitäten auf seiner Website mitgeliefert.

Der Umfang der geloggten Information muss sorgfältig gewählt werden und steht in direktem Zusammenhang mit der Übersichtlichkeit, resp. der Zweckhaftigkeit des Loggings. Bei einem grossen Forum mit hunderten von Beiträgen pro Tag macht es natürlich wenig Sinn, jeden verfassten Beitrag etwa mit '[2005-09-02] [19:20:53] NOTICE - Neues Thema erstellt' zu loggen, zumal diese Benutzeraktion schon im Administrationsbereich des Forums durch die Moderatoren geprüft wird. Aber bei einem ein Eintrag wie '[2005-09-02] [19:20:53] WARNING - ungültige Mailadresse (Eingabe: "hans@muster.de'; DROP TABLE members; --")' im Logfile des eigenen Freizeitprojektes wird sich wahrscheinlich mancher noch einmal überlegen, ob seine Website wirklich sicher vor SQL-Injection ist.

[Copyright by Christoph Cronimund, http://www.webgreenhorn.com/]