Der König ist tot, es lebe der König! Was könnte eine bessere Zusammenfassung des Status quo von Cookies und der Adaption von Post-Cookie-Technologien in der programmatischen Wertschöpfungskette sein? Seit Jahren reden wir über den schleichenden Exitus von Cookies und Alternativen, die wir brauchen. Was ist bisher tatsächlich passiert und warum ist es höchste Zeit, die Alternativen zu forcieren? Der Beitrag beschreibt die Praxis der User Identifikation, auf die wir uns in der programmatischen Welt verlassen und skizziert Lösungen, um den nächsten Schritt in Richtung persistenter Identitäten zu gehen.

Es gibt eine sehr einfache Kausalkette, warum sich alle Programmatic-Advertising-Praktiker auch für die Post-Cookie-Ära interessieren sollten: Ohne Cookie keine Identität. Ohne Identität keine Daten (Targeting). Ohne Daten (Targeting) kein Demand oder zumindest niedrige eTKPs. Ohne Demand kein Umsatz. Diese Kausalkette bricht derzeit an einigen Kettengliedern, denn durch rechtliche Regularien oder Browser als Gatekeeper ändert sich die gesamte Branche.

IDs und warum sie wichtig sind

Eindeutige Identifier (ID) gibt es in vielen Ausprägungen. Dabei muss man zunächst verstehen, was mit eindeutiger Zuordnung bei IDs gemeint ist und wie IDs sich von Identität unterscheiden. Das breite Verständnis für die Unterschiede von IDs und Identität sowie für die Praxis der Zuordnung von IDs muss sich erst noch im Markt etablieren. Im Allgemeinen ist ein Identifier nur eine Reihe eindeutiger Zahlen, Buchstaben oder Symbole, die ein Objekt als eindeutig kennzeichnen. In Datenbanken ist es typischerweise eine lange Zeichenkette, auch in heutigen digitalen Werbesystemen haben IDs keine symbolische Bedeutung sondern liegen typischerweise  gehasht vor. Ein solcher Hashwert sieht beispielsweise so aus: CE06AC1ED1EA6E7B3254F14F19F515AD77E05871.

In der klassischen Cookie-basierten Webbrowser-Welt wird für jedes Device und den darauf verwendeten Browser eine ID generiert. Diese landet entweder in einem (1st oder 3rd Party) Cookie oder im „Local Storage“[1]. Die ID selbst ist somit erst einmal nicht gleichbedeutend mit einer User Identität. Vielmehr stellt sie innerhalb der gegebenen Systemgrenzen eine (meist pseudonyme) eindeutige Repräsentation des User Devices und des dabei verwendeten Browsers dar. Verwendet der User ein zweites Device oder einen anderen Browser, wird eine zweite ID generiert. Diese kann mit der ersten ID zunächst nicht zusammengebracht werden, da sich die Gerätegrenzen nicht ohne weiteres überwinden lassen. Eine ID repräsentiert somit erst einmal nur eine Teil-Identität.

Die ID selbst ist zunächst nutzlos, sofern sie nicht mit Daten verknüpft wird. Dies können z.B. Targeting-Profildaten für einen Benutzer (Soziodemographie, Affinitäten etc.), Cappings einer Kampagne oder bei Consent-Einholung auch ein Opt-in/ -out sein. Während die ID heute nach wie vor in einem Cookie abgelegt wird, verbleiben die assoziierten Daten meist auf der Server-Seite.

Wird ein Cookie gelöscht, geht auch die darin gespeicherte ID mit allen assoziierten Daten verloren. Weder ID noch Daten können dann weiter zugeordnet werden. Es ist somit wichtig, dass das die ID tragende Cookie so lange wie notwendig existiert. Wird ein Cookie durch aktives Löschen des Users oder aber jegliche Browser-Funktionalitäten trotzdem gelöscht, beginnt die Sammlung von (Profil-)Daten an einer neu zu generierenden ID von vorne. Das Cookie selbst ist somit nicht die ID, sondern nur der „Lagerort“.

Genau wie das Verständnis der ID-Cookie-Beziehung ist auch die Kenntnis der ID-Identität-Relation relevant. In der Regel ist letztere pseudonym mit einer Person (User) verbunden. Durchschnittlich verwenden User etwa vier vernetzte Geräte[2]. Unter Berücksichtigung der angegebenen Cookie-Logik müssen also mindestens vier Cookie IDs mit dem User gematched werden, um eine vollständige Identität zu bilden. Beachtet man noch, dass auf einem Gerät mehrere Browser installiert und genutzt werden, wären es sogar noch mehr IDs. Ein solches Matching findet bisher aber kaum statt. Ferner könnte ein Device von mehreren Usern genutzt werden, was zu Fehlinterpretation der Identität führt, sobald der zweite User Daten erzeugt. Schon die so genannte Persistenz eines Cookies, also die Fähigkeit Daten beizubehalten, ist nicht gegeben. Noch weniger beständig ist die Verknüpfung von mehreren Cookies, die zusammen ein Device- bzw. Useragent-übergreifendes und vollständiges Profil eines Nutzers bilden. Die gute Nachricht lautet: Dieses Problem ist lösbar, wenn wir uns mit den Herausforderungen der Post-Cookie-Ära beschäftigen und Lösungsbausteine bereitstellen.

