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

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

CAPI — это не “включил и работает”, а цепочка: пиксель/SDK → сервер → API-гейт → Meta. Если на любом звене нет idempotency, нормальной очереди и ретраев, часть событий теряется или дублируется. Для ROI это одинаково плохо: атрибуция шумит, сплит-тесты врут, а оптимизация едет в слепую.

Собирай архитектуру вокруг server-side first:
— event_id и order_id должны жить сквозняком от фронта до бэка;
— timestamp, fbp/fbc, external_id и user_data передавай без кастомной “очистки”;
— логируй статус каждого запроса, payload hash и ответ API;
— ставь retry с backoff, но с дедупликацией, иначе получишь мусор в отчетах.

Главные точки потери данных: редиректы, таймауты CRM, кривые webhook’и, пустые поля после антифрода и ручные интеграции через no-code. Любая асинхронщина без очереди — это риск. Нормальная схема: событие пишется в буфер/БД, потом уходит в CAPI, а статус доставки возвращается в лог. Так можно быстро искать, где именно рвется цепочка.

Отдельно проверь match quality: если user_data бедный, Meta видит событие, но не связывает его с пользователем. Чистим логи, проверяем постбэки. Data-driven подход или работа вслепую — выбор за тобой.