Click-Attribution nach Safari ITP: Was 2026 noch funktioniert

Apple veröffentlichte die erste Version von Intelligent Tracking Prevention im September 2017. Es wurde als Datenschutzfunktion dargestellt, was auch zutrifft. Gleichzeitig war es eine systematische Demontage jedes Workarounds, den die Ad-Tech-Branche seit dem ersten Bröckeln des Third-Party-Cookie-Ökosystems um 2013 herum aufgebaut hatte. Jede neue ITP-Version schloss den Ausweg, den Marketer in der vorherigen Version gefunden hatten. Bis zum Erscheinen von ITP 2.3 im Jahr 2019 war die Abfolge der Schließungen so gründlich, dass die einzigen Attributionspfade, die auf Safari noch zuverlässig funktionierten, diejenigen waren, die nie von Cross-Site-Tracking abhängig waren.

Dieser Beitrag führt Sie in zeitlicher Abfolge durch diese Sequenz: was jede Version unterbunden hat, welcher Workaround damit gezielt geschlossen werden sollte und wo die Attribution im Jahr 2026 steht. Der ergänzende Beitrag Cookieless attribution explained deckt die breitere Landschaft über verschiedene Browser hinweg ab; dieser hier befasst sich spezifisch mit Safari und dem Redirect-Chain-Muster, das all dies überlebt.

TL;DR#

• ITP 2.0 (2018) blockierte jeglichen Zugriff auf Third-Party-Speicher auf seitenübergreifenden Domains und beendete damit den Standard-Attributionspfad über Ad-Pixel in Safari.
• ITP 2.1 (2019) begrenzte via JavaScript gesetzte First-Party-Cookies auf 7 Tage, was einjährige Attributionsfenster über Tag-Manager beendete.
• ITP 2.2 und 2.3 entfernten Link-Dekorationsparameter und stuften Referrer-Header herab, wodurch die letzten Query-String-Workarounds geschlossen wurden.
• Ein Short-Link auf Ihrer eigenen Domain setzt zum Zeitpunkt des Redirects serverseitig ein First-Party-Cookie – dies ist das einzige Muster, das ITP in all seinen Versionen übersteht und Ihnen ein zuverlässiges 7-tägiges Attributionsfenster in Safari ermöglicht.

Die ITP-Timeline: Eine Aufschlüsselung Version für Version#

ITP erschien nicht fix und fertig aus dem Nichts. Es wurde schrittweise veröffentlicht, wobei jede Version auf eine bestimmte Klasse von Workarounds abzielte, die die Branche als Reaktion auf die vorherige Version entwickelt hatte. Die Sequenz zu verstehen ist wichtig, da die technische Form dessen, was überlebt hat, dadurch definiert wird, was wie geschlossen wurde.

ITP 1.0 - September 2017. Die erste Version klassifizierte Domains basierend auf Bounce-Frequenz und Nutzersignalen als "Cross-Site-Tracker". Domains, die als Tracker eingestuft wurden, erhielten partitionierte Cookies – sie konnten zwar gesetzt, aber in einem seitenübergreifenden Kontext nur gelesen werden, wenn der Nutzer in den letzten 24 Stunden direkt mit der Domain des Trackers interagiert hatte. Für eine Domain wie ein Standard-Analytics-Pixel, die Nutzer nie direkt aufrufen, war das 24-Stunden-Fenster de facto eine Blockade.

ITP 1.1 - März 2018. Advertiser reagierten auf 1.0, indem sie die Attribution über Redirect-Ketten leiteten, die die Tracker-Domain als First-Party-Landing-Point berührten, bevor sie zum Ziel weiterleiteten. Dies verschaffte den Nutzern einen "direkten Besuch" auf der Tracker-Domain, was den Interaktions-Timer zurücksetzte. ITP 1.1 identifizierte dieses Muster – bekannt als Bounce-Tracker – und entfernte den Interaktions-Status, den Bounce-Redirect-Ketten generierten. Domains, die scheinbar nur für das Bounce-and-Redirect-Muster existierten, verloren ihren Interaktions-Status.

Was ITP 2.0 unterbunden hat#

