Safari 27 i mierzalność w 2027 roku: co jest technicznie blokowane i jaka architektura trackingu się utrzyma

Safari 27 odbiera trackingowi po stronie przeglądarki trzy kolejne podstawy: odczyt danych kontekstowych przez skrypty zaklasyfikowane jako śledzące, połączenia ze znanymi zakresami adresów sieci reklamowych oraz kolejne identyfikatory kliknięć (click ID). Kto w 2027 roku chce mieć wiarygodne liczby, musi przenieść zbieranie danych z przeglądarki na własną infrastrukturę – i dokładnie zmierzyć, jak duża jest dziś luka.

Dlaczego ten temat ma znaczenie w 2027 roku

Od 14 września 2026 dostępny jest iOS 27 z Safari 27 (Improvado). To kolejny etap procesu, który od 2017 roku rok po roku odbiera kawałek pomiaru po stronie przeglądarki.

W Niemczech Safari odpowiadało w czerwcu 2026 za 16,8% wszystkich odsłon na wszystkich urządzeniach (Statcounter), w Austrii za 18,1% (Statcounter). Na smartfonach udział wynosił w lipcu 2025 ponad jedną czwartą: 28,4% (Statista). Luka pomiarowa w Safari dotyczy więc odczuwalnej części każdego zbioru danych, a w handlu mobilnym często części o największej sile nabywczej.

Wokół Safari 26 i 27 krąży wiele półprawd. „Safari blokuje Google Tag Managera” jest równie nieścisłe jak „nic się nie zmienia”. Ten artykuł oddziela udokumentowane fakty od ustaleń z kodu źródłowego, wyjaśnia mechanikę każdej warstwy ochrony i kończy się architekturą referencyjną oraz listą kontrolną, która pozwala wyrazić w liczbach lukę Safari w danej witrynie.

Warstwy ochrony w skrócie

Każda generacja Safari docierała do kolejnego poziomu łańcucha pomiarowego: najpierw do pamięci, potem do adresów URL, potem do skryptów, a teraz do sieci.

Źródła: TAGGRS o Safari 27, TAGGRS o Safari 26, Snowplow o regule IP.

Potwierdzone a zaobserwowane: co jest oficjalne, a co pochodzi z kodu źródłowego

Oficjalne informacje o wydaniu Safari 27 nie zawierają żadnego wpisu o ochronie przed śledzeniem. Według analizy Improvado ani zapowiedź iOS 27 od Apple, ani informacje o wydaniu, ani wpis o nowościach w WebKit nie wspominają o zmianie w Link Tracking Protection (Improvado). Oficjalna dokumentacja Safari 26 sprowadza się w istocie do jednego zdania: ochrona przed fingerprintingiem przez znane skrypty śledzące.

Nowości w Safari 27 pochodzą z analizy otwartego kodu źródłowego WebKit, którą przeprowadził analytics engineer Mariusz Brucki i opublikował w lipcu 2026 (TAGGRS). Analiza jest szczegółowa, ale pochodzi od dostawcy infrastruktury do trackingu po stronie serwera. Dla planowania oznacza to, że mechanizmy są udokumentowane w kodzie, a ich dokładny zasięg w wydanej wersji każda witryna musi przetestować samodzielnie.

Najważniejsze ustalenie strukturalne dotyczy list reguł. Według analizy to, które click ID są usuwane, które skrypty ograniczane i które zakresy IP blokowane, zapisano w osobnej bibliotece systemowej. Apple może ją aktualizować niezależnie od przeglądarki, bez informacji o wydaniu i bez aktualizacji Safari.

Wynika z tego nowy sposób pracy: zgodność z Safari nie jest już projektem na każde duże wydanie, lecz stałym zadaniem monitoringu. Luka pomiarowa może powstać dowolnego dnia, nie tylko we wrześniu.

AFP w szczegółach: tag wysyła żądanie, a dane i tak pozostają puste

Advanced Fingerprinting Protection nie blokuje sklasyfikowanego skryptu w całości, lecz odbiera mu pojedyncze uprawnienia. Według analizy kodu źródłowego Apple może dla każdego skryptu osobno zablokować: parametry zapytania w URL (click ID, wartości UTM), referrer, dostęp do ciasteczek, Local Storage, Canvas API, wymiary ekranu i okna, informacje o sprzęcie oraz żądania sieciowe (TAGGRS).

