Cookies

1.    Cookie

Ein Cookie [ˈkʊki], auch Magic Cookie (vom englischen Wort für Plätzchen bzw. magisch. Deutsche Entsprechung: Profildatei) ist ein kurzer Eintrag in einer meist kleinen Datenbank bzw. in einem speziellen Dateiverzeichnis auf einem Computer und dient dem Austausch von Informationen zwischen Computerprogrammen oder der zeitlich beschränkten Archivierung von Informationen. Ein Cookie besteht aus mindestens zwei Bestandteilen, seinem Namen und dem Inhalt oder Wert des Cookie. Außerdem können Angaben über den zweckmäßigen Gebrauch vorhanden sein. Die Datenbank kann oft vom Benutzer des Computers ohne besondere Hilfsmittel nicht eingesehen oder verändert werden.

Von Anwendungsprogrammen oder Teilen oder Erweiterungen des Betriebssystems eines Computers, die einen Dienst zur Verfügung stellen, kann ein Cookie zum Beispiel beim Start des Programms gesetzt werden. Anderen Programmen wird so bekannt, dass sie diesen Dienst in Anspruch nehmen können, wenn sie in der Datenbank den vorher vereinbarten Namen des Cookie finden. Der Wert des Cookie enthält dabei typischerweise eine Speicheradresse, über die Funktionen des Dienstes zugänglich sind. Datenbanken dieses Typs heißen Cookie Jar.

Webbrowser stellen eine Cookie-Datenbank zur Verfügung, die Cookie Cache genannt wird; dort kann der Webserver einer besuchten Webseite Informationen in Form von HTTP-Cookies hinterlegen und bei einem Wiederbesuch der Seite auslesen.
Viele Webseiten hinterlegen ein solches Cookie, um die Nutzer bei erneuten Einloggen wiedererkennen zu können (und z.B. dann andere Werbung einzublenden oder dem Besucher Funktionalitäten bereitzustellen, die dieser nutzen möchte).
Cookies sind eine nachträgliche Erfindung; ursprünglich war das Internet zum Austausch von Daten unter Wissenschaftlern gedacht. Es war also nicht nötig, sich gegenüber dem Server zu identifizieren. Später wurden Anwendungen erfunden, die dies erforderlich machten. Da das ursprüngliche Protokoll so etwas nicht vorsah, hat das Team von Netscape, deren Browser und Server seinerzeit den Markt dominierten, kurzerhand diese Funktionalität erfunden, die dann von anderen Browsern übernommen wurde, weil sie auf elegante Weise das Problem löste. In der Öffentlichkeit wurden Cookies lange Zeit kontrovers diskutiert. In der heutigen Wahrnehmung sind Cookies neutrale "Werkzeuge" im Datenverkehr.

Ein häufiges Beispiel für notwendige Cookies sind Foren. Jeder (angemeldete) Benutzer muss die Möglichkeit haben, Beiträge abzuliefern und nachträglich zu redigieren. Dies ist nur möglich mit Cookies. Dort findet sich oft die Möglichkeit, „eingeloggt zu bleiben“. Dabei wird ein Cookie abgelegt, das eine entsprechende Laufzeit hat und bei erneutem Besuch der Seite immer noch gültig ist, daher ausgelesen und ausgewertet werden kann. Auch Shops basieren häufig auf Cookies, die den Warenkorb steuern. Sollte eine solche "Sitzung" ausgelaufen sein, muss sich der Benutzer erneut einloggen, sich also gegenüber dem Server identifizieren. Das Ergebnis der Prüfung wird im Cookie abgelegt.

1.1.    Herkunft der Bezeichnung
Eine mögliche Erklärung für die Bezeichnung "(Magic) Cookie" ist der Comic "Odd Bodkins" von Dan O'Neill, der in den 1960'ern in der Zeitung San Francisco Chronicle erschien: Einige der Charaktere aßen "Magic Cookies" von dem "Magic Cookie Bush" (vermutlich ein Euphemismus für LSD), unter deren Einfluss sie in das "Magic Cookie Land" gelangten. Somit sind Cookies analog zu den verzehrten Plätzchen eine Art Wertmarke für einen ganzen Sinnzusammenhang oder ein Erlebnis.