ITP 2.0 erschien im September 2018. Es war der strukturelle Bruch. Wo 1.x Third-Party-Cookies partitioniert hatte, ging 2.0 weiter: Es entfernte den Zugriff auf Third-Party-Speicher für klassifizierte Domains vollständig. Cookies, localStorage, IndexedDB, Cache-Daten – all das wurde für jede Domain blockiert, die ITP als Cross-Site-Tracker einstufte.

Die praktischen Auswirkungen auf die Ad-Tech-Branche waren erheblich. Das Facebook Pixel, der Google Ads Conversion-Tag und die meisten Retargeting-Pixel hängen davon ab, ein seitenübergreifendes Cookie zu lesen, um einen Klick mit einer Conversion zu verknüpfen. In Safari schlug dieser Lesezugriff nach ITP 2.0 fehl. Metas eigene Berichte zeigten damals eine Lücke von 15–25 % in der Event-Abdeckung bei Safari-Traffic – Klicks und Conversions, die das Pixel in Chrome oder Firefox sah, tauchten bei Safari-Nutzern einfach nicht mehr auf.

Die Speichersperre war nicht auf Cookies beschränkt. Skripte, die versuchten, Identifikatoren im localStorage unter einer als Tracker klassifizierten Domain zu speichern oder Service Worker zur Persistenz zu nutzen, wurden gleichermaßen blockiert. Die Absicht von 2.0 war es, die Third-Party-Speicherschicht für Tracking-Zwecke strukturell unzugänglich zu machen, statt nur eine spezifische Technik zu unterbinden.

Was ITP 2.1 unterbunden hat#

Nachdem 2.0 die Third-Party-Attribution beendet hatte, zielte ITP 2.1 (März 2019) auf den Workaround ab, der als Reaktion darauf entstanden war: First-Party-Cookie-Attribution via Tag-Manager-Injektion.

Die Logik war schlüssig. Wenn das Third-Party-Pixel blockiert war, konnte man die Attribution immer noch sichern, indem man ein First-Party-Cookie auf der eigenen Domain des Advertisers via JavaScript schrieb – typischerweise injiziert durch einen Tag-Manager wie GTM. Das Cookie war First-Party und unterlag daher nicht den Third-Party-Speicherbeschränkungen von ITP. Viele Teams waren zu einjährigen Attributionsfenstern übergegangen, die so gesetzt wurden, in der Annahme, dass ein document.cookie-Schreibzugriff sicher sei.

ITP 2.1 begrenzte alle via document.cookie gesetzten Cookies – unabhängig vom First-Party- oder Third-Party-Status – auf maximal 7 Tage. Die Begrenzung galt spezifisch für per Skript gesetzte Cookies; Cookies, die über den Set-Cookie HTTP-Response-Header gesetzt wurden, waren von 2.1 nicht betroffen. Die Unterscheidung ist präzise und folgenschwer: document.cookie = "..." in JavaScript ist auf 7 Tage begrenzt. Set-Cookie: ...; Max-Age=31536000 aus einer Server-Antwort ist es nicht.

Das unmittelbare Opfer war das GTM-basierte Attributions-Setup. GTM schreibt Cookies durch JavaScript auf der Seite. Diese Cookies liefen nun in Safari nach 7 Tagen ab, ungeachtet ihres angegebenen Ablaufdatums. Ein Nutzer, der an einem Dienstag auf einen Kampagnen-Link klickte und am darauffolgenden Mittwoch konvertierte, lag außerhalb des Attributionsfensters. Das einjährige First-Party-Cookie-Attributionsfenster, zu dem die Teams nach ITP 2.0 migriert waren, war Geschichte.

Was ITP 2.2 unterbunden hat#

ITP 2.2 verschärfte zwei Bereiche. Erstens reduzierte es die JavaScript-Cookie-Begrenzung auf 24 Stunden in dem spezifischen Fall, in dem die Zielseite von einer Domain verlinkt wurde, die ITP als Cross-Site-Tracker klassifiziert hatte. Wenn ein Nutzer auf einen Link auf der Seite einer klassifizierten Domain klickte, wurden die First-Party-Cookies auf der Zielseite, die via JavaScript gesetzt wurden, auf 24 Stunden begrenzt – nicht auf 7 Tage. Die 7-Tage-Grenze blieb für nicht getrackte Referrer-Pfade bestehen, aber die 24-Stunden-Grenze galt, wenn die Klick-Kette eine klassifizierte Domain enthielt.