Właśnie dlatego AFP jest zdradliwe dla analityki. Skrypt, który nadal może wysyłać żądania sieciowe, ale nie odczytuje ani query stringu, ani referrera, tworzy technicznie poprawne trafienie bez źródła. W zakładce sieci wszystko świeci na zielono, a w raporcie rośnie „Direct” albo „Unassigned”. Tej cichej utraty danych nie wychwyci żaden debuger tagów; widać ją dopiero w rozkładzie kanałów według przeglądarki.

Według analizy na liście fingerprintingu znajdują się między innymi LinkedIn Insight Tag oraz platformy CDP Tealium i Segment. Drugi punkt ma większe znaczenie: jeśli piksel konwersji jest wyzwalany przez sklasyfikowany kontener CDP, dziedziczy jego ograniczenia. Kontener staje się pojedynczym punktem awarii dla wszystkich tagów w nim umieszczonych.

Do tego dochodzi szum. Interfejsy API istotne dla fingerprintingu zwracają w Safari 26 przy każdym zapytaniu nieco inne wartości (gblock). Każda logika, która łączy cechy urządzenia w identyfikator, wytwarza przez to niestabilne ID. Skutkiem są sztucznie zawyżone liczby użytkowników, zaniżone wskaźniki powrotów i rozbite ścieżki klienta. Identyfikacja oparta na fingerprintingu jest więc w Safari nie tylko niepożądana, lecz po prostu bezużyteczna.

Warstwa sieciowa: liczy się cel, a nie pochodzenie skryptu

Według analizy kodu źródłowego Safari 27 sprawdza połączenia wychodzące z listą znanych podsieci sieci reklamowych i przerywa je, zanim zostaną nawiązane (TAGGRS). Dzieje się to poniżej strony, w warstwie transportowej. Przykładem z analizy jest punkt końcowy Bing UET bat.bing.com, blokowany zarówno po domenie, jak i po zakresie IP. Według analizy dane filtrów przypominają wpisy z otwartej infrastruktury Chromium do wykrywania reklam.

W tym miejscu powstaje najczęstsze nieporozumienie wokół „proxy first-party”. Istnieją dwa zasadniczo różne warianty:

Skrypt o zmienionej nazwie na własnej subdomenie nic więc w Safari 27 nie daje, dopóki wysyła dane bezpośrednio do platformy. Odporny jest tylko wariant, w którym przeglądarka komunikuje się wyłącznie z własną infrastrukturą witryny, a przekazywanie odbywa się między serwerami.

Otwarte pozostaje pytanie, jak AFP klasyfikuje skrypty hostowane samodzielnie. Z publicznych źródeł nie wynika jednoznacznie, czy klasyfikacja zależy od adresu URL skryptu, od wzorców w kodzie, czy od obu. Samodzielny hosting nie jest więc pewną ochroną przed odebraniem uprawnień, a jedynie przed blokadą domeny.

Link Tracking Protection: dłuższa lista, ten sam zakres

Link Tracking Protection usuwa znane click ID, zanim strona docelowa się załaduje. Według analizy kodu źródłowego w Safari 27 dochodzą nowe parametry (TAGGRS):

Według dokumentacji Apple zakres działania się nie zmienił: przeglądanie prywatne oraz linki z Poczty i Wiadomości (Improvado). Przy zwykłym przeglądaniu click ID domyślnie pozostają nienaruszone. Wyjątkiem są użytkownicy, którzy w ustawieniach Safari przestawili przełącznik ATFP na całe przeglądanie (w angielskim interfejsie „All Browsing”).

Standardowe parametry UTM, takie jak utm_source, utm_medium i utm_campaign, nie znajdują się na liście. Do przypisywania kanałów parametry UTM są zatem stabilniejsze niż click ID poszczególnych platform. Pozostają dwa zastrzeżenia: AFP i tak może zabronić sklasyfikowanym skryptom odczytu adresu URL, a dotychczasowy schemat Apple polegał na tym, by najpierw rozszerzyć listę, a później poszerzyć jej egzekwowanie.

