<b>CAPI без точной схемы событий превращает атрибуцию в шум, а не в сигнал</b>

<b>CAPI без точной схемы событий превращает атрибуцию в шум, а не в сигнал</b>

Главная ошибка — отправлять в серверный поток те же события, что и в пиксель, без дедупликации. Если event_id не совпадает, система считает два конверсийных факта вместо одного. В результате inflated CR, сломанный ROAS и ложные выводы по аукциону. Сначала фиксируем модель данных, потом подключаем передачу.

Минимальный контур настройки:
— единый event_id на клиенте и сервере;
— стабильные названия событий без синонимов;
— обязательные параметры: event_time, value, currency, user_data;
— хеширование PII до отправки;
— проверка, что сервер не режет события по таймауту или пустым полям.

Дальше смотрим не на факт отправки, а на качество матчинг-пула. Если user_data бедный, CAPI просто ускоряет потерю данных. Нужны хотя бы email, phone, external_id, fbp/fbc, где это допустимо архитектурой. Чем выше доля совпадений, тем меньше модель опирается на вероятностные догадки и тем стабильнее оптимизация на стороне рекламной системы.

Отдельно контролируйте источник истины: если CRM подтверждает покупку позже вебхука, серверный сигнал должен иметь статус final, а не provisional. Иначе вы строите отчетность на двойном учете и ловите фантомный ROMI.

Считаем инкрементальность: CAPI полезен только тогда, когда он снижает потери в цепочке «клик → событие → атрибуция». Без дедупликации, хеша и валидации payload это не интеграция, а генератор артефактов.