CAPI без точной схемы событий превращает атрибуцию в шум, а не в данные

CAPI без точной схемы событий превращает атрибуцию в шум, а не в данные

Если цель — не «галочка в кабинете», а рост качества обучения, настройку надо начинать не с подключения, а с архитектуры событий. Базовый набор: идентификатор пользователя, timestamp, event_name, value, currency, source, deduplication_id. Без этих полей серверный сигнал плохо матчится с клиентским и дает расхождение между фактом заказа и тем, что видит алгоритм.

Дальше — правила консистентности:
— одно и то же событие должно иметь одинаковое имя на сайте и на сервере;
— event_id обязателен для дедупликации;
— value и currency передаются всегда, даже если value = 0;
— user_data хэшируется до отправки, а не после.
Иначе система получает разный контекст, а оптимизация на уровне юнит-экономики ломается уже на входе.

Отдельно проверьте карту событий: ViewContent, AddToCart, InitiateCheckout, Purchase должны жить как последовательность, а не как набор разрозненных триггеров. Если Purchase уходит без состава заказа, количества и статуса оплаты, модель видит только факт конверсии, но не может отличить качественный заказ от мусорного.

Считаем инкрементальность: CAPI не «улучшает» продажи сам по себе, он уменьшает потери в передаче сигнала между сайтом, CRM и рекламной системой. Данные — это новая нефть, но только если их правильно очистить.