Praktyczny wniosek: każda kampania powinna oprócz automatycznego tagowania (auto-tagging) zawierać poprawne parametry UTM. Dla atrybucji bardziej odpornym źródłem prawdy jest własne przypisanie kanałów oparte na UTM.

Niedoceniana pułapka: ciasteczka serwerowe i reguła prefiksu IP

Wiele konfiguracji po stronie serwera po cichu traci w Safari długoterminowe identyfikatory, choć uchodzą za „first-party”. Przyczyną jest reguła obowiązująca od Safari 16.4, która nigdy nie trafiła do informacji o wydaniu: ciasteczka ustawiane przez serwer wygasają po maksymalnie 7 dniach, jeśli pierwsza połowa adresu IP serwera ustawiającego nie zgadza się z adresem IP serwera odwiedzanej witryny (Snowplow). Dotyczy to zarówno IPv4, jak i IPv6.

Typowy przykład: witryna działa u dostawcy hostingu pod adresem 203.0.113.10, a serwer tagowania pod data.example.com w usłudze chmurowej z adresem 198.51.100.20. Mimo własnej subdomeny i ciasteczka HttpOnly Safari traktuje ten serwer jak stronę trzecią. Użytkownik, który wraca po dziesięciu dniach, pojawia się jako nowy.

Rozwiązanie leży w architekturze: punkt zbierania danych musi być obsługiwany z tej samej przestrzeni adresów IP co główny dokument. W praktyce sprawdza się ścieżka w domenie głównej, na przykład example.com/metrics, którą poprzedzający reverse proxy lub CDN przekazuje do serwera tagowania. Przeglądarka i witryna widzą wtedy ten sam adres IP, a czas życia ciasteczka zostaje zachowany.

Do kontroli wystarczy Web Inspector w Safari: w zakładce Storage widać czas wygaśnięcia ciasteczka z identyfikatorem. Jeśli widnieje tam data za siedem dni zamiast za rok, reguła działa.

Architektura referencyjna 2027: przeglądarka rozmawia już tylko z własną infrastrukturą

Pomiar odporny na Safari opiera się na jednej zasadzie: przeglądarka wysyła zdarzenia wyłącznie do punktu końcowego we własnej domenie i we własnej przestrzeni IP, a wszystko dalej odbywa się między serwerami. Blokada sieciowa, blokada domen i skracanie życia ciasteczek tracą wtedy jakikolwiek punkt zaczepienia na ścieżce pomiaru.

Koncepcja opiera się na pięciu elementach:

1. Punkt zbierania danych w tym samym originie. Ścieżka taka jak example.com/metrics, obsługiwana przez ten sam reverse proxy lub ten sam CDN co witryna. Wysyła tam dane lekki własny skrypt albo klient serwerowego menedżera tagów. Z przeglądarki nie wychodzą żadne połączenia do domen platform.
2. Zapis kontekstu przy żądaniu dokumentu. Serwer, który dostarcza stronę docelową, widzi pełny adres URL żądania i nagłówek Referer, niezależnie od tego, jakie uprawnienia AFP odbiera skryptowi. To tutaj serwer odczytuje click ID i wartości UTM i wiąże je z sesją. Granica: tego, co Link Tracking Protection usunęło przed nawigacją, nie otrzyma również serwer.
3. Stabilny identyfikator first-party. Ustawiany przez Set-Cookie z tej samej przestrzeni IP, z atrybutami HttpOnly, Secure i SameSite=Lax. Bez wyprowadzania z cech urządzenia, bo te w Safari i tak zwracają szum.
4. Przekazywanie po stronie serwera. Konwersje trafiają do API konwersji platform reklamowych, zdarzenia analityczne do punktów końcowych po stronie serwera, takich jak GA4 Measurement Protocol lub kontener serwerowy. Każde zdarzenie ma event_id, aby platformy mogły usuwać duplikaty z nadal działającymi tagami w przeglądarce. Status zgody jest przesyłany jako pole w każdym zdarzeniu i steruje przekazywaniem.
5. Własny magazyn surowych danych. Każde zdarzenie trafia najpierw do własnej tabeli, na przykład w BigQuery, ClickHouse lub PostgreSQL, i dopiero potem jest rozsyłane dalej. Ta tabela jest punktem odniesienia dla każdego monitoringu luk i uniezależnia pomiar od raportów platform.

