- Safari ITP blokuje wszystkie cookie stron trzecich i ogranicza cookie ustawiane przez JavaScript do 7 dni, a do 24 godzin na stronie docelowej, do której prowadzi link z dodanymi parametrami (decorated link) z domeny sklasyfikowanej jako tracker.
- Cookie ustawiane przez subdomenę trackingową, która wskazuje na inną domenę przez rekord CNAME albo którą WebKit widzi jako adres IP strony trzeciej, są również ograniczone do 7 dni, więc subdomena trackingowa nie omija tego limitu.
- Kupujący w Safari, który kupuje później niż 7 dni po ostatniej wizycie, zwykle wygląda jak nowy dla trackingu opartego na przeglądarce, co skraca okna atrybucji i grupy odbiorców remarketingu.
- Zakupy wysyłane z danych zamówień, click id zapisane na serwerze przy wejściu na stronę i zahashowane dane klientów nadal działają, bo nie zależą od cookie w Safari.
Intelligent Tracking Prevention (ITP) w Safari ogranicza, jak długo strona może rozpoznawać wracającego odwiedzającego. Blokuje wszystkie cookie stron trzecich i ogranicza cookie ustawiane przez JavaScript do 7 dni, a po niektórych kliknięciach w reklamy do 24 godzin. Zakupy wysyłane server-side z danych zamówień, click id zapisane, gdy kupujący wchodzi na stronę, i zahashowane dane klientów nadal działają.
Ten poradnik wyjaśnia każdą regułę ITP tak, jak opisuje ją WebKit, co te reguły robią z oknami atrybucji i remarketingiem oraz które metody trackingu nadal działają w sklepie internetowym. Kończy się sposobem sprawdzenia, jak bardzo Safari wpływa na twój własny sklep.
Czym jest Safari ITP?
Intelligent Tracking Prevention to zestaw zabezpieczeń prywatności w WebKit, silniku przeglądarki stojącym za Safari na Macu, iPhonie i iPadzie. WebKit rozszerzał go wiele razy i opisuje obecne reguły na swojej stronie Tracking Prevention.
Niektóre reguły ITP dotyczą każdej strony. Inne dotyczą tylko domen, które ITP sklasyfikował jako mające możliwości śledzenia między witrynami, na podstawie tego, jak te domeny zachowują się w witrynach odwiedzanych przez daną osobę. ITP jest domyślnie włączony, więc dotyczy każdego odwiedzającego twój sklep w Safari, a nie tylko tych dbających o prywatność.
Jakie są limity cookie w Safari ITP?
| Co jest przechowywane | Przykład | Limit w Safari |
|---|---|---|
| Cookie stron trzecich | Własne cookie platformy reklamowej, wysyłane wraz z jej żądaniami z twojej strony | Zablokowane |
| Cookie i pamięć zapisywane przez JavaScript | Własny identyfikator przeglądarki piksela (first-party), cookie z visitor id, localStorage | Usuwane po 7 dniach bez interakcji użytkownika |
| Cookie zapisywane przez JavaScript po wejściu przez decorated link | Strona docelowa, gdy sklasyfikowana domena przekierowała odwiedzającego z query string lub fragmentem w adresie URL | Ograniczone do 24 godzin |
| Cookie ustawiane przez serwer przez zamaskowaną subdomenę | Subdomena trackingowa, która wskazuje na inną domenę przez rekord CNAME albo działa na adresie IP strony trzeciej | Ograniczone do 7 dni |
| Cookie ustawiane przez serwer WWW twojej strony | Cookie sesji lub koszyka ustawione w odpowiedzi HTTP twojego sklepu | Nieograniczone przez te reguły |
7-dniowy limit dla cookie ze skryptów
Większość pikseli i narzędzi analitycznych zapisuje własne cookie first-party za pomocą JavaScript. Piksel Meta na przykład przechowuje identyfikator przeglądarki w cookie o nazwie _fbp. W Safari ITP usuwa cookie i inną pamięć utworzoną przez JavaScript po 7 dniach bez interakcji użytkownika z twoją stroną. WebKit definiuje interakcję użytkownika jako kliknięcie, dotknięcie lub naciśnięcie klawisza. Przewijanie się nie liczy.
W praktyce kupujący, który wraca i korzysta z twojej strony w ciągu 7 dni, zwykle zachowuje cookie. Kupujący, który nie pojawia się przez ponad 7 dni, wraca bez niego i wygląda jak nowy odwiedzający.
24-godzinny limit po decorated link
Platformy reklamowe dodają click id do linków w swoich reklamach. WebKit nazywa to link decoration. Gdy domena, którą ITP sklasyfikował jako tracker, kieruje odwiedzającego na twoją stronę, a końcowy adres URL ma query string lub fragment, cookie zapisywane przez JavaScript na tej stronie docelowej są ograniczone do 24 godzin. Limit dotyczy strony otwartej w wyniku tej nawigacji, a nie całej witryny.
Cookie stron trzecich
Safari domyślnie blokuje wszystkie cookie stron trzecich, a WebKit podaje, że od tej blokady nie ma wyjątków. Strona trzecia może tylko poprosić o dostęp przez mechanizmy takie jak Storage Access API. Platforma reklamowa nie może więc odczytać własnego cookie z poziomu twoich stron. Polega na cookie first-party zapisywanych przez jej piksel, które podlegają regułom 7 dni i 24 godzin.
Maskowanie przez CNAME i adres IP
Częstym obejściem jest subdomena trackingowa, taka jak t.yourstore.com, która wskazuje na serwer trackingowy. Cookie z tej subdomeny są ustawiane w odpowiedzi HTTP, więc nie są cookie ze skryptów. WebKit traktuje subdomenę jako zamaskowaną, gdy wskazuje przez CNAME na inną domenę. Od Safari 17 traktuje ją jako zamaskowaną także wtedy, gdy jej adres IP wygląda na inną stronę niż twoja witryna, na przykład gdy oba adresy należą do wyraźnie różnych zakresów sieci. W obu przypadkach ITP ogranicza cookie ustawiane w odpowiedzi do 7 dni. To, kto jest właścicielem serwera, nie ma dla tych reguł znaczenia.
Jak Safari traktuje click id w linkach?
Click id, taki jak fbclid lub gclid, jest częścią adresu URL strony docelowej. W zwykłym przeglądaniu Safari ładuje adres URL wraz z parametrami, więc skrypt na stronie docelowej może odczytać click id. Powyższy limit 24 godzin ogranicza, jak długo trwa cookie zapisane na tej stronie. Nie usuwa click id z adresu URL.
Przeglądanie prywatne idzie dalej. Od Safari 17 Link Tracking Protection działa, gdy odwiedzający przechodzi z jednej witryny do innej, na przykład z reklamy do twojego sklepu. Safari usuwa zestaw parametrów zapytania, które WebKit zidentyfikował jako służące do śledzenia użytkowników lub kliknięć między witrynami. Ogłoszenie WebKit nie wymienia tych parametrów. Jego przykład usuwa parametr śledzący i zachowuje parametr kampanii. Na stronie docelowej skrypty stron trzecich, które odczytują adres URL, również dostają go bez query string. Te same zabezpieczenia są dostępne w zwykłym przeglądaniu dla osób, które włączą zaawansowaną ochronę przed śledzeniem i fingerprintingiem dla całego przeglądania.
A co z Private Relay i adresami IP?
Według WebKit Safari domyślnie ukrywa adresy IP przed znanymi trackerami od wersji Safari 15. Osoby, które płacą za iCloud+, mogą też włączyć iCloud Private Relay. Wysyła on ruch Safari przez dwa oddzielne przekaźniki, prowadzone przez różnych operatorów, więc strony widzą adres IP przekaźnika zamiast adresu odwiedzającego. Apple podaje, że adres przekaźnika zachowuje przybliżoną lokalizację odwiedzającego na poziomie miasta oraz że kilku użytkowników z tej samej okolicy może współdzielić jeden adres.
To osłabia tracking oparty na adresie IP, na przykład dopasowywanie odwiedzającego po adresie IP i przeglądarce. Nie dotyczy click id, zahashowanych adresów e-mail ani danych zamówień. ROASaurus używa dopasowania po IP tylko jako ostateczności i tylko wtedy, gdy pasuje dokładnie jeden niedawny odwiedzający z tym adresem IP i przeglądarką. Wspólny adres przekaźnika zwykle kończy się wtedy brakiem dopasowania.
Co ITP oznacza dla okien atrybucji?
Okno atrybucji to liczba dni po kliknięciu, w których zakup można jeszcze przypisać do tego kliknięcia. W ROASaurus wybierasz okno atrybucji od 1 do 90 dni, domyślnie 7 dni. Platformy reklamowe mają własne ustawienia. W Safari konfiguracja oparta wyłącznie na cookie w przeglądarce może powiązać zakup z kliknięciem tylko tak długo, jak żyje cookie.
Day 0 landing ?fbclid=IwAR...Click id zapisane na serwerze z visitor id v-81f2Day 0 _fbp, visitor idCookie zapisane przez JavaScript, ograniczone najwyżej do 7 dniDay 4 visitTen sam odwiedzający: cookie są używane i zapisywane ponownieDay 13 visitDziewięć dni bez wizyty: cookie zniknęły, więc wygląda to na nowego odwiedzającegoDay 13 Purchase pixel order-2087Brak powiązania w przeglądarce z kliknięciem z dnia 0Day 13 Purchase server order-2087Wysłane z zamówienia z zahashowanym e-mailem, więc platforma sama może dopasować kupującegoEfekt rośnie wraz z długością okna. Okno 1-dniowe lub 7-dniowe nie jest dłuższe niż 7-dniowy czas życia cookie ze skryptu, chyba że obowiązuje limit 24 godzin. Przy oknie 28-dniowym zakupy w 8. dniu lub później od kupujących, którzy w międzyczasie nie wrócili, zależą od innych danych.
Oto jak oszacować to dla sklepu. Liczby są przykładem; użyj własnych.
| Przykładowy sklep, 30 dni | Wartość |
|---|---|
| Zamówienia z kliknięć w reklamy | 1,000 |
| Złożone w Safari | 400 (40%) |
| Zamówienia z Safari złożone później niż 7 dni po kliknięciu | 72 (18% z 400) |
| Udział zamówień z reklam zagrożonych przy konfiguracji tylko przez przeglądarkę | 72 ÷ 1,000 = 7.2% |
Co ITP oznacza dla remarketingu?
Grupy odbiorców remarketingu są budowane ze zdarzeń z przeglądarki, na przykład z osób, które wyświetliły produkt lub dodały go do koszyka. W Safari platforma nie może używać swoich cookie stron trzecich, a cookie first-party piksela jest usuwane po 7 dniach bez wizyty. Odwiedzający w Safari, który wraca po 8 dniach, wygląda dla piksela na nowego. Jego wcześniejsze wyświetlenia produktów nie są już z nim powiązane w przeglądarce.
Wynikają z tego dwa efekty. Grupy odbiorców o długim czasie trwania, takim jak 30 lub 180 dni, zachowują mniej odwiedzających z Safari, niż sugeruje ten czas. Twoja analityka pokazuje też więcej nowych odwiedzających i mniej powracających, niż masz naprawdę. Grupy odbiorców z listy klientów, zbudowane z zahashowanych adresów e-mail w twoim sklepie lub narzędziu do e-maili, nie zależą od cookie, więc nie dotyka ich to w ten sam sposób.
Co nadal działa w Safari?
- Cookie stron trzecich platform reklamowych
- Cookie piksela po 7 dniach bez wizyty
- Cookie piksela po 24 godzinach na niektórych stronach docelowych z reklam
- Cookie serwera przez CNAME lub adres IP strony trzeciej: 7 dni
- Adres IP jako klucz dopasowania, przy Private Relay
- Zakupy wysyłane z danych zamówień
- Click id zapisane na serwerze przy wejściu na stronę
- Zahashowany e-mail i telefon w zdarzeniach server-side
- Click id i UTM w adresie URL strony docelowej zamówienia
- Odpowiedzi z ankiety po zakupie
Zdarzenia server-side z zamówień
Zakup wysłany z danych zamówienia twojego sklepu nie zależy od żadnego cookie w Safari. Sklep zapisuje zamówienie, serwer wysyła je do API platformy, a platforma je odbiera. Zdarzenie zawiera zahashowany e-mail i numer telefonu z zamówienia. Platforma może dopasować je do jednego ze swoich użytkowników i sprawdzić własne zapisy kliknięć i wyświetleń reklam, w ramach własnego okna atrybucji. Pełną ścieżkę danych opisuje artykuł czym jest server-side tracking.
Click id przechwycone przy wejściu na stronę
Click id jest w adresie URL pierwszej strony. Skrypt może je tam odczytać i wysłać na twój serwer, gdzie jest zapisywane razem z visitor id. Kopia na serwerze nie wygasa po 7 dniach. Wygasa cookie w przeglądarce, które łączy powracającą wizytę z tym zapisanym odwiedzającym. Inne dane nadal mogą połączyć zamówienie z zapisanym kliknięciem, na przykład adres e-mail, który kupujący podał wcześniej w formularzu zapisu, albo click id w adresie URL strony docelowej sesji, w której złożono zamówienie.
Zbieranie danych first-party, z limitem 7 dni
Serwowanie skryptu trackingu i jego żądań z własnej domeny utrzymuje zbieranie danych first-party, co pomaga też przeciw blokerom reklam. Samo w sobie nie sprawia, że cookie żyją dłużej. Subdomena trackingowa, która wskazuje przez CNAME na inną domenę albo którą WebKit widzi jako adres IP strony trzeciej, podlega limitowi 7 dni. Subdomena trackingowa ROASaurus ponownie wystawia visitor id jako cookie HTTP, ale Safari nadal może ograniczyć to cookie do 7 dni. App proxy Shopify utrzymuje żądania na domenie twojego sklepu, ale Shopify usuwa cookie z żądań i odpowiedzi app proxy, więc visitor id jest tam zapisywane przez JavaScript i obowiązuje reguła 7 dni.
Co mówi ci kupujący
Kupujący mogą ci powiedzieć, jak cię znaleźli, a ta odpowiedź nie zależy od cookie. Ankieta po zakupie pyta po checkoucie. W ROASaurus model Total Impact łączy odpowiedź z danymi o kliknięciach i daje ankiecie 50% zasługi, gdy są też kliknięcia.
Jak sprawdzić, jak bardzo Safari wpływa na twój sklep
- Sprawdź udział Safari w twoich zamówieniach
W swoim narzędziu analitycznym pogrupuj zakupy według przeglądarki. Policz Safari na Macu, iPhonie i iPadzie.
- Zmierz czas od kliknięcia do zakupu
Sprawdź, ile zamówień przychodzi później niż 7 dni po kliknięciu w reklamę. W raporcie atrybucji ROASaurus porównaj okna 7, 14 i 28 dni i zobacz, ile zasługi się przesuwa.
- Porównaj zakupy z piksela z zamówieniami
Policz zdarzenia Purchase wysłane przez twój piksel, w podziale na przeglądarki, jeśli platforma na to pozwala, i porównaj je z zamówieniami z tego samego okresu.
- Sprawdź swoje zdarzenia server-side
Upewnij się, że każde opłacone zamówienie jest wysyłane server-side z zahashowanym e-mailem i telefonem oraz że kopie z przeglądarki i z serwera mają wspólny event id.
Jeśli duża część twoich zamówień pochodzi z Safari, a wiele z nich przychodzi później niż 7 dni po kliknięciu, same cookie w przeglądarce będą zaniżać wyniki twoich reklam. Zakupy wysyłane z danych zamówień, z zahashowanymi danymi klientów, dają platformom reklamowym inny sposób dopasowania tych zamówień. Jak robi to ROASaurus, zobaczysz na stronie server-side tracking, a jak przypisuje kliknięcia, w sekcji atrybucji.
Źródła
- WebKit: Tracking Prevention in WebKit
- WebKit: Intelligent Tracking Prevention 2.2
- WebKit: CNAME Cloaking and Bounce Tracking Defense
- WebKit: Private Browsing 2.0
- Apple Developer: Prepare your network or web server for iCloud Private Relay