Safari 27 Tracking-Schutz: Was das für die Conversion-Messung bedeutet

Safari 27 wurde im Juni 2026 als Entwickler-Beta veröffentlicht. Die offiziellen Release-Notes befassen sich mit CSS-Korrekturen und Verbesserungen bei der Darstellung. Wir sind noch einen Schritt weiter gegangen und haben den Open-Source-Code von WebKit unter github.com/WebKit/WebKit unter die Lupe genommen – also die Datenschutz-Infrastruktur, die tatsächlich steuert, wie Safari mit Tracking-Anfragen umgeht. Hier ist, was wir herausgefunden haben.

Dies ist eine Fortsetzung unserer Analyse zu Safari 26. Wenn du Hintergrundinformationen zum erweiterten Fingerabdruck-Schutz und zur Funktionsweise des Link-Tracking-Schutzes suchst, fang dort an. In diesem Beitrag geht es um die Neuerungen in Version 27.

Die offiziellen Versionshinweise von Apple zu Safari 27 Beta sind auf der Apple-Entwickler-Website verfügbar.

Eine strukturelle Veränderung, die alles andere noch schlimmer macht

Bevor wir ins Detail gehen, gibt es eine Erkenntnis aus der Quelle, die wichtig ist, um alles, was jetzt folgt, richtig zu verstehen.

Die Datenschutzregeln von Safari sind nicht fest in die Browser-Binärdatei integriert. Welche Klick-IDs entfernt, welche Skripte eingeschränkt und welche IP-Adressen blockiert werden: Apple speichert all das in einer separaten Systembibliothek, die unabhängig von Safari selbst aktualisiert wird. Apple kann eine neue Tracking-Domain, einen neuen Klick-ID-Parameter oder einen neuen IP-Bereich eines Werbenetzwerks zur Sperrliste hinzufügen, ohne ein Browser-Update veröffentlichen zu müssen. Jedes Gerät, auf dem Safari installiert ist, kann aktualisierte Regeln im Hintergrund automatisch erhalten.

Das bedeutet in der Praxis: Selbst wenn Apple in einer bestimmten Safari-Version keine Änderungen bezüglich des Trackings ankündigt, können sich die Regeln, nach denen deine Kampagnen laufen, jederzeit ändern. Das Safari-27-Update erweitert diese Listen, aber das nächste Update der Listen könnte ohne öffentliche Ankündigung erscheinen.

Der Link-Tracking-Schutz deckt jetzt mehr Plattformen ab

Seit Safari 17 entfernt Safari bekannte Tracking-Parameter aus URLs. Im privaten Modus, in Mail und in Nachrichten verschwinden Klick-IDs, noch bevor die Zielseite überhaupt geladen wird. Die Liste der betroffenen Parameter wird mit jeder neuen Version länger.

Neu in Safari 27: Drei weitere Plattformen werden in den Filter aufgenommen:

• Threads: xmt wurde entfernt
• YouTube: „si“ wird entfernt
• X (ehemals Twitter): twclid, cn und cxt werden entfernt

Google- und Meta-Klick-IDs wurden bereits behandelt. Das Hinzufügen von Threads, YouTube und X ist für alle wichtig, die auf diesen Plattformen bezahlte Kampagnen schalten.

twclid ist die primäre Klick-ID von X und erfüllt dieselbe Funktion wie gclid bei Google Ads. si ist eine Share-Source- und Sitzungs-ID, die an YouTube-Share-Links angehängt wird. Es handelt sich dabei nicht um eine ID für bezahlte Klicks wie bei twclid, doch durch ihre Entfernung geht der Quellenkontext des YouTube-Traffics in Safari-Sitzungen verloren. Der Verlust einer der beiden Kennungen in Safari-Sitzungen führt zu derselben Attributionslücke, die Google-Ads-Werbetreibende bereits aus der Handhabung von gclid durch Safari kennen.

LTP wird beim normalen (nicht privaten) Surfen mit Safari noch schrittweise eingeführt. Ab Safari 26 wurden Klick-IDs in Standardsitzungen weiterhin weitergeleitet. Apple geht üblicherweise so vor, dass zuerst die Liste erweitert wird und die Durchsetzung erst in einem späteren Update auf das normale Surfen ausgeweitet wird. Die Parameter sind nun vorhanden. Die Durchsetzung in allen Sitzungen ist der logische nächste Schritt.

AFP ist kein Binärblock

