Ein Cookie enthält folgende Felder:

Unterschieden wird zwischen First Party Cookies, zu welchen Session-Cookies und persistente Cookies zählen, und Third Party Cookies. Einen Sonderfall stellen Flash Cookies (Local Shared Objects) dar.

Session Cookies

Session-Cookies existieren nur während einer Browser-Session und werden temporär im Speicher des Browsers abgelegt. Sobald das Browserfenster geschlossen wird, werden sie wieder gelöscht. Mit ihnen können mehrere Seitenaufrufe einer Session zuverlässig dem entsprechenden Besucher zugeordnet werden.

Aus den gesammelten Daten erhältliche Metriken sind zum Beispiel:

• Die Anzahl, Reihenfolge (Clickstream) und Dauer der Page Impressions
• Entry- und Exit-Pages
• Die Anzahl von Besuchen auf der Webseite (total Visits)

Anwendung finden diese Cookies zum Beispiel bei der Realisierung von Warenkörben in Online-Shops oder zur Wiedererkennung von angemeldeten Usern. Soll der User auch bei weiteren Besuchen wieder erkannt werden, kommen persistente Cookies zum Einsatz.

Persistente Cookies

Im Gegensatz zum Session-Cookie wird das persistente Cookie auf der Festplatte des anfragenden Computers gespeichert und steht somit über mehrere Besuche hinweg zur Verfügung. Zu den eigentlichen Nutzdaten des Cookies wird hier noch eine Art Haltbarkeitsdatum (Max-Age) angegeben, nach dessen Ablauf das Cookie gelöscht wird.

Berühmte Anwendung fand dieses Cookie z.B. bei Amazon zur persönlichen Begrüßung des Besuchers. Auch die „Passwort merken“ – Funktionen vieler Webseiten arbeiten mit einem persistenten Cookie. Hierbei wird natürlich nicht das Passwort im Cookie gespeichert, sondern lediglich eine Identifikationsnummer, mit der auf die Zugangsdaten des Benutzers zugegriffen wird.

Persistente Cookies können weitere Informationen zur Kundenbindung liefern – z.B. über wiederkehrende Besucher (unique Visitors) und ihre Einkaufshistorie.

Third Party Cookies

Prinzipiell handelt es sich hierbei um persistente Cookies, welche allerdings nicht von der besuchten Seite, sondern von einem völlig anderen Server stammen. Die Intention hierbei ist, einen User im Rahmen kooperierender Webseiten domänenübergreifend zu verfolgen. Um dies zu ermöglichen werden auf allen teilnehmenden Webseiten z.B. ein Werbebanner oder Zählpixel vom zentralen Trackingserver eingebunden.

Wird nun eine teilnehmende Webseite aufgerufen, wird auch die Datei vom zentralen Trackingserver abgerufen. Diesem ist es dank der Anfrage nun möglich ein Cookie zu setzen oder ein bestehendes auszulesen. Sollte ein Besucher noch kein Cookie besitzen, wird ihm ein neues mit einem neuen GUID zugewiesen, anhand dessen er innerhalb des gesamten Werbenetzwerks identifiziert und verfolgt werden kann.

Großen, auf vielen Webseiten vertretenen Werbeanbietern (z.B. Google) wird es somit möglich, User über weite Strecken im Internet zu verfolgen. Je nach besuchter Webseitenhistorie, kann der Anbieter daher ein Interessensprofil erstellen und darauf zugeschnittene Werbung ausliefern.

Local Shared Objects (Flash Cookies)

Diese Cookies sind auch bekannt als Local Shared Objects (LSO), Persistent Identification Element (PIE) oder Super-Cookies.

LSOs sind keine HTTP-Cookies im eigentlichen Sinn. Sie sind Dateien des Adobe Flash Players, welcher sie in einem zentralen Ordner auf der Festplatte verwaltet. Dies hat zur Folge, dass einschränkende Cookie-Richtlinien oder ein Wechsel des Browsers keinen Einfluss auf LSOs haben.

