Apple hat sich über die Jahre einen Ruf als Pionier für Tech-Innovationen aufgebaut. Der Innovator im Bereich Smartphones, Computer und mehr räumt dem Thema Datenschutz oberste Priorität ein.
Seit Safari unter iOS 11 und MacOS 10.13 ist die sogenannte Intelligent Tracking Prevention für Millionen von Apple-Usern standardmäßig aktiviert. Dadurch hebt Apple den Schutz der Kundendaten auf das nächste Level an.
Mittlerweile liegt das Datenschutz-Feature bereits in Version 2.3 vor.
Was ist die Intelligent Tracking Prevention?
Die Intelligent Tracking Prevention (ITP) ist eine Funktion von WebKit, einer Open Source-Browser-Engine, die Apples Webbrowser, Safari und andere Browser antreibt. Das Feature hat zum Ziel, durch einen neuen Ansatz zum Umgang mit First Party-Cookies den Datenschutz der User von Safari weiter zu stärken und unerwünschtes Tracking zu verhindern.
Warum Intelligent Tracking Prevention?
Vor dem Einzug der Intelligent Tracking Prevention in den Safari-Browser wurden Third Party-Cookies standardmäßig blockiert. Zudem ist es für die User von Safari auf iOS und MacOS möglich, mittels einer Browser-Erweiterung beliebige Content-Blocker oder AdBlocker zu installieren.
First Party-Cookies galten bisher immer als sicher davor, automatisch blockiert oder entfernt zu werden. Sie sind notwendig, um eine nahtlose User Experience zu gewährleisten. First Party-Cookies werden etwa dafür genutzt, Session-Daten verfügbar zu halten. So speichern Sie Informationen wie:
- Login-Status, um sicherzustellen, dass User in Websites oder Apps eingeloggt bleiben
- Welche Produkte User dem Warenkorb hinzufügen
- Website-Einstellungen wie z. B. die Sprache
- Daten, die User in Formulare eintragen (Name, E-Mail, Firma etc.)
Einige First Party-Cookies können Sie verwenden, um User genauso zu tracken wie mit Third Party-Cookies. Um genau diese Cookies kümmert sich die Intelligent Tracking Prevention.
Details zu Cookies und die genauen Unterschiede zwischen First Party- und Third Party-Cookies finden Sie in diesen Artikeln:
First Party-Cookies als Tracking-Cookies
Es gibt bestimmte Szenarien, in denen First Party-Cookies als Tracking-Cookies verwendet werden können. Schauen wir uns anhand eines Beispiels an, wie ein User mit Hilfe eines First Party-Cookies durch das Internet getrackt werden kann, während er einen mobilen oder einen Desktop-Browser nutzt.
Beispielszenario – Ein User klickt auf eine Werbeanzeige
In diesem Beispiel schauen wir uns an, wie der Prozess in Safari abläuft. In anderen Browsern ist der Prozess vergleichbar, abhängig davon, wie First- und Third Party-Cookies verarbeitet werden.
- Der User besucht eine Website. Die Website erzeugt einen Cookie (xyz890) in ihrer Domain (example.com) und ordnet ihn dem User zu.
- Der User klickt anschließend auf eine Werbeanzeige. Er wird zur Domain der AdTech-Plattform (ad.ads-r-us.com) geleitet.
- Die AdTech-Platform erzeugt einen First Party-Cookie (klm456) unter ihrer Domain und ordnet ihn dem User zu.
- Dann leitet die AdTech-Plattform den Browser weiter auf die Landingpage des Werbetreibenden (www.usedcarsite.com).
Wichtig ist an dieser Stelle der Grund, warum die AdTech-Plattform einen First Party-Cookie erzeugt. Das liegt daran, dass der User auf die Werbung geklickt hat und anschließend zur Domain der AdTech-Plattform weitergeleitet wurde. Hätte der User nicht auf die Anzeige geklickt, hätte die AdTech-Plattform weder ein First- noch ein Third Party-Cookie erzeugen können, da Safari letztere standardmäßig blockiert.
Weil die AdTech-Plattform jedoch ein First Party-Cookie erzeugen und dem User zuweisen konnte, kann sie ihn auch tracken, während er sich im Internet bewegt, und personalisierte Werbung einblenden.
Doch diese Möglichkeit des Trackings mit First Party-Cookies ist durch die Intelligent Tracking Prevention nicht mehr ganz so verlässlich.
So funktioniert die Intelligent Tracking Prevention
Wir haben die Funktionsweise der ITP für Sie zusammengefasst:
- Intelligent Tracking Prevention nutzt ein Machine Learning-Modell (bekannt als Machine Learning Classifier), um festzustellen, welche privat kontrollierten Domains in der Lage sind, User über verschiedene Websites zu tracken. Das Modell basiert auf Statistiken, die vom Browser gesammelt werden.
- Wenn der Machine Learning Classifier feststellt, dass ein bestimmter First Party-Cookie (z. B. ad.ads-r-us.com) für Tracking verwendet werden kann, wird der Cookie blockiert. Ausnahme: die Storage Access API wird genutzt, um den Consent des Users für die Speicherung der Cookies einzuholen (mehr dazu weiter unten).
Wie erwähnt, ist 2.3 die aktuelle Version der Intelligent Tracking Prevention. Bevor wir auf die neueste Version eingehen, schauen wir uns aber zunächst die vorigen Versionen 1.0 und 1.1 an.
Intelligent Tracking Prevention 1.0 und 1.1
Anhand von drei verschiedenen Szenarien beschreiben wir die Funktionen der ersten beiden ITP Versionen:
Szenario 1
In den Versionen 1.0 und 1.1 der Intelligent Tracking Prevention gab es eine Funktion, die es First Party-Trackern erlaubt hat, sich wie Third Party-Tracker zu verhalten, wenn der User die Website innerhalb von 24 Stunden besucht.
Ein User besucht eine Website (example.com) und klickt auf eine Werbeanzeige. Die AdTech-Plattform (ads-r-us), die die Anzeige einblendet, erstellt für diesen User ein First Party-Cookie. Wenn der Nutzer innerhalb von 24 Stunden nach dem Klick auf die Werbung ads-r-us.com besucht, kann der First Party-Cookie von ads-r-us.com als Third-Party-Tracker fungieren.
Die Marketer können dann den Cookie für andere Kontexte wie Retargeting verwenden.
Allerdings ist ein solches Szenario relativ unwahrscheinlich, weil der User aktiv die Website der AdTech-Plattform besuchen müsste. Eine solche Aktion fuhren jedoch die User kaum durch. Natürlich sieht das Ganze bei den großen Werbeunternehmen wie Google, Facebook und Amazon etwas anders aus, wie sie später in diesem Artikel erfahren.
In der Intelligent Tracking Prevention 2.0 (seit MacOS 10.14 und iOS 12) gibt es dieses 24-Stunden-Zeitfenster allerdings nicht mehr. Das heißt, Sie nutzen einen Cookie, um User zu tracken, nur nach ihrer Einwilligung via Storage Access API.
Szenario 2
Der User besucht ads-r-us.com nicht innerhalb von 24 Stunden nach dem Klick auf die Werbeanzeige, sondern erst drei Tage später.
In diesem Fall kann der von ads-r-us.com erstellte Cookie nicht zum Tracken verwendet werden, weil die 24 Stunden abgelaufen sind. Sie können den Cookie also nicht für Retargeting-Zwecke und die Einblendung entsprechender Ads nutzen. Auch in diesem Szenario ist die einzige Möglichkeit, den Consent des Users über die Storage Access API einzuholen.
Szenario 3
Der User besucht ads-r-us.com überhaupt nicht – zumindest nicht innerhalb von 30 Tagen.
In diesem Fall wird der von ads-r-us.com erstellte First Party-Cookie nach 30 Tagen gelöscht.
Seit der Intelligent Tracking Prevention 2.0 steuert die Storage Access API das Löschen, die 30-Tage-Frist gilt aber weiterhin.
Intelligent Tracking Prevention 2.0
Die Einführung der ITP 2.0 Mitte 2018 brachte weitere Features mit, die sich massiv auf Reporting, Affiliate Marketing und Attributions-Techniken auswirken.
Kein 24-Stunden-Zeitfenster mehr
Wie bereits erwähnt, erlaubten die ITP 1.0 und 1.1 innerhalb der 24-Stunden-Frist das Lesen und Verwenden von Cookies im gleichen Kontext wie für Third Party-Cookies.
Die ITP 2.0 ermöglicht es nicht mehr.
Websites können in Safari keine Cookies mehr im Browser des Users für spätere Retargeting- und Attributions-Zwecke speichern. Dies wirkt sich auf Unternehmen aus, die ihre First Party-Cookies in der Funktion eines Third Party-Cookies verwenden. Gleichzeitig schränkte die Intelligent Tracking Prevention 2.0 die Möglichkeiten und die Genauigkeit beim Reporting ein.
Consent-Popup via Storage Access API
Eine weitere bedeutende Aktualisierung der Intelligent Tracking Prevention betrifft die Storage Access API.
Unternehmen, wie Facebook ermöglichen es ihren Usern in der Regel, sich auf mehreren Websites in ihr Konto einzuloggen, um das Teilen, Kommentieren und Liken von Inhalten auf Third Party-Seiten zu vereinfachen. Die ITP 2.0 erkennt nun ein solches Website-übergreifendes Tracking und verteilt die entsprechenden Cookies auf mehrere Dateien. Dadurch ist das Tracken nur noch eingeschränkt möglich.
Widgets wie Facebooks Like- und Share-Buttons, die auf Websites eingebettet sind, müssen nun durch ein Consent-Popup eine Einwilligung für den Zugriff auf First Party-Cookies einholen.
Die Grafik zeigt die Funktionsweise:
Dieses Consent-Popup zeigt dem User jede Website an, auf der er mit einem Facebook-Widget interagieren möchte.Subdomains sind allerdings nicht davon betroffen. Das bedeutet, eine Facebook-Interaktion auf der Seite video.exmple.com zeigt das Pop-Up nicht an, wenn der Seite example.com bereits die Einwilligung des Users durch vorige Interaktion vorliegt.
Wenn der User dann allerdings für mehr als 30 Tage nicht mehr mit einem Facebook-Widget interagiert oder facebook.com besucht, wird der Cookie gelöscht.
Wenn Sie mehr zum Thema Consent wissen möchten, empfehlen wir unseren Artikel: Was ist ein Consent Manager und warum Sie einen brauchen
Schutz gegen First Party-Bounce-Tracker
Die Intelligent Tracking Prevention 2.0 kann Websites erkennen, die ausschließlich als First Party-Bounce-Tracker genutzt werden. Das bedeutet, die Website bietet keinen Content, sondern trackt den User durch eine Reihe von schnellen und aufeinander folgenden Weiterleitungen.
Wenn ein User auf einen Link auf einer Social Media-Website klickt, leitet der First Party-Bounce-Tracker den User nicht direkt dorthin, sondern öffnet eine Reihe an Bounce-Trackern.
Diese Tracker-Domains können Informationen über die Browsing-Historie des Users in ihren First Party-Cookies speichern. ITP 2.0 erkennt aber ein solches Verhalten. Sie behandelt die entsprechenden Domains wie jeden anderen Tracker und löscht die Cookies.
Schutz gegen Tracker-Collusion
Dieses Feature der Intelligent Tracking Prevention identifiziert Weiterleitungen, die nur zu Tracking-Zwecken vorgenommen werden, für Piggybacking und Cookie-Syncing. Beim Piggybacking (deutsch: Huckepack) wird zusätzlicher Tracking-Code des entsprechenden Anbieters in die URL eingefügt.
Die ITP 2.0 deckt solches Verhalten mittels eines sogenannten Collusion-Graphs auf und klassifiziert alle Domains, die als Tracker in den Weiterleitungen involviert sind.
Der Schutz gegen Tracker-Collusion hindert Cookies daran, auf einem User-Browser während solcher Weiterleitungen ausgelesen oder gelöscht zu werden. Dies hat negative Auswirkungen auf Affiliate-Marketing und den Datenaustausch zwischen AdTech-Plattformen.
Nur Ursprungs-URL für Domains ohne User-Interaktion
Durch dieses neue Feature werden nur noch die verkürzten Domains der aufgerufenen URL an Third Party-Tracker weitergegeben. Wenn ein User z. B. eine Website aufruft, die Third Party-Tracker (Werbeanzeigen) enthält, werden die Referrer-Information wie folgt an diese Third Parties weitergegeben:
Vor ITP 2.0: https://ecommercestore.com/clothes/mens/business/shoes
Nach ITP 2.0: https://ecommercestore.com/
Third Party-Tracker haben nun weniger Informationen über den Benutzer als zuvor. Dennoch schränkt dies nicht die Daten ein, die in der URL an die Website eines Werbetreibenden weitergegeben werden können, wenn der User auf seine Anzeige klickt.
Mögliche Lösungen und Workarounds für ITP 2.0
Während ITP 2.0 die Mehrheit der unabhängigen AdTech- und MarTech-Unternehmen herausfordert, haben die Anbieter einige Optionen, um ihre negativen Folgen zu begrenzen. Das wichtigste ist dabei die Verwendung von Server-zu-Server-Konvertierung und Event-Tracking. Facebook und Google entwickelten einige Lösungen, um das ITP-Problem zu lösen oder zu umgehen. Während Google einen site-wide Tag veröffentlichte, das Werbetreibenden hilft, die Conversions weiter zu messen, gab Facebook eine First Party-Cookie-Option heraus.
Intelligent Tracking Prevention (ITP) 2.1
Am 21. Februar 2019 veröffentlichte Apple einen Blogbeitrag, in dem es heißt, dass eine neue Version von Intelligent Tracking Prevention (2.1) in den Betaversionen von iOS 12.2 und Safari 12.1 auf macOS High Sierra und Mojave verfügbar sein wird.
ITP 2.1 macht es für Tracker noch schwieriger, Benutzer im Web zu identifizieren und zu verfolgen, wenn sie über den Safari-Browser im Internet surfen.
Nachfolgend führen wir die wichtigsten Updates in dieser Version der Intelligent Tracking Prevention auf:
7-tägige Gültigkeitsdauer für clientseitig gesetzte Cookies
Sie können Cookies auf zwei Arten setzen. Entweder nutzen Sie HTTP-Responses des Servers (d. h. serverseitig) oder die Document.cookie API von JavaScript (d. h. clientseitig).
Cookies, die über die JS Document.cookie API erstellt werden (auch First Party-Cookies), werden nach 7 Tagen gelöscht, unabhängig von ihrem eigentlichen „Verfallsdatum“. Durch JavaScript erstellte Cookies können auf die über HTTP-Response erstellte Cookies zugreifen, sofern sie nicht HttpOnly enthalten.
Dies wird sich auf viele MarTech-Tools wie Google Analytics auswirken, deren Cookies über die JavaScript-Bibliothek von Google Analytics gesetzt werden. Cookies, die GA in Safari setzt, verfallen nach 7 Tagen, es sei denn, der Cookie wird innerhalb von 7 Tagen erkannt oder es wird ein Workaround implementiert, wie es Simon Ahava vorschlägt.
Storage Access-API für alle Arten von Cookie-Access
In Intelligent Tracking Prevention 2.0 können domänenübergreifende Tracker ihre Cookies so unterteilen, dass sie von Websites verwendet werden, ohne den User zu tracken. Social Media-Login-Formulare auf Websites hätten ihre Cookies z. B. so unterteilt, dass sie noch funktionieren würden, aber einfach nicht in der Lage sind, User zu tracken oder Profile über sie zu erstellen.
Wenn dieses Anmeldeformular für Social Media auf seine unterteilten Cookies zugreifen will, um den User zu tracken, müsste es die Storage Access-API verwenden und die Einwilligung des Users einholen.
Dies änderte sich mit Intelligent Tracking Prevention 2.1. Alle Domains, die ITP 2.1 als mit Tracking-Funktionen ausgestattet identifiziert, müssen die Storage Access-API verwenden, um auf alle Arten von Cookie-Access zuzugreifen. Wenn sich ein User beispielsweise mit seinem Facebook-Konto auf einer Website anmelden möchte, stimmt er zunächst über die Storage Access-API zu.
Do Not Track (DNT)-Support entfernt
Apple entfernte auch den Support für das Do Not Track (DNT)-Signal. Offiziell begründete es das Unternehmen damit, dass viele Websites (und Softwareanbieter) die von den Usern festgelegte DNT-Entscheidung ignorierten und die Besucher weiterhin verfolgten.
Es wirkte sich kaum auf den Datenschutz für Safari-Anwender, da ITP weitaus fortschrittlichere Datenschutz- und Anti-Tracking-Maßnahmen bietet als DNT es je getan hat.
Verifizierter partitionierter Cache
Intelligent Tracking Prevention 2.1 führte auch den verifizierten partitionierten Cache ein. Hintergrund ist, dass das Team von WebKit bemerkte, dass einige Tracker Workarounds für ITP implementierten, von denen einer den Missbrauch von partitionierten Cache beinhaltet.
Als Reaktion darauf wird zu einer Domain, die über Tracking-Funktionen verfügt, ein partitionierter Cache-Eintrag erstellt und zur Überprüfung markiert. Wenn es dann nach 7 Tagen einen Cache-Treffer für diesen Eintrag gibt, wird er wieder geladen. Wenn die neue und die ursprüngliche Antwort im Cache übereinstimmen, wird sie gelöscht. Wenn dies nicht der Fall ist, wird der ursprüngliche Eintrag verworfen und ein neuer Verifizierungsprozess beginnt mit dem neuen Eintrag.
Intelligent Tracking Prevention 2.2 – verschärftes Update
Mit dem ITP-Update schloss Apple weitere Lücken in Safaris Anti-Tracking-Funktion. Mit dieser Aktualisierung von ITP schien Apple auf den Workaround abzuzielen, den Unternehmen wie Facebook und Google eingeführt haben. Damit soll der Traffic weiter gemessen und Anzeigen den Website-Besuchern sowie Online-Käufe auf Websites von Drittanbietern zugeordnet werden können. Intelligent Tracking Prevention 2.2 deaktivierte diese Workarounds nicht vollständig. Vielmehr sollte das Update weitgehend sicherstellen, dass Unternehmen die Workarounds nicht nutzen, um die Anti-Tracking-Funktion von Safari zu umgehen und User kontinuierlich zu tracken.
First Party-Cookies auf 24h begrenzt
Intelligent Tracking Prevention 2.2 verkürzt das Tracking-Fenster der Workarounds auf 24 Stunden. Es schränkt die Möglichkeiten von Unternehmen wie Facebook und Google ein, Traffic- und Attributanzeigen zu messen.
Im Vergleich zu ITP 2.1 verkürzt Intelligent Tracking Prevention 2.2 die Lebensdauer des First-Party-Cookies von sieben Tagen auf einen Tag. Infolgedessen werden die First-Party-Cookies von Facebook und Google nach 24 Stunden gelöscht. Wenn etwa ein User freitags auf eine Anzeige für ein Produkt klickt und das Wochenende nutzen möchte, um über einen Kauf nachzudenken, dann wäre der Cookie montags bereits gelöscht. Der User würde nicht als wiederkehrender Besucher erkannt werden.
Apple ist generell damit einverstanden, dass Unternehmen First Party-Cookies nutzen, um Anzeigen zu erstellen. Gleichzeitig ist Apple aber sehr vorsichtig, wenn Unternehmen diese Funktionalität nutzen, um mehr als nur Attributanzeigen oder Traffic zu analysieren. Daher gilt Intelligent Tracking Prevention 2.2 auch nur für bestimmte Arten von First Party-Cookies.
Welche Arten von First Party-Cookies sind betroffen?
Betroffen sind persistente First Party-Cookies:
- Die im Browser eines Users im Namen eines Drittanbieters abgelegt werden,
- Die in der Lage sind, User auf verschiedenen Websites zu tracken und
- Die Apple als solche identifiziert.
Insbesondere zielt das Update auf Unternehmen ab, die die Methode der Link-Dekoration nutzen, um First Party-Cookies zu löschen und User auf einer Website zu tracken. Die ITP-Workarounds z. B. von Facebook und Google verwenden diese Methode, um Safari-User auf Websites von Drittanbietern weiterhin zu tracken.
Was ist Link-Dekoration?
Link-Dekoration ermöglicht, Informationen an eine URL anzuhängen, auf die ein User klickt, um diese Informationen an die Zielseite weiterzugeben, beispielsweise auch utm-Parameter. Wenn der User einen Link mit solchen zusätzlichen Informationen klickt, kann erkannt werden, wie er auf diese Seite gelangte, z. B. über einen Newsletter, eine Anzeige, Social Media etc.
Was ist das Problem?
Das Problem ist, dass Unternehmen Link-Dekoration verwenden können, um Informationen an andere Websites weiterzugeben. Das wiederum ermöglicht einen User auf diesen Websites dauerhaft zu tracken. Diese Praxis wird als standortübergreifendes Tracking über Link-Dekoration bezeichnet, und genau das ist es, was Apple mit ITP 2.2 anging.
Intelligent Tracking Prevention 2.3: Nun auch LocalStroage betroffen
Das Update der Intelligent Tracking Prevention auf Version 2.3 betrifft alle Nutzer von Safari 13.Die Version ist verfügbar für MacOS 10.13 (High Sierra) und 10.14 (Mojave). Zusätzlich ist sie Standard in MacOS Catalina (10.15), iOS 13 und iPadOS 13 und betrifft somit eine nicht zu ignorierende Zahl an Usern.
Version 2.2 begrenzte die Gültigkeit von permanenten Client-Cookies auf 24 Stunden, wenn die Landingpage der Website ein Query-String oder Fragment (wie z. B. website.example?clickID=0123456789) in der URL aufweist und die Domain von der ITP entsprechend als Tracking-Website klassifiziert ist.
Wie der Ingenieur für WebKit Sicherheit und Datenschutz, John Wilander, in einem Blogpost darlegt, geht die neue Intelligent Tracking Prevention 2.3 vorwiegend mit zwei Maßnahmen gegen den ‘Missbrauch von Link Decoration’ und damit auch gegen bestehende Workarounds vor:
1. Begrenzte Gültigkeit für alle Website-Daten, die via Script aufgerufen werden können
Zahlreiche Tracker sind mittlerweile keine First Party-Cookies mehr, sondern First Party-Storage wie bspw. LocalStorage geworden. Deshalb werden alle Daten von Websites, die wie oben beschrieben, als Tracking-Websites klassifiziert werden und keine Cookies sind, nach sieben Tagen gelöscht, sofern der User die Website nicht erneut in dieser Zeit aufruft.
Damit können Third Party-Scripte nicht mehr die Schutzmaßnahmen des Browsers umgehen und ein weiterer Weg für das Tracking durch Third-Parties, nämlich die Nutzung von Link-Decoration kombiniert mit permanenten Website-Daten, wird unbrauchbar.
LocalStorage ist eine Form von Webspeicher, die es Websites ermöglicht, Daten direkt im Browser und ohne Verfallsdatum zu speichern.
2. Downgrade des document.referrer zu eTLD+1
Eine weitere von Trackern genutzte Maßnahme ist die Link-Decoration der eigenen Referrer-URL anstelle der Zielseite. Document.referrer auf der Zielseite liest dann die Tracking-ID aus.
Wenn eine klassifizierte Domain einen Nutzer umleitet und der Referrer Link-Decoration aufweist, wird document.referrer zu eTLD+1 downgegradet. Wenn ein User zum Beispiel von social.example zu website.example umgeleitet wird, dann stellt ITP sicher, dass nur https://social.example zurückgemeldet wird. Eine vorhandene ClickID kann somit nicht im document.referrer gespeichert werden.
Das Tracking durch Dritte gehört langsam der Vergangenheit an. Server Side Tracking (auch serverseitiges Tracking genannt) und Server Site Tagging sind in den letzten Jahren auf dem Vormarsch. Sie helfen Ihnen, viele Probleme mit dem Third-Party-Tracking und dem clientseitigen First-Party-Tracking zu überwinden, um genauere Daten zu sammeln. Mehr dazu hier: Server Side Tracking mit First-Party-Collector einfach erklärt
Wen betrifft die Intelligent Tracking Prevention?
Die Intelligent Tracking Prevention ist ein weiteres Beispiel für ein Datenschutz-Feature, das die Funktionsweise von Cookies – und damit auch die Online Werbung – bedroht.
Daher sind die von ITP betroffenen Unternehmen diejenigen, die sich bei ihren Werbe- und Marketingdienstleistungen auf Cookies, insbesondere Third Party-Cookies, verlassen. Dazu zählen Anbieter von Retargeting-Werbung, Affiliate-Netzwerke und viele weitere.
Die Intelligent Tracking Prevention betrifft im Mobile Web immerhin etwa ⅓ aller User. Doch sie ist nur eine von vielen Änderungen, mit denen sich die Online-Branche auseinandersetzen muss. Lesen Sie mehr in diesen Artikeln:
Wer ist nicht von der Intelligent Tracking Prevention betroffen?
Während die meisten Marketingunternehmen und Werbetreibenden von der Intelligent Tracking Prevention betroffen sind, gibt es dennoch einige Firmen, die durch das Feature keine allzu großen Probleme bekommen.
Web Analytics und sonstige Marketing-Software, die mit First Party-Cookies arbeiten
Solange First Party-Cookies nur für entsprechende Zwecke – also ohne Drittanbieter zu involvieren – eingesetzt werden, können Cookies gesetzt werden, ohne dass die Intelligent Tracking Prevention das verhindert. Zusätzlich bekommen Ihre Website-Besucher keine Storage Access-Aufforderung eingeblendet, wenn Sie Software wie Piwik PRO einsetzen, die First Party-Daten nicht mit anderen teilt.
Plattformen wie Piwik PRO speichern den Cookie (via JavaScript) unter der Domain der Website, die der User zu dem Zeitpunkt besucht, und tracken ihn nicht durch das Internet.
Wenn Sie etwa die Website www.example.com betreiben und dort die Piwik PRO Tags installieren, wird der Cookie unter der Domain example.com gespeichert. Der Cookie wird nicht mit Third Parties geteilt und die Software wird nur innerhalb der Domain genutzt.
Wenn nun Piwik PRO dafür genutzt wird, eine andere Website zu analysieren, z. B. www.usedcarsite.com, wird unter der Domain dieser Website ein eigener Cookie gespeichert, zusammen mit einer eigenen ID in der Datenbank.
Wenn Sie mehr darüber erfahren möchten, wie Analytics Sie Ihren Geschäftszielen näher bringt, kontaktieren Sie uns. Wir beantworten gerne alle Ihre Fragen.
Self-hosted und white-labeled Software
Die meisten Unternehmen, die self-hosted Software einsetzen, sind von dieser Änderung nicht betroffen. Üblicherweise wird die Software unter einer Subdomain gehostet (bspw. software.example.com), sodass First Party-Cookies erzeugt werden können, wenn ein User die Unternehmens-Website besucht.
Zusätzlich gibt es cloud-basierte Lösungen, bei denen die Software so konfiguriert werden kann, dass sie auf die Subdomain des Nutzers weist. Diese Praxis ist als Custom Domain Support oder Domain White Labeling bekannt.
Mehr zum Thema Daten-Hosting finden Sie in dem Artikel: So hosten Sie Ihr Analytics: Public Cloud, Private Cloud oder On-Premises
Ökosystem von Advertising-Giganten
Waren die großen Unternehmen wie Facebook und Amazon von der Intelligent Tracking Prevention in den Versionen 1.0 und 1.1 noch wenig betroffen, hat sich das mit der aktuellen Version geändert.
Google, Facebook und Amazon müssen – wie anhand des Widget-Beispiels gezeigt – nun die Einwilligung der User über das Storage Access-Popup einholen, wenn sie Cookies speichern und Zugriff auf Website-Daten erhalten wollen.
Fazit
Intelligent Tracking Prevention, DSGVO, und die ePrivacy-Verordnung – Datenschutz ist ein riesiges Thema. Gleichzeitig hat die Online-Branche mit ihren Bemühungen für eine verbesserte User Experience an den immer strengeren Auflagen zu kämpfen.
Den Unternehmen, die auf Werbung und Userdaten angewiesen sind, müssen sich daher mit Alternativen beschäftigen, Workarounds etablieren oder ihre bisherige Strategie überdenken.
Ein Neuanfang mit einer neuen Strategie und vielleicht sogar einem neuen Analytics-Partner, der konform zur DSGVO arbeitet und das Thema Datenschutz großschreibt, kann eine Lösung sein und Sie für die Zukunft rüsten.
Sollten Sie nach einer geeigneten Analytics Software suchen, empfehlen wir Ihnen folgende Artikel zur Durchsicht:
→ Web Analytics Anbieter Vergleich: Welche Plattform ist für Sie die richtige?
→ Vergleichen Sie 7 kostenlose Web-Analytics-Plattformen (einschließlich Produktanalyse)
→ 6 Wege wie Sie Daten online sammeln und der Vergleich 6 beliebter Analytics Plattformen
Dieser Artikel erschien zuerst im Blog von Clearcode mit dem Titel: What Is Intelligent Tracking Prevention and How Does It Work?