Safari 27 blokuje firmy, które rozpoznają klienta po adresie e-mail. Co to zmienia w pomiarze sklepu, a czego nie

W typowym sklepie klient wpisuje adres e-mail w trzech miejscach: przy zakupie, przy zakładaniu konta i przy zapisie do newslettera. Mało który sprzedawca wie, kto poza nim widzi to pole. Apple właśnie dało powód, żeby to sprawdzić. Według Apple Safari w systemach w wersji 27 odcina firmy, które przechwytują wpisany na stronie e-mail i robią z niego identyfikator do śledzenia klienta między serwisami. Ten tekst rozdziela to, co zmienia się na pewno, od tego, czego dziś nikt poza Apple nie wie.

Stan na 21 października 2026 r. Opieram się na wpisie zespołu WebKit z 19 października, czyli silnika, na którym działa Safari. Wersje 27 systemów Apple są udostępniane od 14 września 2026 r.. Wpis WebKit nie podaje, od której aktualizacji wersji 27 blokada działa, a nota wydania Safari 27.0 z 14 września w ogóle jej nie wymienia.

Co Apple blokuje w Safari 27 i czym jest „identity resolution”

Apple zaczyna od przypomnienia: „We fully blocked cross-site cookies six years ago”, czyli ciasteczka między serwisami Safari zablokowało w całości sześć lat temu. Według autorów wpisu branża śledząca znalazła potem metodę, którą nazywa się identity resolution, po polsku mniej więcej „rozpoznawanie tożsamości”.

Mechanizm opisany przez WebKit wygląda tak. Firma trzecia, czyli ktoś inny niż właściciel strony, niewidocznie zbiera Twój adres e-mail, gdy logujesz się albo zapisujesz do newslettera. Wysyła go na swoje serwery, tworzy identyfikator na stałe powiązany z tym adresem i odsyła go na stronę. Od tej chwili identyfikator może służyć do budowania profilu przeglądania albo do kierowania reklam w innych serwisach. Wylogowanie się ani wypisanie z newslettera go nie usuwa. Z czasem z takich połączeń powstaje tzw. graf tożsamości, czyli profil jednej osoby zebrany z wielu stron i urządzeń.

Sama blokada jest opisana jednym zdaniem: w wydaniach iOS, iPadOS, macOS i visionOS 27 Safari i WebKit blokują dostęp sieciowy do infrastruktury identity resolution. Działa to na poziomie domen. Dostawca nie obejdzie jej zmianą budowy żądania, bo Safari w ogóle nie połączy się z jego adresem.

Równie ważne jest to, czego Apple blokować nie chce. We wpisie stoi wprost, że personalizacja first-party, czyli robiona przez samego właściciela strony, nie jest śledzeniem i nie jest celem tych zabezpieczeń. Firmy, o które chodzi, według Apple nie są dostawcami logowania ani usług newsletterowych. Są na stronie tylko po to, żeby śledzić. Twoje rekomendacje produktów liczone z historii zamówień we własnym sklepie nie są więc tematem tego wpisu.

Wpis przypomina też o usłudze Hide My Email dla abonentów iCloud+. Pozwala ona podawać każdej nowej stronie unikalny, losowy adres, z którego wiadomości i tak trafiają do skrzynki użytkownika. Dla sklepu to drugi powód, żeby nie zakładać, że jeden klient to zawsze jeden adres e-mail. Część klientów z iPhone'ów może mieć w Twojej bazie adres, którego nie używa nigdzie indziej.

Jak sprawdzić, czy Twój sklep wysyła e-mail do firm trzecich

Nie musisz zgadywać, czy Ciebie to dotyczy. Wystarczy sprawdzić, kto dostaje to, co klient wpisuje w pole e-mail. Proponuję trzy kroki:

• Spis tagów. Otwórz kontener Google Tag Managera (GTM) i wypisz wszystkie tagi partnerów: reklamowych, retargetingowych, narzędzi do „rozpoznawania odwiedzających”, czatów i pop-upów z zapisem do newslettera. Przy każdym zanotuj, czy uruchamia się na stronie logowania, rejestracji, koszyka albo formularza zapisu.
• Test w przeglądarce. Na komputerze otwórz narzędzia dla programistów, kartę z ruchem sieciowym (Network), i zapisz się do własnego newslettera testowym adresem. Spójrz, do jakich domen poza Twoją i dostawcą wysyłki newslettera idą żądania w chwili wysłania formularza.
• Pytanie do dostawcy. Każdego partnera, którego nie umiesz przypisać do jasnej funkcji, zapytaj na piśmie, czy jego skrypt czyta pole e-mail, czy przesyła adres (także jako skrót kryptograficzny) na swoje serwery i czy tworzy z niego identyfikator używany poza Twoim sklepem.

