Zum Hauptinhalt springen
Apples Intelligent Tracking Prevention (ITP) ist eine Technologie, die die Privatsphaere der Nutzer erhoehen soll, indem sie unerwuenschtes Tracking durch Websites und die darauf installierten Skripte verhindert. Sie kommt in allen Safari-Browsern zum Einsatz, einschliesslich auf Desktop-Computern (Macintosh) und allen iOS-Geraeten (iPhone und iPad). ITP bringt erhebliche Einschraenkungen fuer die Operationen mit sich, die JavaScript-basierte Software durchfuehren kann. Waehrend ITP vor allem auf Online-Werbesysteme abzielt, sind die neuesten Versionen wesentlich aggressiver und wirken sich erheblich auf Webanalyse-Software wie Google Analytics aus. ITP wirkt sich auch erheblich auf A/B-Test-Tools aus. Kameleoon kann auch mit ITP-aktivierten Apple-Geraeten voll funktionsfaehig sein. Sie muessen jedoch einen kleinen Abschnitt Synchronisationscode auf Ihren Backend-Servern einfuegen. Dieser Artikel erlaeutert die technischen Einschraenkungen und Folgen von ITP fuer Experimentation und Analytik.
  • Technische Einschraenkungen durch ITP.
  • Folgen fuer Web Analytics und Conversion-Optimierungsmassnahmen.
  • Von Kameleoon empfohlene Loesung, um ITP-Probleme zu vermeiden.

​
Technische Einschraenkungen durch ITP​

Intelligent Tracking Prevention implementiert erhebliche Einschraenkungen rund um die Verwendung von Cookies und anderem clientseitigen Speicher (wie lokalem Speicher). Es ist wichtig, einige zentrale Eigenschaften von Cookies zu verstehen. Cookies sind (sehr) kleine Datenstuecke, die eine Website im Browser eines Besuchers speichert. Sehr oft handelt es sich dabei um eindeutige, zufaellig generierte Bezeichner. Jedes Cookie ist an eine Domain gebunden (z. B. www.example.com) und hat ein Ablaufdatum. Jedes Mal, wenn ein Serveraufruf an eine Domain erfolgt, die mit einem oder mehreren auf Ihrem Computer gespeicherten Cookies verbunden ist, werden die in diesen Cookies enthaltenen Daten automatisch und transparent an den Webserver dieser Domain gesendet. Folglich werden bei den meisten Webanfragen staendig Cookies hinzugefuegt, mit zwei unmittelbaren Folgen:
  • Die Groesse der Webanfragen nimmt zu, was Ihre Surfgeschwindigkeit verlangsamt.
  • Ihr Browser uebertraegt Daten ohne Ihre ausdrueckliche Zustimmung an entfernte Server, sodass Sie identifiziert und verfolgt werden koennen.
Da Cookies in der Regel recht klein sind, ist das erste Problem im Allgemeinen nicht so bedeutend. Das zweite hat jedoch weitreichendere Folgen und ist fuer Datenschutzbefuerworter von grosser Bedeutung. Die Verwendung von Cookies ist ein komplexes Thema, da Cookies im Web fuer viele verschiedene Zwecke eingesetzt werden. Viele davon sind aufgrund des zustandslosen Charakters des HTTP-Protokolls fuer den grundlegenden Betrieb von Websites erforderlich. Zum Beispiel verlassen sich E-Commerce-Transaktionen in der Regel darauf. Mit ITP moechte Apple die “nuetzlichen” Cookies (jene, die fuer den normalen Betrieb einer bestimmten Website notwendig sind) von den “schlechten” trennen (jenen, die mit Werbung, Tracking und Datenschutzverletzungen verbunden sind). Websites koennen Cookies mit zwei verschiedenen Mechanismen setzen:
  • Wenn ein Aufruf an einen Webserver erfolgt, setzt der Server das Cookie, indem er einen HTTP-Header in der HTTP-Antwort hinzufuegt.
  • Mit JavaScript-Code auf dem Client.
Die zugehoerige Domain des Cookies haengt von der verwendeten Methode ab. Bei Server-Cookies ist es die Domain, an die der Serveraufruf gesendet wurde. Bei clientseitigen JavaScript-Cookies ist die Domain eine der Seiten, von denen aus der JavaScript-Code ausgefuehrt wird (nicht unbedingt die Host-Domain der JavaScript-Datei). Drittanbieter-Cookies beziehen sich auf Cookies, die an eine andere Domain als die aktuell angezeigte Webseite gesendet werden. Wenn Sie zum Beispiel www.randomshop.com durchstoebern, diese Website jedoch einen Aufruf an tracking.ad-system.com macht, koennen Cookies, die mit www.ad-system.com verbunden sind, zusammen mit der HTTP-Abfrage gesendet werden. Sie werden im Kontext Ihrer aktuellen Browsersitzung auf www.randomshop.com als Drittanbieter-Cookies betrachtet. Wenn ein Cookie ablaeuft, loescht der Browser es vollstaendig. Da jedoch die Entitaet, die das Cookie erstellt, das Ablaufdatum waehlt, kann es weit in der Zukunft liegen (z. B. 10 Jahre oder mehr). Diese Dauer stellt sicher, dass es weit ueber das hinaus existiert, was fuer den normalen Betrieb der urspruenglichen Website notwendig ist. Diese Praxis aendert sich mit ITP. Dies sind die beiden Hauptbeschraenkungen, die ITP 2.3 auferlegt:
  • In allen ITP-Versionen sind Drittanbieter-Cookies stark eingeschraenkt. Drittanbieter-Cookies werden von Safari 24 Stunden nach dem Setzen im Browser blockiert. Technisch gesehen werden sie nicht geloescht, sondern nicht mehr automatisch ueber HTTP-Anfragen an den Drittanbieter-Server gesendet. Im vorherigen Beispiel erhaelt ein Besucher, der www.randomshop.com aufruft, bei seinem ersten Besuch ein Cookie von www.ad-system.com ueber einen HTTP-Aufruf an diesen Server. Kehrt der Besucher mehr als 24 Stunden spaeter zurueck, erhaelt die naechste HTTP-Anfrage an www.ad-system.com die urspruenglichen Cookie-Daten nicht.
  • Ab Version 2.3 laeuft jeglicher clientseitige Speicher (JavaScript-basierte Cookies und LocalStorage) nach 7 Tagen ab!
Da Webanalyse- und A/B-Test-Software in der Regel nicht auf Drittanbieter-Cookies setzt, betrifft die erste Einschraenkung hauptsaechlich Werbesysteme. Der Rest dieses Artikels konzentriert sich auf die zweite Einschraenkung.

​
Folgen der Einschraenkungen des clientseitigen Speichers​

Die Begrenzung JavaScript-basierter Cookies auf eine Ablaufzeit von 7 Tagen ist sehr aggressiv. Nahezu alle Webanalyse-Plattformen (einschliesslich Google Analytics) sind JavaScript- oder Frontend-basiert und verwenden alle ein Cookie, um den eindeutigen Bezeichner des Besuchers zu speichern. Dieser Bezeichner wird beim ersten Seitenaufruf des ersten Besuchs des Besuchers auf Ihrer Website zufaellig generiert. Bei nachfolgenden Seitenaufrufen und Besuchen wird der Bezeichner aus dem Cookie wiederverwendet, um den Besucher zu identifizieren. So kann Analyse-Software zwischen einem neuen Besucher (ein neues Cookie wird generiert) und einem wiederkehrenden Besucher (ein zuvor gesetztes Cookie wurde gefunden) unterscheiden. Da Safari die Lebensdauer des Cookies auf 7 Tage reduziert, wird ein Besucher, der einen ersten Besuch am Montag macht und in der folgenden Woche am Dienstag zurueckkehrt, als voellig neuer Besucher betrachtet. Mit anderen Worten, die Daten des neuen Besuchs werden nicht mit dem vorherigen Besuch verknuepft. Infolgedessen sind Ihre neuer Besucher-Metriken in der Analyse-Software fuer Ihren Safari-Traffic nicht mehr verlaesslich. Viele, viele andere Metriken koennen ebenfalls verzerrt sein (Anzahl der eindeutigen Besucher, Zeit bis zum Kauf usw.). Es ist schwierig, irgendeiner Zahl noch zu vertrauen, die von Cookie-basierten Analyseloesungen erzeugt wird. Fuer Desktop-Websites koennte dies als geringfuegiges Aergernis angesehen werden, da der Desktop-Marktanteil von Apples Safari relativ gering ist (generell zwischen 5 % und 10 %). Bei mobilen Websites mit hohem Traffic liegt der Marktanteil von iOS-Geraeten jedoch oft im Bereich von 40-50 %. Dieser Marktanteil bedeutet, dass fast die Haelfte Ihres Traffics betroffen sein kann! Die Mehrheit der Test- und Conversion-Optimierungs-Plattformen integriert ihre Webanalyse-Funktionen. Diese leiden unter denselben Problemen, was an sich schon problematisch ist. Fuer A/B-Experimente entsteht jedoch ein noch ernsteres Hindernis. Jedes Mal, wenn ein Besucher in ein Experiment einsortiert wird, waehlt die Test-Software eine Variation fuer den Besucher aus. Diese Variation muss genau gespeichert werden, denn wenn der Besucher zurueckkommt, muss er die gleiche Variation sehen wie zuvor. Alle Frontend-Test-Loesungen speichern diese Information (die Verknuepfung zwischen Experiment und Variation) in einem Cookie. Mit ITP riskiert ein Besucher, der mehr als 7 Tage nach dem urspruenglichen Ausloesen eines Experiments zurueckkehrt, eine andere Variation zu sehen. Unter diesen Bedingungen liefern A/B-Tests keine verlaesslichen Ergebnisse. Weitere technische Details finden Sie in diesem Blogbeitrag ueber ITP und seine Auswirkungen auf Webanalyse. Der Artikel enthaelt auch eine Liste von Workarounds fuer die ITP-Herausforderung, die im naechsten Abschnitt behandelt wird.