In den meisten Berichten über „Advanced Fingerprinting Protection“ heißt es: „Safari blockiert diese Skripte.“ Der Quellcode liefert ein detaillierteres Bild, und das ist wichtig, um zu verstehen, welche Teile deines Trackings tatsächlich nicht mehr funktionieren.

Wenn Apple ein Skript als Fingerprinting-Tool einstuft, blockiert es dieses nicht einfach nur. Es weist diesem Skript vielmehr bestimmte Berechtigungen zu: eine Liste dessen, worauf das Skript zugreifen darf und worauf nicht. Zu den Kategorien, die Apple einzeln widerrufen kann, gehören:

• URL-Abfrageparameter (Klick-IDs, UTM-Werte)
• Verweisdaten (Traffic-Quelle)
• Zugriff auf Cookies
• Zugriff auf den lokalen Speicher
• Canvas-API (eine gängige Plattform für Fingerprinting)
• Bildschirmgröße und Abmessungen des Darstellungsbereichs
• Informationen zur Hardware-Parallelität
• Netzwerkanfragen

Ein als „classified“ eingestuftes Skript verliert möglicherweise den Zugriff auf URL-Parameter und Referrer-Daten, kann aber weiterhin Netzwerkanfragen stellen. Oder es darf keine Canvas- und Audio-APIs mehr nutzen, behält aber den Zugriff auf Cookies. Die konkreten Auswirkungen hängen davon ab, welche Berechtigungen Apple für dieses bestimmte Skript entzieht.

Das LinkedIn Insight Tag (snap.licdn.com) steht auf der Fingerprinting-Liste. Für das Conversion-Tracking sind die gravierendsten Einschränkungen der Verlust des Zugriffs auf Abfrageparameter (es kann keine Klick-ID ausgelesen werden) und der Verlust von Referrer-Daten (keine Zuordnung der Traffic-Quelle). Das Skript kann zwar weiterhin eine Netzwerkanfrage an die Server von LinkedIn senden, doch ohne die Identifikatoren, die nötig sind, um eine Conversion einem Klick zuzuordnen, lassen sich die gesendeten Daten nicht mit einer Kampagne verknüpfen.

Auf derselben Liste stehen Tealium, Segment, DPG Media und Blueonic.

Wenn eine CDP wie Tealium oder Segment als Fingerprinting-Tool eingestuft wird, gelten für jedes Tag, das sie auslöst, dieselben Einschränkungen. Ein Conversion-Pixel, das über einen eingeschränkten CDP-Container bereitgestellt wird, verliert denselben Zugriff wie ein direkt als Fingerprinting-Tool eingestuftes Skript.

Apple nutzt die eigenen Werbeerkennungslisten von Chromium

Aus der Quelle geht hervor, dass der „Resource Monitor“ von Safari – also die Funktion, die ganze Tracking-Endpunkte und nicht nur einzelne Parameter blockiert – seine Regeln in dasselbe Format zusammenfasst, das auch von Safari-Erweiterungen zum Blockieren von Inhalten verwendet wird. Die eigentlichen Filterdaten stammen aus der Systembibliothek von Apple.

Wenn man sich die Regeln auf einem Gerät mit Safari 27 Beta ansieht, stimmen die Blockierungsmuster mit den Filtereinträgen aus der Open-Source-Infrastruktur zur Werbeerkennung von Chromium überein. Apple greift auf dieselben Filterdaten zurück, die Google für Chromium-basierte Browser entwickelt und als Open Source zur Verfügung gestellt hat.

Quelle: https://github.com/chromium/chromium-ads-detection

Die Blockierung findet nun unterhalb der Anwendungsschicht statt

Frühere Versionen des Tracking-Schutzes in Safari funktionierten auf der Anwendungsebene. Skripte wurden blockiert oder eingeschränkt, bevor sie ausgeführt werden konnten, oder Netzwerkanfragen wurden anhand des Domainnamens blockiert. In Safari 27 wird ein Teil der Blockierung auf die Netzwerk-Transportschicht verlagert, die unterhalb aller Elemente auf der Seite läuft.

Wenn ein Skript versucht, Konversionsdaten zu senden, baut es eine Netzwerkverbindung zu einem Zielserver auf. Safari 27 fängt diese Verbindung ab, bevor sie hergestellt ist. Dabei wird nicht der Inhalt der Anfrage überprüft, sondern die Ziel-IP-Adresse mit einer Liste bekannter Subnetze von Werbenetzwerken abgeglichen.