Nach einer Studie vom September 2008 ist der Adobe Flash Player auf 99% aller internetfähigen Computer installiert. Da LSOs zudem kein Verfallsdatum haben, stellen sie eine interessante und zuverlässige Möglichkeit der Nutzeridentifikation dar.

Der Einsatz von Cookies ist nicht unproblematisch

Auch wenn das Tracken mit Cookies grundsätzlich nicht-reaktiv, also eigentlich ohne Wissen des Besuchers abläuft, sind dennoch viele Irrtümer und Sicherheitsbedenken seit der Erfindung im Jahre 1994 aufgekommen. Dabei verhindern umfassende Restriktionen seitens des Browsers, dass Cookies eine Gefahr für den Client darstellen können:

Cookies sind reine Textdateien und können auf der Festplatte des Clients weder lesen, schreiben noch andere Funktionen echter Programme übernehmen. Für jedes Cookie ist eine Obergrenze von 4096 Bytes (Flash Cookies: Default 100 Kilobytes) einzuhalten und es können maximal 50 Cookies je Domain abgelegt werden. Auch haben Server keine Möglichkeit, Cookies explizit anzufordern oder diese gar zu suchen. Der Browser sendet automatisch die von der aufgerufenen Seite angelegten Cookies an den Webserver zurück, welcher nur erkennen kann ob Daten aus einem Cookie zur Verfügung stehen oder nicht.

Allerdings ist auf die Funktionsweise von HTTP-Cookies kein Verlass, da sie per Browsereinstellung leicht löschbar sind, oder die Annahme ganz verweigert werden kann. Insbesondere Third-Party Cookies werden von Anti-Spywareprogrammen häufig identifiziert und gelöscht oder von vorneherein komplett geblockt.

Anders ist dies bei Flash Cookies. Diese werden nicht vom Browser verwaltet, auch ist ihre Existenz vielen Usern noch nicht bekannt. Mit fortschreitender Verbreitung und steigendem Bekanntheitsgrad sind hier allerdings ähnliche Proteste wie früher bei den HTTP-Cookies zu erwarten. Auch wird es in absehbarer Zeit sicherlich entsprechende Tools zur Verwaltung von LSOs geben.

Um einem Besucher sicher mehrere Seitenzugriffe zuordnen zu können, gibt es zurzeit allerdings nur wenige Alternativen:

• Die Vergabe von Session-IDs, welche dynamisch an jede URL angehängt werden
• Die Registrierung und Authentifizierung der User bei jedem Besuch auf der Webseite
• Die Auswertung des Fingerprints des Besuchers, was im Gegensatz zu den anderen beiden Punkten allerdings keine absolute Sicherheit bei der Identifizierung bietet.

Sollen auch wiederkehrende Besucher identifiziert werden, gibt es neben Cookies nur die Möglichkeit, die Besucher zur Anmeldung an einem Benutzerkonto zu zwingen.

Dieser Artikel entstammt meiner Diplomarbeit zum Thema “Usertracking”. Ich habe lange überlegt wie und in welcher Form ich die Arbeit veröffentlichen könnte und bin zum Schluss gekommen, dass meine Erkenntnisse daraus, über diesen Blog veröffentlicht, dem größten Publikum dienen können.

Eine Ãœbersicht über weitere Artikel und ein Quellenverzeichnis sind unter
http://www.georg-weidner.de/usertracking zu finden.

Grundlage: Die Datenübertragung im WWW

Die Datenübertragung im WWW basiert auf einem Client-Server-Ansatz. Alle vom Besucher initiierten Aktionen werden von seinem Computer (Client) in Anforderungen (Requests) umgewandelt und an einen anderen Computer, z.B. einen Webserver weitergeleitet, der die angeforderten Ressourcen liefert (Response).

