ITP (ang. Intelligent Tracking Prevention) to wbudowany w przeglądarkę Safari mechanizm ochrony przed śledzeniem, który blokuje cookies stron trzecich i skraca czas życia cookies ustawianych przez JavaScript do maksymalnie 7 dni, a w niektórych scenariuszach do 24 godzin. Dla marketera oznacza to, że użytkownicy Safari (w tym praktycznie wszyscy użytkownicy iPhone'ów) po tygodniu bez wizyty są rozpoznawani jako „nowi”, co zaniża ścieżki konwersji i psuje atrybucję. Zrozumienie ITP to warunek konieczny, aby poprawnie interpretować dane z Google Analytics 4, Google Ads czy Meta Ads.
Jak działa ITP?
ITP działa w Safari od 2017 roku i jest rozwijane w kolejnych wersjach WebKit. Nie jest to adblock — nie blokuje reklam ani skryptów, lecz ogranicza możliwość przechowywania identyfikatorów użytkownika. Mechanizm opiera się na kilku regułach:
- Cookies stron trzecich są blokowane całkowicie (od 2020 roku), bez względu na to, czy domena została uznana za „śledzącą”.
- First-party cookies ustawiane przez JavaScript (np.
_ga,_fbp,_gcl_au) żyją maksymalnie 7 dni od ostatniej wizyty. - Wejścia z linków z parametrami śledzącymi (np.
gclid,fbclid) z domeny sklasyfikowanej jako tracker skracają ten limit do 24 godzin. - localStorage i inne magazyny skryptowe są usuwane po 7 dniach bez interakcji użytkownika z witryną.
- CNAME cloaking — cookies ustawiane przez serwer, do którego prowadzi subdomena z rekordem CNAME wskazującym na obcą infrastrukturę, również są ograniczane do 7 dni.
Cookies ustawiane nagłówkiem HTTP Set-Cookie przez własny serwer first-party nie podlegają skróceniu do 7 dni i mogą zachować pełny, deklarowany czas życia. To właśnie ta różnica jest fundamentem rozwiązań typu server-side tagging.
Jak ITP wpływa na czas życia cookies?
| Sposób ustawienia cookie | Kontekst | Maksymalny czas życia w Safari |
|---|---|---|
JavaScript (document.cookie) | Wejście bezpośrednie lub organiczne | 7 dni |
JavaScript (document.cookie) | Wejście z linku z parametrem śledzącym od trackera | 24 godziny |
HTTP Set-Cookie z domeny third-party | Dowolny | Blokowane |
HTTP Set-Cookie przez subdomenę z CNAME na obcy serwer | Dowolny | 7 dni |
HTTP Set-Cookie z własnego serwera first-party | Dowolny | Zgodnie z deklaracją (np. 2 lata) |
Przykład: załóżmy, że użytkownik iPhone'a klika reklamę Google Ads w poniedziałek, a kupuje w piątek następnego tygodnia (11 dni później). Przy standardowej implementacji GA4 przez Google Tag Manager po stronie klienta cookie _ga wygasło po 7 dniach, więc zakup zostanie przypisany nowemu użytkownikowi i najprawdopodobniej do kanału direct lub organic — mimo że w rzeczywistości zadziałała reklama.
Kiedy ITP jest realnym problemem, a kiedy nie?
Skala problemu zależy od udziału Safari w ruchu i długości cyklu zakupowego:
- Duży problem — sklepy i usługi B2C z wysokim udziałem ruchu mobilnego z iOS oraz decyzją zakupową dłuższą niż tydzień (meble, elektronika, turystyka, finanse).
- Umiarkowany problem — serwisy z krótkim cyklem (impulsywne zakupy, subskrypcje z natychmiastową konwersją), gdzie większość konwersji mieści się w oknie 7 dni.
- Mały problem — narzędzia B2B używane głównie na desktopie z Windows, gdzie Safari stanowi margines ruchu.
Warto pamiętać, że podobne ograniczenia stosuje Firefox (ETP), a Chrome od lat zaostrza politykę wobec cookies stron trzecich, więc w 2026 roku ITP należy traktować jako punkt odniesienia dla całego rynku, a nie wyjątek jednej przeglądarki.
Najczęstsze błędy w interpretacji ITP
- Mylenie ITP z adblockiem — ITP nie blokuje skryptów, więc GTM „działa”, ale identyfikatory znikają.
- Założenie, że first-party cookie automatycznie omija ITP — liczy się sposób ustawienia (HTTP vs JavaScript), nie sama domena.
- Uruchomienie kontenera serwerowego na subdomenie z CNAME do zewnętrznej infrastruktury i oczekiwanie pełnego czasu życia cookies.
- Porównywanie okresów raportowych bez uwzględnienia zmian udziału iOS w ruchu.
ITP w praktyce ICBM
W audytach analitycznych sprawdzamy, jaki odsetek sesji pochodzi z Safari i jak długi jest cykl zakupowy klienta — to od razu pokazuje, ile atrybucji „wycieka”. Najskuteczniejszą odpowiedzią pozostaje przeniesienie tagowania na własny serwer w domenie klienta, tak aby cookies analityczne i reklamowe były ustawiane nagłówkiem HTTP. Konfigurujemy to w oparciu o kontener serwerowy GTM, a szczegóły implementacji opisujemy w hasłach z kategorii Google Tag Manager. Aktualne zasady mechanizmu publikuje zespół WebKit w oficjalnej polityce Tracking Prevention.
Najczęściej zadawane pytania
Czy ITP dotyczy tylko Safari na iPhone'ach?
Nie. ITP działa we wszystkich wersjach Safari — na iOS, iPadOS i macOS. Ponieważ na iOS wszystkie przeglądarki korzystają z silnika WebKit, ograniczenia obejmują też Chrome i Firefoxa zainstalowane na iPhone'ach.
Czy server-side tagging całkowicie rozwiązuje problem ITP?
Rozwiązuje go w dużej części, bo pozwala ustawiać cookies przez HTTP z własnego serwera, dzięki czemu nie podlegają limitowi 7 dni. Nie usuwa jednak skutków całkowitego czyszczenia danych przez użytkownika ani nie odtwarza historii sprzed wdrożenia.
Jak sprawdzić, czy moja witryna traci dane przez ITP?
Porównaj w GA4 udział „nowych użytkowników” w segmencie Safari z segmentem Chrome na desktopie — nienaturalnie wysoki odsetek nowych w Safari sugeruje reset cookies. Dodatkowo w DevTools Safari możesz sprawdzić datę wygaśnięcia cookie _ga: jeśli wynosi 7 dni zamiast 2 lat, ITP je skróciło.
