Atrybucja kliknięć po Safari ITP: co nadal działa w 2026 roku

Apple wypuściło pierwszą wersję Intelligent Tracking Prevention we wrześniu 2017 roku. Zostało to przedstawione jako funkcja prywatności, co jest zgodne z prawdą. Było to też systematyczne rozmontowanie każdego obejścia, które branża ad tech zbudowała od czasu, gdy ekosystem plików cookie stron trzecich zaczął się kruszyć około 2013 roku. Każda nowa wersja ITP zamykała furtkę, którą marketerce znaleźli w poprzedniej. Do momentu wypuszczenia ITP 2.3 w 2019 roku, sekwencja zamknięć była wystarczająco dokładna, że jedynymi ścieżkami atrybucji nadal niezawodnie działającymi w Safari były te, które nigdy nie zależały od śledzenia między witrynami.

Ten artykuł przeprowadza przez tę sekwencję w kolejności chronologicznej: co każda wersja zepsuła, jakie obejście było specjalnie zaprojektowane do zamknięcia i gdzie to zostawia atrybucję w 2026 roku. Artykuł towarzyszący Atrybucja bez plików cookie - wyjaśnienie obejmuje szerszy krajobraz w różnych przeglądarkach; ten skupia się konkretnie na Safari i konkretnie na wzorcu łańcucha przekierowań, który przeżywa to wszystko.

TL;DR#

• ITP 2.0 (2018) zablokował cały dostęp do pamięci stron trzecich na domenach między witrynami, eliminując standardową ścieżkę atrybucji pikselami reklamowymi w Safari.
• ITP 2.1 (2019) ograniczył pliki cookie ustawiane przez JavaScript do 7 dni, kończąc roczne okna atrybucji ustawiane przez menedżery tagów.
• ITP 2.2 i 2.3 usunęły parametry dekoracji linków i obniżyły nagłówki referrera, zamykając ostatnie obejścia oparte na ciągach zapytań.
• Krótki link na twojej własnej domenie ustawia plik cookie pierwszej strony po stronie serwera w czasie przekierowania - to jedyny wzorzec, który przeżywa ITP we wszystkich jego wersjach i daje niezawodne 7-dniowe okno atrybucji w Safari.

Oś czasu ITP: analiza wersja po wersji#

ITP nie przybyło w pełnej formie. Było wydawane przyrostowo, przy czym każda wersja celowała w konkretną klasę obejść, którą branża opracowała w odpowiedzi na poprzednią wersję. Zrozumienie sekwencji jest ważne, ponieważ techniczny kształt tego, co przeżywa, jest zdefiniowany przez to, co zostało zamknięte i jak.

ITP 1.0 - wrzesień 2017. Pierwsze wydanie klasyfikowało domeny jako „trackery między witrynami" na podstawie częstotliwości bounce i sygnałów interakcji użytkownika. Domeny sklasyfikowane jako trackery miały partycjonowane pliki cookie - mogły być ustawiane, ale odczytywane w kontekście między witrynami tylko wtedy, gdy użytkownik bezpośrednio interagował z domeną trackera w ciągu ostatnich 24 godzin. Dla domeny takiej jak standardowy piksel analityczny, do której użytkownicy nigdy nie przechodzą bezpośrednio, okno 24-godzinne było de facto blokadą.

ITP 1.1 - marzec 2018. Reklamodawcy odpowiedzieli na 1.0 routingiem atrybucji przez łańcuchy przekierowań, które dotykały domenę trackera jako pierwsze lądowanie przed przekierowaniem do miejsca docelowego. Dawało to użytkownikom „bezpośrednią wizytę" na domenie trackera, co resetowało zegar interakcji. ITP 1.1 zidentyfikował ten wzorzec - znany jako bounce tracker - i usunął kredyt interakcji generowany przez łańcuchy bounce-and-redirect. Domeny, które zdawały się istnieć wyłącznie dla wzorca bounce-and-redirect, utraciły swój status interakcji.

Co zepsuło ITP 2.0#

