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

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

Связка должна быть собрана как поток данных, а не как набор костылей: источник → сервер трекинга → дедупликация → отправка в CAPI → контроль ответов. Если сервер не хранит event_id, event_time и user_data в едином ключе, события начинают теряться на стыке клика, лендинга и оплаты.

Базовые точки контроля:
— event_id генерируется на входе и проходит через весь флоу без пересоздания;
— event_time пишется в момент события, а не на этапе ретрая;
— user_data нормализуется до отправки: email, phone, IP, ua, fbp/fbc;
— для каждого события нужен один источник истины, иначе ловите дубли и разъезд атрибуции.

Потери данных чаще всего идут из-за асинхронных очередей, таймаутов и слабого логирования. Если нет очереди с ретраями, часть конверсий просто исчезает при сетевых сбоях. Если нет storage для сырого payload, вы не сможете восстановить цепочку и проверить, где именно отвалился постбэк. Чистим логи, проверяем постбэки.

Минимальный рабочий стек: серверный endpoint, очередь на отправку, retry policy с backoff, дедуп по event_id и health-check по HTTP-ответам. Data-driven подход или работа вслепую — выбор за тобой.