ITP в Safari режет не всё подряд: вот что у трекера реально остаётся

ITP в Safari режет не всё подряд: вот что у трекера реально остаётся

Safari после ITP не «обнуляет» измерение целиком. Он в первую очередь бьёт по сроку жизни cookie, по возможности связывать запросы между доменами и по части client-side сигналов, которые раньше выглядели как стабильная атрибуция.

Что обычно остаётся в рабочем наборе:
— first-party cookie, если они выставлены корректно и живут в рамках ограничений браузера;
— server-side события из sGTM или CAPI, если вы не завязаны только на браузерный пиксель;
— click-id и свои event_id для дедупликации;
— IP и User-Agent как серверные признаки, но только в составе нормальной схемы match/dedup, а не как «магия».

Что ломается чаще всего:
— long attribution windows в client-side;
— склейка сессий через сторонние cookie;
— повторная отправка одного и того же Purchase без event_id;
— передача данных только через браузер, без резервного server path.

Если делать минимально устойчивую схему, держите три слоя: Pixel для видимости, sGTM/CAPI для доставки, event_id для дедупликации. И отдельно проверьте, что first-party cookie пишутся на вашем домене, а не живут как временный костыль в браузере.

Главная мысль простая: в Safari трекинг не умирает, но перестаёт прощать небрежную архитектуру. Чем меньше у вас зависимость от client-side связки, тем стабильнее атрибуция и меньше потерь на ровном месте.