Дедупликация событий между браузерным пикселем и серверным CAPI: настройка за один вечер

Дедупликация событий между браузерным пикселем и серверным CAPI: настройка за один вечер

Когда вы шлёте одно и то же событие и пикселем, и с сервера, платформа считает его дважды. Конверсии задваиваются, ROAS врёт, оптимизация учится на мусоре. Лечится сквозным `event_id`. Что сделать на этой неделе:

— Сгенерируйте `event_id` на бэкенде в момент действия пользователя (UUID v4 на заказ/лид). Не на клиенте — клиент потеряете при блокировке скриптов.

— Прокиньте этот id на фронт вместе со страницей подтверждения. Браузерный пиксель шлёт событие с `eventID`, передавая ровно ту же строку.

— Сервер шлёт то же событие через Conversions API с полем `event_id` (snake_case — у Meta поля в API и в пикселе называются по-разному, это типовая ошибка).

— Совпасть должны три вещи: `event_id`, `event_name` и попадание в окно дедупликации (у Meta — 48 часов). Разное имя события (`Purchase` против `purchase`) ломает склейку.

— Проверьте в Events Manager → Test Events: у пары должен стоять флаг *Deduplicated*. Если его нет — сверьте регистр имени и формат id побайтово.

Контрольная точка: в Events Manager доля дедуплицированных событий по `Purchase` за сутки должна быть около 90–100%. Всё что ниже 80% — у вас часть трафика без серверного id, ищите где обрывается проброс.

Серверный канал не замена пикселю, а страховка от блокировок. Дедупликация — то, что превращает два источника в один чистый сигнал.

— @AdOpsRoom