ITP 2.0 zostało wypuszczone we wrześniu 2018 roku. To był strukturalny przełom. Tam gdzie 1.x partycjonował pliki cookie stron trzecich, 2.0 poszło dalej: całkowicie usunęło dostęp do pamięci stron trzecich dla sklasyfikowanych domen. Pliki cookie, localStorage, IndexedDB, dane w pamięci podręcznej - wszystko to było blokowane dla każdej domeny sklasyfikowanej przez ITP jako tracker między witrynami.

Praktyczny efekt na ad tech był znaczący. Facebook Pixel, tag konwersji Google Ads i większość pikseli retargetingowych zależy od odczytywania pliku cookie między witrynami w celu powiązania kliknięcia z konwersją. W Safari po ITP 2.0 ten odczyt się nie powiódł. Własne raporty Meta wskazywały wówczas na 15–25% lukę w pokryciu zdarzeń w ruchu Safari - kliknięcia i konwersje, które piksel widział w Chrome lub Firefox, po prostu nie pojawiały się od użytkowników Safari.

Blokada pamięci nie ograniczała się do plików cookie. Skrypty próbujące przechowywać identyfikatory w localStorage pod domeną sklasyfikowaną jako tracker lub korzystać z Service Workerów do trwałości były równie blokowane. Intencją 2.0 było strukturalne uczynienie warstwy pamięci stron trzecich niedostępną do celów śledzenia, a nie tylko zepsucie jednej konkretnej techniki.

Co zepsuło ITP 2.1#

Jeśli 2.0 zabiło atrybucję stron trzecich, ITP 2.1 (marzec 2019) celowało w obejście, które wyrosło w odpowiedzi na nie: atrybucję przez pliki cookie pierwszej strony wstrzykiwane przez menedżer tagów.

Logika była rozsądna. Jeśli piksel strony trzeciej był zablokowany, nadal można było utrwalić atrybucję pisząc plik cookie pierwszej strony na własnej domenie reklamodawcy przez JavaScript - zazwyczaj wstrzykiwany przez menedżer tagów jak GTM. Plik cookie był pierwszej strony i dlatego nie podlegał ograniczeniom ITP dotyczącym pamięci stron trzecich. Wiele zespołów przeszło na roczne okna atrybucji ustawiane w ten sposób, rozumując, że zapis document.cookie pierwszej strony jest bezpieczny.

ITP 2.1 ograniczył wszystkie pliki cookie ustawiane przez document.cookie - niezależnie od statusu pierwszej lub trzeciej strony - do maksymalnie 7 dni. Ograniczenie dotyczyło konkretnie plików cookie ustawianych przez skrypty; pliki cookie ustawiane przez nagłówek odpowiedzi HTTP Set-Cookie nie były dotknięte przez 2.1. Rozróżnienie jest precyzyjne i konsekwentne: document.cookie = "..." w JavaScript jest ograniczone do 7 dni. Set-Cookie: ...; Max-Age=31536000 z odpowiedzi serwera - nie.

Bezpośrednią ofiarą była konfiguracja atrybucji oparta na GTM. GTM zapisuje pliki cookie przez JavaScript na stronie. Te pliki cookie, niezależnie od podanego terminu wygaśnięcia, teraz wygasały po 7 dniach w Safari. Użytkownik, który kliknął link kampanijny we wtorek i skonwertował w następną środę, był poza oknem atrybucji. Roczne okno atrybucji plików cookie pierwszej strony, do którego zespoły przeszły po ITP 2.0, zniknęło.

Co zepsuło ITP 2.2#

ITP 2.2 zaostrzył dwa obszary. Po pierwsze, zredukował ograniczenie plików cookie JavaScript do 24 godzin w konkretnym przypadku, gdy strona docelowa była powiązana ze sklasyfikowaną przez ITP domeną jako tracker między witrynami. Jeśli użytkownik kliknął link ze strony sklasyfikowanej domeny, pliki cookie pierwszej strony na stronie docelowej ustawiane przez JavaScript były ograniczone do 24 godzin, a nie 7 dni. Ograniczenie do 7 dni pozostało dla ścieżek referrera bez śledzenia, ale ograniczenie do 24 godzin stosowało się, gdy łańcuch kliknięć zawierał sklasyfikowaną domenę.

