In unserem zweiten Blogbeitrag behandeln wir das Thema, wie Unternehmen zukünftig Nutzerverhalten erfassen und für die Personalisierung der User Experience verwenden können. Im ersten Teil unseres Blogs haben wir die alternativen Möglichkeiten zur Nutzeridentifizierung ohne Cookies aufgezeigt und bewertet.

Teil 2: Welche Lösungen haben sich bei der Echtzeit-Personalisierung bewährt und welche Erfahrungen liegen vor?

Das Thema Nutzeridentifikation und konsistente Nutzerkommunikation hat für Echtzeit-Personalisierung eine hohe Relevanz. Vor allem die digitale Kanäle Web und mobile App stellen die meisten unserer Kunden im Kontext der Nutzererkennung aufgrund zunehmender Restriktionen im Browserumfeld und der schärferen Gesetzgebungen vor neue Herausforderungen. Wir wollen unsere Erfahrungen und Lösungen hierbei aufzeigen.

1. Personalisierung der Website

First-Party-Cookies
First-Party-Cookies werden angewendet, um Nutzer innerhalb einer Kundendomain und der ihr zughörigen Sub-Domains zu identifizieren. Wenn also ein First-Party-Cookie unter der domain „yourdomain.com“ gesetzt wird, erkennen wir Nutzer sowohl auf allen Websites, die dieser Domain zugehörig sind, als auch auf allen Sub-Domains, wie zum Beispiel subdomain.yourdomain.com.

Der Einsatzbereich eines First-Party-Cookies ist allerdings auf die jeweilige Domain beschränkt, auf der er gesetzt wird, womit er nicht für eine domain-übergreifende Nutzeridentifikation geeignet ist. Zur Erläuterung: Der Wert eines First-Party-Cookies, also in diesem Fall die User-Id, kann nur im Kontext der Domain gelesen werden, in welcher das Cookie auch gesetzt wurde. Die Lebensdauer von First-Party-Cookies beträgt dabei üblicherweise ein bis zwei Jahre, sofern der Nutzer das Cookie nicht zuvor aktiv löscht.

Der Einsatz von First-Party-Cookies funktioniert jedoch nicht ohne technische und rechtliche Herausforderungen. So wird zum einen die Zustimmung des Nutzers (der consent) benötigt (dieses Thema wurde bereits genauer beleuchtet in Teil 1 dieser Blogreihes). Zum anderen gehen Browser und Plattformen teilweise gegen die Nutzeridentifikation durch First-Party-Cookies vor. So schränkt Apple mit seiner iOS- Plattform auf allen Browsern First-Party-Cookies teilweise ein, indem sie die Lebensdauer von First-Party-Cookies, die client-seitig über document.cookie gesetzt werden, auf 7 Tage begrenzt. Zusätzlich wird die Lebensdauer auf nur einen Tag verkürzt, falls die Referrer-Domain eine bekannte Trackerdomain ist und verschlüsselte Parameter in der URL enthält. Der BegriffTrackerdomain bezeichnet dabei die domain, mit der der Browser zum Zwecke der Nutzeridentifikation und Datensammlung kommuniziert. Zur Erkennung der Tracker bedient sich iOS dabei einer Tracking-Radar-Liste, die von der Suchmaschine DuckDuckGo bereitgestellt wird. Auf dieser Liste finden sich z. B. domains von Facebook (facebook.com) oder Google (doublecklick.net). Jedoch wird nicht jede dort gelistete Domain automatisch als Trackerdomain behandelt, die Entscheidung wird per Algorithmus erzeugt und basiert auf Kriterien wie Nutzerverhalten und Anzahl der Aufrufe gegen die Domain im Tracking-Kontext.

Inzwischen existieren einige Alternativen zu diesen Einschränkungen, die sich bewährt haben und die wir für Kunden einsetzen. Eine will ich näher erläutern:

  • Die gesamte Netzwerk-Kommunikation, inklusive Setzen und Lesen des First-Party-Cookies, läuft über die Serverdomain, auf welcher sich der Nutzer aufhält. Dabei müssen die Cookies server-seitig in den http-Headern gesetzt werden, was nur möglich ist, wenn der HTTP-Endpunkt dieselbe domain hat wie die Quelle des HTTP-Aufrufs.
  • In der Praxis heißt das, dass man für die jeweilige Domain des Tracking-Systems entweder einen CName- oder einen A-Eintrag im Domain-Name-System (DNS) eintragen muss. Das kann nur in Zusammenarbeit mit dem Domain-Owner erfolgen und ist damit aufwendiger als herkömmliche Cookie-Integrationen, schafft aber deutlich mehr Transparenz und Nachvollziehbarkeit im Tracking.

Experten-Tipp:
Da die Dynamik an browserbasierten Restriktionen im Cookie-Bereich hoch ist und sich oftmals Neuigkeiten ergeben, empfehlen wir, sich regelmäßig über die Seite https://www.cookiestatus.com/ auf den aktuellen Stand zu bringen. (Tipp: unbedingt bookmarken)

2. Cross Domain Personalisierung

Betreibt ein Kunde verschiedene Domains, über deren Grenzen hinweg Nutzer wiedererkannt werden sollen, setzen wir eine Kombination verschiedener Ansätze ein

Third-Party-Cookies
Third-Party-Cookies werden im Gegensatz zu First-Party-Cookies nicht unter der jeweiligen Kundendomain, sondern unter der Server-Domain des jeweiligen Trackers gesetzt. So wird das Cookie eines Nutzers auf yourdomain.com z. B. unter trackerdomain.com gesetzt. Dadurch kann der Tracker den Wert des Cookies theoretisch über verschiedene Domains hinweg auslesen und den Nutzer wiedererkennen.