2.    HTTP-Cookie
Ein HTTP-Cookie, auch Browser-Cookie genannt ([ˈkʊki]; engl., „Plätzchen“, „Keks“), bezeichnet Informationen, die ein Webserver zu einem Browser sendet oder die clientseitig durch JavaScript erzeugt werden. Der Client sendet die Informationen in der Regel bei späteren Zugriffen an denselben Webserver im Hypertext-Transfer-Protocol-Header an den Server. Cookies sind clientseitig persistente/gespeicherte Daten.
HTTP-Cookies sind eine spezielle Form der allgemeinen Magic Cookies. Sie ermöglichen das clientseitige Speichern von Information, die auch vom Server stammen können und die bei weiteren Aufrufen für den Benutzer transparent an den Server übertragen werden. Dadurch erleichtern Cookies die Benutzung von Webseiten, die auf Benutzereinstellungen reagieren oder den Aufbau von Sitzungen. Dieses Konzept wurde ursprünglich von Netscape entwickelt und in RFC 2109 spezifiziert.

2.1.    Funktionsweise
Cookies werden in den Kopfzeilen (Header) von Anfragen und -Antworten via HTTP übertragen. Cookies entstehen, wenn bei einem Zugriff auf einen Webserver neben anderen HTTP-Kopfzeilen in der Antwort zusätzlich eine Cookie-Zeile übertragen wird (siehe Aufbau). Diese Cookie-Informationen werden dann lokal auf dem Endgerät gespeichert, üblicherweise in einer Cookie-Textdatei. Bei nachfolgenden weiteren Zugriffen auf den Webserver wird der eigene Browser alle Cookies in dieser Datei heraussuchen, die zum Webserver und Verzeichnispfad des aktuellen Aufrufs passen, und schickt diese Cookie-Daten im Header des HTTP-Zugriffs mit zurück, womit die Cookies jeweils an jenen Webserver zurückgehen, von dem sie einst stammten.
Ein Cookie kann beliebigen Text enthalten, kann also neben einer reinen Identifikation auch beliebige Einstellungen lokal speichern, jedoch sollte seine Länge 4 KB nicht überschreiten, um mit allen Browsern kompatibel zu bleiben. Die Cookies werden mit jeder übermittelten Datei übertragen, also auch mit Bilddateien oder jedem anderen Dateityp; dieses gilt insbesondere für eingebettete Elemente wie Werbebanner, die von anderen Servern eingebunden werden als dem Ursprung einer angezeigten HTML-Datei. So kann eine einzelne Webseite zu mehreren Cookies führen, die von verschiedenen Servern kommen und an diese jeweils wieder zurückgeschickt werden; mit einer Anfrage des Browsers werden alle den Server betreffenden Cookies gesendet.
Cookies werden ausschließlich vom Client verwaltet. Somit entscheidet der Client, ob z. B. ein Cookie gespeichert wird oder die vom Webserver gewünschte eingeschränkte Lebensdauer des Cookies durch Löschung ausgeführt wird.

Gängige Browser erlauben dem Nutzer meist einschränkende Einstellungen zum Umgang des Client mit Cookies, z. B.:

1. Keine Cookies annehmen.
2. Nur Cookies des Servers der aufgerufenen Seite annehmen (keine Cookies von Drittservern wie bei Werbebannern).
3. Benutzer bei jedem Cookie fragen.

• hier kann dann meist zwischen „erlauben“ (bleibt), „für diese Sitzung erlauben“ (wird immer angenommen, aber nach dem Schließen des Browsers gelöscht) und „ablehnen“ (nicht akzeptieren) gewählt werden, wobei die gewählte Option gespeichert wird

• Alle Cookies bei Beendigung des Client löschen („Sitzungs-Cookie“).

Dazu erlauben einige Browser verwaltende Aktionen wie:

• Daten im Cookie ansehen.

• Einzelne oder alle Cookies löschen.

Ob ein Cookie angenommen (clientseitig gespeichert) wurde, muss die serverseitige Anwendung in weiteren HTTP-Anfragen erkennen, da vom Client keine Rückmeldung erfolgt.
Der Server kann ein Cookie durch Überschreiben mit leeren Daten löschen.

2.2.    Verwendung
Eine typische Anwendung von Cookies ist das Speichern persönlicher Einstellungen auf Websites, zum Beispiel in Foren. Damit ist es möglich, diese Website zu besuchen, ohne jedes Mal die Einstellungen erneut vornehmen zu müssen.
Mit Cookies können auch Sitzungen realisiert werden. Das HTTP ist per Definition ein zustandsloses Protokoll, daher ist für den Webserver jeder Zugriff völlig unabhängig von allen anderen. Eine Webanwendung, die sich über einen längeren Zeitraum hinzieht, muss mit Zusätzen auf der Anwendungsschicht (im Browser) arbeiten, um den Teilnehmer über mehrere Zugriffe hinweg identifizieren zu können. Dazu wird in einem Cookie vom Server eine eindeutige Session-ID gespeichert, um genau diesen Client bei weiteren Aufrufe wieder zu erkennen und damit nicht bei jedem Aufruf einer Unterseite das Passwort erneut eingegeben werden muss.