HTML-Dokumente werden mittels HTTP (Hypertext Transfer Protocol) an den Client übertragen. Das HTTP ist ein verbindungsloses Protokoll, bei dem die Datenpakete aus Performancegründen einzeln versandt werden. Die Verbindung zwischen Client und Server wird nach jeder Ãœbertragung wieder getrennt, weshalb ein Logfile keinen zusammenhängenden Nutzungsstrom, sondern lediglich eine Auflistung aller bearbeiteten Anfragen zeigt. So resultiert der Aufruf einer einzigen HTML-Seite in der Regel in zahlreichen Logfile-Einträgen, wobei jede eingehende Anfrage (Dokument, Bilder, CSS-Dateien, etc.) in einer neuen Zeile des Logfiles gespeichert wird. Dies hat zur Folge, dass Logfiles immense Ausmaße annehmen können.

Formate und Inhalte von Webserver-Logfiles

Es existieren derzeit etwa 30 standardisierte Logfile-Formate, die mehr oder minder weit verbreitet sind. Die Formate unterscheiden sich in den Angaben, die der Server pro Zeile (Hit) festhält. Felder zu Anfragen, die in einem bestimmten Log-Format festgehalten werden könnten, aber nicht verfügbar sind, werden in den Logfiles mit einem „-“ gekennzeichnet.

Im Allgemeinen werden folgende Werte in den Logfiles festgehalten:

• der Zugriffszeitpunkt
• die angeforderten Inhalte
• der zugreifende Browser
• die Adresse des Clients
• eventuell auftretende Fehler.

In Anlehnung an diese Inhalte haben sich vier Grundformen herausgebildet: Access Log, (Browser) Agent Log, Referrer Log und Error Log. Diese Dateien können je nach Systemkonfiguration getrennt oder in Kombination angelegt werden.

Als Standardformat des Access Log wurde das Common Logfile Format (CLF) entwickelt. Das Combined Logfile-Format (oder auch Extended Common Logfile Format – ECLF) erweitert das CLF um die Inhalte des Agent- und Referrer Log. Die folgende Abbildung zeigt zusätzlich die Unterteilung der Inhalte in Grunddaten über den Besucher und Interaktionsdaten über die ausgelieferten Inhalte.

 

 

Eine Zeile aus dem Log des Formats ECLF könnte zum Beispiel so aussehen:

 88.217.105.216 - - [24/Jul/2008:12:31:57  +0200]
 "GET /wp-admin/ HTTP/1.1" 200 50484 "http://www.georg-weidner.de/"
 "Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.1)  Gecko/2008070208 Firefox/3.0.1"

 

Die einzelnen Bestandteile (Felder eines Webserver-Logfiles des Formats ECLF) sind:

 

Eine Analyse der Daten zeigt, dass am 24 Juli 2008 um 12:31 Uhr und 57 Sekunden das Verzeichnis wp-admin von der IP-Adresse 88.217.105.216 aufgerufen wurde. Dabei fanden weder eine Clientidentifizierung noch eine Clientauthentifizierung statt, weshalb die entsprechenden Felder frei geblieben sind (mit einem „-“ gekennzeichnet). Das transferierte Datenvolumen belief sich auf 50.484 Bytes. Am Status-Code 200 ist zu erkennen, dass die Übertragung erfolgreich war.

Im Referrer- und User-Agent-Zusatz ist zudem festgehalten, dass der Aufruf von der Seite http://www.georg-weidner.de aus erfolgte, der Besucher Windows NT 5.1 (Windows XP) nutzt, mit dem Firefox-Browser Version 3.0.1 surft und als bevorzugte Sprache Deutsch (de) angegeben hat.

Statusinformationen

Ein wichtiger Bestandteil, welcher in fast allen Logfile-Formaten vorgesehen ist, ist die Angabe von Statusinformationen. Dem HTTP folgend verwenden Server eine dreistellige Zahl, die angibt wie die Anfrage serverseitig bearbeitet werden konnte. Den so genannten Status Code sendet der Webserver zum anfragenden Browser und schreibt ihn zudem in das Logfile. Es gilt zu beachten, dass die meisten Browser nicht alle in HTTP/1.0 definierten Status Codes unterstützen.

 

Beispiele für HTTP Status-Codes:
200 OK – Erfolgreiche Bearbeitung der Anfrage (wie im Beispiel oben)
304 Das Dokument wurde seit dem letzten Abruf nicht modifiziert: Abruf vom Browser-Cache
404 Dokument wurde nicht gefunden
500 Interner Server Error

 

Die Systematik des Codes leitet sich von der ersten Ziffer her:
1xx Gegenwärtig nicht benutzt, reserviert für zukünftige Erweiterungen des HTTP
2xx Erfolgreiche Bearbeitung der Anfrage
3xx Weitere Aktionen zur Bearbeitung der Anfrage erforderlich
4xx Clientseitiger Error (z.B. Syntaxfehler in der Anfrage)
5xx Serverseitiger Error (z.B. Ãœberlastung des Servers)

 

Mit Server-Logfiles lassen sich umfangreiche Daten erheben:

• Wer besuchte wann die Webseite
• Woher kommen die Besucher
• Wie navigieren die Besucher durch die Webseite
• Hinweise auf mögliche technische Probleme

 

Allerdings haben Server-Logfiles einige entscheidende Nachteile:

• Große Probleme bei der Datenspeicherung in Caches
• Zugriff von virtuellen Nutzern wie Spidern und Robots gehen mit in die Logfiles ein
• Der Umfang der Logdateien wächst sehr schnell
• Eine Identifikation wiederkehrender Besucher kann problematisch sein

 

Eine genauere Erläuterung der Probleme von Webserver-Logfiles und entsprechende Maßnahmen wird im später unter “Datenaufbereitung” näher behandelt.

Von grundlegendem Vorteil jedoch ist, dass Logfiles sowieso vom Server erzeugt werden. Es müssen also keine zusätzlichen Anstrengungen unternommen werden um Daten zu erheben. Weiterhin handelt es sich um eine nicht-reaktive Erhebung von Daten: Der Nutzer erfährt hiervon nichts und hat auch keine Möglichkeit die Logfile-Einträge zu beeinflussen.

Dieser Artikel entstammt meiner Diplomarbeit zum Thema “Usertracking”. Ich habe lange überlegt wie und in welcher Form ich die Arbeit veröffentlichen könnte und bin zum Schluss gekommen, dass meine Erkenntnisse daraus, über diesen Blog veröffentlicht, dem größten Publikum dienen können.

Eine Ãœbersicht über weitere Artikel und ein Quellenverzeichnis sind unter
http://www.georg-weidner.de/usertracking zu finden.

Der Begriff des Usertracking lässt sich bezogen auf das Internet in drei Schritte unterteilen

• Die Datenerhebung
• Die Datenaufbereitung und -speicherung
• Die Datenanalyse und -verwendung

Bei der Datenerhebung geht es zunächst darum, wie der Webseiten-Besuch eines Besuchers überhaupt registriert wird. Daten die nicht registriert wurden, können später zur Auswertung nicht herangezogen werden. Das Vorgehen muss zudem sorgfältig geplant sein, um qualitativ hochwertige Daten zu erhalten, denn aus einer schlechten Datenqualität lassen sich keine aussagekräftigen Statistiken erstellen.

Die erhobenen Daten müssen zunächst aufbereitet werden. Dazu zählt das Entfernen unwichtiger oder falscher Daten und das Aggregieren zu Standardmetriken. Die daraufhin folgende Speicherung der Daten in einer Datenbank ist keine triviale Angelegenheit und will gut geplant sein, um später alle gewünschten Analysen zu ermöglichen.

Vor der finalen Datenanalyse und -verwendung gibt es wichtige, grundlegende Aspekte zu beachten. Mit der Einbindung weiterer Datenquellen können wertvolle Einblicke in online-offline Zusammenhänge ermöglicht werden. Schließlich ist es mit den Informationen aus dem Usertracking möglich, die Usability der Webseite zu verbessern oder Webseiten zielgruppenspezifisch auszuliefern.

 

 

Die Verfahren der Datenerhebung

Zur Erhebung von Daten stehen im Internet eine Vielzahl von Verfahren zur Verfügung. Diese können nach verschiedenen Kriterien wie z.B. technischen Eigenschaften oder der Partizipation des Users am Erhebungsprozess unterschieden werden.

Weit verbreitet ist die Unterscheidung anhand des Bewusstseins des Users über die Aufzeichnung der Daten, zwischen einer reaktiven und nicht-reaktiven Datenerhebung. Während es eine nicht-reaktive Datenerhebung erlaubt, Aspekte des Besucherverhaltens relativ frei von Störeinflüssen zu erheben, ist es dem Besucher bei einer reaktiven Datenerhebung bewusst, dass Daten über ihn erfasst werden. Folglich reagiert er möglicherweise anders.

Allerdings gilt zu beachten, dass diese Einteilung nicht ganz problemfrei ist. So sind die Verfahren nicht gänzlich voneinander zu trennen, da es stark auf das spezielle Wissen und die Erwartungen des Besuchers ankommt. Womöglich hat er einen kritischen Beitrag gelesen und erwartet nun sogar, dass viel mehr Daten erhoben werden als dies der Fall ist.

Grundlegend gilt zu beachten, dass zur Analyse aller Besucher einer Webseite eine Methode zum Erheben der Daten oft nicht ausreicht. Zum Beispiel führen die meisten Robots keinen JavaScript-Code aus, weshalb sie mit auf JavaScript basierenden Techniken nicht registriert werden können. Sollen sie erfasst werden, muss unter Umständen auf eine zusätzliche Methode zur Datenerhebung zurückgegriffen werden.

Dieser Artikel entstammt meiner Diplomarbeit zum Thema “Usertracking”. Ich habe lange überlegt wie und in welcher Form ich die Arbeit veröffentlichen könnte und bin zum Schluss gekommen, dass meine Erkenntnisse daraus, über diesen Blog veröffentlicht, dem größten Publikum dienen können.

Eine Ãœbersicht über weitere Artikel und ein Quellenverzeichnis sind unter
http://www.georg-weidner.de/usertracking/ zu finden.

Das nächste Kapitel behandelt die Datenerhebung mittels Webserver-Logfiles

Was ist die statistische Signifikanz?
Sie sagt aus, mit welcher Wahrscheinlichkeit der Unterschied zwischen zwei Messgrößen signifikant – also nicht dem Zufall zuzuschreiben – ist.

Wo macht das Sinn?
Bei A/B-Tests, E-Mailkampagnen (z.B. 2 unterschiedliche Angebote), der Frage welche von zwei Werbeanzeigen z.B. bei Google AdWords besser sind…

Ein Beispiel
Wir schalten zum Test zwei Werbeanzeigen auf Analytics und erhalten folgende Zahlen, die ich gleich in ein Tool eingetragen habe:

Szenario 1

Hier ist die Standardabweichung zu gering – mit hoher Wahrscheinlichkeit handelt es sich nur um zufälliges Rauschen: Der Test bietet bisher also keine Entscheidungsgrundlage, obwohl die Conversion Rates etwas anders hätten vermuten lassen können!

Szenario 2

Hier handelt es sich mit einer Wahrscheinlichkeit von 95% nicht um zufälliges Rauschen. Es kann also mit großer Sicherheit davon ausgegangen werden, dass Anzeige Nummer 2 auch in Zukunft besser konvertieren wird.

Fazit
Mit Anwendung dieser Methode erhalten wir in wenigen Sekunden einen tiefern Einblick in unsere Testergebnisse. Natürlich schaffen wir es nicht, saisonale Schwankungen herauszurechnen, erhalten aber ansonsten wertvolle Informationen wie die Ergebnisse einzuordnen sind.

Link
Das oben genutzte Tool kann kostenlos unter teasley.net/free_stuff.htm heruntergeladen werden. (Dabei ist es egal, welches der beiden Tools ihr nutzt – abgesehen von den Beschriftungen unterscheiden sie sich nicht).