FB CAPI: как собрать архитектуру событий без потерь и дублей

FB CAPI: как собрать архитектуру событий без потерь и дублей

Потеря событий почти всегда ломает не креатив, а цепочку доставки: браузер режет cookies, редиректы съедают параметры, а фронт не всегда успевает отправить pixel. Решение — строить CAPI как второй независимый канал, а не как «дополнение». Тогда событие уходит и с клиента, и с сервера, а дедупликация решает конфликт по одному event_id.

Базовая схема: источник → трекер/бекенд → API-гейт → Meta. На входе фиксируй fbp/fbc, user_agent, ip, event_time, external_id, event_source_url. Если есть postback из трекера, маппинг делай на уровне сервера, а не в браузере: меньше потерь на JS-ошибках и меньше шума в логах. Для критичных событий держи очередь повторной отправки, иначе любой таймаут превращается в недосылку.

Ключевые правила:
— event_id генерируется один раз и проходит по всем каналам;
— server_event_id не должен пересоздаваться при ретраях;
— таймауты и коды ответа логируются отдельно от бизнес-события;
— email/phone хешируются до отправки, а не после;
— тестируй только на чистом сегменте, иначе ловишь ложные дубли.

Если видишь просадку match quality, сначала проверяй не «алгоритм», а качество входных полей и консистентность event_time. Чистим логи, проверяем постбэки. Data-driven подход или работа вслепую — выбор за тобой.