Auch Online-Shops können Cookies verwenden, um sitzungslose virtuelle Einkaufskörbe zu ermöglichen. Der Kunde kann damit Artikel in den Einkaufskorb legen und sich weiter auf der Website umschauen, um danach die Artikel zusammen online zu kaufen. Die Artikel-Kennungen werden in einem Cookie gespeichert und erst beim Bestellvorgang serverseitig ausgewertet.

Damit bei Webanwendungen Benutzeraktionen und -eingaben, die für den Server bestimmt sind, bei Abbrüchen der Verbindung zum Server zum Beispiel in Mobilfunknetzen nicht verloren gehen, können Cookies zur Zwischenspeicherung eingesetzt werden. Sie werden dann bei Wiedererrichtung der Verbindung automatisch zum Server geschickt. Die Webanwendung erkennt dabei die Reihenfolge, in der die Cookies erzeugt wurden, und markiert bereits verarbeitete Cookies oder löscht deren Inhalt. Weil bei dieser Verwendung unter Umständen viele Cookies erzeugt werden, die frühestens beim Schließen des Browsers gelöscht werden, der Speicherplatz des Browsers für Cookies aber beschränkt ist, muss die Webanwendung Vorkehrungen gegen einen Cookie-Überlauf treffen.[1]

2.3.    Gefahren
Die eindeutige Erkennung kann für Zwecke eingesetzt werden, die von vielen Benutzern als missbräuchlich angesehen werden. Cookies werden z. B. dafür verwendet, Benutzerprofile über das Surfverhalten eines Benutzers zu erstellen. Ein Online-Shop kann z. B. diese Daten mit dem Namen des Kunden verknüpfen und zielgruppenorientierte Werbemails schicken. Jedoch kann der Online-Shop nur das Surfverhalten innerhalb seiner eigenen Webseite verfolgen.

Server, die nicht identisch mit dem Server der aufgerufenen Webpage sind, können z. B. mit Bilddateien (Werbebanner oder auch Zählpixel) auch so genannte „serverfremde“ Cookies setzen. Diese werden aufgrund ihrer Verwendung auch als „tracking cookies“ bezeichnet (englisch für Verfolgen). Gegebenenfalls kann so der Besuch unterschiedlicher Websites einem Benutzer zugeordnet werden. Es entsteht eine „serverübergreifende“ Sitzung. Daraus kann auf die Interessen des Besuchers geschlossen und Websites entsprechend angepasst („personalisiert“) werden. Bei einer Bestellung in einem Webshop etwa werden die angefallenen Daten naturgemäß einer konkreten Person zugeordnet.

Denkbar wäre ein potentieller Missbrauch bei einer möglichen Kooperation zwischen dem Webshop und dem Werbeunternehmen; diese kann verhindert werden durch eine entsprechende Browser-Einstellung, die nur Cookies des Servers der aufgerufenen Seite (Webshop) annimmt, nicht die der fremden Server, die die Werbung einblenden. Wirbt der Webshop allerdings selber, könnte diese zielgerichtete Werbung so nicht verhindert werden, aber sogar nützlich sein. Amazon wertet bekanntlich die Bestellhistorien der Käufer systematisch aus, um auch unbekannten Besuchern konkrete Vorschläge zu machen.

Noch nicht zu übersehen sind die Gefahren, die dadurch entstehen, dass Großunternehmen wie Google, deren Dienste praktisch jedermann ständig nutzt, sich vorbehalten, die dadurch entstehenden Daten auf unbegrenzte Zeit zu bevorraten und auszuwerten. Um Daten über das Nutzerverhalten zu sammeln, ist man nicht auf Cookies angewiesen. Das Problem ist also wesentlich allgemeinerer Natur.
In Umgebungen, in denen sich mehrere Nutzer denselben Rechner teilen, etwa in Schulen oder Internet Cafés, besteht allerdings die ganz konkrete und offensichtliche Gefahr, dass ein noch gültiger Sitzungs-Cookie vom nächsten Nutzer des Rechners verwendet wird, um diese Sitzung fortzusetzen. Dieses Risiko kann verhindert werden, indem man grundsätzlich alle Cookies vor dem Beenden des Browsers löscht oder eine entsprechende Browser-Einstellung nutzt. Das wäre die Aufgabe des Administrators. Infolgedessen kann man an öffentlichen Plätzen, etwa Bibliotheken oder Universitäten, üblicherweise keine permanenten Cookies hinterlassen.

