ITP 2.0 – Browser Updates schränken Cookie-Tracking ein

Safari hat für Ende September ein Update angekündigt, welches kanalübergreifend das Setzen von Cookies in einigen Fällen blockiert. Im Juni wurde bereits eine Beta-Version von dem Update veröffentlicht. Vor ein paar Tagen hat Firefox nachgezogen und eine sehr ähnliche Änderung angekündigt, die sogar noch einen Schritt weitergeht und auch Fingerprint-Tracking einschränkt. Wann das Update von Firefox live geht ist zurzeit noch unklar.

Warum gerade jetzt? – die beiden Anbieter sprechen in ihren Statements davon, dass sie ihren Usern einen höheren Datenschutz bieten möchten. Ob das wirklich eine selbstlose Entscheidung war oder ob die neue Datenschutz- und E-Privacy-Verordnung die Anbieter zum Handeln zwingt, kann ich nicht beurteilen.

Das ist der erste Stein, der ins Rollen gebracht wird. Langfristig gesehen, werden wir uns wohl komplett vom Cookie-Tracking verabschieden müssen.

Safari und Firefox haben in Deutschland eine Marktabdeckung von knapp 40% (Statista Stand Mai 2018). Die Statistik unterscheidet nicht nach installierter Browser-Version. Tatsächlich wird die Zahl vermutlich geringer ausfallen. Dennoch sollte jeder Advertiser alarmiert sein und entsprechende Schritte einleiten um die Messbarkeit seiner Marketing-Kanäle nicht zu verlieren.

Spätestens an dieser Stelle habe ich sicherlich Deine Aufmerksamkeit. Daher steigen wir jetzt einmal ganz tief ein und wappnen Dich für alles was zu dem Thema auf Dich zukommt!

Browser Updates

Was für den Safari- und den Firefox-Browser angekündigt ist, fasse ich an dieser Stelle nochmal kurz zusammen.

Safari ITP 2.0

Bei Safari wird bis Ende des Monats das eigene ITP Tracking (ITP Intelligent Tracking Prevention) auf 2.0 geupdatet und auf allen IOS Geräten ausgerollt. Die Änderung kommt mit dem Update IOS 12 und MacOS Mojave, die bereits als Beta Versionen zum Download bereitstehen.

Ziel von ITP 1.0 ist es Tracking Domains zu identifizieren und deren Zugriff auf Cookies einzuschränken.

1. Es soll unterbinden, dass in einem Drittanbieterumfeld unberechtigt Cookies ausgelesen werden können. Die Domain, die das Cookie gesetzt hat ist auch als einziger berechtigt dieses auszulesen – auch in einem Drittanbieterumfeld, in dem kein eigenes Pixel integriert ist.
2. Gleichzeitig wird der Zugriff auf die eigenen 1st-party Cookies auf 24 Stunden beschränkt, bevor sie von Safari gelöscht werden. Am häufigsten verbreitet ist im Affiliate-Marketing eine Cookie Laufzeit von 30 Tagen. Da ohnehin mehr als 90% aller Transaktionen innerhalb von 24h abgeschlossen werden, war das eine Einschränkung die zu vernachlässigen war.

ITP 2.0 ist da deutlich strenger unterwegs.

1. Cookies von Drittanbietern, die ohne die Zustimmung des Users gesetzt werden, sind zukünftig gesperrt und können auch nicht ausgelesen werden. Ein gutes Beispiel dafür sind eingebettete Inhalte von Technologien wie Google Maps. Umgangen werden kann das durch die Storage Access API von Safari (siehe unten).
2. Das 24 Stunden Zeitfenster entfällt. Die eigenen 1st-party Cookies können nicht mehr in einem Drittanbieterumfeld gelesen werden. Die Ausnahme ist, dass auf der Drittanbieterseite ein eigenes Pixel integriert ist, welches das Cookie auslesen kann.
3. Die eigenen 1st-party Cookies werden nach 30 Tagen ohne Interaktion gelöscht.
4. Neu eigeführt wird die sogenannte ‚Protection Against Tracker Collusion‘-Funktion. Mit dieser werden Redirects unterbunden die nur darauf abzielen den User zu tracken und Cookies zu setzen. Diese Funktion verhindert das Löschen oder Lesen von Cookies im Browser eines Benutzers während dieser Tracking-Weiterleitungen.

