Cookies – 1st oder 3rd party?

Im Artikel zu den Unique Visitors haben wir kurz das Thema Cookies angeschnitten: Cookies werden in fast allen Webanalysesystemen genutzt, um im Browser eine (anonyme) visitor ID zu speichern, mit der man Visitors  wiedererkennen kann, sowohl innerhalb eines Visits als auch falls sie sich wiederholt auf die Website verirren.

SiteCatalyst kennt drei verschiedene Arten von Cookies:

  1. „1st-party cookies“, die auf der Domäne der Website gesetzt werden,
  2. „3rd-party cookies“, die auf „2o7.net“ gesetzt werden und
  3. „3rd-party cookies“, die auf „omtrdc.net“ gesetzt werden.

Jede Art hat ihre Vor- und Nachteile.

Man kann jederzeit von den 3rd-party zu 1st-party wechseln, oder von „2o7.net“ zu „omtrdc.net“. In die andere Richtung zu wechseln bedeutet üblicherweise, daß alle Besucher neu gezählt werden.

Fangen wir mal mit der ältesten Variante an.

3rd-party Cookies auf „2o7.net“

Früher™ benutzte man für Implementierungen normalerweise „2o7.net“ (Ja, das ist ein „o“ in der Mitte, keine Null). Eine s_code.js Datei aus dem Interface oder aus dem Backend das die Consultants benutzen trackt per Default über „2o7.net“.

  • Vorteil – kein Zusatzaufwand
  • Nachteile – schlechtere Akzeptanz, kein serverseitiger Zugriff

Kein Zusatzaufwand: Kommen wir später drauf zurück.

Schlechtere Akzeptanz: Zwei Gründe sorgen dafür, daß Browser 3rd-party Cookies ablehnen: 1. Gibt es Browser, die das generell per Voreinstellung tun, bestes Beispiel Safari auf iOS und OS X, also praktisch alle Benutzer auf Apple Produkten. 2. gibt es mittlerweile viele Adblocker und Privacy Extensions und Proxies, von denen einige „2o7.net“ als unerwünscht klassifizieren und deswegen blockieren.

Kein serverseitiger Zugriff: Auch darauf kommen wir später zurück.

3rd-party Cookies auf „omtrdc.net“

Das Tracking über „omtrdc.net“ wurde im Dezember 2009 für die Regional Data Collection eingeführt. Seit einiger Zeit sollten eigentlich alle neuen Implementierungen über RDC laufen.

  • Vorteile – kein Zusatzaufwand, schnellere gefühlte Seitenladezeiten
  • Nachteile – schlechtere Akzeptanz, kein serverseitiger Zugriff

Schnellere gefühlte Seitenladezeiten: Der Witz an RDC ist, daß die Trackingrequests unabhängig vom Datenzentrum sind, also nicht mehr z.B. direkt vom Browser nach San Jose gehen, sondern auf einen geografisch näherliegenden Trackingserver, z.B. in London. Das beschleunigt den Zeitraum, bis die Seite komplett fertig geladen ist, der Browser also keinen kreisenden Mauszeiger mehr zeigt.

1st-party Cookies

Wer auf Datenqualität Wert legt und Mehraufwand und Kosten nicht scheut, der kann das Tracking über 1st-party Cookies abwickeln. Der Cookie wird dabei nicht unter „2o7.net“ oder „omtrdc.net“ gesetzt, sondern auf der Domain der Website. Für http://www.test.com würde z.B. das Tracking über metrics.test.com laufen und der Cookie auf test.com gesetzt werden.

  • Vorteile – bessere Akzeptanz, serverseitiger Zugriff
  • Nachteil – Zusatzaufwand und -kosten

Bessere Akzeptanz: Mit 1st-party Cookies steigt die Zahl der Visitors die Cookies akzeptieren und damit die Genauigkeit der Webanalysedaten. Wie schon im Artikel zu den Trafficmetriken erläutert hat das Auswirkungen auf die Visits in SiteCatalyst 14 und die Unique Visitors Metriken generell.