2.4.    Erlauben oder Sperren?
Ein Kompromiss zwischen den Vor- und Nachteilen von Cookies kann erzielt werden, indem man seinen Browser so konfiguriert, dass persistente Cookies nicht oder nur gegen Rückfrage zugelassen werden, was z. B. die Erstellung von Benutzerprofilen erschwert, und Sitzungs-Cookies automatisch zugelassen werden, z. B. für Webeinkäufe, Passwörter. Außerdem bieten die meisten Browser die Möglichkeit, Cookies selektiv für bestimmte Domänen zu erlauben bzw. zu sperren oder nach dem Surfen automatisch zu löschen, wie es automatisch bei Sitzungs-Cookies geschieht. Auch ist es möglich, serverfremde Cookies automatisch abzuweisen, über die ein Dritter, etwa ein Werbepartner der Internet-Seite, das eigene Verhalten über mehrere Server hinweg aufzeichnen könnte.

Es ist auch möglich, Cookies automatisch beim Schließen des Browsers durch diesen löschen zu lassen. Damit werden Probleme mit Mehrbenutzersystemen weitgehend vermieden und die Überwachung des Benutzers durch Cookies wird zumindest eingeschränkt. Zugleich verzichtet der Benutzer damit auf alle Vorteile, die Cookies gewähren; er muss sich also zwangsweise bei der nächsten Sitzung überall wieder neu einloggen. Das führt aber zu neuen Sicherheitsproblemen, denn die Benutzer neigen dazu, überall dasselbe Passwort zu verwenden, da sich niemand eine Vielzahl von Passworten merken kann. Selbst die Benutzung von mehreren Passworten führt dazu, dass der Benutzer gegebenenfalls alle ausprobiert und sie damit gegenüber der betreffenden Webseite preisgibt.

Des Weiteren bieten moderne Browser die Möglichkeit, Funktionen über kleine Zusatzprogramme (Add-Ons) nachzurüsten. So ist es beispielsweise bei Firefox nach Installation eines auf diese Funktion ausgelegten Add-Ons per Klick auf eine Schaltfläche möglich, Internetseiten die Erlaubnis zu geben, Cookies zu speichern[2][3][4] bzw. sogar selbst den Inhalt der Cookies zu manipulieren[5]. Das ermöglicht es, dass man die Cookies generell deaktiviert lassen kann und sie nur dann zu erlauben, wenn die Internetseite nicht richtig funktioniert oder man sich bei einem Onlinedienst anmelden will.

2.5.    Aufbau
Ein Cookie besteht aus einem Namen und einem Wert sowie mehreren erforderlichen oder optionalen Attributen mit oder ohne Wert. Einige Attribute sowie deren Einschließen in Hochkommas werden empfohlen.

1. Name - erforderlich –Beliebiger Name und Wert aus ASCII-Zeichen die vom Server übergeben werden
2. Version - erforderlich – Gibt die Cookie-Management-Spezifikation in einer Dezimalzahl an (derzeit immer 1).
3. Expires - optional – Ablaufdatum, Zeitpunkt der automatischen Löschung in UTC für HTTP/1.0
4. Max-age - optional – Ablaufzeit in Sekunden – 0 für sofortige Löschung. Der Client darf den Cookie auch nach dieser Zeit benutzen, der Server kann sich also nicht darauf verlassen, dass der Cookie nach dieser Ablaufzeit gelöscht wird.
5. Domain - optional – Domain oder Bestandteil des Domainnamens, für den der Cookie gilt
6. Path - optional – Gültigkeits-Pfad (Teil der Anfrage-URI), um die Gültigkeit des Cookies auf einen bestimmten Pfad zu beschränken
7. Port - optional – Beschränkung des Ports auf den aktuell verwendeten oder auf eine Liste von Ports
8. Comment - optional – Kommentar zur näheren Beschreibung des Cookies
9. CommentURL- optional – URL unter welcher eine Beschreibung zur Funktionsweise zu finden ist
10. Secure - optional – Rücksendung des Cookie nur „geschützt“ (wie ist nicht weiter spezifiziert). Die meisten HTTP-Clients senden einen „sicheren“ Cookie nur über eine HTTPS-Verbindung. Das Attribut hat keinen Wert.
11. Discard - optional – Unbedingt Löschung des Cookies bei Beendigung des Webbrowsers.