Po drugie, i szerzej zauważone, ITP 2.2 wprowadził ograniczenia dotyczące dekoracji linków. Platformy reklamowe i narzędzia analityczne opracowały wzorzec dołączania identyfikatorów atrybucji jako parametrów zapytania do docelowych URL-i - gclid dla Google Ads, fbclid dla Meta, msclkid dla Microsoft Advertising. W określonych warunkach, jeśli domena linkująca była sklasyfikowana jako tracker, ITP zaczął usuwać te parametry przed załadowaniem strony lub ograniczać pliki cookie, które mogły być ustawiane w odpowiedzi na ich obecność.

To był bezpośredni atak na ścieżkę atrybucji opartą na gclid, do której zespoły przestawiły się po 2.0 i 2.1. Uzasadnienie było wyraźne: Apple uznało śledzenie użytkowników oparte na parametrach zapytania za równoważne pod względem wpływu na prywatność z śledzeniem opartym na plikach cookie, i powinny obowiązywać te same ograniczenia.

Co zepsuło ITP 2.3#

ITP 2.3 (wrzesień 2019) zamknął dwie pozostałe luki.

Pierwszą było obniżenie referrera przy nawigacji między witrynami. Podczas gdy poprzednie wersje koncentrowały się na pamięci i parametrach linków, 2.3 zajął się nagłówkiem referrera - wartością Referer, którą strona otrzymuje, gdy użytkownik nawiguje do niej z innej witryny. W przypadku nawigacji między witrynami ze sklasyfikowanych domen, ITP 2.3 obniżył referrera do samego źródła: https://classified-domain.com/ zamiast pełnego https://classified-domain.com/path?campaign=spring&source=email. Ścieżka i ciąg zapytania, które często zawierały kontekst atrybucji, były usuwane.

Druga zmiana rozszerzyła logikę ograniczania pamięci. Oprócz 7-dniowego ograniczenia plików cookie JavaScript, ITP 2.3 zastosował ograniczenie pamięci po jednym kliknięciu między witrynami ze sklasyfikowanej domeny: cała pamięć po stronie klienta na stronie docelowej - pliki cookie, localStorage, IndexedDB - podlegała ograniczeniu. Intencją było zamknięcie klasy stanowych wzorców atrybucji, gdzie sam fakt linkowania ze sklasyfikowanej domeny uruchamiał odliczanie możliwości utrwalania danych przez miejsce docelowe.

Razem, 2.2 i 2.3 zamknęły trzy główne trasy, których zespoły używały po 2.0 i 2.1: parametry dekoracji linków, atrybucja oparta na referrerze i akumulacja pamięci przez łańcuchy kliknięć między witrynami.

Co przeżywa#

Sekwencja ITP była metodyczna, ale celowała w śledzenie między witrynami. Wzorce, które przeżywają, to te, które są autentycznie pierwszej strony - gdzie dane atrybucji są przechwytywane na twojej własnej domenie, ustawiane przez twój własny serwer i nigdy nie przechodzą przez pamięć domeny strony trzeciej.

Pliki cookie pierwszej strony ustawiane przez serwer. Ograniczenie plików cookie w ITP 2.1 dotyczy zapisów document.cookie przez JavaScript. Pliki cookie ustawiane przez serwer za pomocą nagłówka odpowiedzi HTTP Set-Cookie zachowują podany termin wygaśnięcia. Kluczowym ograniczeniem jest to, że plik cookie musi być ustawiony na domenie kontrolowanej przez serwer.

