3rd-party Cookies und mehrere Domains [Updated]

Von | 31. Juli 2012

Heute soll es um einen dieser Sonderfälle gehen: Die Debatte um 1st-party oder 3rd-party Cookies im Zusammenhang mit Tracking über Domains hinweg.

Angenommen die Firma XYZ unterhält 2 Websites, www.xyz.com und www.myxyz.com. Die Sites haben ähnliche Ziele und werden daher gemeinsam verwaltet und auch gemeinsam analysiert und optimiert, d.h. die Firma XYZ benutzt eine Report Suite für das Tracking beider Seiten.

1st-party vs 3rd-party Cookies

Wir erinnern uns: es gibt 1st-party Cookies und 3rd-party Cookies. Erstere werden auf der Domain der Website gesetzt, letztere auf einer anderen.

Manchmal hört man auch den Begriff „friendly“ 3rd-party Cookie. Das ist ein Cookie, der zwar nicht auf der Domain der Site gesetzt wird, aber auf einer anderen, die dem Sitebetreiber gehört.

Trackingcookies im Beispiel oben könnten auf xyz.com gesetzt werden. Auf www.xyz.com sind das also 1st-party Cookies, auf myxyz.com „friendly“ 3rd-party Cookies.

3rd-party Cookies generell haben im Zusammenhang mit SiteCatalyst und Webanalyse zwei große Nachteile:

  1. Viele Browser akzeptieren unter Werkseinstellungen keine 3rd-party Cookies.
  2. Manche Browserplugins oder Anti-Sonstwas Pakete klassifizieren die Domains einiger Webanalysetools als gefährlich und blocken die Cookies auf diesen Domains.

Der erste Nachteil war bis vor einigen Jahren irrelevant, weil es nur um Opera ging. Dann jedoch kamen das iPhone und Safari daher und seitdem ist es ein großes Problem, denn alle iOS oder OSX Geräte mit Safari fallen in die Gruppe derer, die keine 3rd-party Cookies akzeptieren.

Der zweite Nachteil ist nachwievor relativ unbedeutend, aber er kann je nach Zielgruppe einer Website durchaus einen Unterschied machen. Für „friendly“ 3rd-party Cookies spielt der zweite Nachteil natürlich keine Rolle.

Also „Friendly“ 3rd-party Cookies?

Eigentlich würde man ja 1st-party Cookies benutzen wollen, bei mehreren Domains geht das aber natürlich nicht. Ein Benutzer hätte auf xyz.com eine andere visitor ID als auf myxyz.com und das Tracking in eine gemeinsame Report Suite wäre witzlos.

Weil 1st-party Cookies hier also nicht sinnvoll sind, empfehlen Consultants „friendly“ 3rd-party Cookies. Die haben zwar immer noch Nachteil 1 (Safari auf iOS und OSX) aber nicht mehr Nachteil 2 (schwarze Liste).

Oft ist die Empfehlung, die größte Domain für die „friendly“ 3rd-party Cookies zu benutzen, also die mit dem meisten Traffic. Dahinter steckt der Gedanke, daß die Cookies auf dieser Domain ja 1st-party sind. Der größte Teil des Traffics wird also genauer gemessen und der kleiner Rest hat immerhin noch besseres Tracking als mit normalen 3rd-party Cookies.

Ich halte das mittlerweile für Unsinn.

Warum?

Zurück zum Beispiel oben.

Angeommen wir folgen der Empfehlung und setzen unsere Trackingcookies auf xyz.com. Dann nehmen wir unser iPad und sehen uns xyz.com an. Da wir hier 1st-party Cookies haben, akzeptiert das iPad den Cookie und wir bekommen eine schöne, ordentliche visitor ID. So weit so gut. Dann klicken wir den Link zu myxyz.com. Immer noch alles gut, denn das iPad wird den Cookie nachwievor lesen können.

Andersherum wird es problematisch. Denn wenn der erste Kontakt des iPads mit myxyz.com ist der erste Trackingcookie 3rd-party, denn er wird ja auf xyz.com gesetzt. Das iPad akzeptiert ihn folglich nicht und SiteCatalyst bleibt nichts übrig als eine visitor ID auf Basis der IP Adresse und des HTTP User-Agent zu berechnen. Wenn der Benutzer dann xyz.com ansteuert, wird das iPad den Trackingcookie akzeptieren.

Im zweiten Beispiel hat das iPad also garantiert zwei verschiedene visitor IDs. In unserer Report Suite taucht es daher als 2 Unique Visitors auf und wir haben jetzt 2 Visits erzeugt. Hm…

Nochmal: Wer seine „friendly“ 3rd-party Cookies auf der meistbesuchten Domain setzt, kann in der gemeinsamen Report Suite nicht nachvollziehen, wie Besucher der wichtigsten Domain mit den anderen Domains interagieren!

Der durchgestrichene Paragraph war Unsinn. Tatsächlich ist diese Empfehlung sinnvoll. Wer „friendly“ 3rd-party Cookies nutzt, kann domänenübergreifend tracken, sobald ein Benutzer einmal auf der für das Tracking genutzten Domain war, daher sollte dafür die meistbesuchte Domain benutzt werden.

Was tun?

Mein Vorschlag: Ich würde entweder die Domain mit dem wenigsten Traffic oder sogar eine ganz unbenutzte Domain für die Cookies benutzen. Falls das nicht geht (warum auch immer) würde ich ganz normale 3rd-party Cookies einsetzen.

Normale 3rd-party Cookies haben wie erwähnt den Nachteil geringerer Akzeptanz.

SiteCatalyst berechnet in solchen Fällen eine visitor ID aus IP Adresse und Browserkennung. Das ist ganz klar weniger genau als die Lösung mit Cookies. Es bedeutet aber, daß für das iPad im Beispiel auf beiden Sites die gleiche visitor ID berechnet wird, solange sich IP und Browser nicht ändern.

Anders gesagt: mir ist „weniger genau“ lieber, wenn die Alternative „ungenau“ ist. Lieber eine berechnete visitor ID als garantiert zwei.

Notizen

Der Unterschied zwischen normalen und „friendly“ 3rd-party Cookies ist wie erwähnt nur relevant für Nachteil 2, also schwarzgelistete Domains in einigen Browserplugins oder Anti-Irgendwas Softwarepaketen. Ich kann das nicht mit Zahlen untermauern, würde aber vermuten, daß wir uns hier am Rande der Irrelevanz bewegen, wenn nicht sogar mitten drin. Wie üblich hängt das sicher von der Site ab.

Die gleiche Argumentation wie oben gilt natürlich auch, wenn man mehrere Domains oder Websites in eine global report suite trackt. Das ist nur mit „friendly“ 3rd-party Cookies sinnvoll, oder einfachen 3rd-party Cookies.

Kommentar verfassen

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.