|
Messung von Internetnutzung
von Kerstin Schrepfer
Inhaltsverzeichnis:
1. Erfolgsmessung von Webangeboten
2. Cookies - Vom Nutzen des Übels
2.1. Der Nutzen von Cookies
2.2. Aufbau und Inhalt eines Cookies
2.3. Bedenken gegeüber der Verwendung von Cookies
2.4. Nutzen für die Erfolgsmessung
3. Logfileanalyse
3.1. PageImpressions
3.2. Visits
4. Auswertung und Nutzen von Logfiles
4.1. Die IP-Adresse
4.2. Die Zeitangabe
4.3. Wortlaut der Anfrage (Pfad)
4.4. Der http-Statuscode und das Transfervolumen
4.5. Referer-Daten
4.6. Agent-Information
5.Verzerrung der Daten
5.1. Proxy- und Cache-Server
5.2. Suchmaschinen und Robots
6. Sinn und Unsinn der Reichweitenmessung im Internet
7. Quellenverzeichnis
1. Erfolgsmessung von Webangeboten
Reichweitenmessungen sind in den alten Medien wie Fernsehen, Radio und Zeitschriften
eine Normalität, während die Reichweitenforschung bzw. Erfolgskontrolle
bei Online-Medien, auch Web-Controlling genannt, erst seit einigen Jahren im
Gespräch ist und sich gerade noch in der Wachstumsphase befindet. Immer
mehr Online-Anbieter entdecken die Möglichkeit der Erfolgskontrolle für
ihre Internet-Angebote und es haben sich in den letzten Jahren bereits einige
Firmen auf diesen Forschungsbereich spezialisiert, wie z.B. Luna-Park, oder
ihr Angebot entsprechend erweitert, wie beispielsweise die Interessengemeinschaft
zur Verbreitung von Werbeträgern e.V. (IVW) oder MMXI Europe in Zusammenarbeit
mit der Gesellschaft für Konsumforschung (GfK). Vor allem die IVW ist darum
bemüht, daß sich einheitliche Maßeinheiten etablieren, um einen
Vergleich der verschiedenen Daten zu ermöglichen.
Die Ergebnisse der Analysen helfen den Webanbietern, die Schwächen und
Stärken ihrer Online-Angebot zu ermitteln und entsprechende Handlungsschritte
einzuleiten. Auch im Bereich der Anzeigenschaltung können sich Unternehmen
bezüglich der Preiskalkulation auf die Analyseergebnisse stützen und
ihren Kunden angemessene Angebote machen. Während sich die IVW früher
hauptsächlich nur für die zahlende Kundschaft interessiert hat, die
sich aus Werbung finanziert hat, ist sie inzwischen dazu übergegangen,
ihre Angebot der Reichweitenmessung auch nicht-kommerziellen, werbefreien Web-Anbietern
zur Verfügung zu stellen, womit beispielsweise die Web-TV Angebote der
öffentlich-rechtlichen Rundfunkanstalten gemeint sind.
Im Bereich der Online-Medien gibt es verschiedene Möglichkeiten der Erfolgskontrolle.
So ermitteln z.B. NetValue und MMXI Europe mittels Panel die Nutzungszahlen
für Internetangebote, wofür sie eine spezielle Software an den Computern
der Panelteilnehmer installieren, das alle Aktivitäten des Mediennutzers
erfaßt und speichert. Da dieses Verfahren jedoch bereits einigermaßen
aus der Fernsehreichweitenforschung bekannt ist, möchte ich mich in dieser
Arbeit mehr auf die unbekannteren Methoden konzentrieren, die sich vor allem
auf die Auswertung von Logfiles stützen. Doch obwohl dieses Verfahren auf
den ersten Blick sehr überzeugend wirkt, ist die Glaubwürdigkeit der
erhobenen Daten eher gering, da sich die Technologie des Internets als sehr
komplex erweist. Die einfacheren Methoden der Erfolgsmessung z.B. durch “Leserbriefe”,
d.h. in diesem Fall direkte Rückmeldungen durch Emails oder beispielsweise
direkter Austausch im Chat, möchte ich hier ebenfalls beiseite lassen,
da es sich lediglich um ergänzende Mittel der Erfolgskontrolle oder Öffentlichkeitsarbeit
aber nicht um statistische Meßmethoden handelt. Bevor ich jedoch ausführlich
auf die Auswertung von Logfiles zu sprechen komme, möchte ich kurz die
Möglichkeit des Cookieeinsatzes bei der Erforschung der Internetnutzung
darlegen, die im Gegensatz zur Rückmeldung per Emails und Chats nicht dermaßen
vom Wohlwollen des Nutzers abhängt.
2. Cookies - vom Nutzen des Übels
Viele Internetnutzer haben bereits schon einmal von Cookies gehört oder
haben sie bereits “persönlich” kennengelernt, doch was sich genau
dahinter verbirgt, ist den meisten nicht bekannt. In der Regel hört man
viel Negatives über Cookies, obwohl sie für die User oftmals auch
erhebliche Vorteile mit sich bringen. “Cookies wurden mit dem Browser Netscape
Navigator 1.1 im Jahre 1994 als “Netscape Cookies” eingeführt
[und] der Navigator bot mit der Version 2.0 erstmals die Möglichkeit, Cookies
zu deaktivieren,” man ist also den Cookies keineswegs hilflos ausgeliefert.
Bei einem Cookie handelt es sich um eine kleine Textdatei, die in einem extra
dafür vorgesehenen Verzeichnis, das je nach verwendeten Browser in unterschiedlichen
Unterordnern zu finden ist, auf der Festplatte abgespeichert wird. Die Speicherung
der Cookiesdatei führt der eigenen Browser durch, wohingegen der Server
der angezeigten Website keine Zugriffsmöglichkeit hat. Er kann folglich
den Browser des Besuchers lediglich mit der Niederlegung eines Cookies beauftragen.
Die gespeicherten Informationen stehen jeweils mit der vom Nutzer besuchten
Internetseite im Zusammenhang und werden bei Beenden des Browsers entweder sofort
gelöscht oder ,wie bereits erwähnt, in einem entsprechenden Verzeichnis
auf der Festplatte gespeichert. Besucht man nach einiger Zeit erneut diese Website,
überprüft der Browser, ob der URL-Pfad der Website mit dem im Cookie
angegebenen übereinstimmt und schickt die Informationen des Cookies nur
dann an den Webserver zurück, wenn sich die beiden URLs decken (Näheres
hierzu siehe unten). Ist dies nicht der Fall, “können [die Cookies]
nicht ausgeführt werden, d.h. sie können nichts andres machen als
Text enthalten.”
2.1. Der Nutzen von Cookies
Durch den Einsatz von Cookies wird das Surfen im Internet teilweise erleichtert
bzw. automatisiert, da sich z.B. eine wiederholte Eingabe von Informationen
in Formulare für den Internetnutzer erübrigt, diese können nämlich
einfach und schnell durch Cookies festgehalten und bei Bedarf aktiviert werden.
Der Nutzer spart somit sowohl Zeit als auch Kosten (falls nach Einheiten abgerechnet
wird). Sucht man sich beispielsweise in einer Internetbuchhandlung verschiedene
Bücher heraus, wird bei jeder Markierung ein Cookie abgelegt. Gelangt man
schließlich zum Bestellformular, muß der Kunde die Artikelangaben
nicht erst wiederholen, da sie durch die Cookies automatisch geladen werden.
Zudem kann der entsprechende Web-Server anhand der Informationen aus dem Cookie
erfahren, ob der Nutzer z.B. Krimis oder Liebesromane favorisiert und bei dem
nächsten Besuch auf die jeweiligen Neuerscheinungen aus diesem Bereich
hinweisen. Der Web-Anbieter hat demzufolge die Möglichkeit, seine Website
bzw. die Werbung individuell auf den Besucher abzustimmen. Ähnlich verhält
es sich auch mit personalisierten Websites, wie man sie sich z.B. bei yahoo
zusammenstellen kann. Dort werden die Informationen, wie sich der Nutzer seine
persönlich zugeschnittene Website wünscht, in Cookies mit entsprechend
langer Lebenszeit abgespeichert.
Die Funktionsweise der Cookies kann auch für die Messung der Internetnutzung
nutzbar gemacht werden, denn durch die Aktivierung seiner Cookies kann ein Webserver
feststellen, wann und wie oft ein Nutzer sein Internetangebot besucht hat. Zudem
läßt sich ein Besucher, der eine dynamische IP-Adresse erhalten hat
und somit eigentlich für den Webserver unkenntlich geworden ist, durch
Cookies eindeutig identifizieren. Dynamische IP-Adressen werden z.B. von T-Online
und Compuserv benutzt, die ihren Kunden beim Einwählen ins Internet eine
zufällig ausgewählte IP-Adresse mit auf den Weg geben, mit der sie
schließlich auch bei den Webservern registriert werden. Ein Webserver
könnte nun aufgrund der “falschen” IP-Adresse annehmen, daß
es sich um einen bisher unbekannten Besucher oder - falls es eine bereits bekannte
Adresse ist - um einen bereits bekannten Besucher handelt. Anhand von Cookies
wird jedoch eine eindeutige Identifizierung des Nutzers möglich, wenn man
einmal davon absieht, daß es sich nicht immer die gleiche Person vor dem
gleichen Rechner sitzen muß. Auch wenn dies noch nicht für eine aussagekräftige
Analyse genügt, erlauben die Cookies dem Webserver zumindest eine ungefähr
Einschätzung der Nutzung seines Web-Angebotes.
2.2. Aufbau und Inhalte eines Cookies
Die Informationen im Cookie beziehen sich - wie bereits gesagt - jeweils nur
auf den Webserver, der sie vom Browser anlegen ließ, d.h. andere Webserver
können nicht ohne Erlaubnis auf die Cookies zugreifen (wobei es auch hier
Möglichkeiten gibt, dies zu umgehen, worauf ich aber im Anschluß
noch zu sprechen komme).
Anhand von zwei Beispielen, die aus der Internetseite von Uwe Brinkmann herstammen,
werde ich im Weiteren den Aufbau eines Cookies erläutern:
·.netscape.com TRUE / FALSE 946688399 NETSCAPE_IP 1000e020,10073a5f
·www.bingo-ev.de FALSE /cgi-bin/ub FALSE 873421199 NAME Uwe%20Brinkmann
Der erste Abschnitt, die Domain, nennt den Hostname des Servers, von dem das
Cookie ursprünglich gesetzt wurde und an den die Informationen aus dem
Cookie auch wieder zurückgesendet werden dürfen.
An zweiter Stelle befindet sich sozusagen noch einmal eine Bestätigung
des ersten Abschnittes, der Wahrheitswert. “TRUE” bedeutet, daß
jeder weitere Rechner der Domain Zugriff auf das Cookies erhalten kann, während
bei “FALSE” dagegen nur der speziell genannte Rechner zugreifen darf.
Wenn z.B. wie im erstgenannten Cookie nach der Domain “.netscape.com”
der Wahrheitswert TRUE steht, erhalten auch andere Rechner dieser Domain die
Informationen, wie z.B. “cgi.netscape.com”.
Der nächste Wert wird Path (dt. “Pfad”) genannt. Auf Wunsch kann
hier - wie im zweiten Beispiel zu sehen - zusätzlich eine unteres Verzeichnis
angegeben werden, so daß das Cookies nur dann zurückgesendet wird,
wenn sich der Nutzer auf dieser speziellen oder einer ihr untergeordneten Website
befindet. Meistens findet man aber lediglich das Zeichen “/”, “das
für die oberste Pfadebene (steht) und bedeutet, daß die Information
immer übertragen wird.”
An nächster Stelle ist wiederum ein Wahrheitswert (engl. “secure”)
zu finden. “TRUE” bedeutet diesmal, daß die Informationen nur
bei einer sicheren Verbindung zwischen Client und Server zurückgegeben
werden, “d.h. wenn HTTPS (HTTP oder SSL) verwendet wird.”
Im Weiteren wird das Verfallsdatum des Cookies aufgeführt, das duch einen
neunstelligen Zahlencode verschlüsselt ist. Mit Ablauf des Datums löscht
der Browser das Cookie und die Informationen werden nicht mehr an den Server
gesendet.
Im Anschluß daran steht der Name des Cookies, der häufig abgekürzt
wird, und an letzter Stelle der wichtigste Part des Cookies: der Wert. Im zweiten
Beispiel wurde z.B. der Name “Uwe Brinkmann” als Wert festgehalten,
wobei das Zeichen %20 im ASCII-Code, in dem die Cookies geschrieben werden,
einem Leerzeichen entspricht. Allerdings sind die gespeicherten Informationen
nicht immer so deutlich erkennbar, sondern wurden manchmal durch einen verschlüsselten
Code unleserlich gemacht (siehe erstes Beispiel). Es empfiehlt sich jedoch,
solche Cookies zu löschen, denn der Webserver sollte dem Besitzer des Rechners
aus Vertrauensgründen die Möglichkeit geben, die über ihn gespeicherten
Informationen zu kontrollieren.
Ein Cookie darf maximal die Größe von 4 KB haben und ein Server darf
nicht mehr als 20 Cookies pro Domain ablegen. Damit sollen die Nutzer davor
geschützt werden, daß die Festplatte nicht mit Datenmüll zugeschüttet
wird und sich außerdem die übertragene Datenmenge, die durch das
Versenden von Cookies entsteht, in einem angemessenen Rahmen hält. Deshalb
ist auch die Zahl der Cookies auf einer Festplatte auf höchstens 300 festgelegt.
Trotz dieser Einschränkungen und Sicherheitsvorkehrungen gibt es doch noch
einige kritische Anmerkungen zum Cookiegebrauch, die für Internetnutzer
aber auch für Webanbieter von Interesse sein könnten.
2.3. Bedenken gegenüber der Verwendung von Cookies
Obwohl die Anzahl der Cookies pro Server und Rechner beschränkt ist, “entsteht
eventuell ... bei hoher Auslastung erhebliche Netzbelastung und damit Wartezeiten.”
Würde man sich bei der Erfolgsmessung auf Cookies beschränken, würde
man mit diesem Problem auf jeden Fall konfrontiert werden, aber ansonsten sind
diese Bedenken eher unbegründet.
Mehr Unbehagen bereitet jedoch der Gedanke, daß wir Nutzer in unserem
Verhalten ausspioniert und die gesammelten Daten mißbraucht werden können.
So konnte ich z.B. auf der Website von Uwe Berger erfahren, daß Webserver
durchaus auch in der Lage sind, Cookie-Informationen konkurrierender Webanbieter
abzurufen und für ihre Zwecke zu gebrauchen. Laut Uwe Berger existiert
im Internet-Explorer ein Programmfehler (“Bug”), der es WebServern
ermöglicht ihre URL derart zu manipulieren, daß der Microsoft-Browser
annimmt, er befände sich auf der Website eines anderen Angebotes. Wenn
“eine Website mit böser Absicht hinter ihre URL für die weitere
Navigation statt einem Slash ein Prozentzeichen ein(fügt), Beispiel: http://www.url.de%xxx%2xxx%2xxx%3F.yyy.com,
überspringt der Microsoft-Browser die Prozentzeichen und behandelt die
zuletzt genannte Adresse, in unserem Fall yyy.com so, als befände man sich
auf der Seite.” Der Browser sendet somit auch die Cookie-Informationen
des anderen Servers an die manipulierte Website und gibt damit je nach Inhalt
des Cookies auch Informationen preis, die nicht für Dritte gedacht waren.
In diesem Zusammenhang gab es in den USA bereits eine Klage gegen den Internet-Werbungsvermarkter
DoubleClick.
2.4. Nutzen für die Erfolgsmessung
Wie die Ausführungen gezeigt haben, können Cookies Servern einige
interessante Informationen über ihre Besucher liefern. So läßt
sich z.B. erfahren, wann und wie oft der User auf die Website zugegriffen hat,
welche IP-Adresse, welchen Internet-Browser oder welches Betriebssystem er besitzt.
Um aber eine umfassende Analyse zu erstellen und damit valide Aussagen über
das Surfverhalten auf der Website und deren Reichweite machen zu können,
müßte der Gebrauch von Cookies immens ausgeweitet werden, was aber
auf Grund der Beschränkungen und der zu transportierenden Datenmenge nicht
möglich ist. Zudem sollte man als Webanbieter bedenken, daß der Nutzer
nicht mit Cookies überhäuft werden möchte und dieser eventuell
auch negativ gegen Cookies eingestellt ist. Man würde damit lediglich riskieren,
den Nutzer eventuell zu verlieren. Eine “kundenfreundlichere” Erfolgsmessung
wäre die Auswertung von Logfiles, die User beim Surfen im Internet bei
den besuchten Webservern hinterlassen. Allerdings können die Cookies dabei
eine hilfreiche Ergänzung darstellen, wie sich bei den folgenden Ausführungen
noch zeigen wird.
3. Logfileanalysen
In Deutschland wurde das Verfahren zur Onlinereichweitenmessung mit Hilfe von
Logfiles durch die IVW (Interessengemeinschaft zur Verbreitung von Werbeträgern)
und dem VDZ (Verband Deutscher Zeitschriftenverleger) im November 1997 eingeführt,
womit ein neuer Standard gesetzt wurde. Logfiles sind Protokolldateien, in denen
jedes vom Webserver angeforderte Objekt einen Eintrag hinterläßt.
Ruft z.B. ein Nutzer eine Seite auf, die aus vier Graphiken, Text und einer
Musikdatei besteht, hinterläßt er im Logfile fünf Einträge,
die jeweils neben der Angabe des angeforderten Objekts auch noch eine Vielzahl
weiterer Informationen über den Besucher. Diese einzelnen Zeilen bzw. Einträge
in der Protokolldatei bezeichnet man als Hit, d.h. als “Zugriff auf ein
einzelnes Element einer HTML-Seite”. Der Nutzer im erwähnten Beispiele
würde demnach fünf Hits erzeugen. Ursprünglich galt die Azahl
der Hits als Maßstab für den Erfolg einer Website, da diese Maßeinheit
jedoch mehr vom grafischen Aufbau einer Seite als von der Zahl der Besucher
abhängt, eignen sich Hits nur bedingt bzw. genaugenommen überhaupt
nicht zur Erfolgsbewertung einer Website. Deshalb einigten sich im August 1996
“die vier Medienverbände (Zeitungs- und Zeitschriftenverleger, Private
Rundfunk- und Fernsehanstalten sowie Mulitmediaverband) auf PageViews [heute:
PageImpressions, d. A.] und Visits als “Medienwährung””,
da diese von der graphischen Aufbereitung einer Website unabhängig sind
und als standardisierte Größen einen Vergleich mit Konkurrenz- oder
eigenen Archivdaten möglich machen.
3.1. PageImpressions
Der Begriff PageImpression (dt.: “Seitenabfrage”) “bezeichnet
die Anzahl der Sichtkontakte mit einer potentiell werbeführenden HTML-Seite.
Sie liefern ein Maß für die Nutzung einzelner Seiten eines Angebotes.”
Es heißt hier “potentiell werbeführenden HTML-Seite”, weil
die Ergebnisse dieses Meßverfahrens als Basis für die Berechnung
der Werbebannerpreise herangezogen werden, die beispielsweise nach dem Prinzip
des Tausend-Kontakt-Preises abgerechnet werden. Doch auch hier taucht beim Zählen
der PageImpressions das Problem auf, daß die Zahlen z.B. durch Verwendung
von Framesets nach oben manipuliert werden können. Die Frametechnik wurde
vom Browserhersteller Netscape eingeführt und ermöglicht es, eine
Website aus mehreren einzelnen HTML-Seiten (Frames) zusammenzusetzen. Jedes
einzelne Frame würde jedoch im Normalfall als Seite betrachtet und somit
als PageImpression gezählt werden, was zu einer Verfälschung der Daten
führt. Um die Glaubhaftigkeit der Daten zu gewährleisten, verpflichtet
z.B. die IVW ihre Kunden bzw. Mitglieder dazu, nur jeweils ein Frame im Set
als PageImpression zu zählen. Hierzu stellte sie folgende Regel für
die Contentklassifizierung auf:
“Ein Frameset darf also beim ersten Laden nur einen Frame mit einem Content-Pixel
enthalten. Auch jede weitere Nutzeraktion darf nur in jeweils einem Frameset
ein Content-Pixel aufrufen - dabei darf es sich dann auch um einen anderen Frame
handeln.”
In das auserwählte Frame wird demnach zusätzlich zum bestehenden Inhalt
das IVW-Pixel eingefügt, das bei Abruf der Seite zusammen mit den restlichen
Daten übertragen wird und von der IVW-Box, dem speziell hierfür von
der IVW entwickelten Meßgerät, registriert und als PageImpression
gezählt wird. Die anderen Frames der Website bleiben somit für die
Zählung bedeutungslos.
3.2. Visits
Als zweite anerkannte Maßeinheit zählt ein Visit, der “einen
zusammenhängenden Nutzungsvorgang (Besuch) eines WWW-Angebotes (bezeichnet).
(...) Als Nutzungsvorgang zählt ein technisch erfolgreicher Seitenzugriff
eines Internet-Browsers auf das aktuelle Angebot, wenn er von außerhalb
des Angebotes erfolgt.” Die Auswertung der Visits lassen Aussagen über
das Nutzungsverhalten der Besucher des Web-Angebotes zu. So kann man z.B. betrachten,
wie sich die Besucher im Angebot bewegen und wie lange sie insgesamt die Homepage
besucht haben. Zusammen mit den PageImpressions läßt sich erschließen,
wie intensiv und lange sich der User mit den Inhalten der einzelnen Websites
beschäftigt hat. Allerdings “(gilt) nach einer Richtlinie der deutschen
Werbeindustrie ein Visit als beendet, wenn 30 Minuten lang keine Zugriff mehr
erfolgt ist.”
4. Auswertung und Nutzen von Logfiles
PageImpressions und Visits werden mit Hilfe der Logfile-Auswertung berechnet
und in den sogenannten Reports, die zur Erfolgseinschätzung eines Webangebotes
dienen, statistisch aufbereitet. So kann z.B. ein Website-Anbieter kontrollieren,
wieviele Seiten im Durchschnitt pro Besucher betrachtet wurden und somit auf
die Nutzungsintensität und Attraktivität seines Angebotes schließen.
Im WorldWideWeb existieren verschiedene Arten von Logfiles, da sich nicht alle
Server an den von der W3C verabschiedete Standard halten (so verwenden z.B.
Netscape Enterprise Server und Microsoft IIS andere Formate). Als Standard wird
das von UNIX-Servern verbreitete NCSA-Format betrachtet, doch auch hier können
die Inhalte je nach Voreinstellung variieren. Verwendet man zur Auswertung eine
spezielle Software, sollte man sich vorher versichern, daß die Software
sowohl verschiedene Formate als auch Zusatzinformationen auswerten kann, was
sich aber meist in den Grundeinstellungen einrichten läßt.
Beim Standard-Logfile kann man wiederum zwischen dem Common Logfile Format und
dem Extended Logfile Format unterscheiden, wobei im Extended Logfile zusätzlich
zu den Informationen des Common Logfiles auch z.B. Angaben zum Referer und Agent-Informationen
zu finden sind, die für eine brauchbare Auswertung der Website sehr von
Nutzen sind.
In den nachfolgenden Abschnitten möchte ich anhand eines Extended Logfiles
aufzeigen, was die einzelnen Einträge bedeuten und mit welchen Problemen
bzw. Verzerrungen man bei der Auswertung der Daten rechnen muß. Als Beispiel
soll folgendes Logfile herangezogen werden:
Ics1F.EF.srv.t-online.de - - [23/Apr/1999:20:21:51 +0200] ”GET /images/ielogo.gif
HTTP/1.0” 200 7090 ”http://www.schneegans.de/” ”Mozilla/4.0
(compatible; MSIE 5.0; Windows NT)”
4.1. Die IP-Adresse
“Ics1F.EF.srv.t-online.de”
Zu Beginn des Logfiles steht die IP-Adresse des anfragenden Rechners (hier:
Ics1F.EF.srv.t-online.de). Die IP-Adresse setzt sich eigentlich aus einem numerischen
Code zusammen, der auch in einigen Logfiles zu sehen ist. Manche Webserver können
jedoch die Zahlencodes in den uns geläufigeren Domain-Namen übersetzen,
so daß eine Erkennung des Besuchers erleichtert wird. Anhand der Top-Level-Domain
(z.B. “.de” für Deutschland oder “.es” für Spanien)
läßt sich ferner in einem begrenzten Umfang feststellen, wieviele
Besucher aus dem Ausland angefragt haben. Allerdings muß man bedenken,
daß es sich hierbei um Urlauber handeln könnte, die z.B. in einem
Internetcafe im Ausland im WWW surfen. Internetcafes an sich stellen für
die Identifizierung von Nutzern ebenfalls ein Problem dar, weil man nicht immer
eindeutig unterscheiden kann, ob Nutzer X nur eine Pause eingelegt hat oder
sich bereits ein neuer Nutzer Y vor dem Rechner befindet. Die IP-Adresse im
Logfile ist in diesem Fall die gleiche, auch wenn es sich um zwei verschiedene
Besucher gehandelt haben sollte.
Auch die Zuteilung dynamischer Internetadressen erschwert die Wiedererkennung
eines Users und damit die Identifizierung von Stammbesuchern bzw. die Auswertung
von Visits. Dynamische IP-Adressen werden z.B. von großen Internet-Service-Providern
wie T-Online und CompuServ verwendet. Linkt sich beispielsweise ein Kunde von
T-Online ins WorldWideWeb ein, wird ihm vom Provider T-Online eine neue Identität
verpaßt, indem ihm aus einem Pool von Adressen per Zufall irgendeine beliebige
Adresse zugeteilt wird, mit der er sich weiter auf die Reise ins WWW begibt.
Die im Logfile angegebene IP-Adresse ist daher kaum aussagekräftig, denn
taucht sie z.B. mehrmals im Logfile auf, muß es sich nicht unbedingt um
den gleichen Nutzer handeln, sondern es kann auch ein neuer Besucher dahinterstecken,
der die selbe Internetadresse vom Provider zugeteilt bekommen hat.
Ähnlich verhält es sich mit den Firewalls, ein Programm, das vor allem
viele Firmen zum Schutz gegen Hackerangriffe von außen verwenden. Dieses
Programm reduziert alle internen IP-Adressen auf eine gemeinsame IP-Adresse,
so daß trotz vieler unterschiedlicher Nutzer nur jeweils diese eine IP-Adresse
im Logfile erscheint. Zumindest bleibt in diesem Fall erkennbar, um welche Firmen
es sich handelt, so daß hier durchaus noch Rückschlüsse auf
potentielle Kundschaft gezogen werden können.
Der Undurchsichtigkeit von IP-Adressen kann man allerdings durch den zusätzlichen
Einsatz von Cookies entgegentreten, weil sich mit deren Hilfe die einzelnen
Nutzer eindeutig identifizieren lassen. Weiterhin könnte man User durch
eine Registrierung mit Paßwort zur Aufgabe ihrer Anonymität veranlassen,
doch “Erfahrungen diverser Anbieter ... haben gezeigt, dass die große
Mehrheit der Internet-Nutzer nicht bereit ist, derartige Anmeldeprozeduren zu
akzeptieren.” Meldet sich allerdings ein Besucher mittels eines Paßwortes
an, findet sich im Logfile anstelle der zwei Gedankenstriche “- -”
der Login-Name des Besuchers. Da dies aber selten der Fall ist, bleibt diese
Stelle meistens leer.
Die genannten Schwierigkeiten machen deutlich, daß eine korrekte Erfassung
der Visits nicht gewährleistet ist. Würde sich die Verzerrung der
Daten aber auf diese wenigen Felder beschränken, könnten man sie eventuell
durch statistische Verfahren wieder ausgleichen. Es gibt jedoch weitere technische
Gegebenheiten, wie Proxy- und Cache-Server oder Suchmaschinenrobots und Spiders,
die eine exakte Messung verhindern. Auf diese Punkte werde ich jeodch wegen
der Komplexität des Themas im Kapitel 5 noch ausführlicher zu sprechen
kommen.
4.2. Die Zeitangabe
“[23/Apr/1999:20:21:51 +0200]”
Der nächste Wert gibt den Zeitpunkt des Besuchs an, d.h. wann der Browser
die Dateien vom Webserver angefordert hat. Neben dem Datum (23/Apr/1999) wird
auch die exakte Zeit (20:15:51) inklusive der Abweichung (+0200) gegenüber
der GMT (Greenwich Mean Time) angegeben, wobei jeweils die Systemzeit des Servers
zugrunde liegt. Der Abweichungswert ist vor allem für die Auswertung von
Website-Angeboten notwendig, die sich aus mehreren Servern aufbauen “(z.B.
Load-Balancing oder zusätzliche Datenbanken)”. Ohne diesen Abweichungswert
wäre ein korrektes Zusammenfügen der verschiedenen Logfiles kaum möglich
und man würde verfälschte Werte erhalten. Um die Auswertung zu erleichtern
sollte man bei solch aufgespaltenen Angeboten folglich darauf achten, daß
die Systemzeiten der einzelnen Server übereinstimmen.
Anhand der Zeitdaten kann der Website-Anbieter den besten Zeitpunkt für
das Updaten seines Angebotes ermitteln, denn dies sollte möglichst zu Zeiten
mit geringer Auslastung stattfinden, damit die Seite bis zur “Rush-Our”
wieder ohne Einschränkungen funktionsfähig und auf den aktuellsten
Stand gebracht worden ist.
Die Zeitangaben können zudem hilfreich bei der Einschätzung des Nutzerverhaltens
sein. Es läßt sich z.B. erschließen, wie lange sich ein User
mit dem Web-Angebot insgesamt und den jeweils einzelnen Seiten beschäftigt
hat. Fällt beispielsweise auf, daß sich die Besucher größtenteils
sehr schnell durch das Web-Angebot bewegen, kann der Anbieter die entsprechenden
Seiten gegebenenfalls überarbeiten, indem er z.B. die Textinformation kürzer
fast oder ein attraktiveres Design wählt und eventuell störende Elemente
entfernt. Dagegen lohnt sich auf beliebten Seiten mit langer Aufenthaltszeit
der Einbau von wichtigen Informationen, denn dort erreichen sie die größte
Reichweite und werden mit höherer Wahrscheinlichkeit von den Nutzern wahrgenommen.
Somit läßt sich durch die Analyse der Zeitinformationen die Effektivität
einer Website erhöhen. Allerdings können die Zeitangaben auch in die
Irre führen, denn kurze Aufenthaltszeiten müssen nicht zwangsläufig
auf eine minderwertige Website hindeuten. Stattdessen wäre es auch möglich,
daß eine Seite - gerade weil sie so interessant sind - ausgedruckt, gespeichert
oder kopiert worden ist.
4.3. Wortlaut der Anfrage (Pfad)
”GET /images/ielogo.gif HTTP/1.0”
Es gibt drei verschiedene Arten der Anforderung von Dateien, die man mit GET,
POST und HEAD bezeichnet. Für HTML-Dateien wird üblicherweise GET
verwendet, was lediglich bedeutet, daß eine Datei vom Server angefordert
und schließlich auch zum Client übertragen wird. Auch in dem aufgeführten
Beispiel wird die Methode GET verwendet. POST steht an dieser Stelle, wenn Formulardaten
vom Client zum Server gesendet werden, und HEAD, wenn lediglich die Kopfdaten
einer Datei gefordert werden, was aber äußerst selten der Fall ist.
Im Weiteren kann man aus dem Logfile erkennen, wie der Pfad der Anfrage exakt
lautet, also welche Datei der Nutzer geliefert haben möchte. Im Beispiel
handelt es sich um die Datei “images/ielogo.gif”. Die darauf folgenden
Informationen (“HTTP/1.0”) geben Auskunft über den Namen und
die Version des verwendeten Protokolls.
4.4. Der http-Statuscode und das Transfervolumen
“200 7090”
Mit Hilfe des dreistelligen numerischen Codes kann der Anbieter kontrollieren,
ob die angeforderten Dateien erfolgreich übertragen wurden oder ob es Fehlermeldungen
gegeben hat. Findet sich wie im Beispiel die Zahl “200”, so kann der
Webanbieter davon ausgehen, daß die Datei erfolgreich an den Nutzer übertragen
wurde. Ein Zeichen für die vollständige Übermittlung ist auch
die Anzahl der Bytes (“7090”), die im Anschluß an den Statuscode
steht und die in solchen Fällen der Dateigröße entspricht.
Eine grobe Übersicht der Bedeutung der Statuscodes findet sich im Internet
bei der IVW:
1xx = Informational - Nicht benutzt, aber für zukünftige Nutzung reserviert
2xx = Success - Der Request wurde erfolgreich empfangen, ausgewertet und akzeptiert
3xx = Redirection - Weitere Aktionen müssen unternommen werden, um den
Request zu vervollständigen
4xx = Client Error - Der Request enthält fehlerhafte Syntax oder kann nicht
ausgeführt werden
5xx = Server Error - Dem Server gelang es nicht, einen scheinbar gültigen
Request auszuführen
Die Codes sind vor allem dann interessant, wenn es bei der Übertragung
der Dateien Schwierigkeiten gab. Der Webanbieter kann durch sie entschlüsseln,
um welches Problem es sich gehandelt hat und die entsprechenden Maßnahmen
ergreifen, um die Fehler zu beheben. Wurde z.B. eine Website des Angebotes aktualisiert
und damit auch zugleich die URL ein wenig abgeändert, kann es vorkommen,
daß einige Links, die zu dieser Seite führen, nach der Überarbeitung
nicht mehr funktionieren. In diesem Fall taucht der Code 404 auf. Auch vorzeitig
abgebrochene Ladevorgänge werden durch eine Fehlermeldung erkennbar, was
vor allem häufig bei Seiten passiert, die grafisch sehr aufwendig gestaltet
sind und beispielsweise große Bilddateien enthalten. Die Ladezeiten sind
dementsprechend sehr lang und viele Nutzer haben nicht die notwendige Geduld,
den vollständigen Seitenaufbau abzuwarten. Anhand der Transferdaten kann
man weiterhin erkennen, bei wieviel Bytes die Übertragung abgebrochen wurde.
Tauchen derartige Fehlermeldungen öfter auf, sollte sich der Website-Anbieter
überlegen, ob es nicht sinnvoller wäre, ein schlichteres Webdesign
vorzuziehen, damit auch Nutzer mit eher älteren Computern oder Modems die
Website problemlos erreichen können.
4.5. Referer-Daten
”http://www.schneegans.de/”
Die folgende Auskunft im Logfile ist für die Auswertung besonders interessant,
da man Informationen darüber erhält, wie der Nutzer ursprünglich
auf die Website gelangt ist. Der Server kann somit z.B. in Erfahrung bringen,
wie oft über welche Links auf seine Seiten zugegriffen wurde und ob sich
verlinkte Werbebanner auf anderen Websites gelohnt haben.
Besonders nützlich sind Referer-Angaben, die von Suchmaschinen stammen,
denn anhand dieser kann man ermitteln, über welche Suchbegriffe das Angebot
am häufigsten ausfindig gemacht wird. “Diese Informationen sind bei
der Entscheidung hilfreich, welche Begriffe in den Meta tags (Meta tags sind
Schlüsselwörter, die Suchmaschinenroboter (artificial agents) benutzen,
um Websites zu kategorisieren) verwendet werden sollten, um von Suchmaschinen
leichter gefunden zu werden”. Eine Auswertung der Referer-Daten ist allerdings
nicht immer möglich, denn “viele Surfer schätzen ihre Privatsphäre
und unterbinden die Übermittlung des Referers mit Programmen wie WebWasher.”
Auch wenn die URL der Website direkt in die Adresszeile eingegeben wurde, gibt
es keine Auskunft über den Referer.
Durch Referer-Variable kann man zudem unterscheiden, ob der Nutzer von außen
auf das Angebot zugegriffen hat oder sich gerade innerhalb von diesem bewegt.
Befindet er sich innerhalb des Angebots, sind die Referer-Daten weniger von
Bedeutung, da bereits die Angabe des Pfads im Logfile ausreichend darüber
Auskunft gibt, wie sich der Nutzer durch das Web-Angebot bewegt. “Kommt
der Nutzer ... von einer URL, die nicht Teil des Angebots ist, zählt dies
als Startpunkt für einen neuen Visit. (....) Das Verlassen eines Angebots
zum Verfolgen eines Links mit direkter Rückkehr in das Angebot zählt
... nicht als Visit, da der Referer in diesem Fall noch eine interne URL enthält.”
4.6. Agent-Information
”Mozilla/4.0 (compatible; MSIE 5.0; Windows NT)”
Der letzte Abschnitt des Logfiles ist besonders in Hinblick auf die Entscheidungen
das Web-Designs betreffend relevant, da genannt wird, welcher Browser vom Nutzer
verwendet wird und - je nach Browsereinstellung - auch Informationen zum Betriebssystem
preisgegeben werden. Zudem kann man anhand der Agent-Daten erkennen, ob es sich
um Besuch von einem normalen Nutzer oder einer Suchmaschine bzw. Robot handelt,
weil dieser hinterlassen an dieser Stelle eine für sie typische Kennzeichnung.
Jan Winkler bietet beispielsweise auf seiner Website die Möglichkeit an,
eine Liste mit den aktuellen Robots oder Suchmaschinen herunterzuladen.
Goldberg gibt auf seiner Website an, daß es heutzutage über 50 verschiedene
Web-Browser auf dem Markt gibt, die unter den Internetnutzern Verwendung finden,
wobei Netscape den Markt anführt. Berücksichtigt man außerdem
die verschiedenen Versionen dieser Browser, steigt die Zahl sogar auf über
350 verschiedene Möglichkeiten. Der Webanbieter sollte sich also vergewissern,
welche Browser in welcher Version von seinem Zielpublikum hauptsächlich
benutzt wird, um eine problemlose Übertragung der Websites zu gewährleisten.
Steht in der Agent-Information z.B. lediglich “Mozilla/2.0”, handelt
es sich um einen Netscape Browser mit der Version 4.0. Oftmals findet man jedoch
auch Zusätze in Klammern, wie beispielsweise “(compatible; MSIE 5.0;
Windows NT)”, die den eigentlichen Informationswert enthalten. Der User
besitzt demnach nicht - wie vielleicht angenommen - einen Netscape Browser,
sondern einen Microsoft Internet Explorer Browser der Version 5.0, der allerdings
mit dem Netscape Browser 4.0 kompatibel ist. Weiterhin wird ersichtlich, daß
der Besucher in diesem Beispiel das Betriebssystem Windows NT benutzt. Der Hinweis
auf das Betriebssystem und dessen Version kann hinsichtlich der Seitenaufmachung
sehr hilfreich sein, da eine Website bei verschiedenen Betriebssystemen auch
verschieden aussehen kann. Zum Beispiel kann Macintosh mehr Farben verarbeiten
als Windows, weshalb das gewählte Webdesign bei Nutzern mit Macintosh sehr
beeindruckend wirken kann, während es bei Windows-Nutzern völlig farblos
erscheint. Der Webanbieter hat also die Möglichkeit, sein Web-Design danach
auszurichten, welche Betriebssysteme von der Mehrheit seiner Besucher bevorzugt
verwendet werden.
5. Verzerrung der Daten
Die Logfile-Analyse erscheint auf den ersten Blick für die Erfolgsbewertung
bzw. Reichweitenforschung für Internetseiten ideale Voraussetzungen zu
haben, da angeblich alle Zugriffe von allen Nutzern für die Auswertung
zur Verfügung stehen. Es wurde jedoch bereits schon angedeutet, daß
die Logfile-Analyse durchaus einige Schwächen aufzuweisen hat, die Reabilität
und Validität der Daten in Frage stellen. Im letzten Kapitel habe ich beispielsweise
bereits auf die Schwierigkeiten mit dynamischen IP-Adressen oder Internetcafes
hingewiesen, durch die ein Logfile an Informationswert verliert. Eine viel gravierendere
Verzerrung der Daten findet allerdings durch Proxy- und Cache-Server statt,
deren Funktionsweise und Auswirkungen für die Logfile-Analyse ich im Folgenden
ausführen möchte.
5.1. Proxy- und Cache-Server
Ein Cache ist “ein schneller Puffer, der Daten zwischenspeichern und diese
immer wieder sehr schnell zur Verfügung stellen kann.” In Bezug auf
das Internet bedeutet dies, daß Websites in einem Cache zwischengespeichert
und bei einer erneuten Anfrage des Nutzers schnell aus dem Zwischenspeicher
geladen werden können, womit dem Nutzer eine längere Ladezeit erspart
bleibt. Für Webanbieter haben die Caches den Vorteil, daß sich durch
die Zwischenspeicherung ihres Webangebotes die Datentransfermenge verringert
und sich somit die Übermittlungskosten minimieren. Gerade beliebte Webseiten
finden sich in diesen Zwischenspeichern, da sie häufig von Nutzern angefordert
werden und damit die Wahrscheinlichkeit, gecachet zu werden, sehr hoch ist.
Caches findet man zum einen auf der Festplatte des Nutzers selbst oder auch
bei Internet-Providern, größeren Firmen und Institutionen. Die Cache-Speicher
der Internet-Provider bezeichnet man als Proxy-Server, was eine Unterscheidung
der beiden Caches erleichtert. Beim Aufruf einer Website durch den User überprüft
dessen Browser zuerst, ob sich diese im Cache des Rechners befindet und ruft
diese gegebenenfalls von dort ab. Liegt die Seite nicht vor, wird die Anfrage
an den Provider weitergegeben, wo die Anfrage wiederum einer Prüfung unterzogen
wird, nämlich ob sie im Proxy-Server des Providers bereits vorhanden ist.
Hier kommt es schließlich auf die Einstellungen im Proxy-Server an, wie
die Anfrage weiterhin behandelt wird. Ist die Seite z.B. im Zwischenspeicher
bzw. Puffer vorrätig, erhält der Nutzer die Website auf seinen Rechner,
ohne daß der eigentliche Anbieter dieser Website jemals von dieser Anfrage
erfahren wird, da es keinen Eintrag im Logfile-Register gibt. Die Anfrage gelangte
in diesen Fall lediglich bis zum Provider, der sie schließlich ohne Weiterleitung
beantworten konnte. Damit gehen dem Webanbieter eine Vielzahl aussagekräftige
Einträge verloren und die Zahl der Visits und PageImpressions wird ins
Negative verzerrt. Außerdem kann der Nutzungsvorgang eines einzelnen Besuchers
verfälscht werden, da es durchaus passieren kann, daß einige Seiten
aus dem Cache und ein paar wenige nur direkt abgerufen werden, so daß
nur die direkt angefragten Seiten im Logfile vermerkt sind. Manche Proxy-Server
besitzen jedoch die Voreinstellung, daß sie jedesmal oder zumindest einmal
pro Session kontrollieren, ob es sich bei der gespeicherten Website noch um
eine aktuelle Version handelt. Wenn keine Aktualisierung notwendig ist, taucht
im Logfile des Servers zumindest die Fehlermeldung 304 auf, d.h. die Seite wurde
nicht übertragen, womit der Webanbieter zumindest in Erfahrung bringen
kann, daß sich jemand für sein Angebot interessiert hat. Gibt es
eine neuere Ausgabe der Website, wird diese vom Provider angefordert und es
findet wie bei einer normalen Anfrage ein entsprechender Eintrag im Logfile
des Servers statt. Hier kann es allerdings wiederum passieren, daß es
sich um eine dynamische IP-Adresse handelt, die - wie bereits erwähnt -eine
korrekte Auswertung der Daten ebenfalls erschwert.
Die Zahl der Caches nimmt stetig zu und unter den Caches selbst gibt es zusätzliche
Verflechtungen bzw. Cache-Verbünde, wo zwischengespeicherte Daten bzw.
Websites untereinander ausgetauscht werden. Damit wird die Effektivität
der Caches zwar weiter gesteigert, aber zugleich gehen den Servern für
ihre Erfolgsmessung wertvolle Datenmengen verloren. Es wäre zwar vorstellbar,
daß die Caches ihre Daten mit denen der Server austauschen, da sich aber
innerhalb kürzester Zeit sehr große Datenmengen ansammeln und diese
zur Archivierung gespeichert werden müßten, kann dies allein aus
Speicherplatzgründen kaum realisiert werden. Möchte ein Webanbieter
gewährleistet haben, daß alle Anfragen im Logfile wiederzufinden
sind, kann er das Cachen seiner Webseiten durch eine entsprechende Programmierung
im Head der HTML-Seite verhindern. Seine Seiten müssen somit stets direkt
abgerufen werden, was aber sowohl für die Nutzer als auch für ihn
selbst mit Nachteilen verbunden ist, denn die Ladezeiten verlängern sich
und die erhöhte Datenmenge führt zu einer Kostensteigerung für
die Netzbandbreite. Würde allerdings jeder diese Mechanismen des Cachen
umgehen, würde man einen Zusammenbruch des WorldWideWeb riskieren, da es
die Datenmenge nicht mehr verarbeiten kann. Eine andere, ökonomischere
Lösung bietet die IVW mit der ein Pixel großen Graphik an. Diese
wird im Head-Abschnitt der HTML-Seite eingesetzt und wird im Gegensatz zum Rest
der Seite nicht gecachet, d.h. bei einer Anfrage kann zwar der Großteil
der Seite aus dem Cache geladen werden, das Pixel wird jedoch als Bestandteil
der Seite stets aktuell vom Anbieter abgefragt, so daß dieser einen Eintrag
im Logfile erhält. Damit wird wieder ein Zählen der PageImpressions
möglich und zudem bleiben auch die Transferkosten wegen der geringen Datenübertragung
(lediglich das Pixel wird übertragen) gering. Auch in den Logfiles wird
die Datenmenge auf ein angenehmes Maß reduziert, da hier lediglich Logfiles
für die abgerufenen Pixel geschrieben werden, die in diesem Fall stellvertretend
für die gelesene Seite stehen. Dieses Verfahren befindet sich jedoch noch
nicht lange auf den Markt, weshalb die Ergebnisse aus der Testphase noch abzuwarten
bleiben.
5.2. Suchmaschinen und Robots
Während Caches die Ergebnisse der Logfile-Auswertung ins Negative verzerren,
lassen Suchmaschinen die Daten fälschlicherweise sehr vorteilhaft aussehen,
da ihre “Kontrollbesuche” auf den ersten Blick im Logfile denen von
“echten” Nutzern gleichen. Mit Hilfe kleiner Programme (Bots) durchsuchen
sie das Internet nach Schlagwörtern, um ihren Index auf einen aktuellen
Stand zu bringen, und initiieren mit ihren Besuchen folglich auch Logfile-Einträge,
die unter Umständen als Nutzungsvorgang eines normalen Besuchers interpretiert
und ausgewertet werden. Die von Suchmaschinen aufgerufenen Internetseiten werden
jedoch lediglich mit der entsprechenden Adresse in der Datenbank abgespeichert,
um sie schließlich den eigentlichen Nutzern bei entsprechender Stichworteingabe
zur Auswahl zustellen. Es gibt inzwischen “eine fast unüberschaubare
Anzahl verschiedener Programme, Tools und Werkzeuge, die im Web kursieren”,
wie beispielsweise die Suchmaschinen Alta Vista, Hotbot oder Fireball, die ihre
Datenbankbestände regelmäßig neu überholen müssen.
Man muß daher von einer starken Verfälschung bei der Auswertung der
Logfile-Daten ausgehen, denn jeder dieser “Kontrollbesuche” hinterläßt
einen Eintrag im Logfile-Register, der bei einer korrekten Verwertung der Daten
nicht mit einen normalen Nutzer gleichgesetzt werden dürfte. Um die Verzerrung
der Untersuchungsergebnisse zu minimieren, kann man jedoch die Agent-Dateien
der Logfiles in der Auswertung berücksichtigen, anhand derer sich Suchmaschinen
herausfiltern lassen. So hinterläßt z.B. der Spider, d.h. das Suchprogramm,
von Fireball hier die Kennung “KIT” und bei Google findet man den
Eintrag “Googlebot”. Es gibt mittlerweile auch Softwareprogramme,
die speziell zur Erkennung von Suchmaschinen konzipiert wurden, und im Internet
kursieren einige Listen mit den Erkennungsmerkmalen der Suchmaschinen, wie beispielsweise
bei Luna-Park oder Jan Winkler. Diese Softwareprogramme bzw. Listen benötigen
jedoch eine ständige Aktualisierung, da sich das Internet schnell verändert
und stetig neue Anbieter von Suchmaschinen hinzukommen oder auch wegfallen.
Allerdings gibt es auch einige, die keine Kennung hinterlassen, weshalb eine
Indentifizierung sehr schwierig ist und sie somit in die normale Auswertung
mit einfließen. Gegebenenfalls lassen sich aber deren Besuche auch ohne
Hilfe von entsprechenden Auswertungsprogrammen ermitteln, da ein Visit eines
Suchmaschinen-Robots meist eine verhältnismäßig hohe Anzahl
an PageImpressions aufweist, beispielsweise 20 PageImpressions zu einem Visit.
Da man aber nie mit Sicherheit sagen kann, daß alle Suchmaschinen-Einträge
aussortiert wurden, bleibt die Gefahr der Datenverfälschung in einem gewissen
Maß bestehen.
6. Sinn oder Unsinn der Reichweitenmessung im Internet
Die Logfile-Analyse findet inzwischen eine relativ große Verbreitung und
erscheint für viele Internet-Anbieter ein ideales Instrument zur Erfolgsmessung
zu sein, da scheinbar alle Nutzungsvorgänge im Logfile genauestens festgehalten
werden. Wie die vorangegangenen Ausführungen aber gezeigt haben, muß
die Validität und Reabilität der Logfile-Analyse in Frage gestellt
werden, da es einfach zu viele Unsicherheitsfaktoren gibt. In der Tat ist die
Verzerrung der Daten meiner Meinung nach sogar so groß, daß mir
eine aussagekräftige Analyse unmachbar erscheint. Auch der Einsatz von
Cookies ist, wie sich gezeigt hat, für eine größere Erfolgsmessung
nicht sinnvoll, da man hier noch viel schneller an die Grenzen des Möglichen
stößt. Bei meinen Nachforschungen konnte ich durchaus feststellen,
daß an den Lösungen für diese Probleme gearbeitet wird und diese
Bemühungen zum Teil auch bereits zum Erfolg geführt haben, aber es
bleiben dennoch genügend Unsicherheiten, die die Validität und Reabilität
der Daten in Frage stellen. Goldberg merkte dementsprechend auf seiner Website
an, daß man von den Logfiles lediglich sichere Angaben über die Datentransfermenge
erhält. Auf dieser Datenbasis können zwar ebenfalls Entscheidungen
getroffen werden, - z.B. graphische Überarbeitung einer Seite, wenn es
auffällig viele Abbrüche bei dieser gibt - aber eine wirkliche Erfolgsaussage
kann nicht getroffen werden.
Obwohl die Meßmethoden Schwächen aufzeigen, stützen sich viele
Firmen bei der Erfolgsmessung ihrer Websites auf die Logfile-Analyse. Positive
Ergebnisse eignen sich eventuell für die Öffentlichkeitsarbeit, um
bei den normalen und eher unwissenden Kunden Eindruck zu hinterlassen, im Geschäftsverkehr
mit seinen Partnern sollte man jedoch darauf hinweisen, “daß aufgrund
technischer Gegebenheiten niemals die wirkliche Nutzung exakt reproduziert werden
kann.” Auch für den Vergleich mit anderer Firmen oder den eigenen
Archivdaten erscheinen mir die Daten nur bedingt oder überhaupt nicht tauglich,
da die Meßbedingungen aufgrund der stetigen Veränderungen im Internet
nicht gleich bleiben und schlechtere oder bessere Ergebnisse aufgrund der Verzerrungen
nicht unbedingt den realen Gegebenheiten entsprechen müssen. Meiner Meinung
nach eignen sich diese Analysen am besten als Orientierungshilfe, wenn Schwierigkeiten
bei der Internetpräsenz auftreten und man Informationsmaterial zur Problemlösung
benötigt.
Am glaubwürdigsten erscheinen die Meßmethoden der Interessengemeinschaft
zur Verbreitung von Werbeträgern e.V., da sich diese sehr darum bemüht,
Probleme wie z.B. das Cachen von Internetseiten durch neue Ideenentwicklungen
zu umgehen. Außerdem will man den Internetangeboten im Video- und Audioformat
gerecht zu werden, wie z.B. dem StreamingMedia im Internetfernsehen und -radio,
und diese anstatt anhand von PageImpression mit einer zeitbezogenen Größe
erfassen. Die Reichweitenforschung im Internet wird stetig weiterentwickelt und verbessert.
Es bleibt abzuwarten, ob die Bemühungen auf diesem Gebiet eines Tages
mit den Entwicklungen im Internet Schritt halten können und eine valide
Reichweitenforschung möglich wird.
Kerstin Schrepfer
7. Quellenverzeichnis:
1. Berg, Heinz-Peter. “Workshop: Elektronische Zeitschriften an wissenschaftlichen
Bibliotheken - Gewinnung von statistischen Nutzungsdaten aus LogFiles”.
25. März 1999. 21. Aug. 2001. http://bibliothek.uni-regensburg.de/iuk/berg/logfile.htm
2. Berger, Uwe. “Gefahren von Cookies”. 2001. 26. Aug. 2001. http://www.bluemerlin-security.de/Berichtcookiegefahren.php3
3. Berger, Uwe. “Anonym surfen”. 2001. 26. Aug. 2001. http://bluemerlin-security.de/Berichtanonymsurfen.php3
4. Brinkmann, Uwe. “Laßt die Cookies leben!”. 14. Okt. 1999.
26. Aug. 2001. http://www.bingo-ev.de/~ub304/cookies.htm
5. Goldberg, Jeffrey. “Why web usage statistics are (worse than) meaningless”.
18. Mai 2001. 21.Aug. 2001. http://www.goldmark.org/netrants/webstats/
6. Heitmann, Thomas. “Logfile-Analyse”. 25. März 1999. 21. Aug.
2001. http://thomasheitmann.de/beratung/evaluation/logfile.htm
7. Holldorff, Frank. “Was sind Cookies?”. 24. Okt. 2000. 26. Aug.
2001. http://www.raven.to/cookie/
8. Interessengemeinschaft zur Verbreitung von Werbeträgern e. V. (IVW).
“IVW präsentiert erstmals neues Online-Messverfahren”. Pressemitteilung
vom 30. April 2001. 20. Mai 2001. http://www.ivw.de/news/pm-index.html
9. IVW. “IVW Online-Messsystem”. “FAQ - Zur Einführung des
neuen IVW-Online-Messsystems”. 16. Mai 2001. 18. Aug. 2001. http://www.ivw.de/news/pm-index.html
10. IVW. “IVW Online-Medien”. 20. Mai 2001 und 18. Aug. 2001. http://www.ivw.de/online/index.html
11. IVW. “Beschlüsse des Verwaltungsrats”. 30. Juli 2001. 18.
Aug. 2001. http://www.ivw.de/online/index.html
12. IVW. “Sitemap”. “IVW Mitgliedschaft”. “Anlage 3
zu den Richtlinien für Kontrolle von Online-Medien”. 5. Sept. 2001 und 10. Okt. 2001. http://www.ivw.de/online/index.html
13. Luna-Park. ”Die Geister, die ich rief...”. 15. Juli 2001. 18.
Aug. 2001. http://www.luna-park.de/de/suchmaschinenmarketing/index.html
14. Luna-Park. "Logfileformate - die Lizenz zum Kontrollieren”. 18.
Mai 2001. 18. Aug. 2001. http://www.luna-park.de/de/suchmaschinenmarketing/archiv/logfileformate_20010518.html
15. Luna-Park. ”Pressespiegel”. ”Zu wenig Kontrolle”. Aus
W&V, 42/99, S. 174. 25. Aug. 2001. http://www.luna-park.de/de/presse/spiegel/w&v.html
16. NetValue Deutschland GmbH. Komplette Homepage. 1999-2001. 23. Aug. 2001. http://www.de.netvalue.com
17. MMXI Deutschland GmbH. “TV-Websites konnten ihre Besucherzahlen in
den vergangenen 11 Monaten um bis zu 400% erhöhen”. Pressemitteilung
vom 10. Okt. 2001. 23. Aug. 2001. http://www.de.jupitermmxi.com/press/release/20001010.jsp
18. MMXI Deutschland GmbH. “Measurement”. 2001. 23. Aug. 2001. http://www.de.jupitermmxi.com/aboutus/index.jsp#1
19. Rubin, Jeffrey. “A Strategic look at Log Analysis”. 21. Aug. 2001. http://www.headcase.syr.edu/NEW/Research/
20. Schade, Oliver. “Sinn und Unsinn von Web-Statistiken”. 16.Okt.1996. und 23. Mai 2001. http://www.heise.de//ix/artikel/9611096/statistik.shtml
21. Schneegans, Christoph. “Logfiles”. 21. Aug. 2001. http://schneegans.de/logfiles/aufbau.html
22. “Was sind Cookies und wozu bei Cyberboard.ch?”. 26. Aug. 2001. http://www.cyberboard.ch/cookies.htm
23. Winkler, Jan. “LogFile Analyse”. ? 21. Aug. 2001. http://jan-winkler.de/dev/d_logf.htm
24. WebSuxess.2001. 20. Mai 2001. http://www.websuccess-websuxess.software.de
|