Beispielsweise ist bat.bing.com der UET-Endpunkt von Bing. Er verweist auf die Werbeinfrastruktur von Microsoft. Befindet sich der IP-Bereich des Microsoft-Werbeservers auf der Sperrliste, wird die Verbindung unterbrochen, bevor Daten den Browser verlassen. Dabei spielt es keine Rolle, woher das Skript stammt, von welcher Domain es geladen wurde oder wie die Anfrage aufgebaut war.

First-Party-Proxy-Konfigurationen sind eine gängige Umgehungslösung, bei der du ein Tracking-Skript von deiner eigenen Subdomain lädst. Diese Umgehungslösung hilft hier jedoch nicht weiter. Das Skript wird zwar von deiner Domain geladen, muss seine Daten aber dennoch an die Server einer Werbeplattform senden. Diese Server haben feste IP-Adressen. Genau diese Verbindung zu diesen IP-Adressen blockiert Safari.

In der Quelle gibt es außerdem Hinweise auf eine separate Kategorie von Domains, die fest als bedingungslos blockierbar hinterlegt sind – unabhängig davon, welche Datenschutzeinstellungen der Nutzer aktiviert hat. Der Mechanismus ist im Code sichtbar; der konkrete Inhalt dieser Liste ist es jedoch nicht, da er sich in einer unveröffentlichten Apple-Datei befindet. Betrachte die Existenz dieser Kategorie als beobachtet und ihren genauen Umfang als unbestätigt.

Der Blockierverlauf von Safari, Schicht für Schicht

Mit jeder größeren Version kommt eine neue Oberfläche hinzu.

• 2017: Mit dem ITP wurden Einschränkungen für Cookies und Speicherfristen eingeführt
• Safari 17: ATFP hat im privaten Modus die Netzwerkblockierung auf Domain-Ebene sowie das Entfernen von Klick-IDs aus Links eingeführt
• Safari 26: AFP hat die Klassifizierung von Fingerprinting-Skripten in allen Browsermodi eingeführt, mit der Möglichkeit, Berechtigungen für einzelne Skripte zu widerrufen
• Safari 27: Sperrung von IP-Bereichen auf der Netzwerk-Transportschicht, ein erweiterter Klick-ID-Filter und CDPs auf der Fingerprinting-Liste

Frühere Schutzmaßnahmen zielten darauf ab, was Skripte lesen oder speichern konnten. Die Blockierung auf Netzwerkebene zielt darauf ab, wohin Daten gelangen können. Du kannst den Dateinamen eines Skripts, einen URL-Pfad oder eine First-Party-Subdomain ändern. Die IP-Adressen, auf denen die Ad-Server von Microsoft oder LinkedIn gehostet werden? Die ändern sich nicht.

Wo TAGGRS passt

Server-side GTM verändert die Architektur so, dass die Einschränkungen auf Browserebene von Safari keine Rolle mehr spielen. Nicht, weil es irgendetwas auf raffinierte Weise umgeht, sondern weil die Tracking-Anfragen, die Safari blockiert, gar nicht erst durch den Browser laufen.

Bei einer standardmäßigen clientseitigen Konfiguration führt der Browser das Skript aus, liest die benötigten Daten von der Seite aus und sendet die Konversionsanfrage an den Endpunkt einer Werbeplattform. Die Netzwerkschicht von Safari erkennt diese ausgehende Verbindung und blockiert sie.

Mit sGTM sendet der Browser eine Anfrage an deinen eigenen Server, deine eigene Subdomain, deine eigene IP-Adresse. Der Server übernimmt von dort aus alles. Er verarbeitet die Events und leitet die Daten über Server-zu-Server-Aufrufe an Google, Meta, LinkedIn oder Bing weiter, ohne dass diese jemals den Browser des Nutzers passieren. Es gibt nichts, was Safari abfangen könnte.

bat.bing.com und snap.licdn.com werden auf Domain- und IP-Ebene blockiert. Mit sGTM ruft dein Setup diese URLs niemals vom Browser aus auf. Die Verbindungen zu den Werbeplattformen werden auf dem Server hergestellt, nachdem die Browser-Interaktion bereits aufgezeichnet wurde.

Das „Enhanced Tracking Script“ von TAGGRS fügt eine weitere Ebene hinzu : Es verschlüsselt die Anfrage vom Browser zum Server, wodurch verhindert wird, dass Ad-Blocker durch Mustererkennung die Anfrage als Tracking-Traffic identifizieren, noch bevor sie die Seite überhaupt verlässt.