Storage Access API

Gleichzeitig werden die Advertiser angehalten von Safari einen Code im Shop zu integrieren, der eingebettete Inhalte authentifizierte. Die sogenannte Storage Access API ist wie ein Popup zu verstehen, welches sich vor dem Zugriff auf die eingebetteten Inhalte öffnet und den User nach seiner Cookie Zulassung fragt. Nur mit der Storage Access API von Safari erhält man die Möglichkeit mit Cookies von Drittanbietern zu arbeiten. Andernfalls werden diese blockiert.

Die Storage Access API lässt sich über einen Code-Schnipsel im eigenen Shop integrieren. Weitere Informationen dazu erhält Ihr hier.

3rd-party Cookies im Affiliate-Tracking

Was genau die ganzen Einschränkungen für das Affiliate Tracking bedeutet versuche ich euch an dem folgenden Schaubild zu erklären.

Bei dem Prozess handelt es sich um ein durchschnittliches Cookie-Tracking. Der User klickt auf einen Trackinglink, er wird zum Online Shop weitergeleitet. Im Hintergrund findet ein Redirect zum Netzwerk statt (gestrichelte Linie) wobei das Netzwerk-Cookie gesetzt wird.

1. Es handelt sich dabei um das 1st-party Cookies des Netzwerks. Der User schleift das Cookie in den Online Shop des Advertisers: Das 1st-party Cookies des Netzwerks gelangt in ein Drittanbieterumfeld – das Cookie wird durch ITP 2.0. gelöscht und erreicht nicht einmal mehr den Online-Shop.
2. Optional: Sollte bei dem Prozess noch ein zusätzlicher Redirect zu einem Trackinganbieter führen, der sein Cookie setzen möchte, dann wird diese Weiterleitung zukünftig blockiert.
   Aus der Sicht des Advertisers handelt es sich unter Punkt 1 um ein Drittanbieter- oder auch 3rd-party Cookie. 1st und 3rd ist eine Bezeichnung und dient nur der Unterscheidung zwischen Drittanbieter-Cookies und den eigenen Cookies. Von einem 3rd-party Umfeld spricht man, wenn das 1st-party Cookie des Advertisers durch den User auf eine Drittanbieterseite gelangt – dazu zählt jede Webseite, die nicht dem Advertiser gehört.

Firefox Tracking Protection

Firefox hat schon seit Längerem eine integrierte Tracking Protection. Usern ist es möglich aktiv in den Einstellungen Cookies zu deaktivieren. Mit dem zukünftigen Update sollen 3rd-party Cookies standardmäßig deaktiviert sein. Der umgekehrte Fall also – die User müssen aktiv werden um Drittanbieter Cookies empfangen zu können. Wer kommt schon auf die Idee das zu tun? Außer wenn bestimmte, für den User wichtige Inhalte nur mit aktivierten Cookies einsehbar sind, wie es z.B. bei vielen Online-Zeitungen der Fall ist.

Darüber hinaus will Firefox auch Fingerprint-Tracking einen Riegel vorschieben, indem der Browser den Speicherzugriff von Drittanbietern sperrt. Das Fingerprint-Tracking lebt vom Rendering der Browserinformationen und Einstellungen die den digitalen Fingerabdruck des Users ergeben. Wenn genau auf diese Informationen nicht mehr zugegriffen werden kann, fällt die Trackingmethode weg.

In der Ankündigung geht nicht hervor, ob damit der Fingerprint vom Advertiser und/oder der Fingerprint vom Drittanbieter gemeint ist. Ggf. gibt es an dieser Stelle noch ein Schlupfloch, ähnlich wie beim Cookie-Tracking.

Die Updates clever handeln

Zurzeit gibt es keinen konkreten Lösungsansatz den wir empfehlen können, die beiden Updates können sich für jeden Advertiser anders auswirken. Welches Cookie nun blockiert wird und welches nicht, ist Auslegungssache vom Browser. Gleichzeitig kann sich die Beta-Version auch noch verändern.