2.5.1.    Funktionsweise – ein Beispiel
Szenario: Eine Webseite bietet eine Suchfunktion an, die sich an den zuletzt eingegebenen Suchbegriff erinnern kann, selbst wenn der Benutzer zwischenzeitlich den Browser beendet. Dieser Suchbegriff kann nicht auf dem Server gespeichert werden, da der Server dazu den Besucher eindeutig identifizieren müsste, und das geht mit reinem HTTP nicht. Deshalb soll der zuletzt eingegebene Suchbegriff vom Browser des Besuchers (in einem Cookie) gespeichert werden.
Wenn der Besucher die Suchfunktion zum ersten Mal aufruft (hier mit dem Suchbegriff „cookie aufbau“), schickt er folgende Anfrage an den Server:
GET /cgi/suche.py?q=cookie+aufbau HTTP/1.0
Der Server antwortet mit dem Suchergebnis und bittet den Browser mit der „Set-Cookie“-Zeile, sich den letzten Suchbegriff zu merken:

HTTP/1.0 200 OK
Set-Cookie: letzteSuche="cookie aufbau";
            expires=Tue, 29-Mar-2005 19:30:42 GMT;
            Max-Age=2592000;
            Path=/cgi/suche.py;
            Version="1"

(Normalerweise stehen alle Eigenschaften des Cookies in einer einzigen Zeile. Zur besseren Lesbarkeit steht hier jedoch nur ein Attribut pro Zeile.) Der Cookie hat die folgenden Eigenschaften:

• Nutzdaten (letzteSuche): Der letzte Suchbegriff

• Ablaufdatum (expires): Der Cookie wird nur in Anfragen mitgeschickt, die vor dem 29. März 2005 passieren.

• Maximalalter (Max-Age): Der Cookie wird nur in den folgenden 30 Tagen mitgeschickt, später nicht mehr.

• Teilbereich der Webseite (Path): Der Cookie wird nur an die Suchmaschine (/cgi/suche.py) geschickt, da alle anderen Teile der Webseite die Information nicht brauchen.

Zusätzlich zu der Pfad-Einschränkung wird der Cookie auch nur an den Server zurückgeschickt, von dem er gekommen ist. Dies wird durch die fehlende „Domain“-Variable erreicht.

Bei jeder weiteren Suchanfrage schickt der Browser nun, wenn er den Cookie akzeptiert, diesen an den Server zurück. Das sieht dann so aus:

GET /cgi/suche.py?q=12345 HTTP/1.0
Cookie: letzteSuche="cookie aufbau"; $Path=/cgi/suche.py; $Version="1";

Allen Eigenschaften des Cookies ist ein „$“ vorangestellt, mit Ausnahme der Nutzdaten (hier: letzteSuche). Der Server hat jetzt also die Information über den aktuellen Suchbegriff (12345) und den letzten (cookie aufbau). Zwischen diesen beiden Suchanfragen kann eine Zeit von bis zu 30 Tagen (Ablaufdatum) liegen.

2.5.2.    Browseranforderungen
Nach RFC 2965 soll ein Browser Folgendes unterstützen:

• Es sollen insgesamt mindestens 300 Cookies gespeichert werden können.

• Es sollen pro Domain mindestens 20 Cookies gespeichert werden können.

• Ein Cookie soll mindestens 4096 Bytes enthalten können.

Manche Browser können mehr Cookies und/oder auch Cookies mit längeren Zeichenketteninhalten verarbeiten, garantiert ist dies aber nicht. Umgekehrt halten sich aber auch nicht alle Browser an alle Anforderungen.


3.    Flash-Cookie
Flash-Cookies oder Local Shared Objects (LSO) stellen eine neue Art der Speicherung von Benutzerdaten auf dem surfenden PC durch Nutzung des Adobe Flash Players dar.
Im Gegensatz zu Browser-Cookies (HTTP-Cookies) ermöglicht diese Technik den Webseiten, Inhalte browserunabhängig und ohne Verfallsdatum auf dem Rechner des Webseitenbetrachters zu speichern. So werden Inhalte, die beim Betrachten eines Flash-Films mit einem Browser (z. B. Firefox) geschrieben wurden, auch beim Betrachten der Internetseite mit einem anderen Browser (z. B. Windows Internet Explorer) an den Server gesendet.
Problematisch ist der Umstand, dass diese LSOs nicht von der Cookieverwaltung des Browsers administriert werden und bei Bedarf manuell oder per Software (Flash-Cookie-Killer, Flash-Cookie-Manager, CCleaner) gelöscht werden müssen. Für den Browser Firefox gibt es u. a. dazu inzwischen eine Browsererweiterung[1]. Die Speicherung von LSOs lässt sich auch mit dem Einstellungsmanager des Flash-Players konfigurieren, der allerdings nur online über die Adobe-Website zugänglich ist.[2]
Der Speicherort der LSOs unter Microsoft Windows ist
%AppData%\Macromedia\Flash Player\#SharedObjects

