Safari 27 und die Messbarkeit 2027: Was technisch blockiert wird und welche Tracking-Architektur standhält

Safari kann Messanfragen blockieren oder Angaben aus einer Anfrage entfernen. Ein erfolgreich gesendetes Ereignis enthält deshalb nicht automatisch eine brauchbare Herkunftsangabe. Für die Planung 2027 zählt der tatsächlich geprüfte Datenweg: Was erreicht den Server, was darf ein Skript lesen und was erscheint anschließend im Bericht?

Die Quellenprüfung vom 25. Oktober 2026 trennt dokumentierte Funktionen von offenen Fragen. Apples Versionshinweise zu Safari 27 belegen keine vollständige neue Liste gesperrter Werbenetze oder URL-Parameter. Der öffentliche WebKit-Code zeigt mögliche Filter und Rechte, aber keine verlässliche Liste aller aktuell ausgelieferten Regeln. Konkrete neue Einträge wie xmt, si oder bestimmte Anbieter werden hier deshalb nicht als bestätigte Safari-27-Sperren behandelt. Ein eigener Safari-Gerätetest wurde für diesen Beitrag nicht durchgeführt. [1, 4, 5]

Welche Schutzmechanismen belegt sind

Die Funktionen haben unterschiedliche Aufgaben. Ein Netzwerkfilter verhindert eine Verbindung. Link Tracking Protection entfernt bestimmte Kennungen aus einer Adresse. Fingerprinting-Schutz erschwert die Wiedererkennung anhand von Gerätemerkmalen. Eine Cookie-Grenze verkürzt dagegen die Speicherung einer Kennung. Diese Fälle brauchen jeweils einen eigenen Test.

Die Tabelle fasst vorhandene Mechanismen zusammen und ordnet keine neue Schutzstufe pauschal jeder Safari-Version zu. Einstellungen, privates Surfen, Inhaltsblocker und die konkrete Anfrage können das Ergebnis verändern. Nationale Browseranteile ersetzen keine Auswertung des eigenen Website-Verkehrs. [2, 3, 6]

Fehlende Daten trotz erfolgreicher Anfrage

Eine leere Herkunftsangabe lässt sich prüfen: Im Netzwerkprotokoll stehen die tatsächlich übertragenen Felder. Eine erfolgreiche HTTP-Antwort bestätigt zunächst nur die Übertragung. Erst der Vergleich von Eingabe, gesendeten Daten und Bericht zeigt, an welcher Stelle Angaben fehlen. Ein höherer Anteil „Direct“ allein beweist keinen Safari-Filter.

Fingerprinting-Schutz bedeutet außerdem nicht, dass jede Abfrage neue Zufallswerte liefert. WebKit beschreibt unter anderem veränderte Ausgaben und vereinheitlichte Gerätemerkmale; bestimmte Audio-Werte bleiben innerhalb eines Puffers konsistent. Daraus folgt keine allgemeine Aussage, dass sämtliche Fingerprints unmöglich sind. [7]

Im öffentlich gelesenen WebKit-Code erfolgt eine Skriptzuordnung unter anderem anhand von Hostnamen und Domains. Die Schnittstellen enthalten getrennte Rechte etwa für Cookies, lokale Speicherung, URL-Parameter und Netzwerkanfragen. Dieser Entwicklungsstand ist kein Nachweis für die vollständigen Regeln einer installierten Safari-27-Version. Auch die pauschale Vererbung aller Einschränkungen von einem Tag-Container auf jedes nachgeladene Skript ist damit nicht belegt. [4, 5]

Was eine eigene Domain verändert

Ein Collection-Endpoint ist ein solcher Annahmepunkt für Messereignisse. Ein Reverse Proxy kann Anfragen unter einem eigenen Pfad an einen internen Dienst weiterreichen. Der Browser sieht dann den eigenen Pfad. Das ersetzt weder eine Prüfung der gespeicherten Daten noch erforderliche Einwilligungen.

