Der Einfluss von Intelligent Tracking Prevention (ITP) auf A/B-Tests, und wie die Einschränkungen vermieden werden können
Können Marketeers ihrem A/B-Testing-Tool heute noch trauen?
Vor kurzem hat Apple sein neuestes Intelligent Tracking Prevention veröffentlicht. Das wirft Fragen bzgl. der Zuverlässigkeit von gängigen Methoden der Conversion-Optimierung auf.
Wir bei Kameleoon sind überrascht, dass ITP nicht für mehr Wirbel in der Welt des digitalen Marketings gesorgt hat. Dieses eher technische Thema nimmt schließlich einen enormen Einfluss auf die Arbeit von Marketing-Teams, die mit A/B-Testing arbeiten.
Um mehr über ITP zu erfahren, haben wir uns an unseren CTO Jean-Noël Rivasseau gewandt. Gerade die neueste 2.1-Version führt drastische Einschränkungen bei Browser-Betrieb und JavaScript-Apps (insbesondere Cookies) ein.
ITP ist nativ in Safari integriert, und obwohl dieser Browser relativ selten auf Desktop anzutreffen ist, liegt sein Marktanteil auf mobilen Endgeräten bei 40 bis 50%. Das bedeutet, dass fast die Hälfte des Traffics potenziell von ITP betroffen ist.
Hier die großen Punkte, die Jean-Noël für uns hervorgehoben hat:
- Merkmale von ITP 2.1
- Sein Einfluss auf A/B-Testing-Tools
- Kameloons Lösung des Problems
1 Was ist Intelligent Tracking Prevention?
Apples ITP dient dem verbesserten Schutz der Privatsphäre der User. Es blockiert Versuche von Webseiten und Scripts, Besucher ohne ihr Einverständnis zu verfolgen. ITP ist auf allen Safari-Browsern installiert.
Die neueste Version, ITP 2.1, enthält neue weitreichende Einschränkungen für Web Analytics Software mit JavaScript. Vereinfacht gesagt bedeutet das, dass JavaScript-Cookies (die bereits vor ITP 2.1 nicht voll zuverlässig waren, weil sie manuell gelöscht werden können) ihren Nutzen komplett verlieren.
Die vorigen ITP-Versionen zielten hauptsächlich auf Online-Werbung ab. ITP 2.1 dagegen wirkt sich auch auf Web Analytics-Software wie Google Analytics und A/B-Testing-Tools aus.
Wie das funktioniert? ITP verkürzt die Lebensdauer von JavaScript-Cookies auf nur 7 Tage. Auf Apples Webkit-Blog wird das deutlich ausgesprochen: „Mit ITP 2.1 wird die Gültigkeit aller Client-document.cookie erstellten Cookies auf 7 Tage gekappt“.
Diese Begrenzung ist eine sehr aggressive Vorgehensweise. Fast alle Web Analytics-Plattformen (Google Analytics eingeschlossen) basieren derzeit auf dem Duo JavaScript/Front End und nutzen Cookies zur Speicherung des Unique Identifiers des Besuchers.
Dieser Identifier wird normalerweise per Zufallsfaktor beim ersten Besuch der ersten Seite generiert. Er wird dann für alle besuchten Seiten und folgenden Besuche weiterbenutzt, um diesen bestimmten Besucher verfolgen zu können. So erkennt Google Analytics z.B. ob es sich um einen neuen oder wiederkehrenden Besucher handelt, je nachdem, ob bereits ein Cookie vorhanden ist.
Die eingeschränkte Gültigkeit der Cookies auf Safari bleibt weit hinter der von Google Analytics definierten Lebensdauer zurück. Konkret heißt das, dass ein Besucher, der am Montag eine Webseite besucht hat und am folgenden Dienstag zurückkehrt als neuer Besucher identifiziert wird.
Der erneute Besuch wird nicht mit dem vorigen in Verbindung gesetzt. Der Indikator „Neuer Besucher“ hat somit für Safari-Nutzer erheblich an Vertrauenswürdigkeit verloren - und nicht nur er. Auch Faktoren wie „Unique Visitors“, „auf der Webseite verbrachte Zeit vor einem Kauf“ usw. werden verfälscht. Sie sehen: Web Analytics Daten insgesamt sind mit weit größerer Vorsicht zu genießen.
2 Welchen Einfluss nimmt ITP 2.1 auf A/B-Testing-Tools?
Die meisten Conversion-Optimierungs-Plattformen integrieren Web Analytics in ihr Tool. Das heißt, dass sie den gleichen Problemen ausgesetzt sind, was für sich schon schlimm genug ist. Für A/B-Tests gibt es aber ein noch schwerwiegenderes Hindernis.
Jeder Besucher, der an einem Test teilnimmt, sieht eine für ihn gewählte Variante. Diese Variante wird gespeichert, damit er bei einem folgenden Besuch die gleiche Version sieht. Alle Front End Testing-Tools speichern diese Information in einem Cookie.
Mit ITP besteht die Gefahr, dass ein nach über einer Woche wiederkehrender Besucher eine andere Variante der Webseite sieht. Unter diesen Bedingungen verlieren Test-Ergebnisse stark an Bedeutung.
Um dieses Problem zu lösen, können Anbieter versucht sein, Cookies nicht mit JavaScript zu erstellen, sondern diese auf dem Server über einen http-header zu speichern. Dafür muss man allerdings auf den Code im Backend zurückgreifen, was die Umsetzung erschwert und keine wirkliche Lösung darstellt, wenn man weiß, dass der Erfolg von Testing-Tools weitgehend auf ihrer einfachen Handhabung beruht: Eine JavaScript-Datei wird in den HTML-Quellcode, oder noch einfacher, über ein Tag-Management-System integriert.
Wenn der Kunde komplizierte Aktionen durchführen muss, um die Lösung einzurichten oder stabil zu halten, kann er vorziehen, keinerlei Tool zu nutzen. Http-Header sind also keine wirklich wegbare Lösung des Problems für Web Analytics-Anbieter.
3 Warum ist Kameleoon als einzige Conversion-Optimierungs-Plattform in der Lage, Apples ITP automatisch und transparent zu bewältigen?
Die Antwort ist Kameleoons Cross Domain Local Storage.
Local Storage wird heute von fast allen Browsern akzeptiert. Es handelt sich um Speicherplatz im Browser, der die gleichen Möglichkeiten der Datenverwaltung wie ein Cookie bietet.
Local Storage hat alle Merkmale, um Cookies zu ersetzen. Und ITP 2.1 macht keinerlei Einschränkungen auf dieser Ebene. So sind mehrere Testing-Plattformen bereits von Cookies auf Local Storage umgestiegen. Einen großen Nachteil hat diese Methode allerdings: Die Speicherung ist auf eine spezifische Subdomain beschränkt.
Das liegt am Aufteilungssystem der Subdomains und an den genutzten Protokollen. Im Gegensatz zu Cookies, bei denen der auf http://www.beispiel.com ausgeführte JavaScript-Code *beispiel.com Cookies erstellen kann (was bedeutet, dass Sie den Cookie über kaufen.beispiel.com oder sofort.kaufen.com abrufen können), ist Local Storage nach Subdomains UND Protokollen aufgeteilt.
Wenn Sie Daten im Local Storage der Subdomain http://www.beispiel.com abspeichern, haben Sie weder von http://kaufen.beispiel.com, noch von https://www.beispiel.com Zugriff. Protokoll und Domain müssen strikt identisch sein.
Außer wenn Sie nur eine Webseite und eine einzige Subdomain für die gesamte Webseite haben, bereitet diese Art der Anwendung von Local Storage zahlreiche Probleme.
Diese sind den durch ITP geschaffenen Problemen nicht unähnlich, auch wenn sie andere Gründe haben. Stellen wir uns vor, dass Ihre E-Commerce-Webseite auf https://www.irgendeinshop.com gehostet wird, der Conversion-Prozess aber über https://transaktion.irgendeinshop.com abläuft. Ist die Besucher-ID im Local Storage hinterlegt, zählt Ihre Analytics-Lösung zwei Besucher für einen Kauf, einen auf www.irgendeinshop.com, den anderen auf transaktion.irgendeinshop.com. Die Daten werden nicht von einer Domain auf die andere übernommen und die Lösung würde zwei statt einer Session und einen einzigen Besucher identifizieren.
Für A/B-Tests werden Sie wieder doppelt abgestraft. Wenn Sie einen Test mit zwei Varianten durchführen, in dem die User Journey verändert wird, kann es gut sein, dass der Besucher auf der Haupt-Webseite eine Variante sieht und dann, im Laufe des Conversion-Prozesses, die andere! Das ist nicht nur für die User Experience desaströs, sondern macht Ihren Test schlichtweg unbrauchbar.
Wir sind deshalb einen Schritt weiter gegangen und haben eine komplett cross-domain ausgerichtetete Local Storage Lösung entwickelt. Wir wissen schließlich, dass wenn auch nur ein kleiner Teil ihres Traffics eine Subdomain Ihrer Webseite benutzt, Ihre Testergebnisse weniger vertrauenswürdig oder gar verfälscht sind.
Unser Local Storage-Projekt haben wir bereits 2014 ins Leben gerufen. Damals brauchten wir mehr Speicherplatz im Browser, um die von Kameleoon gesammelten Daten im Front End abzuspeichern.
So können wir unsere Predictive Machine Learning-Algorithmen auch für diese Informationen anwenden. Ja, unsere neuronalen Algorithmen arbeiten direkt im Browser, mit Javascript! Das System funktioniert ausgezeichnet und verdient einen eigenen Artikel.
Mit den ersten Versionen von ITP haben wir unser System leicht anpassen müssen. Komischerweise werden externe Local Storage-Domains in allen ITP-Versionen wie Third Party Daten behandelt, als wären es Cookies. Zuerst haben wir eine iFrame-Datei auf unserer eigenen Domain (Kameleoon) und nicht auf der Domain des Kunden eingerichtet - hauptsächlich, um das Setup zu vereinfachen. Die Local Storage-Daten wurden daher als extern betrachtet und von Safari blockiert. Daraufhin haben wir die Positionierung des iFrame verändert, damit er auf der Domain unseres Kunden gehostet wird.
So sind die negativen Auswirkungen von ITP bei A/B-Tests und Web Analytics ausgeschaltet, und Sie können in Ruhe testen und analysieren. Sie müssen nur sicherstellen, dass Sie über unsere duale Integrationsmethode von JavaScript-Dateien und iFrame verfügen.
Abschließend zwei Bemerkungen:
- Wir garantieren, dass unser eigenes Analytics-System nicht von ITP betroffen ist und alle Traffic-Daten korrekt sind, können dieses Versprechen allerdings nicht auf externe Analytics-Plattformen ausweiten. Die Integrationen mit Partner-Tools funktionieren wie gehabt. Wir empfehlen unseren Kunden in diesem Fall, sich direkt mit ihrem Anbieter in Verbindung zu setzen.
- Unser Server-Side SDKs (und mobilen SDKs) sind nicht von ITP betroffen, da der Tracking-Aufruf für Analytics von Server zu Server gemacht wird, statt über Frontend. Wenn Sie die Schnittstelle Backend/Frontend nutzen, wird ein Cookie eingesetzt, um den kameleoonVisitorCode zu synchronisieren. Der Cookie wird über den Server erstellt (http-Header), statt im Frontend und gilt deshalb als First Party Cookie und ist als solcher nicht von ITP betroffen.
4 Zum Schluss
Wir bei Kameleoon sind sehr stolz auf unsere einfache und effiziente Lösung des ITP 2.1-Problems. Dank dieser Lösung können unsere Kunden weiterhin stabile und relevante A/B-Tests auf mobilen Endgeräten durchführen, ohne wertvolle Zeit mit verschiedenen Anpassungen zu verschwenden, um ITP zu umgehen.
Als Software-Anbieter sehen wir unsere Rolle darin, das Leben unserer Kunden so weit wie möglich zu vereinfachen. Was das hier genannte Beispiel dann auch klar belegt!
Auch in Zukunft werden wir Apples ITP-Technologie genau weiterverfolgen, ebenso wie Initiativen anderer Browser (Firefox nutzt eine ähnliche Technologie, bisher aber mit weniger weitreichenden Auswirkungen). Jede neue Version wird sofort analysiert, damit wir Ihnen so schnell wie möglich eine Lösung bieten können.
Um mehr über die technischen Aspekte von ITP 2.1 und Kameleoons diesbezügliche Lösung zu erfahren, empfehlen wir die Lektüre des entsprechenden Artikels unserer Dokumentation.