Dieser Ordner ist in den Einstellungen des persönlichen Profils zu finden. Unter Windows XP normalerweise:
C:\Dokumente und Einstellungen\Username\

Bei Windows Vista finden sich die Flash-Cookies unter:
C:\Benutzer\USERNAME\%AppData%\Roaming\Macromedia\Flash Player\#SharedObjects

Der Ordner %AppData% ist standardmäßig unter Windows XP und Vista nicht sichtbar. Die Sichtbarkeit des Ordners kann über die Ordnereinstellungen geändert werden.

Der Speicherort der LSOs unter Mac OS X ist
~/Library/Preferences/Macromedia/Flash Player/#SharedObjects

Unter anderen unixartigen Betriebssystemen wie Linux und Solaris befinden sich die Dateien unter
~/.macromedia/Flash_Player/#SharedObjects

4.    Ohne Cookies kein korrektes Tracking
Ein sauberes Tracking ist die Grundlage jeder Web-Analyse. Je genauer sich die einzelnen Nutzer und Ihr Verhalten abbilden läßt, umso paßgenauer kann die Web-Site optimiert werden. Mit Hilfe von Cookies lassen sich Nutzer klar identifizieren und die erhobenen Daten lassen sich einer konkreten Sitzung zuordnen

4.1.    Tracking-Szenarios
Um einen Nutzer/Besucher Ihrer Web-Site klar identifizieren und verfolgen zu können, brauchen Sie eine besucherspezifische Kennung, die sich über den gesamten Besuchszeitraum nicht verändert.
Es gibt mehrere Methoden dies technisch zu bewerkstelligen; die am häufigsten genutzten Möglichkeiten sind: IP-Adresse, IP-Adresse und Browser-Kennung (user agent), Login-Name, Sitzungs-Cookies und Permanent-Cookies.
Wir wollen zwei Tracking-Methoden herausgreifen:

4.1.1.    Die einfachste Methode
Das Tracking mittels IP-Adresse sowie mittels IP-Adresse und Browser-Kennung. Da jeder Nutzer, der auf Ihre Web-Site zugreift, über eine IP-Adresse und einen Browser verfügt, läßt sich dieses Verfahren standardmäßig anwenden.

4.1.2.    Die genaueste Methode
Tacking mittels Cookies liefert sicherlich mit Abstand die genauesten und detailliertesten Daten in Bezug auf Nutzer und ihr Verhalten auf der Web-Site. Allerdings erfordert ein sinnvolles Cookie-Management einiges an Aufwand und Vorarbeit.
Diese beiden Arten der Nutzer-Verfolgung werden in der Praxis von fast allen Web-Site-Betreibern eingesetzt.

4.2.    IP-Tracking im Detail
"Immer noch besser als gar nichts" - dies beschreibt die Qualität des IP-Adressen-Trackings recht gut. Dieses Verfahren ist nicht geeignet, Nutzer eindeutig zu identifizieren und ihnen Sitzungen zuzuordnen. Warum? Weil viele Nutzer mit dynamischen, d.h. ständig wechselnden IP-Adressen surfen. Ein Nutzer, den Sie heute unter 197.45.34.67 tracken, kommt morgen mit der IP-Adresse 201.1.56.135 zu Ihnen. Sie haben keine Chance jemals herauszufinden, dass es sich hier um ein und denselben Nutzer handelt. Da es nicht unbegrenzt viele IP-Adressen gibt, verfügen ISPs wie T-Online, AOL oder Freenet über einen festen Pool an IP-Adressen - jedem Surfer wird beim Online-gehen eine zufällige IP-Adresse zugewiesen. Wenn die Verbindung zum Internet dann beendet ist, fällt die IP-Adresse wieder zurück an den ISP, der sie dann an einen anderen Surfer vergeben kann und wird.
Das Resultat: Es sieht so aus, als ob Sie viele Stammkunden haben, dabei handelt es sich um ganz unterschiedliche Besucher, die sich nur eine IP-Adresse teilen. Da jeder Besucher bei jedem Besuch eine neue IP-Adresse nutzt, sind die Statistiken in Bezug auf Mehrfachnutzer nicht aussagekräftig.
Ein weiteres Problem sind Nutzer, die einen Proxy-Server nutzen, um ins Internet zu gelangen. Große Firmen und ISPs wie AOL oder Akamai nutzen diese Technik. Nutzer, die über einen Proxy-Server ins Internet gehen teilen sich eine IP-Adresse. In der Analyse läßt sich dann nicht feststellen, ob ein oder mehrere Nutzer Ihre Web-Site besucht haben.
Diese Probleme verschärfen sich mit steigenden Nutzerzahlen.