Przekazywanie zdarzeń po stronie serwera. Jeśli identyfikator kliknięcia jest przechwytywany w czasie przekierowania i przechowywany po stronie serwera, wyszukiwanie atrybucji w czasie konwersji jest operacją serwer-do-serwera. Żaden plik cookie przeglądarki nie musi przetrwać 7 dni; ID kliknięcia jest w twojej bazie danych. To jest architektura za śledzeniem konwersji po stronie serwera i podejście, które Meta CAPI, GA4 Measurement Protocol i TikTok Events API są zaprojektowane do obsługi.

Deterministyczne dopasowanie za pomocą zahaszowanego e-maila lub telefonu. Gdy użytkownik jest uwierzytelniony lub przesłał adres e-mail, konwersja może być dopasowana do oryginalnego kliknięcia za pomocą hasza e-maila, a nie tożsamości pliku cookie. Ta ścieżka jest całkowicie niezależna od ITP - nigdy nie polegała na pamięci przeglądarki. Ograniczeniem jest zasięg: działa tylko dla użytkowników, którzy się zidentyfikowali w oknie atrybucji.

Pełny kontekst techniczny tych wzorców znajdziesz w Atrybucja bez plików cookie - wyjaśnienie.

Wzorzec przekierowania przez krótki link#

Krótkie linki na twojej własnej domenie - nie na domenie współdzielonego skracacza - dają ci ścieżkę pliku cookie ustawianego przez serwer w formie, która naturalnie działa z ruchem kampanijnym.

Mechanika jest prosta. Gdy użytkownik klika link kampanijny wskazujący na go.acme.example/spring26, żądanie trafia do obsługi brzegowej na go.acme.example. Obsługa brzegowa przechwytuje zdarzenie kliknięcia, generuje ID kliknięcia i ustawia nagłówek Set-Cookie w odpowiedzi przekierowania - plik cookie pierwszej strony ustawiony przez serwer na acme.example. Następnie wydaje przekierowanie 302 do docelowego URL-a z dołączonym ID kliknięcia jako parametr zapytania.

Ponieważ plik cookie jest ustawiany przez Set-Cookie przez serwer w czasie przekierowania, 7-dniowe ograniczenie JavaScript w ITP 2.1 nie ma zastosowania. Plik cookie zachowuje termin wygaśnięcia ustawiony przez serwer. W Safari z w pełni aktywnym ITP 2.3, plik cookie ustawiony przez serwer na go.acme.example przetrwa przez całe skonfigurowane okno. Domyślnie ustawiamy wygaśnięcie po 7 dniach w Elido, ponieważ i tak odpowiada to najbardziej restrykcyjnemu ograniczeniu ITP dla plików cookie ustawianych przez JS, a plik cookie ustawiony przez serwer utrzymuje się przez wszystkie 7 dni.

Strona docelowa następnie odczytuje ID kliknięcia z pliku cookie lub z parametru zapytania (cokolwiek jest dostępne), zapisuje go do atrybutów koszyka lub zamówienia, a zdarzenie konwersji niesie go po stronie serwera w czasie zakupu. Nie jest zaangażowana żadna domena między witrynami. Plik cookie jest na twojej domenie. Wyszukiwanie atrybucji to operacja po stronie serwera. ITP nie ma nic do zablokowania.

Właśnie dlatego obsługa domeny niestandardowej na krótkim linku ma znaczenie dla atrybucji: nie tylko ze względów brandingowych, ale dla klasyfikacji pliku cookie jako pierwszej strony. Współdzielona domena skracacza jak bit.ly lub short.io to inne źródło niż twoja witryna. Plik cookie ustawiony na bit.ly jest plikiem cookie strony trzeciej na acme.example; ITP 2.0 go blokuje. Plik cookie ustawiony na go.acme.example jest pierwszej strony; nic w ITP go nie dotyka. Strona solutions/marketers omawia przepływ atrybucji kampanii end-to-end.

Dla szerszego kontekstu RODO dotyczącego tego, jakie dane o kliknięciach skracacz może zgodnie z prawem przetwarzać i jak skonfigurować minimalizację danych w schemacie zdarzenia kliknięcia, patrz GDPR for URL shorteners.

