Safari ITP umgehen:
Same-Origin sGTM für 400-Tage-Cookies 2026

1. Was ITP genau macht

Intelligent Tracking Prevention ist Apples Anti-Tracking-Mechanismus in Safari. Lebt im WebKit-Browser-Engine, also Safari macOS, Safari iOS, jeder iPhone-Browser (Chrome auf iPhone nutzt WebKit, nicht Blink). ITP klassifiziert Domains anhand des User-Verhaltens als „Tracking" oder „nicht Tracking" und behandelt Cookies auf Tracking-Domains restriktiver.

Drei zentrale Mechanismen:

• 7-Tage-Cap für JavaScript-Cookies (alle Cookies via document.cookie)
• 24-Stunden-Cap für Cross-Site-Trackers (Cookies werden nach 24h gelöscht wenn Domain als Tracker klassifiziert)
• IP-Matching-Rule (Safari 16.4+): server-set Cookies nur volle Lifetime wenn IP zum Main-Site matched

2. Historie 2017-2026

3. Das Cookie-Kappungs-Problem konkret

Ein normales Google-Ads-Conversion-Tracking funktioniert so: User klickt Anzeige, GCLID wird in Cookie geschrieben (_gcl_aw), Cookie lebt 90 Tage, User kommt in 3 Wochen zurück und konvertiert, GCLID wird gesendet, Conversion wird attribuiert.

Mit Safari ITP: User klickt Anzeige, GCLID wird via JavaScript in Cookie geschrieben, Cookie wird durch ITP auf 7 Tage gekappt, User kommt in 3 Wochen zurück - Cookie ist weg, GCLID weg, Conversion nicht attribuiert. Aus Google-Sicht sieht es so aus als wäre der User „organisch" gekommen.

4. Safari 16.4 IP-Matching-Rule (das, was viele übersehen)

Bis Safari 16.4 (April 2023) gab es einen klaren Workaround: Cookies via HTTP Set-Cookie Header vom Server setzen statt via JavaScript. Server-set Cookies waren vom 7-Tage-Cap ausgenommen und lebten bis zu 400 Tage (Browser-Default).

Seit Safari 16.4 wurde das eingeschränkt: Server-set Cookies leben nur dann ihre volle Lifetime, wenn die IP-Adresse des Servers (oder zumindest das /16-Subnet-Präfix) zum IP-Präfix der Hauptdomain matcht. Wenn nicht: Cookie wird trotzdem auf 7 Tage gekappt.

Praktisches Beispiel: Deine Website läuft auf Cloudflare (104.21.x.x), dein sGTM auf Stape EU (34.107.x.x). Safari sieht: zwei verschiedene IP-Präfixe → behandelt sGTM-Cookies als „suspicious first-party" → kappt auf 7 Tage, selbst wenn du sie korrekt via Set-Cookie HTTP Header setzt.

5. Warum CNAME Cloaking heute tot ist

Eine alte Workaround-Technik war CNAME Cloaking: lege Subdomain an (track.example.com), zeige diese per DNS-CNAME auf Tracking-Provider-Server (z.B. track.example.com → customer.adobe.com). Aus Browser-Sicht ist die Subdomain First-Party, faktisch trackt Adobe.

