Cookies seit H.25.4

Von | 4. Juni 2013

Wer im März genau aufgepaßt hat, mag gesehen haben, daß der SiteCatalyst Code seit Version H.25.4 eine neue Fallbackmethode für 3rd-party Cookies mitbringt.

Das Thema 1st– vs 3rd-party Cookies sollten wir uns also noch einmal ansehen.

Es ist zur Zeit auch ein Thema, das in aller Munde ist. Die Welle will ich gerne voll abreiten 😉

Warum jetzt?

Im Grunde gibt es zu der Thematik 3rd-party Cookies gar nicht so viel Neues zu sagen. Das Thema kocht zur Zeit hoch, weil Firefox 22 vor der Tür steht. Zur Erinnerung: FF22+ wird wie Safari auf iOS per Default keine 3rd-party Cookies schreiben. Schreiben!

Für uns Webanalysten bedeutet das, daß die Genauigkeit unserer Daten leiden wird.

Um wieviel genau hängt davon ab, welche Browser die Besucher einer Webseite einsetzen. Ich gehe davon aus, daß eine Site wie der Heise Newsticker mehr Probleme haben wird als z.B. eine Bank.

Was war genau das Problem?

Aus unserer Perspektive ist das Problem die sinkende Genauigkeit bei Analysen, die auf visitor IDs aufbauen.

Das sind all die, bei denen man die Aktivitäten der Besucher über Zeiträume hinweg verfolgt, also z.B. Kampagnentracking mit Success Events oder Fallout Reports.

Die Kampagnen sind aus Sicht des Marketing sicher das größte Problem: wenn meine Attribution nicht mehr für alle Besucher korrekt zugewiesen werden kann, wie soll ich dann entscheiden wohin mit dem Etat?

Lösungsansatz 1 – Filtern

Wer SiteCatalyst 15, Adobe Analytics 1.2, Data Warehouse oder Discover verwendet, kann seine Reports filtern oder segmentieren. Es gibt dafür z.B. in SiteCatalyst ein voreingestelltes Segment:

[Screenshot]

Segment für Visitors mit Cookies

Mit diesem Segment werden nur noch Daten der Besucher angezeigt, die tatsächlich Cookies akzeptieren, d.h. man hat die gewünschte Genauigkeit, sieht aber nur einen (je nach Site mehr oder weniger großen) Teil der Daten.

Ich denke, daß dieser Ansatz für die meisten Websites ganz gut funktionieren kann. Man erinnere sich daran, daß die Genauigkeit in der Webanalyse sowieso ein unerreichbares Ideal ist (siehe Die 10%-Regel), dann sieht das Filtern in vielen Fällen gar nicht so schlecht aus — die Qualität der gefilterten Daten ist schließlich besser als ohne Filter!

Javascript

Die eigentlich Neuigkeit: Die Datei s_code.js hat seit der Version H.25.4 einen Mechanismus eingebaut, der einen Fallback-Cookie namens s_fid setzt.

Der Code schreibt eine visitor ID in diesen Cookie, die im Folgenden bei Trackingcalls übermittelt wird und vom System benutzt werden kann, falls z.B. kein s_vi Cookie gesetzt werden kann und daher keine „normale“ visitor ID zur Verfügung steht.

Der Cookie wird per Javascript gesetzt, ist also automatisch ein 1st-party Cookie. Ein SSL Zertifikat braucht man hier aber nicht.

Dieser Fallback funktioniert mit den schon erwähnten FF22+ und Safari auf iOS, Tracking dieser Geräte-/Browserkombinationen wird also besser werden, wenn man seinen s_code auf H.25.4 oder neuer hievt.

Nachteile?

Generell ist die Lösung besser als der „alte“ Fallback mit IP Adresse und HTTP User-Agent.

Die Vorteile liegen auf der Hand: Man hat einen Cookie, muß sich also keine Gedanken machen, wie weit IP Adressenpools, wechselnde IP Adressen und Browserupdates die Daten verfälschen.

Mir fällt nur ein potentieller Nachteil ein: wer über mehrere Domains hinweg absichtlich mit 3rd-party Cookies trackt, sollte lieber zum Filter greifen.

2 Gedanken zu „Cookies seit H.25.4

  1. Pingback: Jahresrückblick 2013 | Webanalyse auf Deutsch

Kommentar verfassen

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