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. „1^st-party cookies“, die auf der Domäne der Website gesetzt werden,
2. „3^rd-party cookies“, die auf „2o7.net“ gesetzt werden und
3. „3^rd-party cookies“, die auf „omtrdc.net“ gesetzt werden.

Jede Art hat ihre Vor- und Nachteile.

Man kann jederzeit von den 3^rd-party zu 1^st-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.

3^rd-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 3^rd-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.

3^rd-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.

1^st-party Cookies

Wer auf Datenqualität Wert legt und Mehraufwand und Kosten nicht scheut, der kann das Tracking über 1^st-party Cookies abwickeln. Der Cookie wird dabei nicht unter „2o7.net“ oder „omtrdc.net“ gesetzt, sondern auf der Domain der Website. Für 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 1^st-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 1^st-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 1^st-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 1^st-party Cookies kann der Trackingcode die visitor IDs migrieren, man hat also nicht auf einmal wegen des Umstiegs nur noch neue Visitors.

Für 1^st-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 1^st-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.