Fazit: Zwar sind die absoluten Zahlen beim Tracking via IP-Adressen wenig aussagekräftig, doch lassen sich Trends im Allgemeinen mit dieser Methode recht gut analysieren.

4.3.    Cookie-Tracking im Detail
Cookies sind kleine Text-Dateien, die vom Browser auf der Festplatte des Nutzers abgelegt werden. Zwar sind Cookies nicht unumstritten - so schlecht für den Nutzer, wie sie in der einschlägigen Fachpresse dargestellt werden sind Cookies nicht. Web-Mail oder Online-Shopping beispielsweise sind ohne Cookies schwer vorstellbar.
Cookie ist nicht gleich Cookie - die "besten" Cookies stammen von der besuchten Web-Site, sind permanent und P3P-konform. P3P steht für Platform for Privacy Preferences (PPP, oder eben P3P) - einem internationalen Datenschutz-Standard. Die meisten Nutzer akzeptieren diese Art von Cookies. Da die meisten Nutzer Ihre Cookies nicht sehr oft löschen - und praktisch nie während einer Sitzung - sind Cookies sehr verlässlich, wenn es darum geht Nutzer zu indentifizieren und ihre Aktionen zu verfolgen.
Cookies lassen sich wie folgt klassifizieren:

1. Permanent-Cookies (leben ewig) vs. Sitzungs-Cookies (überleben das Ende der Sitzung nicht)
2. First party (werden von der besuchten Web-Site gesetzt) vs. Third Party (werden von anderen Sites als der besuchten gesetzt)
3. anonym vs. personengebunden
4. P3P-konform vs. nicht P3P-konform

4.3.1.    Permant vs. Sitzung
Ein Permanent-Cookie wird für eine bestimmte Zeit auf der Festplatte des Nutzers gespeichert, beispielsweise bis zum 31.1.2035. Ein Sitzungs-Cookie dagegen wird gelöscht, sobald der Nutzer die Web-Site verlässt. Mit beiden Typen lassen sich Sitzungen verfolgen, aber nur mit Hilfe eines Permanent-Cookies lassen sich wiederkehrende Besucher identifizieren.

4.3.2.    First party vs. Third party
Ein First-party-Cookie wird von der besuchten Web-Site ausgeliefert. Ein Third-party-Cookie stammt dagegen von einer Site, die nur mittelbar mit der besuchten Site etwas zu tun hat. Third-party-Cookies werden of von Ad-Servern oder Anbietern von Web-Analytics-Services eingesetzt.

4.3.3.    Anonym vs. personengebunden
Verzichten Sie darauf personengebundene Daten zu erheben. Für ein sauberes Tracking sind anonyme Cookies vollkommen ausreichend. Zum einen sind Sie dazu durch den Datensparsamkeits-Paragraphen des Bundesdatenschutzgesetzes (BDSG §3a) verpflichtet, zum andern werden die wenigsten Nutzer personenbezogene Daten herausgeben. Wenn Sie aus anderen Gründen personenbezogene Daten erheben, beispielsweise während eines Bestellvorgangs, sollten Sie diese in einem separaten Cookie speichern und so die einzelnen Funktionalitäten sauber von einander trennen.

4.3.4.    P3P-konform
Wenn Ihre Cookies P3P-konform sind, sollten Sie dies vermerken, denn damit erhöhen Sie die Akzeptanz Ihres Cookies. Allzu viel Aufmerksamkeit müssen Sie dem Punkt P3P aber nicht widmen, denn wenn Sie anonyme First-party-Cookies ausliefern werden über 95% aller Nutzer diese Cookies akzeptieren.

4.4.    Fazit
Optimieren lässt sich eine Web-Site nur auf Basis eines verlässlichen Nutzer-Trackings. Mit Hilfe permanenter, anonymer First-party-Cookies lässt sich dieses Ziel erreichen.

5.    Welche Möglichkeiten der Datenerhebung gibt es?
Drei Arten der Datenerfassung sind im Rennen: Log-Dateien, Cookies und JavaScripten. Im folgenden werden wir die Vor- und Nachteile der einzelnen Arten näher beleuchten.

5.1.    Log-Dateien
Log-Dateien sind keine Marketing-Tools, sondern dienen der technischen Diganose des Web-Servers. Marketing-Fragen lassen sich deshalb durch Log-File-Analyse nur bedingt beantworten.

Pro:

• Die Daten fallen sowieso an

• Enthalten technische Daten (Browser-Daten, Beriebssystem) und Verhaltens-Daten (Referrer, woher kamen die Nutzer).

