FB CAPI ломается не в API, а в архитектуре передачи событий
Если события идут только из браузера, ты теряешь часть цепочки: adblock, отказ от cookies, обрыв сессии, дубль конверсии. Нормальная схема — гибрид: Pixel для клиента, CAPI для сервера, а между ними единый event_id и строгая дедупликация.
• Генерируй event_id на стороне трекера до редиректа и тащи его в лидах, заказах и postback.
• Сохраняй минимум: fbp, fbc, external_id, timestamp, value, currency, event_name.
• Шли события через очередь или буфер, а не напрямую из формы: так ты переживёшь лаги, ретраи и падения API.
• Логи режь по связке event_id → status → retry_count, иначе потеря данных станет невидимой.
Самая частая ошибка — отправлять CAPI без валидации: дубли, пустые user_data и разъехавшееся время события убивают match quality и делают оптимизацию шумной. Проверяй таймстемпы, нормализуй телефоны и email перед хешированием, а тестовые события отделяй от боевых.
Чистим логи, проверяем постбэки. Если у тебя нет сквозной трассировки от клика до CAPI-ивента, ты не строишь атрибуцию — ты гадаешь.
Трекер-стек
@tracker_stack_ubt
FB CAPI ломается не в API, а в архитектуре передачи событий
Этот пост опубликован в Telegram-канале Трекер-стек. Подписаться можно по ссылке: @tracker_stack_ubt.