Мониторинг Meta CAPI и server-side: что проверять, пока трафик ещё не просел

Мониторинг Meta CAPI и server-side: что проверять, пока трафик ещё не просел

Если событие отправляется, это ещё не значит, что оно доехало в Meta без потерь. У server-side трекинга сбои чаще всего тихие: часть хитов уходит в дубликаты, часть — в «сырые» параметры, часть — в пустые user_data.

Проверяйте цепочку целиком: браузер → сервер → CAPI → Events Manager. Смотрите не только на факт отправки, но и на match quality, количество deduped events, долю missing parameters и расхождение между внутренней логикой и отчетом Meta. Один и тот же пиксельный event может выглядеть «зелёным», но при этом терять атрибуцию из-за плохого event_id или кривого хеширования.

Отдельно мониторьте стабильность параметров: email, phone, external_id, fbp/fbc, IP и user-agent. Если у части лидов поля приходят в разном формате, качество матчинга падает без видимого алерта. Полезно держать простое правило: любое изменение формы, CRM, трекера или прокладки должно проходить через тестовый прогон с контролем дубликатов и полноты payload.

Минимальный набор контроля: лог отправки, ответ API, сверка событий по часу, алерт на резкое падение match quality и отдельная проверка postback-цепочки. Если этого нет, проблемы с CAPI обычно находят не по мониторингу, а по просадке CPA.

Лучше ловить расхождения на уровне полей и статусов, чем потом искать «почему алгоритм стал хуже».