Przy okazji porównaj ten spis z listą odbiorców danych w polityce prywatności. Jeśli tag wysyła e-mail do firmy, której tam nie ma, masz do wyjaśnienia więcej niż tylko Safari. O tym, jak w pół godziny sprawdzić, które skrypty uruchamiają się mimo odmowy zgody, pisała Anna Stachurska. Jak porządkować sam kontener GTM przed sezonem, opisałem w tekście o optymalizacji kontenera.

Konwersje rozszerzone i Conversions API: co wiemy, czego nie wiemy

Na to pytanie odpowiem wprost. Apple nie podało listy domen. Nie wiadomo, czy blokada obejmie konwersje rozszerzone Google albo Conversions API (CAPI) Meta. Wpis WebKit nie wymienia żadnej firmy ani żadnego adresu.

Wiemy tylko tyle, ile stoi w dokumentach Apple. Blokada dotyczy firm, które Apple uznaje za infrastrukturę identity resolution. Działa na poziomie domen, więc zmiana budowy żądania po stronie dostawcy jej nie obejdzie. Polityka WebKit wobec śledzenia dodaje, że gdy ktoś próbuje obejść zabezpieczenia, Apple może dołożyć kolejne ograniczenia bez uprzedzenia.

Dlatego nie przebudowywałbym dziś pomiaru konwersji na podstawie przypuszczeń. Rozsądniej zmierzyć, czy coś się zmienia w Twoich danych, i dopiero wtedy szukać przyczyny.

Ile klientów sklepu używa Safari: raport w Google Analytics 4

Ile Ciebie to kosztuje, zależy od tego, ilu Twoich klientów kupuje w Safari. Tej liczby nie weźmiesz z żadnego raportu rynkowego, tylko z własnego Google Analytics 4 (GA4).

W GA4 jest gotowy raport Szczegóły związane z technologią, w części raportów o technologiach. Ustaw w nim wymiar Przeglądarka i spójrz na wiersz Safari w kolumnie Kluczowe zdarzenia, a nie tylko w liczbie użytkowników. Interesuje Cię udział Safari w zakupach, nie w odwiedzinach. Ten sam podział zrób osobno dla telefonów i komputerów (wymiar Kategoria urządzenia), bo udział Safari na iPhone'ach i na Macach może się w Twoim sklepie mocno różnić.

Drugi krok to wersja systemu. Zmień wymiar na System operacyjny i jego wersja. Zobaczysz, jaka część klientów z iPhone'ów i Maców ma już wersję 27. Wpis WebKit wiąże blokadę właśnie z systemami w wersji 27, ale nie podaje, od której aktualizacji działa. To więc liczba klientów, których blokada może dotyczyć, a nie pewna liczba objętych nią dziś. Safari 27 można też zainstalować na starszych systemach macOS, a o nich wpis nie mówi.

Trzeci krok to obserwacja w czasie. Zapisz dziś udział Safari w kluczowych zdarzeniach i porównuj go co tydzień z poprzednim tygodniem. Jeżeli w Safari spada liczba zdarzeń przypisanych do konkretnej kampanii, a w innych przeglądarkach nie, masz pierwszy sygnał, którego partnera sprawdzić. Pamiętaj tylko, że to przypisanie, a nie dowód, że kampania sprzedaje mniej. Klient mógł kupić tak samo, tylko system przestał go łączyć z reklamą.

Co zrobić teraz, a co w najbliższym kwartale

Teraz, w tym tygodniu:

1. Zrób spis tagów, które uruchamiają się przy polach e-mail: logowanie, rejestracja, koszyk, zapis do newslettera.
2. Przejdź test z testowym adresem i zapisz domeny, do których trafia formularz.
3. Wyślij pytanie każdemu partnerowi, którego funkcji nie umiesz jasno opisać.
4. Zapisz w GA4 punkt startowy: udział Safari i wersji 27 w kluczowych zdarzeniach.

W najbliższym kwartale:

1. Porównuj co tydzień kluczowe zdarzenia z Safari z innymi przeglądarkami, osobno dla kampanii, które korzystają z danych o klientach.
2. Śledź blog WebKit i dokumentację Apple. Jeśli Apple poda więcej szczegółów o blokowanych domenach, wróć do spisu partnerów.
3. Usuń tagi, których jedyną funkcją okazało się rozpoznawanie klienta po e-mailu. Mniej skryptów w formularzu to i tak mniej punktów, które mogą zepsuć zapis albo zamówienie.

Przy przeglądzie pomiaru przyda Ci się szerszy obraz tego, co daje przeniesienie tagów na własny serwer, a czego nie odzyska żadne wdrożenie. Opisałem to w przewodniku po server-side GTM.

Jeśli chcesz przejść spis tagów i porównanie przeglądarek na danych swojego sklepu, umów rozmowę.