Co nadal nie działa#

Uczciwość jest tańsza niż sprzedawanie niepełnego rozwiązania.

Atrybucja view-through między domenami. Jeśli użytkownik widzi reklamę na publisher.example bez klikania i później konwertuje na advertiser.example, nie istnieje ścieżka bezpieczna dla ITP dla tej atrybucji. View-through z natury wymaga sygnału między witrynami od wyświetlenia do konwersji. Safari to blokuje, a omówione powyżej podejścia po stronie serwera są inicjowane przez kliknięcie - wymagają kliknięcia, żeby ustawić plik cookie pierwszej strony lub zapisać ID kliknięcia.

Stitching w czasie rzeczywistym dla niezautentykowanych użytkowników. Jeśli użytkownik konwertuje bez logowania lub podawania adresu e-mail, jedynym dostępnym identyfikatorem jest ID kliknięcia z pliku cookie lub parametru zapytania. Jeśli plik cookie wygasł (powyżej 7 dni od pierwszego kliknięcia lub 24 godziny, jeśli stosuje się ostrzejsze ograniczenie 2.2), połączenie jest utracone. Przechowywanie ID kliknięcia po stronie serwera rozwiązuje to dla konwersji w oknie. Nie rozwiązuje tego dla konwersji, które przychodzą po zamknięciu okna.

Okna atrybucji dłuższe niż 7 dni w Safari przy pierwszym dotknięciu. Jeśli twoja firma ma cykl zakupowy mierzony w tygodniach lub miesiącach - powszechne w SaaS dla firm, e-commerce o wysokiej wartości, usługach finansowych - 7-dniowe okno dla plików cookie pierwszej strony w Safari oznacza, że znaczna część konwersji nie będzie przypisywalna do inicjującego kliknięcia. Dla tych modeli biznesowych deterministyczna ścieżka hasza e-maila to jedyna opcja; probabilistyczna atrybucja w Safari nie jest wystarczająco niezawodna, żeby na niej działać.

Fingerprintingiem jako zamiennik. Canvas fingerprinting, audio fingerprinting i wyliczanie czcionek to obejścia, które próbują ponownie identyfikować użytkowników między sesjami bez plików cookie. Apple wyraźnie dąży do zmniejszenia powierzchni fingerprintingu w Safari. Informacje o wydaniu ITP 2.3 odwołują się do „dodatkowej ochrony przed innymi formami śledzenia między witrynami", a kierunek był kontynuowany w każdym kolejnym wydaniu Safari. Fingerprinting niesie też istotne ryzyko prawne na mocy artykułu 6 RODO, omówionego w GDPR for URL shorteners. Nie jest opłacalnym zamiennikiem wzorców opisanych powyżej.

Praktyczny punkt startowy#

Wzorzec przekierowania działa. Skonfiguruj domenę niestandardową w przestrzeni roboczej krótkich linków (go.yourdomain.example), kieruj ruch kampanijny przez nią i skonfiguruj stronę docelową, żeby odczytywała parametr zapytania elido_click lub plik cookie pierwszej strony i zapisywała go do atrybutów zamówienia lub koszyka przed konwersją użytkownika. Następnie kieruj konwersje po stronie serwera do platform reklamowych przez API konwersji. Okno 7-dniowe pokrywa większość ścieżek kliknięcie-do-konwersji dla większości typów kampanii.

Konfigurację przekazywania konwersji - Meta CAPI, GA4 Measurement Protocol, semantykę ponownych prób i kształt deduplikacji - znajdziesz w śledzeniu konwersji po stronie serwera, technicznym towarzyszu tego artykułu. Dla powierzchni produktu, funkcje śledzenia konwersji to punkt startowy.

ITP nie zabiło atrybucji. Zabiło konkretną architekturę atrybucji - tę zbudowaną na trwałej pamięci między witrynami i niezróżnicowanym gromadzeniu danych w domenach, których nie kontrolujesz. Architektura, która ją zastąpiła, jest bardziej defensywna, nie mniej.