Crossdomain-Tracking
Posted by 
Mai 21, 2008 •
Seit wenigen Wochen sitze ich nun auf der Seite eines Web Analytics Tool-Anbieters und mir ist aufgefallen, dass bei jedem Kunden das Thema Crossdomain-Tracking sehr weit oben mit auf der Agenda steht.
Es gibt kaum noch Unternehmen, die nur eine einzige Domain betreiben und daher kommt immer öfter der Wunsch hoch zum einen die Besucher auch auf ihrem Weg über mehrere Domains hinweg zu verfolgen und zum anderen eine domainübergreifende Sicht auf die Daten zu haben.
Beim Tracking über mehrere Domains hinweg tritt folgende Problematik auf: Verwende ich auf einer Domain First Party Cookies zum tracken und verlasse diese Domain, so kann ich diesen Cookie nicht mehr verwenden, da ein First Party Cookie immer an eine Domain gebunden ist. Setze ich nun auf der zweiten Domain einen neuen First Party Cookie, so geht mir die Historie des User verloren und ich habe Grundsätzlich zwei Besucher. Aus Sicht der einzelnen Domains ist das zwar ok, aber aus der Vogelperpektive auf alle Domains möchte man gerne diesen Besucher nur einmal zählen und zusätzlich auch seinen Weg über beide Domains hinweg verfolgen.
Die einfachste Lösung wäre die Verwendung der klassischen Third Party Cookies, die von der Domain des Web Analytics Anbieters oder einer zentarlen Kundendomain gesetzt werden. In dem Fall kann man ein und den selben Cookie über mehrere Domains hinweg verwenden ohne dabei den User aus den Augen zu verlieren. Allerdings sind Third Party Cookies nicht mehr State-of-the-Art und jeder Kunde möchte gerne First Party Cookies einsetzen, da die Ablehnungsrate bei diesen Cookies deutlich geringer ist. Ob man dadurch Zahlen bekommt, die besser geeignet sind eine Website zu optimieren könnte man sicherlich noch einmal diskutieren, aber so sieht es nun mal aus und mit der Situation muss man als Anbieter von Web Analytics Tools umgehen.
Um nun auf allen Domains First Party Cookies einsetzen zu können kann man sich einer Kombination aus First und Third Party vorstellen. Der First Party Cookie wird gesetzt um das übliche Tracking zu realisieren. Zusätzlich wird ein Third Party Cookie gesetzt der ausschließlich dazu da ist einen eindeutige ID des Users von Domain zu Domain zu transportieren. Wechselt der User nun die Domain, so kann die Zielseite den Third Party Cookie verwenden, die ID auslesen und diese dem First Party Cookie zuordnen um so die Historie des Users wieder herzustellen. Zwar geht mir der Zusammenhang bei den Usern verloren, die den Third Party Cookie ablehnen, aber für den Großteil der User habe ich dann die verknüpften Daten.
Grundsätzlich lässt sich so der Weg eines Besuchers auch über mehrere Domains hinweg verfolgen. Nun stellt sich noch die Frage, wie man das im Web Analytics Tool visualisiert?
Eine Möglichkeit besteht darin alle Domains in eine ID zu tracken. So kann ich den Weg des Besuchers innerhalb der Reports verfolgen. Allerdings muss ich Vorkehrungen treffen um die Domains auseinanderhalten zu können, da die Tools meistens davon ausgehen, dass die Daten alle von einer Domain stammen. Die einfachste Möglichkeit dies zu lösen wäre die Bildung von Segmenten pro Domain. Entweder man segmentiert direkt nach der Domain oder man führt ein Attribut ein, welches wiederum erlaubt darüber ein Segment zu bilden.
Die zweite Möglichkeit wäre die Bildung von Master- und Sub-ID’s. Jede Domain hat eine Sub-ID in der sie separat betrachtet werden kann. Zusätzlich kann man mit der Master-ID auf die aggregierten, bzw. konsolidierten Daten aller Domains schauen.
Zuletzt bieten einige Hersteller die Möglichkeit spezieller Reports und Dashboards, die für die Betrachtung mehrere Domains ausgelegt sind. Diese Reports zeigen meistens aggregierte Daten und bieten einen schnellen Vergleich zwischen den Domains, haben jedoch Limits im Detailgrad.
Die wichtigste Aufgabe ist aus meiner Sicht jedoch die Definition der Fragestellung. Dass jeder Crossdomain-Tracking möchte ist klar. Um nun aber die beste Methode auswählen zu können und die beste Visualisierung, ist es wichtig zuerst die Fragestellung und den Business Case zu formulieren. Ich bin mir sicher, dass der Anbieter Eures Vertrauens dann auch die richtige Lösung aus dem Hut zaubern kann.
Wenn Ihr Anmerkungen oder weitere Ideen zu dem Thema habt, würde ich mich freuen darüber in den Kommentaren zu diskutieren.
Schlagwörter: crossdomain, first party cookies
Ganz richtig, es kommt auch hier auf die Business Requirements an.
Beim Tracking verschiedener Domains in eine Reporting ID und anschließender Segmentierung nach Domains wird die Segmentierungsfunktion zweckentfremdet.
. Für analytische Zwecke innerhalb der Domains (Segmente) stößt man dann jedoch auf Grenzen, es sei den das Tool kann Segmente segmentieren! Schön ist das insgesamt nicht, da man sich bei webanalytischer Optimierung doch eher auf die jeweilige Domain konzentriert und Segmentation als analytische Kernfunktion dringend benötigt wird.
Für reine Reportingzwecke ist das meistens kein Problem. Im Gegenteil man spart sogar Kosten (ich habe Kunden die leben damit wunderbar
Besser aber auch teurer ist die zweite von Dir genannte Möglichkeit, das Tracking in Master- und Sub-ID’s zu organisieren. Bei HBX und SiteCalalyst gibt es dafür die Möglichkeit globale Account bzw. Reports Suite ID zu nutzen, die dann gleichzeitig übergeben werden. Es werden also mit jedem Seitenrequest zwei Datentöpfe gleichzeitig angesteuert. Im Reporting haben wir dann für jede Domain viele in sich geschlossene, unabhängige Reportingeinheiten mit voller Funktionalität sowie zusätzlich eine globale crossdomain Reportingeinheit mit voller Funktionalität. In der globalen Reporting Einheit werden die Besucher der jeweiligen Domains jedoch nicht nur einfach aufsummiert, sondern innerhalb der Domainlandschaft nur einmal gezählt (depuplizierte Visits und Visitors).
Bei der Deduplizierung der Visits und Visitors liegt das Problem beim Crossdomain First Party Cookie Tracking. Bisher konnte mir keiner der führenden Web Analytics ASP´s dafür eine Lösung anbieten. Ich denke, wer unbedingt Crossdomain FPC machen will muss das Inhouse applikationsseitig lösen. Z.B. kann man im Omniture SiteCatalyst das Tracking auf der Basis einer Visitor ID organisieren. Laufen alle Domains über eine Web Applikation ist das ein smarter Weg. Bei verteilten Domains kommt man damit jedoch nicht weiter.
Moin zusammen,
dann gebe ich doch Heute auch mal einen Kommentar ab. Das Problem ist natürlich bekannt. Neben den aufgezeigten gibt es aber noch eine weitere Lösung first Party Cookies auch über mehrere Domains hinweg “mitzunehmen”. Indem man die Links die von Domain A zu Domian B führen dementsprechend verändert, dass die first Party Cookies (und deren Daten) von A nach B übergeben werden. Voraussetzung hierfür ist natürlich dass sämtliche Links die zwischen den eigenen Domains hin und her gehen verändert werden müssen, was einen gewissen Aufwand bedeuten kann. Dennoch ist dies eine recht einfache Lösung, da man sich dann hinterher in den Report auch die einzelnen Domains wieder anzeigen lassen kann und diese entweder individuell oder aggregiert analysieren kann.
Sovielk von meiner Seite.
Viele Grüße,
Timo
Zur ThirdParty-Thematik: Wie setzt man die Dinger eigentlich? Über eine eingebundene JavaScript-Datei, die extern liegt?
Andere Frage wäre: Warum werden die eigentlich häufiger abgelehnt? Beim Firefox wüsste ich keine Einstellung, die da selektiv vorgeht und im IE7 meine ich unter Datenschutz auch gesehen zu haben, dass sowohl 1. als als auch 3. Party Cookies akzeptiert werden. Vielleicht doch nicht so ein Problem?
@Thomas D.: Ja, gesetzt werden die normalerweise über eine eingebundene JavaScript-Datei. Die Einstellungen muss ich mir noch mal genau anschauen. Hab schon lange nicht mehr nachgeschaut. ich nehme eh jeden Cookie mit, der kommt
@Thomas D: Kommt ein Besucher auf meine Website, die von einer dritten Partei (Web Analytics Service Provider) getrackt wird, werden die Cookie immer vom Server der dritten Partei gesetzt. Die JavaScript Tracking Codes befinden sich natürlich auf meinen Seiten.
Der Trick beim FirstParty Cookie Tracking ist, dass ich auf dem Tracking Server beim Web Analytics Service Provider den CNAME meiner Subdomain eintragen lassen kann. Das Zählpixel wird dann von einem Server der unter meiner Subdomain angemeldet ist ausgeliefert und stammt somit von der ersten Partei.
Der IE7 blockt in der standard Einstellung übrigens nur ThirdPartyCookies, die ohne P3P Datenschutzrichtline daher kommen, was nur selten der Fall ist.
Die ganze Diskussion um FPC ist also gar nicht so wild!?
Was sagen denn die Web Analytics Service Provider dazu? Warum empfehlen die Toolhersteller denn FPC?
@Michael Roth: Ich stimme Dir vollkommen zu, dass die Diskussion gar nicht so wild ist. Auch mit TPC kann man sehr gut leben und analysieren. Ich glaube First Party Cookies haben sich zu einem Buzzword entwickelt, welches gerne von Leuten abgefragt wird, die nicht so einen tiefen technischen Background haben.
Trotzdem halte ich FPC für eine einzelne Domain für die beste Lösung, da die Implementierung dadurch auch nicht komplizierter wird.
Erst bei mehreren Domaind und komplexen Systemlandschaften macht die Diskussion aus meiner Sicht überhaupt Sinn.
Patrick, das sehe ich ganz genauso!
Das FPC Thema ist ja vor einiger Zeit von bestimmten Anbietern auch zu Marketingzwecken gepuscht worden. Es gab ja dann in den communities auch viele Diskussionen.
Am Ende funktioniert doch fast das gesamte Onlinemarketing noch immer mit ThirdPartyCookies. Ich habe einige Migrationen von TPC zu FPC durchgeführt. So viel bringt es wirklich nicht.
Du hast aber recht: FPC ist für einzelne Domains die beste Lösung (…auch eine kleine Verbesserungen ist eine Optimierung
. Solange man keine SSL Seiten hat ist das sowieso keine Frage. Mit SSL hat man wegen des Zertifikates etwas mehr Formalitäten bei der FPC Implementierung zu beachten. Aber auch das ist bei entsprechend zeitlicher Planung ja kein Problem.
Beim Crossdomaintracking funktioniert das FPC Tracking eben nicht mehr so einfach. Wer würde sich schon nur wegen FPC für eine Logfilelösung entscheiden oder gar jeden link anfassen…