Zweitens, und weithin beachtet, führte ITP 2.2 Einschränkungen für die Link-Dekoration ein. Ad-Plattformen und Analytics-Tools hatten ein Muster entwickelt, bei dem Attributions-Identifikatoren als Query-Parameter an Ziel-URLs angehängt wurden – gclid für Google Ads, fbclid für Meta, msclkid für Microsoft Advertising. Unter bestimmten Bedingungen begann ITP, wenn die verlinkende Domain als Tracker klassifiziert war, diese Parameter vor dem Laden der Seite zu entfernen oder die Cookies zu begrenzen, die als Reaktion auf deren Vorhandensein gesetzt werden konnten.

Dies war ein direkter Angriff auf den gclid-basierten Attributionspfad, zu dem Teams nach 2.0 und 2.1 gewechselt waren. Die Begründung war explizit: Apple betrachtete nutzerbasiertes Tracking über Query-Parameter in Bezug auf den Datenschutz als gleichwertig mit Cookie-basiertem Tracking, weshalb dieselben Einschränkungen gelten sollten.

Was ITP 2.3 unterbunden hat#

ITP 2.3 (September 2019) schloss zwei verbleibende Lücken.

Die erste war das Referrer-Downgrading bei seitenübergreifender Navigation. Während sich vorherige Versionen auf Speicher und Link-Parameter konzentriert hatten, befasste sich 2.3 mit dem Referrer-Header – dem Referer-Wert, den eine Seite erhält, wenn ein Nutzer von einer anderen Seite dorthin navigiert. Bei seitenübergreifenden Navigationen von klassifizierten Domains stufte ITP 2.3 den Referrer auf "Origin-only" herab: https://classified-domain.com/ anstelle des vollständigen https://classified-domain.com/path?campaign=spring&source=email. Der Pfad und der Query-String, die oft Attributions-Kontext enthielten, wurden entfernt.

Die zweite Änderung weitete die Speicher-Begrenzungs-Logik aus. Zusätzlich zur 7-Tage-Grenze für JavaScript-Cookies wendete ITP 2.3 nach einem einzigen seitenübergreifenden Klick von einer klassifizierten Domain eine Speicherbegrenzung an: Jeglicher clientseitige Speicher auf der Zielseite – Cookies, localStorage, IndexedDB – unterlag der Begrenzung. Ziel war es, eine Klasse von statusbehafteten Attributionsmustern zu schließen, bei denen allein der Akt der Verlinkung von einer klassifizierten Domain einen Countdown für die Fähigkeit der Zielseite startete, Daten zu persistieren.

Zusammen schlossen 2.2 und 2.3 die drei Hauptwege, die Teams nach 2.0 und 2.1 genutzt hatten: Link-Dekorationsparameter, Referrer-basierte Attribution und Speicher-Akkumulation über seitenübergreifende Klick-Ketten.

Was überlebt#

Die ITP-Sequenz war methodisch, aber sie zielte auf Cross-Site-Tracking ab. Die Muster, die überleben, sind diejenigen, die tatsächlich First-Party sind – wo die Attributionsdaten auf Ihrer eigenen Domain erfasst, über Ihren eigenen Server gesetzt werden und niemals den Speicher einer Third-Party-Domain passieren.

Serverseitig gesetzte First-Party-Cookies. Die Cookie-Begrenzung von ITP 2.1 gilt für document.cookie-Schreibvorgänge via JavaScript. Cookies, die von einem Server über den Set-Cookie HTTP-Response-Header gesetzt werden, behalten ihr angegebenes Ablaufdatum. Die entscheidende Einschränkung ist, dass das Cookie auf der Domain gesetzt werden muss, die der Server kontrolliert.