Bei LinkedIn ist der praktische Ansatz „Linkedin CAPI“ über den sGTM-Container, wobei das Insight-Tag durch einen server-side Conversion-Aufruf ersetzt wird. Bei Bing ist es das entsprechende Microsoft Ads API. Beide lösen die Abhängigkeit von der browserseitigen Skriptausführung, die Safari nun blockiert.

Die Vorteile summieren sich. Da die Konvertierungsanfrage vom Browser aus niemals den Endpunkt einer Werbeplattform erreicht, gibt es für die Netzwerkschicht von Safari nichts abzufangen, und die Blockierung hat schlichtweg keine Angriffsfläche.

Außerdem behältst du die Kontrolle über deine First-Party-Daten : Das Event landet zuerst auf deinem Server, sodass du bestimmst, was weitergeleitet wird und wie. Die Ladezeiten verbessern sich, da ressourcenintensive clientseitige Tags von der Seite entfernt werden. Die Lösung ist langlebiger als Browser-Workarounds. Wenn Apple eine Blockliste erweitert oder eine neue Safari-Version veröffentlicht, muss eine server-side Architektur nicht neu gepatcht werden, da sie von vornherein nie von der Ausführung auf der Browserseite abhängig war.

Was bereits auf dem Spiel steht

Die stabile Version von Safari 27 wird zusammen mit iOS 27 und macOS 27 ausgeliefert, die voraussichtlich im Laufe des Jahres 2026 erscheinen werden. Die Quellenanalyse ermöglicht es, die Sicherheitslücken zu erfassen, bevor das Update in die Produktion geht.

YouTube- und X-Kampagnen – „si“ und „twclid“ sind im neuen Klick-ID-Filter enthalten. Bei der Attribution für Safari-Nutzer, die auf YouTube-Links oder X-Anzeigen klicken, wird es zu Lücken kommen, sobald die LTP-Durchsetzung auf das normale Surfen ausgeweitet wird. YouTube gehört zu den Werbeplattformen mit dem höchsten Traffic. „twclid“ ist die primäre Klick-Kennung von X. Beides ist kein Randfall.

CDPs, die Conversion-Tags verarbeiten – Tealium und Segment stehen auf der Liste der Fingerprinting-Skripte. Jedes Conversion-Pixel oder Remarketing-Tag, das über eine eingeschränkte CDP ausgelöst wird, unterliegt denselben Zugriffseinschränkungen. Die CDP selbst wird zum Schwachpunkt, nicht das einzelne Tag.

LinkedIn Insight Tag und Bing UET – das Insight Tag steht auf der Fingerprinting-Liste, wobei der Zugriff auf Abfrageparameter und Referrer gesperrt wurde. Der Bing-UET-Endpunkt wird sowohl auf Domain-Ebene als auch über das IP-Subnetz blockiert. Beides wurde durch die Quellenanalyse bestätigt.

First-Party-Proxy-Einrichtungen – Die Blockierung auf Netzwerkebene in Safari überprüft die Ziel-IP-Adresse, nicht die Ursprungsdomain des Skripts. Ein Proxy auf deiner eigenen Domain leitet die Daten weiterhin an die Server einer Werbeplattform weiter. Die Verbindung zu diesen Servern wird unterbrochen.

Jede browserbasierte Umgehungslösung – wie First-Party-Proxys, umbenannte Skripte oder neue Subdomains – fällt unter die aktuellen Blockierungsmaßnahmen von Safari. Durch server-side Tracking werden die Conversion-Daten komplett aus diesen Bereichen herausgenommen, sodass Safari nichts mehr abfangen kann.

Wenn du sehen möchtest, wie diese Konfiguration in der Praxis funktioniert, findest du in unserer detaillierten Anleitung zu Safari 26 eine ausführliche Beschreibung der sGTM-Architektur.

Bist du bereit, mit dem server-side Tracking loszulegen? Erstelle ein kostenloses TAGGRS-Konto.

FAQ

Blockiert Safari Tracker wirklich?

Ja. Safari blockiert auf mehreren Ebenen: Cookie-Einschränkungen (Intelligent Tracking Prevention), Netzwerkblockierung auf Domain-Ebene im privaten Modus (Private Browsing 2.0), Einschränkungen für Fingerprinting-Skripte (Safari 26.0-Versionshinweise von WebKit), sowie die Blockierung von IP-Bereichen auf der Netzwerk-Transportschicht in Safari 27 (bestätigt durch eine Analyse des WebKit-Quellcodes, noch nicht in Apples öffentlichen Versionshinweisen dokumentiert). Browserbasiertes Tracking für Safari-Nutzer wird mit jeder neuen Version unzuverlässiger. Server-side Konfigurationen sind davon nicht betroffen, da keine Tracking-Anfragen den Browser passieren.

