FB CAPI ломается не в пикселе, а в архитектуре передачи событий

FB CAPI ломается не в пикселе, а в архитектуре передачи событий

Схема должна быть простой: фронт собирает browser data, сервер — business event, дальше оба события сходятся в одном event_id. Если у тебя нет дедупликации, один и тот же purchase улетает дважды; если нет таймстампов и нормального match key, часть конверсий просто не склеится. Чистим логи, проверяем постбэки.

Базовый стек:
• client event через pixel для первичного сигнала
• server event через CAPI для устойчивой доставки
• event_id как ключ склейки
• user_data: hashed email, phone, external_id, fbp/fbc
• ретраи на стороне сервера, а не ручной повтор из кабинета

Потери обычно возникают в трех местах: фронт не успел отправить событие, сервер получил 5xx и не добил очередь, CRM шлет мусор в поле user_data. Лечится очередью с подтверждением доставки, idempotency key и валидацией payload до отправки. Если event_id генерится на клиенте — проверь, что он не пересоздается при каждом reload.

Отдельно следи за качеством матчинга: пустые hash-поля, кривой формат телефона, отсутствие fbp/fbc, рассинхрон времени на серверах. Технический стек определяет потолок вашего ROI. Data-driven подход или работа вслепую — выбор за тобой.