Was sind die Herausforderungen?

Die Art und Weise, wie IDs in einer Cookie-basierten Welt gespeichert werden, beeinflusst signifikant die Informationsgehalt und Genauigkeit der profilierten Identität.

Basierend auf den uns vorliegenden Daten[3] existieren mehr als 20 Prozent aller Cookies in einer Desktop-Umgebung nicht länger als einen Tag. Weitere 15 bis 20 Prozent werden vor Ablauf eines Monats gelöscht. Bei Anbietern in einem 3rd-Party-Kontext (bei denen es sich in der Regel um alle Teilnehmer des programmatischen Ökosystems handelt) ist das Problem meist noch dramatischer. Viele der aktuell Cookie-basierten IDs bilden damit nur Teile einer Identität/eines User-Profils ab: Die Profilierung an einer ID muss jedes Mal neu gestartet werden, sobald die ID gelöscht wird. Doch das ist nur eines der Probleme mit der Identität: Native Apps  auf mobilen Devices eignen sich für die Nutzung von Cookies schlichtweg nicht mehr. Somit muss die alte Cookie-Welt mit der neuen nativen Mobile-Ad-ID-Welt verknüpft werden.

Eine von Mobilgeräten dominierte Welt

Cookies waren eine perfekte Lösung in einer Welt, in der nur der Desktop-Browser zum Surfen genutzt wurden. Aus Sicht der Privatsphäre war es einfach, diese zu löschen, oder ihre Erstellung auf einem Gerät zu verbieten. Diese Ära geht spätestens seit Oktober 2016 ihrem Ende entgegen, da seit diesem Zeitpunkt erstmals mehr als die Hälfte (51,3 Prozent) der weltweiten Internet-Nutzung durch mobile Geräte generiert wird.

Aber warum sind Cookies auf mobilen Endgeräten ein Problem? Sofern nicht explizit eingebettet (Webview), enthalten native Apps keine Browser-Funktionalität wie Cookies, HTML oder Javascript mehr. Möchte man sie trotzdem nutzen, muss man einen sogenannten Webview einbetten, der aus Performance-Gesichtspunkten langsam und speicherintensiv ist, was der Usability schadet.

Auf mobilen Geräten haben die Hersteller der Betriebssysteme hingegen Cookie IDs durch Geräte- (Anzeigen-) IDs wie IDFA (iOS: „Identifier for Advertising“), AAID (Android: „Android Advertising ID“) oder Windows ID (Windows Phone OS) ersetzt. Diese Advertising IDs können wiederum nur aus dem nativen, nicht jedoch aus dem Web-Kontext heraus gelesen werden.

Betriebssystem-/Browser-Hersteller haben diese Art von Mobile Ad IDs in mobilen Browsern nie eingeführt. Chrome hat dies zuletzt damit begründet, dass die Code Basis von Chrome hierfür zu stark hätte umgebaut werden müssen. Schade aus meiner Sicht, da es folglich zur Entwicklung von Fingerprint-Methoden und in einigen Fällen von probabilistischem Voodoo (sorry, statistische Methoden) kam, das bei weitem nicht so genau eine Identität über mehrere Geräte hinweg ergibt, wie das in Marketing-Unterlagen häufig versprochen wird (= false positive / negative).

Die stationäre (Web-Desktop) und die mobile Welt (Native Android/iOS App) lassen sich daher nicht einfach zusammenführen.

Direkte / indirekte Werbeblockierung

Auch die in den letzten Jahren eingeführten Werbeblocker haben starke Auswirkungen auf die digitale Welt. So hat der „Wild-Wild-West“ Umgang mit Nutzern durch Teile der Werbebranche zu etwa 25 Prozent direktem (Adblock Plus, Ghostery, uBlock, AdGuard, Disconnect.me usw.) und etwa fünf bis zehn Prozent indirektem (in der Regel Antiviren-Software, die Browser-Plug-in-Funktionen zum Blockieren von Werbung enthält) AdBlocking geführt. Also ist ein Viertel des Kuchens bereits gegessen, bevor Werbetreibende und Vermarkter sich überhaupt an den Kaffeetisch setzen können.