Welche Parameter entfernt Safari 27 aus URLs?

Im privaten Modus und beim Öffnen von Links aus „Mail“ oder „Nachrichten“ entfernt Safari mithilfe des Link-Tracking-Schutzes eine ständig wachsende Liste von Klick -ID-Parametern. Apple erklärt den Mechanismus dort: Bekannte Tracking-Abfrageparameter werden vor dem Aufruf entfernt, und Skripte von Drittanbietern auf der Zielseite können die vollständige URL nicht lesen. Neu in Safari 27: xmt (Threads), si (YouTube), twclid, cn, cxt (X/Twitter). Zu den bereits zuvor abgedeckten Parametern gehören gclid, fbclid und msclkid. Hintergrundinformationen dazu, warum Klick-IDs in URLs überhaupt eine Rolle spielen, findest du im ITP 2.3-Beitrag von WebKit zum Thema „Link Decoration“. Standard-UTM-Parameter (utm_source, utm_medium, utm_campaign) sind davon nicht betroffen.

Werden sich diese Änderungen auch auf das normale Surfen mit Safari auswirken?

Der Schutz vor Link-Tracking im normalen (nicht privaten) Surfmodus wird schrittweise eingeführt. Ab Safari 26 werden Klick-IDs in Standardsitzungen weiterhin weitergeleitet. Safari 27 erweitert die Filterliste, aber Apple führt die Durchsetzung in der Regel schrittweise ein. Nutzer können bereits jetzt den stärkeren Schutz im privaten Modus für alle Sitzungen aktivieren – über den „Erweiterten Schutz vor Tracking und Fingerprinting“ (in den Safari-Einstellungen auf „Alle Browsersitzungen“ eingestellt; siehe Apples Safari-Anleitung). Die vollständige Durchsetzung in allen Sitzungen ohne diese Umschaltoption ist das Ziel, auf das Apple hinarbeitet.

Was ist AFP, und blockiert es ein Skript vollständig?

AFP (Advanced Fingerprinting Protection) stuft Skripte als Fingerprinting-Tools ein und wendet auf jedes einzelne eine bestimmte Reihe von Zugriffsbeschränkungen an. Es handelt sich nicht um eine pauschale Sperre. In der Ankündigung zu WebKits Safari 26.0 wird beschrieben, was eingeschränkt wird: APIs, die Geräteeigenschaften preisgeben (Bildschirmgröße, Hardware-Parallelität, Canvas, Audio), durch Skripte geschaffener Speicher (Cookies, localStorage) und Navigationsdaten (Abfrageparameter, document.referrer). Apple kann einige dieser Einschränkungen aufheben, während andere bestehen bleiben. Die praktischen Auswirkungen hängen davon ab, welche Zugriffsrechte Apple für das jeweilige Skript entzieht. Die ursprüngliche Version des „Private Browsing“-Modus wird im Abschnitt „Advanced Fingerprinting Protection“ von WebKit erläutert.

Was ist der Unterschied zwischen AFP und ATFP?

AFP (Advanced Fingerprinting Protection) schränkt den Zugriff auf bestimmte Fingerprinting-Skripte ein. ATFP (Advanced Tracking and Fingerprinting Protection) ist die für den Nutzer sichtbare Safari-Einstellung, die den Schutz des privaten Browsens – einschließlich des Entfernens von Link-Parametern und des Blockierens von Trackern auf Domain-Ebene – auf das normale Surfen ausweitet, wenn sie aktiviert ist. Der WebKit-Beitrag zu „Privates Surfen 2.0“ behandelt beides: AFP kümmert sich um die Einschränkungen für Fingerprinting-Skripte, während der Schalter „Erweiterter Schutz vor Tracking und Fingerprinting“ steuert, ob LTP und das Blockieren von Trackern auch außerhalb des privaten Surfens gelten. ATFP ist standardmäßig nur im privaten Surfen aktiviert. Die AFP-Schutzmaßnahmen wurden in Safari 26 auf alle Sitzungen ausgeweitet. Apples Übersicht für Verbraucher zu diesen Funktionen findest du unter apple.com/privacy/features.