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.

Die Anreise über Dubai hatte 2 Highlights: Das Handynetz in Duabi names “EtiSalat” und den ersten Flug mit dem A380, welcher seeehr behäbig daher kommt.
Tipp: Die Fensterplätze in der Economy ganz vorne sind nicht verkehrt, weil man dank der Biegung des Rumpfes zumindest ein Bein zwischen Außenwand und Vordermann durchstrecken kann.

In Seoul angekommen…, rutschten wir noch in 2 Tage Regenzeit, was auf den Fotos auch unschwer zu übersehen ist. Dazu sagen muss man allerdings, dass es eigentlich nur in “Regenpausen” möglich war, überhaupt den Foto rauszuholen. Bei vollem Wasserfall von oben wäre dies nicht ratsam gewesen.

Nach unserer Ankunft und einem genialen Abendessen in einem Szeneviertel gab es auch gleich das erste typisch asiatische Erlebnis zu verbuchen: Die Subway bleibt um kurz nach 0 Uhr stehen – Betriebsende. Um kurz nach Mitternacht! Wir also raus aus der Subway und rein in den Regen, irgendwo in Seoul versucht neben den anderen Passagieren der U-Bahn ein Taxi zu ergattern. Unser Ziel: Grand Hilton Seoul – alles klar, easy – wer kennt das nicht?
Der Taxifahrer dreht also und fährt wieder in die Innenstadt… ?!?
10 Minuten später stehen wir vor dem Millennium Seoul Hilton und lassen unserem Taxifahrer vom Hotelboy erklären, dass es noch ein zweites Hilton in Seoul gibt. Nach einigem hin und her meint dieser: Ich hab erst mal ausgehandelt, dass ihr den Weg hierher nicht zahlen müsst. Den Weg hab ich auch erklärt, bin mir aber nicht sicher, ob er [der Taxifahrer] es verstanden hat – ich wünsch euch aber viel Glück und eine gute Nacht!
Danke

Was hat Seoul zu bieten?

• Seoul ist riesig!
  11 Mio EW, die Metropole mit den angrenzenden Nachbarstädten hat sogar 23 Mio EW! Für eine kleine Ecke mit der Subway braucht man wirklich eeewig.
• Essen!
  Ich liebe sie, die vielen Straßenstände und kleinen Restaurants wo es die ach so genialen, frisch zubereiteten Häppsche gibt.
  Ganz klar natürlich auch, dass man in einer Stadt wie Seoul einfach alles bekommt – der Himmel auf Erden!
• Einkaufen!
  Wie in vielen asiatischen Großstädten gibt es unendlich große (oft unterirdische) Malls, in die man vor dem Regen oder der Mittagshitze fliehen kann. Ungleich genialer natürlich die alten Märkte mit den engen Gassen, die einen Europäer einfach erschlagen mit ihren vielen Gerüchen und Eindrücken.
• Sehenswürdigkeiten!
  Tempel, Schreine und Paläste – mitten in der Stadt, oft zwischen Hochhäusern eingequetscht. Viele Schreine sind auch heute noch rege besucht.
• Nordkorea…
  Ein Thema über das keiner redet, welches aber allgegenwärtig ist. So stehen überall Feuerlöscher, Gasmasken und Generatoren. Bunkereingänge haben wir auch einige gesehen. In unserem Hotelzimmer (7. Stock) war in Fensternähe eine Seiltrommel im Boden verankert mit welcher man sich im Notfall abseilen kann.

Beeindruckend!

• Die öffentlichen Flächen – allen voran die Subway – sind wie geleckt. So hängen in den Bahnhöfen sogar Gemälde an den Wänden und niemand kommt auf die Idee diese zu zerstören. Warum auch? Es gehört ja allen.
  Tipp: Die mit Abstand saubersten Toiletten gibt’s auch in der Subway – ist auch fast immer jemand da, der sie ununterbrochen putzt.
• Hilfsbereitschaft, Freundlichkeit und Offenheit – Wahnsinn! Zur Not einfach irgendwo hinsetzen, hilflos schauen und die nächsten 5 Leute helfen dir. Schade nur, dass die Sprachbarriere immens hoch ist weil (v.a. außerhalb von Seoul) kaum jemand englisch spricht. Umso toller, dass man trotzdem so viele Menschen trifft, mit denen es dann doch irgendwie klappt sich zu verständigen – natürlich nur, weil diese das auch unbedingt wollen und die Zeit investieren.
• Wie wenig Leute englisch sprechen: Es wird – wenn koreanisch nicht geht – halt auf japanisch oder chinesisch versucht – half uns freilich relativ wenig.
• Das koreanische Handynetz ist so modern, dass ein bis zwei Jahre alte europäische Handys ihren Dienst verweigern.
• McDonals liefert Essen aus! – und nein, ich hab mich strikt geweigert so nen Mist im kulinarischen Himmel zu essen.

Soviel Text für’s Erste – weitere Einzeilheiten und kleine Anekdoten stehen beim jeweiligen Foto. Im nächsten Teil folgt der Weg durch das südkoreanische Hinterland nach Changwon. Teil drei wird die sehr beeindruckenden 3 Tage in Fukuoka, Japan behandeln.
Sehr lesenswert ist auch der Wikipedia-Artikel über Seoul.

[nggallery id=9]

So funktionieren folgende Punkte heute immer noch nicht:

• Bluetooth Datentransfer
• Tethering
• Akkulaufzeit: Das Galaxy hält selbst im Standby keinen Tag durch
• Navigationsfunktion

Obwohl einige dieser Punkte immer noch beworben werden, wurde vor einigen Woche bekannt, dass von Seiten Samsung/O2 an keinem weiteren Update gearbeitet wird. Damit ist klar, dass einige beworbene Funktionen das Galaxy niemals funtkionieren werden.

Da für mich insbesondere Tethering eine essentielle Funktionalität darstellt, habe ich mich etwas schlau gemacht bzgl. “Rücktritt vom Kaufvertrag wegen Nichterfüllung”.

Kurz gesagt: O2-Kunden haben Glück, denn O2 nimmt das Galaxy aus Kulanz zurück – das geht sogar ohne relativ viel Aufwand – Top!

Wem es ähnlich geht, dem möchte ich den Thread im android-Hilfe Forum ans Herz legen. Hier gibt es alle Informationen und Hilfestellungen, die man wünschen kann. (nicht nur zu O2)

Ich habe seit 3 Tagen das HTC Desire. Mein bisheriges Fazit: Genial! HTC Sense ist einfach wirklich feine Sache – und die Akkulaufzeit (meine größte Sorge) ist für mich geschundenen Galaxy-Nutzer auch ausreichend.

1. Server Monitor

Server Monitore werden als Server Plug-In realisiert und zeichnen alle serverseitigen Ereignisse auf. Im Unterschied zu normalen Webserver-Logfiles werden die erhobenen Daten in Echtzeit an ein Data Warehouse übertragen und können sofort ausgewertet werden.

Problematisch wird der Einsatz von Server Monitoren jedoch, wenn ein Unternehmen mehrere Webserver parallel betreibt. Um hier ein vollständiges Bild vom Nutzerverhalten zu erhalten, müssen die Daten der verschiedenen Server zusammengefasst werden. Dies kann sehr aufwändig und fehlerbehaftet sein.

2. Network Monitor (Packet Sniffer)

Eine mögliche Lösung wäre der Einsatz eines Network Monitors (Packet Sniffers). Dieser ist zwischen dem Internet und der Serverfarm angesiedelt und protokolliert passiv alle versandten TCP-/IP-Pakete.

Da ein Network Monitor im Gegensatz zum Webserver auf einer niedrigeren Netzwerkschicht kommuniziert, hat er Zugriff auf weitergehende Informationen. Dies sind neben der Bestätigung, dass die vom Webserver versandten Daten den Empfänger erreicht haben, auch Informationen über:

• Client-initiated disconnects (z.B. Stop-Button während einem Download gedrückt)
• Netzwerkprobleme (z.B. Server retransmissions wegen überlasteten Netzwerken)
• Busy signals (z.B. Ignorierte Anfragen wegen einem überlasteten Server)
• Die Zeit, die der Server zum Antworten gebraucht hat

Mit einem Network Monitor können also zusätzliche Informationen über die technischen Rahmenbedingungen (Geschwindigkeit, Qualität und Ausfallsicherheit) gesammelt werden – alles Werte, die für die Qualität eines Internetauftritts von grundlegender Bedeutung sind.

3. Reverse Proxy Monitor

Noch weiter als Packet Sniffing geht ein Reverse Proxy Monitor (RPM), welcher den Kommunikationsstrom zwischen Client und Webserver nicht nur filtert, sondern auch gezielt verändert. Auf diese Weise lassen sich zusätzliche Informationen erheben (z.B. CGI-Parameter oder semantische Schlagworte). Angesiedelt wird ein Reverse Proxy Monitor, wie auch ein Network Monitor, zwischen dem Internet und dem Webserver.

Ein bekannter Anbieter dieser Technik ist die Firma SiteSpect. Ihr RPM ermöglicht neben der Datenerhebung und Analyse auch eine einfache Realisierung von A/B- und multivariaten Tests. Alle Analysen und Contentvariationen werden dabei vom RPM on the fly umgesetzt.  Es sind also keinerlei Änderungen an den Inhalten auf dem Webserver nötig.

Diese Techniken zur Netzwerküberwachung haben einige Vor- und Nachteile.

Von Vorteil ist:

• Andere Verfahren zur Datenerhebung sind überflüssig
• Es können live und zentral so viele Daten gesammelt werden wie mit keiner anderen Methode. Dazu gehören zum Beispiel neben den üblichen Geschäftsdaten auch technische Informationen wie Serverfehler und Auslastungsdaten.
• RPMs ermöglichen es, immer First Party Cookies einzusetzen

Von Nachteil ist allerdings:

• Die Installation eines solchen Systems erfordert einiges Know-how, Konfigurationsarbeit und Zugriff auf das Netzwerk.
• In den Rohdaten können brisante Informationen wie Passwörter, Adressdaten und Kreditkartennummern unverschlüsselt vorhanden sein. Folglich sind einige Anstrengungen erforderlich, um das System auch datenschutzrechtlich sicher zu gestalten.
• Auch ein RPM stößt an seine Grenzen, wenn der Browser Daten aus dem Cache lädt oder massiv Flash eingesetzt wird.
• Ist die Datenerhebung vom Daten ausliefernden Webserver separiert, können anhand der Logfiles die Entscheidungskriterien (z.B. Zielgruppeneigenschaften) die zur Auslieferung eines bestimmten, dynamisch generierten Contents geführt haben, nicht mehr nachvollzogen 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.

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.

Museen

• Kunsthistorisches Museum
  So viele Bilder… dazu noch Ägyptischen, Antike, Münzen – tolle Sonderausstellung über “Vermeer – the art of painting“!
• Schatzkammer
  Von der kaiserlichen Garderobe, dem Reichsapfel bis zur Ikone – alles da. Eine interessante und gut aufgebaute Ausstellung.
• Wagenburg
  Die kaiserlichen Kutschen (“der österreichische Hof, der für seine zurückhaltende Art bekannt war” – ja ne, is klar)
• Hofburg: Sisi Museum & Kaiserappartements & Silberkammer
  Im Erdgeschoss tonnenweise Gold und Silber, oben Sisikult – interessant, ansonsten Geschmackssache
• Schloss Schönbrunn
  Netter Schlosspark mit Ausblick. Im Schloss das was man erwartet mit gutem Audioguide (nicht zu viel und nicht zu wenig Informationen)
• MUMOK – Museum Moderne Kunst
  Das Gebäude ist interessant – der Inhalt nicht. Mit dieser abgehobenen, neumodischen “Kunst” werd ich nicht mehr warm.

Sehenswürdigkeiten

• Riesenrad
  Nett – mehr aber auch nicht. Nach 12 Minuten war der Spaß schon wieder vorüber. Man fährt nur eine Umdrehung, während der für jede Gondel angehalten wird.
• Donauturm
  Toller Ausblick! Empfehlenswert sowohl bei Tag als auch bei Nacht. Sehr windig. Hätte ein Stativ für meinen Foto mitnehmen sollen.
