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

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

Если серверные события дублируют браузерные без event_id, алгоритм начинает считать одну и ту же конверсию дважды. Если вы шлёте только лид без статуса оплаты, то оптимизация уходит в пустой сигнал. Базовая схема должна быть такой: browser event для скорости, CAPI для устойчивости, а дедупликация — через одинаковый event_id на обоих каналах.

Проверяйте три точки:
• Идентификатор события совпадает в браузере и на сервере
• Timestamp не «гуляет» между источниками
• Match quality не падает из-за пустых email/phone/fbp/fbc

Ограничения браузеров чаще всего бьют по атрибуции, а не по самой отправке. Когда cookie режутся, спасает не «магия» трекера, а нормальная схема first-party: свой домен, передача параметров в URL, сохранение click id и прокидывание их до purchase. Если этого нет, CAPI просто отправит событие без нормального связывания с кликoм.

Анализ данных говорит сам за себя: сначала смотрите в Events Manager расхождения между browser и server, потом — логи трекера и ответы API. Если сервер шлёт, а кабинет не принимает, проблема обычно в структуре payload, dedup или в том, что событие не проходит валидацию по обязательным полям. Тестируем гипотезу — смотрим на спенд.

Сильная связка CAPI — это не больше событий, а чище данные и стабильное сопоставление.