Browser als Gatekeeper

Neben der rasanten Entwicklung des AdBlockings entsteht ein weiteres schwarzes Loch für die Werbeeinnahmen in einer Programmatic First Welt. Die Browser-Anbieter selbst drängen parallel zu den anstehenden Restriktionen auf Basis der DSGVO in die Position des Privacy Gatekeepers. Ob aus eigenem Interesse, vorausschauendem Gehorsam gegenüber Vorschriften oder sozialer Verantwortung, lassen wir mal dahingestellt.

Safari startete im Juni 2017 mit der Einführung von Intelligent Tracking Prevention (ITP). Dieser Mechanismus und seine Weiterentwicklung in späteren Versionen führte zu einer vollständigen Sperrung von 3rd Party Cookies. So überlebt heute im Safari ein 3rd Party Cookie nicht einmal eine einzelne Session, sofern es überhaupt noch geschrieben werden kann. Das Blockieren von 1st Party Cookies steht bevor.

Mozilla kündigte zuerst die Einführung seiner "Enhanced Tracking Prevention" für Firefox mit Version 63 im Oktober 2018 an, hat sie jedoch schlussendlich für Neuinstallationen erst im Juni 2019 per Default aktiviert. Der Mechanismus blockiert 3rd Party Cookies von Werbe-/ Tracking-Domains basierend auf der Liste "disconnect.me", die auf github erhältlich ist.

Microsoft hat gerade eine Beta-Version seiner eigenen Tracking Prevention in Edge integriert, die aufgrund möglicher Änderungen in den kommenden Versionen noch nicht standardmäßig aktiviert ist. Edge basiert seit letztem Jahr auf Chromium. Daher wird es interessant sein zu sehen, wie Microsoft die von Google in Chromium eingeführten Änderungen anpasst respektive übernimmt.

Last but not least hat Google auf seiner Google I/O-Entwicklerkonferenz im Mai 2019 die neuesten Pläne zur Entwicklung von Datenschutz- und Sicherheitsfunktionen für den Chrome-Browser (bzw. Chromium) bekannt gegeben:

• Es wird ein neues „SameSite“ Cookie-Attribut eingeführt (siehe IETF-Spezifikationen), das in HTTP-Headern mit dem Namen "SameSite" gesetzt werden kann. Ein SameSite-Attribut von "strict" bedeutet, dass das Cookie nur auf der gleichen Site gelesen werden kann und somit das Lesen im 3rd-Party-Kontext verhindert wird. Alle alten Cookies werden als Cross Site Cookies (Cross Site) markiert.
• Anti-Fingerprint-Schutz, der insbesondere darin bestehen wird, die für das Fingerprinting notwendigen Datenpunkte im Browser für Javascripte unlesbar zu machen.
• Eine verbesserte Benutzeroberfläche soll Nutzern eine bessere Auswahl an Datenschutzeinstellungen ermöglichen.

Gleichzeitig kündigte Google in seinem Chromium-Planungsdokument Manifest v3 kürzlich eine Änderung an, die die Funktionen seiner webRequest-API einschränkt. Plugins verwenden diese, um das Blockieren von Werbung oder Tracking zu ermöglichen. Die Ankündigung bedeutet möglicherweise das Aus von externen Adblocking-Plugins – dennoch gehen auch hier die Meinungen über die Gründe weit auseinander.

EU-GDPR verändert unsere Arbeitsweise

In den letzten zwölf Monaten wurde fast alles über die im Mai 2018 in Kraft getretene EU-Datenschutzgrundverordnung (DSGVO) gesagt oder geschrieben. Trotzdem lohnt sich ein kurzer Blick auf die Auswirkungen auf unsere Branche und Programmatic Advertising im Speziellen.

Die DSGVO enthält Vorschriften zum Schutz natürlicher Personen bei der Verarbeitung personenbezogener Daten und zum freien Datenverkehr. Programmatische Werbung befasst sich in vielerlei Hinsicht mit der Erhebung, Verwendung, Umwandlung und Weitergabe solcher von der DSGVO definierten, personenbezogener Daten. Damit lassen sich bessere Ergebnisse bei Geboten (bid-pricing) und AdDelivery erzielen. Gleichzeitig gibt es aus vielen Gründen große Unterschiede im Umgang mit den Vorschriften.

