Apples härteres Vorgehen gegen übergreifende Identifier wurde Anfang Oktober ersichtlich, als im öffentlichen Webkit-Bugtracker eine Liste blockierter Adtech-Domains auftauchte. Inzwischen hat sich der Konzern offiziell dazu geäußert. Die Quintessenz: Safaris Browser-Engine Webkit blockiert Netzwerkzugriffe zu bestimmten Domains, über die Nutzer:innen anhand dauerhafter Kennungen über Websites und Geräte hinweg wiedererkannt werden können.

ID5 will nun mehr seiner Identity-Infrastruktur serverseitig betreiben, wie CEO Mathieu Roche gegenüber Digiday erklärte. Funktionen, die bislang über Aufrufe von Drittanbieter-Domains im Browser liefen, könnten stattdessen über Infrastruktur des Publishers ausgeführt werden. Dadurch lassen sich die betreffenden Requests nicht mehr auf dieselbe Weise direkt durch Safari blockieren. Erste Integrationen werden laut Digiday bereits mit ausgewählten Publishern getestet.

Auch das Trusted Server Framework des IAB Tech Lab rückt damit wieder stärker in den Fokus. Das Open-Source-Modell verlagert unter anderem Ad Requests, Auktionen und Creative-Auslieferung in eine serverseitige Umgebung unter der Aufsicht des Publishers. Das soll Publishern mehr Kontrolle über technische Abläufe und First-Party-Daten geben, ist allerdings auch mit zusätzlichem Infrastruktur- und Integrationsaufwand verbunden.

Hierzulande spielen in der ID-Landschaft unter anderem Utiq und NetID eine größere Rolle in den Bidstreams. Für diese europäischen Identity-Lösungen lässt sich der Schritt von ID5 allerdings nicht eins zu eins übertragen, denn Utiq arbeitet bereits mit First-Party- und serverseitigen Komponenten. Publisher richten für den Dienst eine eigene Subdomain ein, über die unter anderem serverseitig gesetzte First-Party-Cookies verwaltet werden. Erst nach erteilter Zustimmung wird der sogenannte Adtechpass erzeugt, der anschließend über Prebid oder OpenRTB als Identifier an Supply- (SSP) und Demand-Side-Plattformen (DSP) weitergegeben werden kann.

Auch NetID folgt einem anderen Ansatz. Das Herzstück der deutschen Technologie ist ein Single Sign-on, über das Nutzer sich bei verschiedenen Angeboten anmelden und Einwilligungen verwalten können. Die darauf basierenden Angebote arbeiten ebenfalls mit einem serverseitigen Identifier zur Wiedererkennung von Nutzern. Webkit grenzt Login-Provider in seiner Erklärung ausdrücklich von den angegriffenen Identity-Resolvern ab. Für die programmatische Aktivierung kann eine NetID dennoch ebenfalls als Identifier in den Bidstream gelangen. Utiq unterstützt beispielsweise die Weitergabe einer im Browser vorhandenen NetID über sein Prebid-Modul.

Damit hängt die Wirkung von Apples Sperren von der jeweiligen Architektur ab: wo eine ID entsteht, wo sie gespeichert wird und über welchen technischen Weg sie schließlich in die programmatische Lieferkette gelangt.

Wie verbreitet solche Identifier im Programmatic Advertising inzwischen sind, zeigt eine im September veröffentlichte Studie von Forschenden des New Jersey Institute of Technology (NJIT) sowie Beteiligten von Adalytics und Deepsee.io. Untersucht wurden sogenannte Extended Identifiers (EIDs). Über dieses standardisierte Feld in OpenRTB können unterschiedliche Identity-Lösungen ihre Nutzerkennungen in Programmatic-Requests übermitteln.

Über einen Zeitraum von 41 Monaten analysierte das Team mehr als 145 Millionen Header-Bidding-Requests von rund 616.000 Websites. Im Mai 2025 übermittelten 83,76 Prozent der untersuchten Websites mindestens eine EID. Zwölf der 18 analysierten Identity-Anbieter erzeugten demnach IDs, die eine Wiedererkennung über Websites, Geräte und längere Zeiträume ermöglichen konnten. Bei 16 Anbietern beobachteten die Forschenden zudem EID-Übertragungen auf EU-Websites, obwohl ihr Crawler keine Consent-Banner bediente und keine ausdrückliche Einwilligung erteilte. Die Autoren und Autorinnen sehen darin Hinweise darauf, dass solche Identifier auch ohne vorherige aktive Zustimmung übertragen werden können.

Die Verlagerung der Identity-Resolution auf die Server-Seite entzieht Teile der ID-Infrastruktur zunächst dem direkten Zugriff der Browser-Sperre, aber an der grundsätzlichen Haltung in Cupertino mit Blick auf Cross-Site- und Cross-Device-Identifizierung ändert das nichts. Man kann derzeit nur spekulieren, ob serverseitige Modelle dauerhaft außerhalb der Webkit-Sperren bleiben oder Apple seine Regeln einfach auf weitere technische Ebenen ausweitet.