URL-Parameter und Cookies getrennt prüfen

Link Tracking Protection kann Kennungen bereits vor dem Laden der Zielseite entfernen. Dann erreicht die entfernte Angabe auch den Server nicht. Kampagnenparameter und die Leserechte eines Skripts sind getrennte Fragen: Ein Parameter kann auf dem Server ankommen, während ein eingeschränktes Skript keinen Zugriff darauf erhält. Privates Surfen und die zusätzliche Einstellung für alle Browsing-Vorgänge gehören deshalb in die Testmatrix. [3, 7]

UTM-Parameter wie utm_source benennen eine Kampagnenquelle. Eine Click-ID bezeichnet dagegen einen bestimmten Anzeigenklick. Eine Kampagnenzuordnung auf UTM-Basis ist hilfreich, rekonstruiert aber keine entfernte Click-ID und beweist keine einzelne Anzeigenwirkung.

Bei Server-Cookies unter einer eigenen Subdomain können CNAME- und IP-Prüfungen greifen. Ein CNAME ist ein DNS-Verweis auf einen anderen Namen. WebKit beschreibt Beschränkungen für bestimmte Fälle, in denen eine eigene Subdomain einen Drittanbieter verdeckt. Daraus folgt keine identische Behandlung jedes Cookies von einer abweichenden Server-IP. [6]

Für einen konkreten Test werden der ausgesendete Set-Cookie-Header, die im Browser gespeicherte Ablaufzeit und die spätere Verfügbarkeit verglichen. Ein Ablaufdatum nach sieben Tagen kann auch vom Server selbst stammen. Ein Pfad auf der Hauptdomain kann bestimmte Unterschiede im Datenweg vermeiden, garantiert aber keine längere Speicherung. HttpOnly verhindert JavaScript-Zugriff; daraus folgt keine Ausnahme von Safaris Speicherregeln.

Ein überprüfbarer Aufbau für 2027

1. Erhebung begrenzen. Erforderliche Einwilligungen und zulässige Zwecke müssen bereits die Erhebung und Speicherung steuern, nicht erst die Weiterleitung. Eine eigene Datenbank macht eine Erfassung nicht automatisch zulässig.
2. Verfügbare Herkunft erfassen. Der Server erhält die tatsächlich angefragte URL. Der Referer-Header kann fehlen oder nur die Herkunfts-Domain enthalten; ein URL-Fragment nach # gehört nicht dazu. Bereits entfernte Parameter lassen sich dadurch nicht zurückholen. [8]
3. Weiterleitung je Ziel prüfen. GA4 Measurement Protocol ergänzt die reguläre Erfassung; eine reine Umstellung darauf kann unvollständige Berichte erzeugen. Eine allgemeine event_id entfernt nicht automatisch alle GA4-Doppelungen. Für Käufe in Web-Datenstreams beschreibt Google die Deduplizierung über transaction_id. [9, 10]
4. Eigene Ereignisse nachvollziehbar speichern. Eine erlaubte, zweckgebundene Tabelle kann den Eingang und die Weiterleitung vergleichen. Diese Tabelle enthält nur eingegangene Ereignisse und ist kein vollständiges Verzeichnis aller Besuche.

Weniger JavaScript kann die Seite entlasten. Eine Verbesserung der Ladezeit oder der Reaktionszeit auf Eingaben muss jedoch am konkreten Aufbau gemessen werden.

Messlücken mit einer klaren Zählbasis untersuchen

Der Vergleich beginnt mit demselben Seitenabruf auf beiden Seiten: Eine eindeutige Request-ID verbindet einen ausgelieferten HTML-Abruf mit dem zugehörigen Pageview-Ereignis. Ein Abruf mit zwei wiederholten Ereignissen zählt weiterhin nur einmal. Browser-Cache, interne Navigation ohne neuen HTML-Abruf, Bots und Vorabladen benötigen eigene Regeln.

