Conversion API работает только тогда, когда выстраивается как система, а не как “галочка”

Conversion API работает только тогда, когда выстраивается как система, а не как “галочка”

Клиентский пиксель и server-side CAPI решают разные задачи: первый ловит поведение браузера, второй — фиксирует факт события на стороне сервера. Если отправлять одно и то же событие без строгой дедупликации по event_id, модель получает дубли и начинает переоценивать эффективность связок.

Базовая схема настройки:
— единый event_id на фронте и бэке;
— стабильный набор user_data: email, phone, external_id после нормализации;
— одинаковая event_name-логика для всех источников;
— передача timestamps в одной временной зоне;
— контроль event_source_url и action_source.

Далее важна не “полнота полей”, а качество матчинга. Данные — это новая нефть, но только если их правильно очистить: хэшировать нужно только нормализованные значения, без пробелов, лишних символов и разнобоя в регистре. Иначе match rate падает, а алгоритм закупки получает шум вместо сигнала. Считаем инкрементальность: если событие и так стабильно приходит из браузера, CAPI должен не заменять его, а закрывать потери по отказам, блокировкам и потере cookie.

Проверьте цепочку атрибуции отдельно: тестовое событие, совпадение по времени, наличие source/medium, и отсутствие дублей в CRM-выгрузке. Если сервер шлет событие позже окна атрибуции, в отчете оно уже не влияет на обучение, даже при идеальной технике.

Оптимизация на уровне юнит-экономики начинается с чистого трекинга: сначала дедупликация, затем нормализация, потом контроль match rate и только после этого масштабирование бюджета.