CAPI повышает точность не магией, а правильной схемой передачи событий

CAPI повышает точность не магией, а правильной схемой передачи событий

Конверсионный API нужен не для «ускорения алгоритма», а для снижения потерь в цепочке трекинга. Если браузерный пиксель видит только часть событий, модель оптимизации обучается на шуме. Считаем инкрементальность: чем полнее и чище сигнал, тем ниже дисперсия в атрибуции и выше качество обучающей выборки для аукциона.

Базовая настройка всегда одна:
— отправлять ключевые события server-side, а не дублировать всё подряд;
— передавать event_id для дедупликации браузерных и серверных хитов;
— прокидывать максимум идентификаторов матчинга: email, phone, external_id, IP, user agent;
— нормализовать формат данных до отправки, иначе матчинг деградирует;
— хранить логи отказов, чтобы видеть, где ломается цепочка. 🧩

Главная ошибка — считать, что достаточно «подключить интеграцию». Без проверки дедупликации вы получите двойной учёт. Без теста на задержки — события будут приходить, когда обучение уже успело принять решение. Без контроля match quality вы не поймёте, это у вас вырос объём или просто ухудшилось сопоставление.

Правильная схема: браузерный пиксель как резервный слой, CAPI как основной источник, а QA — по каждому типу события отдельно. Сначала сверяете sent vs received, потом долю matched events, затем расхождения по ценности и статусу заказа. Оптимизация на уровне юнит-экономики начинается с того, что данные не врут сами себе.

Если событие нельзя дедуплицировать и воспроизвести в логах, его нельзя использовать как опору для оптимизации.