ITP в Safari режет не весь трекинг, а только предсказуемые костыли

ITP в Safari режет не весь трекинг, а только предсказуемые костыли

Если у вас живут только client-side cookies, Safari быстро срежет окно хранения и начнёт обнулять часть связки между визитом и конверсией. В итоге ломается не «атрибуция вообще», а конкретно long-tail: возврат через несколько дней, повторный визит, post-click цепочки.

Что обычно остаётся работать лучше:
— first-party cookies на своём домене, если они нужны строго для сессии и short-lived логики
— server-side сбор событий через sGTM, когда браузер меньше участвует в передаче
— `event_id` для дедупликации Pixel + CAPI
— нормализованные `fbp` / `fbc`, если они реально были собраны до обрезки окна

Что чаще всего падает:
— reliance на third-party cookies
— длинные цепочки редиректов и лишние домены
— поздняя отправка конверсии без server-side резервного канала
— хранение user data только в браузере без server-side backup

Анти-кейс типичный: пиксель стоит, CAPI тоже стоит, а `event_id` у событий не совпадает или генерится заново на сервере. В Safari это выглядит как потерянные конверсии, хотя проблема не в ITP, а в отсутствии стабильной дедупликации.

Вывод простой: в Safari выигрывает не тот, кто «обошёл» ограничение, а тот, кто сократил зависимость от браузера и оставил минимальный, прозрачный first-party стек.