• Führung durch die Wiener Staatsoper
  Sehr interessant! Für den Wiener Opernball wird auf der Bühne die zweite Hälfte des Zuschauerraums als exakte Kopie aufgebaut. Der Ball geht bis 5 Uhr früh – doch bereits um 13 Uhr findet die nächste Vorstellung statt. Dafür arbeiten rund 2500 Leute nur für dieses Event!
• Spanische Hofreitschule => Besuch der Morgenarbeit
  Der Besuch der Morgenarbeit (10-12 Uhr) ist weitaus günstiger als die Abendveranstaltung. Man darf so lange wie man will bleiben und beim Training zusehen. Geschmackssache.
• Swarovski Wien
  Bei vielen Frauen wird beim Betreten des Ladens der Schalter wohl auf “Kaufrausch” umgelegt. Sehr interessante Szenen lassen sich da beobachten!
  Ansonsten nett gemacht und v.a. kostenlos! Auch kann man sich über den “perfekten Schliff von Swarovski” aufklären lassen – und dass sie diesen “sogar bei Holz” anwenden!
• Vienna Airlines
  Ein Flugsimulator gegenüber vom Riesenrad auf dem Wiener Prater. Coole Sache! Man fliegt etwa 10 Minuten die Sehenswürdigkeiten von Wien ab und steht dabei auf einer beweglichen Plattform.
• Haus der Musik
  Eher für Kinder. Informiert über alles was mit Musik zu tun hat. Beginnend von “Wie funktioniert Schall und das menschliche Ohr” bis hin zu den wichtigsten wiener Komponisten.
• Café Sacher
  Sehr teuer: Sachertorte + Kafe = 10 EUR. Nicht unbedingt ein “must have”, auch wenn ich den Kuchen echt gut fand.
  Tipp: Nicht ins Café Sacher gehen, sondern nebenan ins “Sachereck” – da gibt’s das gleiche ohne anstehen.

Essen

• Figlmüller (http://www.figlmueller.at)
  Das angeblich beste Wiener Schnitzel – wirklich unglaublich gut! Tisch vorbestellen!
• Bitzinger’s Augustinerkeller
  Sehr gutes Essen, direkt am Albertina
• Buschenschank Wolff (http://www.wienerheuriger.at)
  Highlight in Wien! Unglaublich gutes Essen und Wein, billig, viel, seeeehr nettes Personal. Man fährt etwa 20 Minuten mit dem Bus – das ist es aber locker wert!
  Ich kann nur jedem nahe legen, die Zeit für ein Abendessen zu investieren!

Fazit

Für mich war Wien sehr kalt (brutaler Ostwind), zum Glück nicht unglaublich teuer (Ermäßigungen dank Angehörigkeit zur Tourismusbranche), sehr kulturlastig (die Museen sind wirklich gut gemacht) und auf jeden Fall eine lohnenswerte Reise! Ich werde Wien im Sommer sicherlich nochmal besuchen – das Donauufer sah schon sehr vielversprechend aus. Vielleicht klappt’s dann auch mit dem Besuch von Bratislava.

Fotos

Leider war das Wetter während meinem Besuch ziemlich durchwachsen. Darum im Folgenden nur eine Auswahl der besten Fotos.

[nggallery id=8]

Liebe Eltern von heute: Wacht auf und bereitet euren Nachwuchs auf das reale Leben vor!
Wohin soll das führen, wenn eure Sprößlinge später – wie von euch gelernt – den Lehrer bei der Sprechstunde zur Einschulung mit dem Anwalt konfrontieren? Oder sogar gleich körperlich zur Sache gehen?
Nurnoch fordern, aber nichts mehr geben – Hauptsache der eigene Arsch wird schön fett?!

Aber hey, wer merkt schon dass man keine Ahnung hat, wenn man laut genug brüllt und dem anderen die Schuld gibt?
Irgend einer wird schon mitschreien – bis der andere fertig ist – Jawoll!

Vielleicht fällt euch ja in 40 Jahren auf, dass ihr euer eigenes Grab geschaufelt habt – dann wenn eure Kinder euch den Mittelfinger zeigen und fragen, warum sie sich um euch kümmern sollten? Immerhin habt ihr als alte Säcke keinerlei Nutzen mehr für sie.

Leider darf ich als direkt betroffener Sohn einer Lehrerin – wegen laufender Verfahren – keine Einzelheiten veröffentlichen.

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