FB CAPI ломается не в кабинете, а в цепочке передачи событий
Событие должно идти по схеме: client → server → CAPI endpoint → match по event_id → постбэк в трекер. Если в этой цепочке нет единого event_id, дубли не режутся, а конверсия расползается между браузером и сервером. Базовая архитектура: capture на лендинге, сохранение click_id, передача в CRM/шлюз, затем отправка server-to-server с обязательной синхронизацией времени и статуса лида.
Три точки потери данных:
— не сохраняется click_id при редиректах и кросс-домене;
— CRM режет кастомные поля или меняет формат payload;
— событие уходит без дедупликации, и браузерный пиксель конкурирует с CAPI.
Проверяй не только отправку, но и обратную верификацию: входящий webhook, логирование body, ответ endpoint, повторная отправка при 5xx/timeout. Для критичных событий держи очередь с retry и idempotency key, иначе один сетевой сбой превращается в слепую дыру в атрибуции. Отдельно контролируй timezone, currency, value и external_id — mismatch по ним убивает матчинг сильнее, чем кажется.
Практика простая: сначала строишь маршрут данных, потом уже оптимизируешь качество трафика. Чистим логи, проверяем постбэки. Data-driven подход или работа вслепую — выбор за тобой.
Трекер-стек
@tracker_stack_ubt
FB CAPI ломается не в кабинете, а в цепочке передачи событий
Этот пост опубликован в Telegram-канале Трекер-стек. Подписаться можно по ссылке: @tracker_stack_ubt.