Worauf ich hinaus will: Es bringt nichts vor Start der Updates das komplette Tracking umzustellen. Man kann nie wissen wie sich die Änderung auswirkt und an welcher Stelle überhaupt Anpassungsbedarf besteht. Nach dem Update heißt es: Testen, Testen, Testen – werden die Transaktionen über den Safari-Browser noch getrackt? Wie hoch ist der Anteil der nicht getrackten Sales? Lohnt sich dafür der Aufwand das Tracking umzustellen?
Eines ist klar, wenn eine Anpassung vorgenommen werden muss, bedeutet das für den Advertiser einen ziemlich hohen Aufwand.

Problemzonen beim Tracking

Nicht nur das Netzwerk-Cookie kann zukünftig zu Problemen führen. Alle Advertiser die in Ihrem Shop die Trackingweiche eines Drittanbieters verbaut haben müssen damit rechnen, dass es auch hier zu Schwierigkeiten kommen kann. Die technischen Dienstleister nutzen in der Regel ebenfalls Cookies um die User zu markieren und durch den Shop zu verfolgen. Auch hier handelt es sich in den meisten Fällen um 3rd-party Cookies.

Lösungsansatz

1. Netzwerk-Cookies umgehen

Gehen wir vom Worst Case Szenario aus und alle Ankündigungen von Firefox und Safari werden mit voller Stränge umgesetzt: Das 3rd-party Netzwerk-Cookie wird blockiert.

Die Netzwerke haben mehrere Artikel zu dem Thema veröffentlicht, in denen sie konkrete Empfehlungen geben. Diese sind jedoch nur für wenige Advertiser relevant! Mehr dazu lest Ihr hier: Was sagen die Affiliate Netzwerke zu Safari ITP 2.0?

Es gibt eine Lösung die auf Cookie- und Fingerprint-Tracking verzichtet und uns trotzdem ermöglicht, die trackingrelevanten Informationen zum Zählpixel zu transportieren. Auf alle Advertiser, die bisher nicht mit einem serverseitigen Tracking arbeiten, kommt leider ein größerer Aufwand zu.

Was ist eigentlich das serverseitige Tracking? Beim serverseitigen Tracking wird das Zählpixel nicht auf der Dankeseite eingebunden, sondern – Überraschung – auf dem Server des Advertisers. Da das Netzwerk-Cookie nicht auf den Server gelangt, sondern die ganze Zeit im Shop bleibt, muss das Zählpixel aktiv befüllt werden. Das bedeutet, der Advertiser speichert die trackingrelevanten Informationen ab (Beim Cookie-Tracking erhält er die Informationen aus dem Cookie). Sobald der User eine Bestellung abschließt, sendet der Advertiser die trackingrelevanten Informationen an das Zählpixel auf seinem Server und ruft dieses auf – das Tracking wird ausgelöst und die Provision gelangt an das Netzwerk.

Die Alternative zum serverseitigen Tracking ist standardmäßig die Integration auf der Dankeseite des Online-Shops. Hierhin gelangt durch den User auch das Netzwerk-Cookie, sobald dieser eine Bestellung abgeschlossen hat. Zählpixel und Netzwerk-Cookie kommunizieren miteinander, so dass das Zählpixel die Informationen aus dem Cookie automatisch ausliest. Der Advertiser reichert das Pixel noch um Informationen, wie z.B. die Warenkorbhöhe, an und ruft diese auf – das Tracking wird ausgelöst und die Provision gelangt an das Netzwerk.

Wir gehen jetzt mal davon aus, dass der Advertiser bereits das serverseitige Tracking, wie eben beschrieben, im Einsatz hat. Wenn nicht das Cookie die trackingrelevanten Informationen an den Online-Shop übergibt, da es durch den Browser blockiert wird, dann geht das über angehängte Parameter im Deeplink. Die Funktion beherrscht jedes Netzwerk und ist schnell umgesetzt. Hier ein Deeplink am Beispiel von affilinet:

Vorher: https://www.mustershop.de?canal=aff

canal ist in dem Beispiellink der Parameter der beim Advertiser die Cookie-Weiche steuert.

Nachher: https://www.mustershop.de?canal=aff&ref=477171-20000&affmt=2&affmn=2

Die zusätzlichen Parameter die das Netzwerk selbstständig anhängt sind PublisherID, SubID, WerbemittelID und WerbemittelTyp. Die ersten beiden Werte sind trackingrelevant, die anderen notwendig für die Statistiken.

Es gibt darüber hinaus noch zwei weitere Parameter die sich bei Bedarf durch das affilinet Netzwerk anhängen lassen. In meinem Beispiel habe ich nur die relevanten aufgeführt. Darüber hinaus gibt es noch den Timestamp des Klicks und die Kanalgruppe. Letzteres kann auch über die PublisherID im Netzwerk gematcht werden.

2. Trackingrelevante Informationen speichern

Wir sind soweit, dass der User die trackingrelevanten Informationen angehängt an den Deeplink in den Online-Shop führt. An dieser Stelle ist der Advertiser oder der technische Dienstleister gefragt, der die Weiche stellt. Die Informationen aus den Parametern müssen auf der Einstiegsseite des Users ausgelesen und abgespeichert werden. Das bedeutet, auf allen Haupt- und Unterseiten muss der Advertiser darauf vorbereitet sein, die Parameter zu erfassen.

Der Advertiser kann die Informationen in einem eigenen 1st-party Cookie speichern und auf der Dankeseite durch die Weiche auslesen lassen. Wenn ein technischer Dienstleister die Weiche verwaltet (Drittanbieter) hätten wir an dieser Stelle einen Konflikt – wie gelernt, handelt es sich dann um ein 3rd-party Cookie, welches durch Firefox und Safari blockiert wird und nicht im Browser des Users gespeichert werden kann.

3. Einschränkungen der Cookie-Weiche umgehen

Auch der technische Dienstleister der für die Weiche zuständig ist, kann sich auf die Einschränkungen durch Safari einstellen.

Ein ähnliches Prinzip hat sich Google gerade zunutze gemacht. Für das Markieren der User im Online-Shop für z.B. Remarketing Maßnahmen werden ebenfalls Cookies gesetzt. Wie bereits oben geschrieben, kann nur die Domain das Cookie auslesen die es auch gesetzt hat. Bei Google unterscheiden sich die beiden Domains und wir hätten an dieser Stelle wieder einen Konflikt. Google hat dafür ein neues Tag programmiert (Global Tag) welches den Google-Tag Manager auf der Seite des Advertisers ersetzt. Dadurch werden die Domain die das Cookie setzt und die Domain die das Cookie ausliest, identisch.

Damit hat Google sehr schnell auf die angekündigten Änderungen reagiert. Für die technischen Dienstleister ist das jedoch nicht ganz so einfach, da hier die Ressource und ggf. auch die Expertise nicht an einen Konzern wie Google heranreicht. So eine Lösung zu programmieren kostet daher Geld und Zeit. Steht dann schlussendlich der neue Code, muss der Advertiser diesen sehr kleinteilig und aufwändig überall ergänzen – was wie bei jeder manuellen Aufgabe, natürlich zu Fehlern führen kann.

Fazit

Zum Update von Firefox und Safari lässt sich abschließend sagen, auch wenn die angekündigte Blockade von 3rd-party Cookies in den nächsten Monaten verschärft wird, können wir das Tracking mit einer weiterhin hohen Zuverlässigkeit anpassen. Das bedarf jedoch technische Ressource und Aufwand sowohl beim Advertiser als auch beim technischen Dienstleister der die Weiche stellt.

Sollten wir zukünftig komplett auf Cookies verzichten müssen sieht die Situation wiederum ganz anders aus: Ohne Cookie oder Fingerprint-Tracking wird es zukünftig deutlich erschwert die Customer Journey der User zu messen. Das klappt nur noch bei Bestandskunden die dauerhaft eingeloggt sind. Hier lässt sich der User über das Login identifizieren. Wie das Affiliate Marketing ohne Cookie- oder Fingerprint-Tracking aussehen kann, lest Ihr hier: Worst Case: Cookies sind Geschichte