Safari/WebKit erkennt CNAME Cloaking seit 2020. Mechanismus: Safari macht DNS-Lookup, prüft ob CNAME-Target außerhalb der eTLD+1 liegt (i.e. „outside the registrable domain"), wenn ja → behandelt als Tracker, kappt JavaScript-Cookies auf 7 Tage. CNAME Cloaking ist heute funktional tot.

6. Wie viel das wirklich kostet

Realer Impact je nach Geschäftsmodell:

Verlust = Safari-Marktanteil × Anteil der User die nach 7+ Tagen konvertieren. Safari-Anteil Deutschland: ~17 % Desktop, ~30 % Mobile. Im Mobile-First-Commerce überproportional schmerzhaft.

Was das für deine Conversion-Tools bedeutet: bei Meta CAPI werden fbc und fbp Cookies gekappt - dein EMQ-Score sinkt für Safari-User. Bei Google Ads Enhanced Conversions überlebt der GCLID-Cookie nur 7 Tage - Conversions ohne Email-Match werden nach einer Woche nicht mehr attribuiert. Same-Origin sGTM rettet beide Tools gleichzeitig.

7. Die drei Lösungswege

Drei technische Optionen, je nach Setup-Komplexität:

8. Same-Origin sGTM via Cloudflare Worker

Konkretes Setup für die meisten Cases - Cloudflare-Site fronted Stape-sGTM:

1. Cloudflare Worker erstellen: Dashboard → Workers & Pages → Create Worker
2. Worker-Code schreiben (siehe unten)
3. Route binden: example.com/sgtm/* → Worker
4. sGTM-Tagging-URL ändern in Web-Container von https://sgtm.example.com auf https://example.com/sgtm
5. Container publishen + Live-Test

export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    // Strip /sgtm prefix, forward to Stape endpoint
    const targetPath = url.pathname.replace(/^\/sgtm/, '');
    const targetUrl = 'https://sgtm.example.com' + targetPath + url.search;

    // Rebuild request with original method, headers, body
    const proxyRequest = new Request(targetUrl, {
      method: request.method,
      headers: request.headers,
      body: request.body,
      redirect: 'manual'
    });

    const response = await fetch(proxyRequest);

    // Pass through Set-Cookie headers (critical!)
    // Cloudflare merges them automatically
    return new Response(response.body, {
      status: response.status,
      headers: response.headers
    });
  }
};

Was hier passiert: Cloudflare empfängt Requests an example.com/sgtm/*, proxied sie zu Stape weiter, gibt die Antwort inklusive Set-Cookie Headers zurück. Aus Browser-Sicht: alle Requests landen auf example.com - selbe Domain, selbe IP-Range, kein IP-Matching-Problem, Cookies leben 400 Tage.

9. Alternative: Stape Custom Loader Power-Up

Wenn du keinen Cloudflare Worker bauen willst, bietet Stape das Custom Loader Power-Up an (~$20/Monat extra). Es injectet einen kleinen Loader-Script in deine Hauptdomain der dann alle sGTM-Anfragen über deine Hauptdomain routet. Funktional dasselbe Resultat wie der Worker-Ansatz, aber Stape macht die Infrastruktur für dich.

1. Stape Dashboard → dein Container → Power-Ups
2. Custom Loader aktivieren
3. Stape generiert Code-Snippet - dieses VOR dem GTM-Script auf deiner Website einfügen
4. Sub-Domain auf Same-Origin-Path umschalten in den Container-Settings
5. Test im Safari ITP Debug Mode

10. Test im Safari ITP Debug Mode

So verifizierst du dass deine Cookies jetzt nicht mehr gekappt werden:

1. Safari öffnen → Preferences → Advanced → „Show Develop menu" aktivieren
2. Menubar → Develop → Experimental Features → ITP Debug Mode aktivieren
3. Website besuchen → Develop → Show Web Inspector → Storage → Cookies
4. Bei jedem Cookie die Expires-Spalte prüfen - sollte 400 Tage in der Zukunft sein, nicht 7 Tage
5. Console-Tab nach ITP Debug: Logs durchsuchen - dort steht warum ein Cookie gekappt wurde

11. DSGVO bleibt unverändert

Die Same-Origin-Lösung ändert nichts an deinen DSGVO-Pflichten:

• ✓ Consent Mode v2 aktiv: Cookies feuern nur mit Einwilligung
• ✓ Privacy Policy erwähnt alle Tracking-Cookies, auch wenn sie als First-Party gesetzt werden
• ✓ AVV mit Stape/Cloudflare: Auftragsverarbeitungs-Vertrag nach Art. 28 DSGVO
• ✓ Datenminimierung: 400-Tage-Cookie nur für Daten die du wirklich brauchst (z.B. GCLID, Session-ID)

Wichtig: Längere Cookie-Lifetime macht das Tracking NICHT „mehr datenschutz-konform" - du musst trotzdem alle DSGVO-Anforderungen erfüllen. Es macht es nur technisch funktionstüchtig für Safari-Nutzer.

12. FAQ

Was ist Safari ITP genau?

Intelligent Tracking Prevention ist Apples Anti-Tracking-Mechanismus in Safari (seit 2017). Seit 2019 kappt ITP alle per JavaScript gesetzten Cookies auf maximal 7 Tage. Seit Safari 16.4 (April 2023) kappt es auch server-seitig gesetzte Cookies, wenn die Server-IP nicht zum Main-Site-IP-Präfix matcht. Resultat: Attribution-Daten verschwinden nach einer Woche - was Performance-Bidding zerstört.

Warum hilft normaler Server-Side GTM nicht automatisch gegen ITP?

Wenn dein sGTM-Container auf einer Subdomain läuft (z.B. sgtm.example.com via Stape) und das IP-Präfix der Stape-Server nicht zum IP-Präfix deines Hauptservers matcht, behandelt Safari 16.4+ es weiter als „suspicious" und kappt Cookies auf 7 Tage. Die meisten Stape-Setups treffen dieses Problem - die Lösung ist Same-Origin Path-Based Setup.

Was ist CNAME Cloaking und warum funktioniert es nicht mehr?

CNAME Cloaking war eine alte Technik: Subdomain (track.example.com) per CNAME auf Drittanbieter-Server zeigen lassen, damit es wie First-Party aussieht. Safari/WebKit erkennt das seit 2020 und kappt alle JavaScript-Cookies auf solchen Subdomains auf 7 Tage. CNAME Cloaking ist heute funktional tot - nicht mehr nutzen.

Was ist die Lösung gegen Safari ITP?

Same-Origin Path-Based sGTM: statt der Subdomain sgtm.example.com läuft sGTM unter example.com/sgtm/ über einen Reverse Proxy (Cloudflare Worker, Nginx, oder Stape Custom Loader Power-Up). Da Same-Origin, gibt es keine IP-Matching-Probleme und Cookies können bis zu 400 Tage gesetzt werden. Google empfiehlt dieses Setup explizit.

Wie viel macht der Unterschied wirklich aus?

Safari-Anteil in Deutschland ~17-20 % Desktop, in Mobile ca. 30 %. Bei 7-Tage-Cookie-Cap verschwinden alle Safari-Nutzer aus der Attribution sobald sie eine Woche zwischen Klick und Conversion warten. Bei B2B-Sales-Cycles (Wochen bis Monate) sind das schnell 15-25 % verlorene Attribution. Mit 400-Tage-Cookies via Same-Origin sGTM bleibt die Attribution erhalten.

Ist Same-Origin sGTM DSGVO-konform?

Ja - DSGVO-Konformität hängt nicht von der technischen Cookie-Lifetime ab, sondern von Consent Mode v2, korrekter Privacy Policy, AVV mit Anbietern und Datenminimierung. Same-Origin Path-Based sGTM ändert nichts an diesen Pflichten - im Gegenteil, durch First-Party-Charakter wird die Datenhoheit beim Werbetreibenden klarer geregelt.