Ein Schlüsselbereich für Stakeholder des Programmatic Advertising wird die Argumentation der Rechtmäßigkeit der Verarbeitung (Artikel 6, DSGVO) sein, die hauptsächlich in (a) Zustimmung, (b) Vertragserfüllung oder (f) berechtigtes Interesse zu trennen ist. Behält man die bevorstehende Veröffentlichung des IAB TCF v2.0 (Transparency and Consent Framework) im Hinterkopf, werden standardisierte Zwecke und Funktionen der Verarbeitung (Purposes/Features) eine Schlüsselrolle in der Diskussion entlang der gegebenen Rechtsgrundlagen spielen. Dazu gehören:

• Speicherung und Zugriff auf Informationen auf einem Gerät
• Profilerstellung
• Personalisiertes Targeting
• Erstellung von Multi-Device-Graphen
• Überprüfung / Betrugserkennung
• Geräteübergreifende grafische Darstellung
• Geo-Lokalisierung
• Fingerprinting

Was sind Lösungsbausteine?

Angesichts der skizzierten Herausforderungen für die Aufrechterhaltung der Identität und damit des Umsatzes in einem „Programmatic-first–Ökosystem“ – man erinnere sich an die Kausalkette – stellt sich die Frage, welche Lösungsbausteine ​​existieren. Meiner Meinung nach gibt es derzeit fünf Arbeitsschwerpunkte, mit denen wir uns beschäftigen müssen:

1. Persistente IDs
2. Server-to-Server Bidding
3. 1st Party AdDelivery
4. Datenschutzkonforme Datenerhebung, -speicherung und -nutzung
5. Permission Management

Ich möchte mich an dieser Stelle auf die ersten beiden Punkte konzentrieren.

Persistente IDs

Die Qualität von IDs steht und fällt mit ihrer Lebensdauer (= Persistenz / Speicherzeit), ihre Interoperabilität (Multi-Device-Fähigkeit) und ihre Marktdurchdringung / Skalierbarkeit (kann jeder sie generieren oder lesen / anpassen). Aus Gründen der Übersichtlichkeit ist es wichtig, die vorhandenen Lösungen zu gruppieren und zu charakterisieren. Im Allgemeinen finden wir:

• Login-basierte, deterministische Kennungen
  • Basierend auf einer eindeutigen Zeichenfolge gemäß z.B. UUID-Standard, E-Mail-Adresse oder datenbankgesteuerten Identifikatoren, die zusätzlich für die Pseudonymisierung gehasht wurden
  • Zuverlässig (= deterministischer Charakter) und präzise reproduzierbar
  • Persistent auf der Serverseite speicherbar
  • In der Regel nicht geräte-/ browser-abhängig und daher mehrgerätefähig
  • Aufgrund der Vielzahl von Websites ohne Login nicht unbedingt breit genug über die Nachfrage- / Angebotslandschaft verteilt (= Marktdurchdringung / Skalierbarkeit)
     
• Auf Fingerprinting basierende IDs, probabilistische Identifikatoren
  • Basierend auf statistischen Methoden (= probabilistisch), die oft nicht genau genug sind (hohe Wahrscheinlichkeit einer „false positive / negative“ Identifizierung und damit geringe Qualität der Identität
  • Umfangreiche Datenmengen erforderlich, um ordnungsgemäß zu funktionieren – je mehr Daten-Touchpoints pro Benutzer / Person desto genauer
  • Persistent auf der Serverseite
  • Potenziell Multi-Device-fähig (solange auf allen Geräten klassischer Web Access besteht)
  • Hohe Wahrscheinlichkeit einer Einschränkung durch Browser (siehe Chrome-Ankündigung zur Einschränkung der Fingerprint Möglichkeiten)
  • Meist Javascript abhängig. Das führt zu Performance und Usability Problemen, da sich die Internet-Nutzung immer mehr auf mobile Endgeräte verlagert und von nativen Apps dominiert wird
     
• Mobilgeräte-IDs
  • Gerätespezifisch / betriebssystemspezifisch = nicht geräteübergreifend
  • Übliche Vertreter: iOS IDFA, Android AAID, Windows ID
  • Nicht in der Web-Umgebung verfügbar, sondern nur in nativen Apps
  • Präzise, ​​aufgrund der Einzigartigkeit pro Gerät
  • Langlebig, solange Benutzer diese nicht zurücksetzen - was bisher selten der Fall ist
  • Aufgrund der Anzahl der Geräte und der Vielzahl der Betriebssysteme nicht identitätsorientiert, sondern gerätespezifisch und damit nur die halbe Miete
     
• Cookie- / lokale Speicher-IDs
  • Betriebssystem-, browser-, domänenspezifisch
  • Präzise, ​​aber geringe Persistenz aufgrund der Cookie-Löschmechanismen in Browsern
  • Veraltete Lösung aufgrund der zunehmenden Anzahl nativer Apps, die ohne die Integration von Webviews keine Cookies unterstützen