Safari ITP 2.1: Wie beeinflusst das mein Tracking?

Apple hat bekannt gegeben, dass Safaris Intelligent Tracking Prevention (ITP) aktualisiert wird.

Das letzte Update ITP 2.0 beschränkte sich auf 3rd Party Cookies. Hiervon waren die in Safari gezählten Conversions für Google Ads, den Campaign Manager oder Display & Video 360 betroffen. In unserem Blogartikel  “ITP: Conversion: unabhängig vom Browser richtig messen” erfahren Sie, wie Sie sicherstellen, dass Ihre Conversions in Safari nach wie vor gezählt werden.

Bis jetzt waren Webanalyse-Daten von Safaris Intelligent Tracking Prevention nicht betroffen. Mit dem jetzigen Update ITP 2.1 wird sich dies ändern. Webanalyse-Tools wie Google Analytics, Adobe Analytics oder Webtrekk nutzen 1st Party Cookies. Safaris Update sieht vor, clientseitige 1st Party Cookies nur mehr für 7 Tage zu speichern.

Welche Auswirkungen hat das Safari ITP 2.1. Update?

Nach Ablauf der Cookie-Laufzeit werden Nutzer in Safari nicht mehr wiedererkannt und als neue Nutzer gezählt. Der Effekt ist umso größer, je mehr Nutzer zwischen zwei Besuchen mehr als 7 Tagen verstreichen lassen. So trifft das Update vermutlich die Website einer Tageszeitung, deren Nutzer mehrmals in der Woche die Website aufrufen, weniger stark als eine B2B-Website.

In Google Analytics sind die folgenden Auswirkungen auf die Daten zu erwarten:

1. Auswirkung auf nutzerbasierte Metriken

  • ein höherer Anteil an Safari-Nutzern, da diese nach Ablauf der Cookie-Laufzeit in Safari erneut und somit mehrfach gezählt werden (die Auswertung nach Sitzungen ist davon allerdings nicht beeinträchtigt)
  • aus demselben Grund: ein höherer Anteil neuer Nutzer bzw. ein geringerer Anteil wiederkehrender Nutzer
  • weniger Sitzungen pro Nutzer, da Sitzungen in Safari nach Ablauf der Cookie-Laufzeit von 7 Tagen neuen Nutzern zugewiesen werden

2. Auswirkungen auf nutzerbasierte Berichte

  • geringerer Customer Lifetime Value (LTV)
  • geringere Verlaufsdaten ab 7 Tagen im Kohorten-Bericht
  • in den Akquisitions-Berichten (last non direct) wird ein größerer Anteil an Conversions dem Marketingkanal “Direkt” zugeschrieben, da sie nach Ablauf der Cookie-Laufzeit nicht mehr einem vorherigen Kanal zugeschrieben werden können
  • im Multi-Channel-Trichter-Bericht “Vorbereitete Conversions” entstehen weniger vorbereitete Conversions, da die Pfade nach Ablauf der Cookie-Laufzeit enden
  • aus demselben Grund: in den Attributions-Berichten entsteht eine Unterbewertung von Marketingkanälen, die aufgrund der abgelaufenen Cookie-Laufzeit nicht dem Conversion-Pfad zugeordnet werden können

3. Auswirkungen auf Segmente und Audiences

Szenario: Ein Safari-Nutzer kauft ein Produkt für 500 Euro. Derselbe Safari-Nutzer kauft 10 Tage später ein weiteres Produkt für 600 Euro. Für eine Remarketing-Kampagne sollen Nutzer angesprochen werden, die mindestens 1.000 Euro Umsatz generiert haben.

Variante 1: Wenn zwischen den beiden Käufen keine weitere Sitzung stattgefunden hat, dann können die beiden Käufe nicht ein und demselben Nutzer zugewiesen werden, da das Cookie nach 7 Tagen Inaktivität abgelaufen ist. Der Nutzer wird nicht in die Zielgruppe “mindestens 1.000 Euro Umsatz” aufgenommen.

Variante 2: Wenn zwischen den beiden Käufen weitere Sitzungen stattgefunden haben, wird in jeder dieser Sitzungen das Cookie erneuert und die Laufzeit zurückgesetzt. In diesem Fall können beide Käufe einem Nutzer zugeordnet werden. Aus diesem Grund wird der Nutzer in die Zielgruppe aufgenommen.

