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

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

Если сервер отправляет Purchase, а в Events Manager пусто, проблема обычно в одном из звеньев цепочки: client_id не матчится, event_id не уникален, а ретраи плодят дубли. CAPI должен быть не «ещё одним POST», а частью схемы с нормальной маршрутизацией событий.

Базовый стек: пиксель для фронта, CAPI для сервера, единый event_id для дедупликации, timestamp в UTC, обязательные user_data хэши, и отдельный лог отправки. Без этого невозможно понять, где именно теряются ViewContent, InitiateCheckout или Lead.

Что проверять в первую очередь:
— совпадает ли event_name и schema между фронтом и сервером;
— уходит ли событие через S2S только после подтверждения действия;
— не режет ли шлюз request body, cookies или referrer;
— есть ли retry с backoff, а не бесконечный повтор без контроля;
— пишется ли ответ API в сырые логи для последующей сверки.

Если трафик смешанный, разделяй источники по отдельным потокам и помечай события source/placement/campaign_id. Тогда можно сравнить client-side и server-side конверсию, найти провалы по конкретному офферу и отключить шум до того, как он убьёт оптимизацию.

Чистим логи, проверяем постбэки. Data-driven подход или работа вслепую — выбор за тобой.