Efekt uboczny: mniej JavaScriptu stron trzecich na stronie wyraźnie poprawia czas ładowania i Interaction to Next Paint.

Pomiar luki Safari: macierz testów, wskaźniki, zapytanie

Wielkość luki w danej witrynie da się wyrazić prostym porównaniem: logi serwera liczą każdą dostarczoną stronę, a analityka liczy tylko to, co dotrze do przeglądarki. Różnica w podziale na przeglądarki zawęża efekt przeglądarki. Nie wyodrębnia go jednak całkowicie: założeniem jest, że odrzucone zgody i blokery reklam działają w Chrome i Safari podobnie. Safari obsługuje własne blokery treści, a odsetek zgód może się różnić w zależności od przeglądarki. Odsetek zgód według przeglądarki z własnego logu zgód pokazuje, jaka część różnicy wynika z tego czynnika.

Ręczna macierz testów

Cztery wskaźniki do bieżącego monitoringu

1. Wskaźnik pokrycia według przeglądarki: zdarzenia odsłony podzielone przez żądania dokumentów z logów serwera po odfiltrowaniu botów.
2. Wskaźnik click ID: udział wejść z płatnych kampanii z click ID, Safari w porównaniu z Chrome w tej samej kampanii.
3. Udział „Direct” według przeglądarki: wartość rosnąca tylko w Safari wskazuje na odebrany dostęp do referrera lub adresu URL.
4. Wskaźnik powrotów po 8–30 dniach: jeśli w Safari gwałtownie spada, prawdopodobnie działa limit 7 dni.

Przykładowe zapytanie (BigQuery SQL)

Warunkiem jest identyfikator żądania, który serwer przy dostarczaniu zapisuje w dokumencie, a zdarzenie odsłony odsyła z powrotem. Dzięki temu wiersz logu i zdarzenie da się połączyć dokładnie.

-- Wskaźnik pokrycia i wskaźnik click ID według przeglądarki, ostatnie 28 dni
WITH logs AS (
  SELECT browser_family, request_id,
         REGEXP_CONTAINS(url, r'[?&](gclid|msclkid|fbclid|twclid)=') AS has_click_id
  FROM server_access_logs
  WHERE is_document_request AND NOT is_bot
    AND ts >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 28 DAY)
),
hits AS (
  SELECT DISTINCT request_id
  FROM analytics_events
  WHERE event_name = 'page_view'
    AND ts >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 28 DAY)
)
SELECT
  l.browser_family,
  COUNT(*) AS zapytania_dokumentow,
  ROUND(COUNTIF(h.request_id IS NOT NULL) / COUNT(*), 3) AS wskaznik_pokrycia,
  ROUND(COUNTIF(l.has_click_id) / COUNT(*), 3) AS wskaznik_click_id
FROM logs l
LEFT JOIN hits h USING (request_id)
GROUP BY l.browser_family
ORDER BY zapytania_dokumentow DESC;

Jeśli wskaźnik pokrycia (wskaznik_pokrycia) Safari jest o kilka punktów procentowych niższy niż w Chrome, jest to luka wynikająca z przeglądarki. Ponieważ Apple może zmieniać listy reguł bez aktualizacji, to zapytanie powinno trafić do codziennego dashboardu z alarmem przy skokowych zmianach.

Lista kontrolna na 2027 rok

Osiem punktów decyduje o tym, czy konfiguracja przetrwa Safari 27 i kolejne generacje.

Podsumowanie

Safari 27 wyznacza moment, w którym obejścia po stronie przeglądarki dochodzą do kresu. Skrypty o zmienionych nazwach, nowe subdomeny i proxy służące tylko do hostingu skryptów celują w miejsca, które Safari kontroluje dziś na głębszym poziomie. Wiarygodny pozostaje pomiar, w którym udział przeglądarki ogranicza się do jednego żądania do własnej domeny.

Największą dźwignią na 2027 rok nie jest przy tym kolejne narzędzie, lecz widoczność. Kto codziennie oblicza wskaźnik pokrycia według przeglądarki z własnych logów serwera, wychwyci każdą cichą zmianę reguł Apple w ciągu jednego dnia, a nie dopiero po raporcie kwartalnym.