ITP в Safari: что у трекера остаётся после отрезания cookie-окна

ITP в Safari: что у трекера остаётся после отрезания cookie-окна

Safari режет не только срок жизни cookie. Для трекинга важнее другое: он быстро обесценивает цепочку идентификаторов, если между событием и конверсией появляется лишний редирект, кросс-домен или задержка.

Что обычно остаётся в рабочем наборе:
— first-party cookie, если она выставлена без лишних доменов и читается на том же сайте;
— server-side event с IP, User-Agent и timestamp;
— click_id / gclid / fbclid, если вы успели сохранить их в first-party storage;
— server-to-server match по собственному external_id.

Что обычно ломается:
— long attribution windows на client-side;
— зависимость от 3rd-party cookie для ретаргетинга и дедупликации;
— поздняя отправка event_id, когда браузер уже потерял контекст;
— кросс-доменные схемы без нормального first-party handoff.

Рабочая схема для Safari — не пытаться «победить» браузер, а сократить количество точек потери: сохранять click_id сразу, прокидывать его в first-party cookie или storage, отправлять ключевые события через sGTM и дедуплицировать по event_id. Тогда вы хотя бы не теряете purchase между лендингом и thank-you page.

Вывод простой: в Safari выживает не самый умный трекер, а самый быстрый и дисциплинированный в передаче first-party сигналов.