In der Praxis gibt es jedoch eine ganze Reihe von Browser-Restriktionen, die dazu führen, dass sich der Lebenszyklus von Third-Party-Cookies seinem Ende zuneigt. Zwar sind Third-Party-Cookies als Cross-Domain-Identifier partiell immer noch einsetzbar, Firefox und alle unter iOS genutzten Browser blockieren jedoch in aktuellen Versionen per default das Auslesen gesetzter Third-Party-Cookies. Chrome unterstützt die Methode noch bis 2022, wenn die Third-Party Cookies server-seitig mit entsprechenden Attributen gesetzt werden. Im Laufe des Jahres 2022 wird Chrome den Support für Third-Party-Cookies einstellen.

Aufgrund dieser Entwicklungen setzen wir bei der domainübergreifenden Nutzeridentifikation zunehmend auf Lösungen, die auf User-Logins oder URL-Parametern basieren.

URL-Parameter
URL-Parameter sind eine Möglichkeit, um bestimmte Informationen wie z.B. die User-Id, von einer Domain auf eine andere Domain zu transferieren. So besteht die Möglichkeit, die User-Id als URL-Parameter bei einem Link-Klick des Nutzers an die Ziel-URL anzuhängen. Beim Besuch der anderen Domain kann der Nutzer dann wiedererkannt werden. Ein Beispiel für eine solche Ziel-URL könnte lauten: yourdomain.com?info=374859403 wobei 374859403 für die unique Id des Users steht.

Experten-Tipp:
Die Praxis hat gezeigt, dass dieser Ansatz aus Sicht der Nutzerpersonalisierung besonders gut funktioniert, wenn der Use Case vorsieht, Nutzer durch personalisierte Ansprache von Domain A auf Domain B zu bringen damit sie auf Domain B konvertieren. In diesem Fall kann die UserId als Parameter an die auf Domain B verweisende Redirect-URL gehängt werden.

User-Login
Existiert ein Portal, über das sich ein Nutzer einloggt, kann der User nach dem Login anhand des dahinterliegenden User-Accounts (z.B. anhand seiner Customer-Id) eindeutig identifiziert werden. Wenn sich ein Nutzer mit seinem Account auf verschiedenen Domains einloggen kann, wird er domainübergreifend zum Zeitpunkt des Logins erkannt und die Nutzer-Daten können retrospektiv miteinander verknüpft werden.

3.Mobile App Personalisierung

Bei der Nutzererkennung auf mobilen Endgeräten wird zwischen mobilem Web und mobilen Apps unterschieden. Während die Nutzeridentifikations-Mechanismen beim mobilen Web, sprich bei Websites, die über mobile Endgeräte angesteuert werden, sehr ähnlich funktionieren, wie bei nicht mobilen Endgeräten (siehe vorheriger Absatz „Webseite“), funktioniert die Nutzererkennung bei mobilen Apps grundlegend anders. Während die Nutzeridentifikation im Web-Bereich primär auf über JavaScript gesetzten und gelesenen Cookies basiert, ist die Basis für die Identifikation von Nutzern auf mobilen Apps so genannte Tracking Software Development Kits (Tracking SDKs). Diese SDKs existieren für verschiedene Plattformen wie iOS, Android oder Windows und beinhalten ein Set an vordefiniertem Code, den Entwickler in ihre mobilen Apps einbinden können und der die Identifikation der Nutzer ermöglicht, sofern dieser der Sammlung seiner Daten zustimmt. SDKs vereinfachen Entwicklern insofern das Leben, dass sie keinen eigenen Code zum Tracking der Nutzer schreiben müssen. Stattdessen senden die mobilen Apps Nutzerdaten direkt mit Verweis auf den jeweiligen Nutzer an den Tracking-Server:

Bei der Nutzeridentifikation gibt es zwei Möglichkeiten:

  • User-Id ohne Authentifizierung bzw. User-Login

    • Diese User-Ids sind auch oft unter dem Namen User-Pseudo-Id bekannt. Diese Ids sind verknüpft mit der jeweiligen Mobile-App-Installation und ändern sich nicht, solange der Nutzer die App nicht neu installiert. Sie können Nutzer nur innerhalb der jeweiligen Mobile App identifizieren, nicht aber app- oder device-übergreifend.

  • User-Id mit Authentifizierung bzw. User-Login

    • Wenn der Nutzer sich bei der mobilen App einloggt besteht die Möglichkeit, ihn anhand des dahinterstehenden Accounts eindeutig zu identifizieren. Wenn sich der Nutzer mit demselben Account bei verschiedenen mobilen Apps anmeldet, kann er auch app-übergreifend erkannt werden und die Nutzer-Daten können retrospektiv miteinander verknüpft werden

Eine eindeutige und saubere Identifizierung der Nutzer auf den Kanälen Web und mobile App ist der erste, wichtige Schritt hin zu einem besseren Nutzerverständnis und bildet die Basis für eine einheitliche, kanalübergreifende Sicht auf den Nutzer und somit für Echtzeit-Personalisierung und die Optimierung der User Experience. In unserem nächsten Blogbeitrag werden wir darüber berichten, welche Möglichkeiten es gibt, individuelle, kanalspezifische Identitäten zu verknüpfen und in einem Identitäts-Graphen zu kombinieren.

Photo: Antonio Gravante| Unsplash