​
Loesungen fuer Kameleoon​

Die erste Umgehungsloesung, die Kameleoon implementiert hat, bestand darin, wichtige Informationen wie Variationszuweisungen im LocalStorage statt in Cookies zu speichern. Tatsaechlich ist die Verwendung von LocalStorage anstelle von Cookies in Kameleoon aelter als ITP, da LocalStorage gegenueber Cookies mehrere Vorteile hat. Ein Vorteil ist, dass per JavaScript gesetzte Cookies bereits vor ITP nicht vollkommen vertrauenswuerdig waren, weil Nutzer sie manuell loeschen konnten. Stattdessen LocalStorage zu verwenden, funktionierte zunaechst; die neueste Version von ITP behandelt LocalStorage jedoch wie ein Cookie, und Eintraege laufen nach 7 Tagen ab. Infolgedessen garantiert diese Methode keine zuverlaessigen A/B-Tests und Personalisierungen mehr auf Safari. Die von Kameleoon empfohlene Loesung besteht darin, das Cookie kameleoonVisitorCode, das den wichtigen visitorCode-Bezeichner enthaelt, mit einem HTTP-Header serverseitig zu setzen, anstatt nur browserseitig mit JavaScript. ITP legt keine Einschraenkungen fuer Cookies fest, die von Servern gesetzt werden, sodass dieses Cookie ein ausreichend langes Ablaufdatum haben kann. Mit dieser Methode synchronisiert das System dieses Cookie zwischen Frontend und Backend, und die Lebensdauer des Cookies ist nicht mehr durch ITP begrenzt. Sobald Kameleoon auf Safari den visitorCode durch Lesen des serverseitig gesetzten Cookies kameleoonVisitorCode erhaelt, prueft es, ob der aktuelle LocalStorage leer ist. Wenn er leer ist, lag der letzte Besuch des Besuchers wahrscheinlich mehr als 7 Tage zurueck. Kameleoon fuehrt einen Server Synchronization Call (SSC) durch, um alle Daten abzurufen, die im LocalStorage vorhanden waren, von Backend-Servern. Sobald dieser Aufruf abgeschlossen ist, werden die Daten in ihrem vorherigen Zustand wiederhergestellt. Normale Operationen koennen dann fortgesetzt werden. Obwohl der Analyse-Kern von ITP unberuehrt bleibt und die gemeldeten Traffic-Daten zuverlaessig sind, kann Kameleoon dies fuer Webanalyse-Plattformen von Drittanbietern nicht garantieren. Integrations-Bruecken mit Partner-Tools funktionieren weiterhin auf die gleiche Weise. Besprechen Sie die Situation mit dem Anbieter der gewaehlten Analyseloesung.

​
Fazit​

Mit der in diesem Artikel beschriebenen Loesung koennen Sie weiterhin zuverlaessige AB-Experimente mit der Safari-Nutzerbasis durchfuehren. Kameleoon stellt einen empfohlenen Workaround bereit und ermutigt zur Umsetzung, anstatt Safari aus der Testbasis auszuschliessen. Weitere Aenderungen an ITP sind zu erwarten, da Apple weiter daran arbeitet, die Privatsphaere der Nutzer zu schuetzen. Kameleoon beobachtet die Entwicklung der ITP-Technologie von Apple und aehnlicher Initiativen anderer Browser-Anbieter kontinuierlich. So verfuegt Firefox beispielsweise ueber eine aehnliche Loesung wie ITP, die jedoch noch nicht so strikt ist. Alle bahnbrechenden Aenderungen werden analysiert und Loesungen werden kommuniziert.