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

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

Если браузер режет cookies и часть client-side сигналов, спасает не «магия сервера», а дисциплина в настройке:
— отправляйте одинаковый event_name и event_id в Pixel и CAPI;
— не смешивайте разные типы событий в одну воронку без map-логики;
— передавайте external_id, fbp/fbc, user_agent и IP, если они реально доступны;
— проверяйте, что purchase, lead и initiate_checkout не дублируются на стороне трекера.

Главный риск — не отсутствие event, а мусорные дубли. Когда Pixel и сервер считают одну конверсию дважды, алгоритм получает кривой сигнал, а аналитика начинает врать. Анализ данных говорит сам за себя: если event match quality низкий, сначала чините идентификаторы и дедуп, потом уже крутите бюджеты.

Обход ограничений браузеров строится на двух вещах: first-party сборе данных и стабильной передаче server-side событий. Практика простая — фиксируйте источник клика, сохраняйте click id в первом хите, прокидывайте его до финального шага и не теряйте его между доменами и редиректами. Если переходов несколько, проверяйте каждую точку, где может обнулиться сессия.

Тестируем гипотезу — смотрим на спенд. Сначала сверяйте количество событий в трекере, кабинете и CRM, потом только масштабируйте связку. Если расхождение больше нормы, проблема почти всегда в карте событий, а не в трафике.