Serverseitiges Event-Forwarding. Wenn die Klick-ID zum Zeitpunkt des Redirects erfasst und serverseitig gespeichert wird, ist der Attributions-Abgleich zum Zeitpunkt der Conversion eine Server-to-Server-Operation. Es muss kein Browser-Cookie 7 Tage überleben; die Klick-ID befindet sich in Ihrer Datenbank. Dies ist die Architektur hinter server-side conversion tracking und der Ansatz, für den Meta CAPI, GA4 Measurement Protocol und TikTok Events API konzipiert wurden.

Deterministisches Matching via gehashter E-Mail oder Telefonnummer. Wenn ein Nutzer authentifiziert ist oder eine E-Mail-Adresse übermittelt hat, kann die Conversion der ursprünglichen Klick-ID über den E-Mail-Hash zugeordnet werden, statt über die Cookie-Identität. Dieser Pfad ist völlig unabhängig von ITP – er war nie auf Browser-Speicher angewiesen. Die Einschränkung ist die Abdeckung: Es funktioniert nur für Nutzer, die sich innerhalb des Attributionsfensters identifiziert haben.

Der vollständige technische Kontext für diese Muster findet sich in Cookieless attribution explained.

Das Short-Link-Redirect-Muster#

Short-Links auf Ihrer eigenen Domain – nicht auf einer gemeinsam genutzten Shortener-Domain – ermöglichen Ihnen den Weg über server-gesetzte Cookies in einer Form, die natürlich mit Kampagnen-Traffic funktioniert.

Die Mechanik ist unkompliziert. Wenn ein Nutzer auf einen Kampagnen-Link klickt, der auf go.acme.example/spring26 zeigt, trifft die Anfrage auf einen Edge-Handler auf go.acme.example. Der Edge-Handler erfasst das Klick-Event, generiert eine Klick-ID und setzt einen Set-Cookie-Header in der Redirect-Antwort – ein serverseitig gesetztes First-Party-Cookie auf acme.example. Anschließend erfolgt der 302-Redirect zur Ziel-URL, wobei die Klick-ID als Query-Parameter angehängt wird.

Da das Cookie über Set-Cookie vom Server zum Zeitpunkt des Redirects gesetzt wird, greift die 7-Tage-JavaScript-Begrenzung von ITP 2.1 nicht. Das Cookie behält die vom Server konfigurierte Gültigkeitsdauer. In Safari überlebt ein serverseitig gesetztes Cookie auf go.acme.example bei voll aktivem ITP 2.3 das gesamte konfigurierte Zeitfenster. Wir setzen bei Elido standardmäßig ein 7-tägiges Ablaufdatum, da dies ohnehin der restriktivsten ITP-Beschränkung für JS-gesetzte Cookies entspricht, und das serverseitig gesetzte Cookie hält diese vollen 7 Tage durch.

Die Zielseite liest dann die Klick-ID aus dem Cookie oder dem Query-Parameter (je nachdem, was verfügbar ist), schreibt sie in den Warenkorb oder die Bestellattribute, und das Conversion-Event überträgt sie zum Kaufzeitpunkt serverseitig. Es ist keine Third-Party-Domain involviert. Das Cookie befindet sich auf Ihrer Domain. Der Attributions-Abgleich ist eine serverseitige Operation. ITP hat nichts, was es blockieren könnte.

Deshalb ist die Unterstützung von Custom-Domains für einen Short-Link-Workspace für die Attribution so wichtig: nicht nur für das Branding, sondern für die cookie first-party classification. Eine gemeinsam genutzte Shortener-Domain wie bit.ly oder short.io ist ein anderer Origin als Ihre Website. Ein auf bit.ly gesetztes Cookie ist ein Third-Party-Cookie auf acme.example; ITP 2.0 blockiert es. Ein auf go.acme.example gesetztes Cookie ist First-Party; ITP rührt es nicht an. Die Seite solutions/marketers deckt den Kampagnen-Attributions-Flow von Anfang bis Ende ab.

Für tiefergehende Informationen zum DSGVO-Kontext, welche Klick-Daten ein Shortener rechtmäßig verarbeiten darf und wie man Datenminimierung im Klick-Event-Schema konfiguriert, siehe GDPR for URL shorteners.

Was immer noch nicht funktioniert#

Ehrlichkeit ist besser, als eine Teillösung als Allheilmittel zu verkaufen.

