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

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

Архитектура должна быть простой: источник события → ваш сервер → CAPI-гейт → Facebook. Не гоняйте событие напрямую из фронта, если есть риск блокировок, adblock, JS-ошибок и разрыва сессии. На сервере фиксируйте event_name, event_time, event_id, fbp/fbc, IP, UA, external_id и source_url. Без event_id нормальный дедуп между Pixel и CAPI невозможен.

Критичные точки потерь:
— нет стабильного event_id на стороне клиента и сервера
— куки fbp/fbc не доживают до серверной отправки
— события уходят без таймстампа или с задержкой, которая ломает атрибуцию
— ретраи настроены без идемпотентности и создают мусор в отчетах

Схема с очередью надежнее синхронного POST: сначала кладете событие в буфер, потом отдельный воркер шлет в CAPI и пишет ответ в лог. Это дает контроль над retry-policy, rate limit и ошибками 4xx/5xx. Важно хранить сырой payload и статус доставки, иначе вы не отличите потерю на клиенте от отказа API-гейта.

Держите отдельный мониторинг по доле совпадений Pixel/CAPI, по ошибкам валидации и по пустым параметрам. Если падает match quality, первым делом проверяйте сбор fbp/fbc, TTL куки и корректность source_action_source. Чистим логи, проверяем постбэки.