(Wie man nachsieht, ob man eigentlich ein Problem hat, steht auch dort: Site Metrics > Visitors > Daily Unique Visitors Report laden, dann den „Persistent Cookies“ Filter einschalten.)

Serverseitiger Zugriff: Weil der Cookie mit der visitor ID („s_vi“) unter der gleichen Domain gespeichert ist wie die Website kann der Webserver darauf zugreifen. Das bedeutet man kann die visitor ID auslesen und z.B. für serverseitiges Tracking per Data Insertion verwenden.

Zusatzaufwand: Die eigentliche Implementierung ändert sich nicht, egal welche Cookies man einsetzen möchte. Ist jedoch einen Teil der Website secure (also per HTTPS), dann benötigt man für 1st-party Cookies Zertifikate auf Adobes Servern, damit die sich dem Browser gegenüber korrekt ausweisen können und der Browser kein Sicherheitsproblem anzeigt.

Je nach zugrundeliegenden Trackingcalls („2o7.net“ oder RDC) benötigt man ein Zertifikat mit Lizenz für 2 („2o7.net“) oder 5+ (RDC) Server. Diese(s) Zertifikat wird auf den Adobe Servern geladen und stellt sicher, daß ein Trackingcall nicht im Browser eine Sicherheitswarnung auslöst.

Notizen

Kosten fallen für 1st-party Cookie Implementierungen nur an, wenn tatsächlich ein Teil der Website nur per HTTPS erreichbar ist. Falls das nicht der Fall ist, braucht man nur Zugriff auf den Nameserver.

Beim Umstieg von „207.net“ auf RDC oder 1st-party Cookies kann der Trackingcode die visitor IDs migrieren, man hat also nicht auf einmal wegen des Umstiegs nur noch neue Visitors.

Für 1st-party Implementierungen mit RDC werden 5 Lizenzen für das Zertifikat benötigt, weil es zur Zeit 5 „collection center“ gibt. Das muß nicht immer so bleiben. Es könnte also sein, daß man in Zukunft mehr Lizenzen für das Zertifikat hinzukaufen muß.

Wichtig: Wer eine 1st-party Implementierung mit Zertifikaten benutzt, sollte nicht vergessen, daß die Zertifikate auslaufen! Es ist Aufgabe jedes Kunden, rechtzeitig neue Zertifikate zu senden, die dann eingespielt werden können. Das macht man am einfachsten über ClientCare.

Über

German expat living in Switzerland (formerly UK and France). Consultant and member of the Multi-Solutions Group at Adobe, working with the Digital Marketing Suite. Father of 4 girls.

Tagged with: , ,
Veröffentlicht in Grundlagen
7 comments on “Cookies – 1st oder 3rd party?
  1. […] soll es um einen dieser Sonderfälle gehen: Die Debatte um 1st-party oder 3rd-party Cookies im Zusammenhang mit Tracking über Domains […]

  2. […] funktioniert am besten im Zusammenspiel mit Javascript und 1st-party Cookies, damit man die visitor ID auslesen und wiederverwenden […]

  3. […] wir wissen, dient der s_vi Cookie dazu, für jeden Browser eine visitorID zu speichern. Wenn das nicht klappt, dann benutzt […]

  4. […] tracken per Javascript. Die Identifizierung der Benutzer wird dabei über einen (anonymen) Cookie geregelt, oder als Fallback über eine Kombination aus HTTP User-Agent und IP […]

  5. […] Thema 1st- vs 3rd-party Cookies sollten wir uns also noch einmal […]

  6. […] Wert steht im Backend in einer Art Tabelle. Diese Tabelle wiederum wird über die visitor ID […]

Sagen Sie Ihre Meinung!

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

Autoren
%d Bloggern gefällt das: