<b>FB CAPI ломается не в пикселе, а в цепочке передачи событий</b>

<b>FB CAPI ломается не в пикселе, а в цепочке передачи событий</b>

Схема должна быть простой: источник → сервер трекера → CAPI-гейт → Facebook. Чем больше промежуточных скриптов и ручных коллбеков, тем выше шанс потерять event_id, timestamp и дедупликацию. На уровне архитектуры критично разделить client-side и server-side потоки, а потом сводить их по одному ключу.

Базовый набор для стабильной передачи:
— единый event_id для браузера и сервера;
— нормализованный user_data: email, phone, fbp, fbc, ip, ua;
— очередь ретраев на 2–3 попытки с логированием ответа;
— контроль таймаута, чтобы не дублировать событие при лаге;
— маппинг событий без «творчества» в названиях.

Главная причина потерь — грязный постбэк-слой. Если трекер режет параметры, а API-гейт не валидирует payload, в FB улетает пустой или кривой event. Проверяй не только факт отправки, но и статус ответа, совпадение event_name, наличие dedup key и заполненность обязательных полей. Чистим логи, проверяем постбэки.

Для защиты от потерь ставь мониторинг на разрыв между кликом, конверсией и отправкой CAPI. Если сервер получил лид, а Facebook его не принял, событие должно уходить в повторную очередь, а не исчезать. Data-driven подход или работа вслепую — выбор за тобой.