Seitenübergreifende View-Through-Attribution. Wenn ein Nutzer eine Anzeige auf publisher.example sieht, ohne zu klicken, und später auf advertiser.example konvertiert, gibt es keinen ITP-sicheren Pfad für diese Attribution. View-Through erfordert von Natur aus ein seitenübergreifendes Signal von der Impression zur Conversion. Safari blockiert dies, und die oben beschriebenen serverseitigen Forwarding-Ansätze sind klickbasiert – sie erfordern den Klick, um das First-Party-Cookie zu setzen oder die Klick-ID zu schreiben.

Echtzeit-Stitching für nicht authentifizierte Nutzer. Wenn ein Nutzer konvertiert, ohne sich jemals einzuloggen oder eine E-Mail-Adresse zu hinterlassen, ist die Klick-ID aus dem Cookie oder Query-Parameter der einzige verfügbare Identifikator. Wenn das Cookie abgelaufen ist (nach mehr als 7 Tagen nach dem ersten Klick oder 24 Stunden bei der strengeren Begrenzung von 2.2), geht die Verknüpfung verloren. Die serverseitige Speicherung der Klick-ID löst dies für Conversions innerhalb des Fensters. Es löst es nicht für Conversions, die erst nach Ablauf des Fensters eintreffen.

Attributionsfenster von mehr als 7 Tagen auf Safari für First-Touch. Wenn Ihr Geschäftsmodell einen Kaufzyklus von Wochen oder Monaten hat – üblich im B2B-SaaS, im hochwertigen E-Commerce oder bei Finanzdienstleistungen – bedeutet das 7-Tage-Fenster für First-Party-Cookies in Safari, dass ein erheblicher Teil der Conversions ihrem ursprünglichen Klick nicht zugeordnet werden kann. Für diese Geschäftsmodelle ist der deterministische E-Mail-Hash-Pfad die einzige Option; probablistische Attribution auf Safari ist nicht zuverlässig genug, um darauf basierend Entscheidungen zu treffen.

Fingerprinting als Ersatz. Canvas-Fingerprinting, Audio-Fingerprinting und Font-Enumeration sind Workarounds, die versuchen, Nutzer über Sitzungen hinweg ohne Cookies wiederzuerkennen. Apple ist explizit dazu übergegangen, die Fingerprinting-Oberfläche in Safari zu reduzieren. Die ITP 2.3 Release Notes erwähnen "zusätzlichen Schutz gegen andere Formen von Cross-Site-Tracking", und diese Richtung wurde in jedem nachfolgenden Safari-Release beibehalten. Fingerprinting birgt zudem erhebliche rechtliche Risiken unter DSGVO Artikel 6, wie in GDPR for URL shorteners erläutert. Es ist kein tragfähiger Ersatz für die oben beschriebenen Muster.

Praktischer Ausgangspunkt#

Das Redirect-Muster funktioniert. Richten Sie eine Custom-Domain in Ihrem Short-Link-Workspace ein (go.yourdomain.example), leiten Sie Kampagnen-Traffic darüber und konfigurieren Sie Ihre Zielseite so, dass sie den Query-Parameter elido_click oder das First-Party-Cookie liest und vor der Conversion des Nutzers in die Bestell- oder Warenkorbattribute schreibt. Leiten Sie die Conversions dann serverseitig über die Conversions-API an die Ad-Plattformen weiter. Das 7-Tage-Fenster deckt für die meisten Kampagnentypen den Großteil der Click-to-Conversion-Pfade ab.

Für das Conversion-Forwarding-Setup – Meta CAPI, GA4 Measurement Protocol, die Retry-Semantik und die Deduplizierung – ist server-side conversion tracking die technische Ergänzung zu diesem Beitrag. Für die Produktoberfläche ist conversion tracking features der Ausgangspunkt.

ITP hat die Attribution nicht getötet. Es hat eine spezifische Architektur der Attribution getötet – diejenige, die auf dauerhaftem seitenübergreifendem Speicher und undifferenzierter Datenakkumulation über Domains hinweg aufbaute, die man nicht kontrolliert. Die Architektur, die sie ersetzt hat, ist besser vertretbar, nicht schlechter.