• Es gibt viele Software-Pakete, mit denen man Log-Dateien bearbeiten und statistisch zugänglich machen kann.

Kontra:

• Daten nicht in Echtzeit auswertbar.

• Zählweise unsicher, mal werden zu viele, dann wieder zu wenige Nutzer gezählt.

• Mehre Nutzer, die hinter einer Firewall sind, werden als ein Nutzer gezählt

• Caching verzerrt die Ergebnisse, es kommen nicht alle Anfragen auch wirklich beim Server an und werden deshalb auch nicht gezählt.

• Nutzer, die im Browser die Schaltflächen "Vorwärts" und "Zurück" klicken, werden nicht korrekt erfasst.

• Wechselnde IP-Adressen erschweren die Zuordnung von Sitzungen zu einzelnen Nutzern.´

• Nicht menschlicher Datenverkehr von Robots und Spidern wird mitgezählt. Wenn sich die Robots nicht korrekt beim Server identifizieren, ist dieser Datenverkehr fast nicht auszufiltern.

• Ihre eigenen Aufrufe werden ebenfalls mitgezählt. Wenn sie auf Ihr Angebot mit einer statischen IP-Adresse zugreifen, lässt sich dieser Datenverkahr relativ leicht ausfiltern.

• Wenn Ihre Site erfolgreich ist, werden die Log-Dateien riesig. Sie brauchen dann eine ausgefeilte Logistik und leistungsstarke Rechner, um die Dateien halbwegs zügig auszuwerten.

• Komplexe dynamische Web-Sites mit verschiedenen Servern, die sich über diverse Domains und Sub-Domains verteilen sind so praktisch nicht in den Griff zu kriegen.

5.2.    Cookies
Ohne Cookies geht es nicht. Nur über Cookies lassen sich Browser eindeutig identifizieren. Mit Hilfe von Cookies lassen sich Sitzungen nachvollziehen, Nutzer eindeutig identifizieren (Erstbesuch vs. Erneuter Besuch). Ein ganz wichtiger Punkt beim Thema Cookies sind die Datenschutzrichtlinien. Sie sammeln Nutzerdaten und sollten deshalb über klar formulierte Datenschutzrichtlinien verfügen, die auch einer rechtlichen Überprüfung standhalten. Nutzer sind mittlerweile recht aufgeklärt, was Cookies angeht, viele Browser erlauben das Cookie-Management und weisen den Nutzer daraufhin, wenn eine Site einen Cookie speichern will. Es gilt die Balance zu finden zwischen Datensammeln und Nutzer verärgern, denn ein Nutzer, der es Ihrer Site nicht gestattet irgendwelche Cookies zu setzen, ist weniger wert, als wenn Sie durch Selbstbeschränkung vielleicht weniger Informationen pro Besucher erhalten, dafür aber prozentual mehr Nutzer das Cookie-Setzen gestatten.

5.3.    Tracking via JavaScript
Mit Web-Beans - von Kritikern auch Web-Bugs genannt - gespickte Seiten sind der neueste Trend im Web-Anlytics-Sektor. Vorteile hier: Sie als Site-Betreiber müssen nur einige kleine JavaScript-Schnipsel in Ihre Site implementieren, den Rest übernimmt ein spezialisierter Dienstleister. Sie müssen sich nicht mit zusätzlichen Kosten für Hard- und Software aufbürden, sondern mieten einfach was sie brauchen. Die Statistiken werden rufen Sie mit dem Browser ab, bzw. laden sie im Excel-freundlichen Format auf die heimische Festplatte. Außerdem sind diese JavaScripten sehr robust gegenüber Zählfehlern, die auf Cashing beruhen.

Vorteile:

• Daten liegen in Echtzeit vor.

• Komplexe Sites, mit mehreren Domains/Sub-Domains und dynamischen URLs lassen sich so gut tracken.

• HTML-E-Mails sind ebenfalls zählbar.

• Zusätzliche technische Informationen wie Bildschirmauflösung lassen sich ebenfalls erfassen.

Nachteile:

• Funktioniert nur, wenn die Nutzer JavaScript aktiviert haben, über 97% aller Nutzer haben das aber.

• Datenschutz: Der Nutzer besucht Ihre Site, seine Daten werden aber - ohne sein Wissen - von einem Dritten erfasst, gespeichert und ausgewertet.

• Outsourcing-Kosten fallen an. Die JavaScripten müssen auf allen Seiten einer Web-Site, die getrackt werden sollen eingebaut werden. Bei großen Sites kann das sehr arbeitsintensiv werden.

• Performance-Probleme beim Dienstleister schlagen auf die eigene Site durch.