Die Testmatrix umfasst normales und privates Safari, erweiterten Schutz für alle Vorgänge, Links aus Mail oder Nachrichten und einen Vergleichsbrowser. Je Fall werden URL am Server, gesendete Ereignisfelder, blockierte Anfragen und Cookie-Verhalten protokolliert. Browser-Version, Einstellungen, Einwilligungszustand und aktivierte Inhaltsblocker gehören zum Ergebnis.

Das folgende BigQuery-Beispiel verwendet zwei projektspezifische Tabellen, keinen fertigen GA4-Export. measurement_allowed darf nur wahr sein, wenn die Erfassung dieses Abrufs zum Messzweck zulässig ist und eine dafür erforderliche Einwilligung vorliegt. is_prefetch, is_bot und is_document_request sind zuvor aufbereitete Log-Felder. Der Zeitraum endet einen Tag vor der Auswertung, damit verspätete Ereignisse Zeit zum Eintreffen haben; ein Tag ist keine Garantie für vollständigen Nachlauf.

WITH bounds AS (
  SELECT TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 29 DAY) AS start_ts,
         TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 DAY) AS end_ts,
         CURRENT_TIMESTAMP() AS checked_at
), raw_logs AS (
  SELECT l.*, COUNT(*) OVER (PARTITION BY request_id) AS id_rows
  FROM server_access_logs AS l CROSS JOIN bounds AS b
  WHERE l.ts >= b.start_ts AND l.ts < b.end_ts
), logs AS (
  SELECT browser_family, request_id,
    REGEXP_CONTAINS(
      SPLIT(COALESCE(url, ''), '#')[OFFSET(0)],
      r'[?&](gclid|msclkid|fbclid|twclid)=[^&#]+'
    ) AS has_click_id
  FROM raw_logs
  WHERE is_document_request AND NOT is_bot AND NOT is_prefetch
    AND measurement_allowed
    AND request_id IS NOT NULL AND TRIM(request_id) != ''
    AND id_rows = 1
), hits AS (
  SELECT DISTINCT request_id
  FROM analytics_events AS e CROSS JOIN bounds AS b
  WHERE event_name = 'page_view'
    AND e.ts >= b.start_ts AND e.ts < b.checked_at
    AND request_id IS NOT NULL AND TRIM(request_id) != ''
)
SELECT l.browser_family,
       COUNT(*) AS document_requests,
       ROUND(SAFE_DIVIDE(COUNTIF(h.request_id IS NOT NULL), COUNT(*)), 3)
         AS capture_rate,
       ROUND(SAFE_DIVIDE(COUNTIF(l.has_click_id), COUNT(*)), 3)
         AS click_id_share
FROM logs AS l LEFT JOIN hits AS h USING (request_id)
GROUP BY l.browser_family
ORDER BY document_requests DESC;

capture_rate ist der Anteil eindeutig zugeordneter Dokumentabrufe mit mindestens einem Pageview. click_id_share bezieht sich auf alle berücksichtigten Dokumentabrufe, nicht nur auf bezahlte Einstiege. Die Abfrage schließt fehlende, leere und innerhalb des Zeitfensters mehrfach vorkommende Request-IDs aus. Anzahl und Ursachen dieser Ausschlüsse müssen separat kontrolliert werden. Die Zuordnung setzt über alle Abrufe hinweg eindeutige IDs voraus.

Eine niedrigere Safari-Quote ist ein Untersuchungshinweis, kein isolierter Browser-Effekt. Unterschiedliche Einwilligungen, Inhaltsblocker, Erkennungsfehler und Datenverluste können ebenfalls beitragen. Für eine Click-ID-Quote bezahlter Einstiege braucht die Zählbasis zusätzlich zuverlässig erkannte Kampagnen-Landings. Mehr „Direct“ oder weniger wiederkehrende Besuche sind weitere Hinweise, aber kein eindeutiger Nachweis einer bestimmten Safari-Regel.