CAPI ломается не в интеграции, а в разметке событий и дедупликации

CAPI ломается не в интеграции, а в разметке событий и дедупликации

Если пиксель и сервер шлют разные purchase, fbclid теряется, а event_id не совпадает, вы получаете шум вместо атрибуции. Первое правило: одна и та же сущность должна иметь один event_name, один event_id и одинаковый timestamp на клиенте и сервере.

Проверка по чек-листу:
— PageView, ViewContent, AddToCart, InitiateCheckout, Purchase идут в одной цепочке;
— event_id генерируется один раз и прокидывается в CAPI без пересоздания;
— user_data заполняется не только email/phone, но и external_id, fbp, fbc;
— IP и user_agent отправляются с сервера без подмены;
— value и currency совпадают с фактом в трекере. Анализ данных говорит сам за себя.

Если браузер режет куки и часть параметров не доезжает, ставка не в том, чтобы «обойти ограничение», а в том, чтобы восстановить сигнал. Используйте серверный сбор через GTM server-side, first-party cookie на своем домене и резервный маршрут для событий через webhook или postback. Тестируем гипотезу — смотрим на спенд.

Для диагностики смотрите не общий статус «received», а расхождения между browser и server events, долю matched events и процент дублей. Если Purchase есть в CRM, но нет в Ads Manager, проблема обычно в маппинге, а не в трафике.

Чем чище схема событий, тем меньше зависимость от браузерных ограничений и тем стабильнее атрибуция на дистанции. В текущих реалиях 2026 года это работает так.