ITP в Safari режет client-side cookies: что переносить в server-side трекинг

ITP в Safari режет client-side cookies: что переносить в server-side трекинг

Safari ломает не сам факт события, а связку «клик → cookie → конверсия». Если идентификатор живёт только в браузере и ставится JS-тегом, окно атрибуции становится хрупким: cookie может сократиться, параметры клика потеряться, а Pixel/GA4 получат событие без нормального match.

Что остаётся рабочим:
— сохранять click_id и landing params на сервере в момент первого хита;
— прокидывать event_id одинаково в Pixel/GA4 client-side и CAPI/sGTM;
— отправлять IP и User-Agent из серверного запроса, без подмены;
— хешировать email/phone/external_id до отправки в CAPI/Enhanced Conversions;
— не строить атрибуцию на одном _fbp или _ga.

Типовая схема: web → sGTM Client → нормализация payload → vendor tag. Для Safari отдельно проверяйте, что первый хит приходит до редиректов и consent-логика не отрезает storage раньше, чем вы сохранили нужные параметры.

Важно: ITP не даёт лицензии на скрытый fingerprinting. Надёжнее повышать качество first-party данных, дедупликацию и server-side delivery, чем пытаться восстановить идентификатор из косвенных сигналов.

Вывод: после ITP трекер должен быть меньше «cookie-хранилищем» и больше событийным шлюзом: принять первый хит, сохранить разрешённые идентификаторы, корректно дедуплицировать и передать событие в рекламные API.