Wie groß ist das Ausmaß von ITP 2.1.?

Aktuell beschränkt sich das Ausmaß auf Safari-Nutzer. In der D-A-CH-Region verwendet etwa jeder fünfte Nutzer Safari. Auf detaillierte Angaben wird an dieser Stelle bewusst verzichtet, da der Anteil je nach Unternehmen variiert. Es empfiehlt sich, in den Browser-Bericht Ihres Webanalyse-Tools zu prüfen, wie hoch der Anteil an Safari-Nutzern auf Ihrer Website ist.

Mit Firefox könnte bald ein weiterer Browser nachziehen, der die Cookie-Laufzeit für clientseitige 1st Party Cookies auf 7 Tage beschränkt. Über erste Tests wurde bereits berichtet.

Was kann ich dagegen tun?

Möglichkeit #1: User ID-Feature verwenden

Nutzer werden über Browser-Cookies identifiziert, die eine Client ID speichern. Wenn ein Nutzer seine Cookies löscht, erhält er beim nächsten Besuch eine neue Client ID und wird als neuer Nutzer erfasst. Wechselt ein Nutzer den Browser oder das Gerät, erhält er eine neue Client ID und wird somit nicht als ein und derselbe Nutzer identifiziert.

Das User ID Feature ermöglicht es, Daten von verschiedenen Geräten und aus unterschiedlichen Sitzungen eindeutige IDs zuzuordnen. Zum Beispiel kann ein Login verwendet werden, um Nutzer über verschiedene Geräte hinweg eindeutig zu identifizieren.

User ID

Safari-Nutzer erhalten nach Ablauf der Cookie-Laufzeit von 7 Tagen eine neue Client ID und werden in der nächsten Sitzung als neue Nutzer erfasst. Im Falle der User ID werden eingeloggte Nutzer nach Ablauf der 7 Tage weiterhin dieselbe ID erhalten, da sie über den Login identifiziert werden. Folglich werden sie als wiederkehrende Nutzer erfasst.

Voraussetzung für das User ID Feature ist, dass es für Nutzer einen Anreiz gibt, sich – wie im Falle des Logins – zu erkennen zu geben.

Das User ID-Feature beschränkt sich auf die User ID-Datenansicht, die ausschließlich Daten für Zugriffe von Nutzern mit User ID enthält.

Möglichkeit #2: Client ID im local storage speichern

Wenn Sie wie bisher clientseitige 1st Party Cookies verwenden, ist die Cookie-Laufzeit in Safari auf 7 Tage beschränkt. Eine längere Cookie-Laufzeit ermöglicht Ihnen local storage. Allerdings bringt local storage die Einschränkung mit sich, dass kein Cross-Subdomain-Tracking möglich ist. Wenn Sie nur eine Domain wie www.e-dialog.at und keine Subdomains wie blog.e-dialog.at verwenden, ist diese Variante für Sie geeignet.

Möglichkeit #3: Cookies serverseitig erzeugen

Die Cookie-Laufzeit  von 7 Tagen in Safari gilt nur für Cookies, die mit document.cookie also clientseitig gesetzt werden. Eine aufwendige Lösung stellt das Speichern der Client ID mit einem serverseitigen Cookie dar. Hierfür bedarf es eines durchdachten Konzeptes, das eine reibungslose Umstellung ermöglicht. Zudem sind der Zugriff auf den Webserver und Kenntnisse in der Backend-Programmierung erforderlich.

Hier folgt ein Überblick über die verschiedenen Lösungen und die damit verbundenen Einschränkungen und Aufwände:

Übersicht der Lösungen für Safari ITP 2.1

Hinweis: Status vom 15.3.2019. Dieser Artikel wird regelmäßig aktualisiert.

Benötigen Sie Hilfe?

Wenn Sie das User ID-Feature nutzen oder eine der vorgeschlagenen Lösungen umsetzen wollen, unterstützen wir Sie gern dabei. Wenden Sie sich an unsere Webanalyse-Experten unter kontakt@e-dialog.at

Hinterlassen Sie einen Kommentar: