С server-side атрибуцией и RevOps: как X5 выстроила “единый контур” маркетинга и измерения

С server-side атрибуцией и RevOps: как X5 выстроила “единый контур” маркетинга и измерения

Контекст
В 2026 году у продуктовых сетей давление с двух сторон: средний чек в e-com продолжает снижаться (экономия уходит в повторные покупки и потребление по акциям), а “последний клик” перестаёт объяснять причинность. Плюс растёт доля поисковых сценариев с нулевыми переходами: часть пользователей закрывает потребность через AI-обзоры и не приходит “в лоб” на сайт. В такой реальности маркетинг и продажи всё сильнее спорят не о креативе, а о цифрах: что реально приносит выручку, а что просто присутствует в пути.

Задача
X5 (группа компаний) столкнулась с типовым разрывом для маркетинговых команд:
- аналитика жила в разных системах (веб-аналитика, CRM, реклама, коллтрекинг) без единого идентификатора клиента;
- измерение влияния кампаний было “по событию”, а не “по выручке” (конверсии на верхних шагах не связывались с продажами);
- атрибуция зависела от клиентских браузеров и cookie-данных, что ухудшало стабильность показателей от месяца к месяцу.

Решение
Решение было не “внедрить ещё один тул”, а разложить контур на слои: сбор → идентификация → доставка данных → управляемая модель измерения.

1) Server-side сбор и стандартизация событий
- перенесли ключевые события на server-side (данные уходят через контролируемый шлюз, а не напрямую из браузера);
- завели единый словарь событий: “просмотр оффера”, “выбор слота/доставки”, “оформление заказа”, “оплата”, “возврат”;
- настроили контроль качества: дедупликацию заказов и валидацию обязательных полей (id пользователя, канал, источник, время).

2) “Сквозной ключ” через CRM и транзакции
- связали клики/сессии с CRM по хэшированным идентификаторам (email/телефон при согласии), а покупки — с заказами в бэкенде;
- вместо “MQL/не MQL” сделали измерение через коммерческий результат: revenue на этапе “заказ” и “повторная покупка” (retention) уже в данных.

3) Пересборка атрибуции: от last-click к incrementality
- отказались от единственной оценки “кто последний”;
- добавили holdout-логики и модель прироста (incrementality): сравнение групп с и без воздействия с учётом макро-факторов (сезонность, промо-активности, наличие товара/слотов).
Это важно: цель — не “красивый ROAS”, а вероятность того, что кампания меняет поведение, а не просто совпадает по времени.

4) RevOps-ритм и операционная дисциплина
- утвердили контур ответственности: маркетинг — за качество данных и гипотезы, продажи — за конверсию в коммерческое действие, customer success — за повтор и работу с качеством заказов;
- еженедельный цикл пересмотра кампаний через метрики прироста выручки и качество воронки, а не через “сколько кликов”.

Результат
Что это дало на практике (цифры команды обычно фиксируют помесячно):
- стабильность атрибуции выросла: доля “необъяснённых” заказов снизилась (меньше потерь из-за блокировок и деградации cookie);
- измерение влияния стало переносимым между каналами: кампании в поиске, перформансе и CRM стали сопоставимы через выручку и прирост;
- управленческие решения ускорились: время от запуска гипотезы до корректировки медиаплана сократилось благодаря единым событиям и сквозным ключам;
- на уровне портфеля заметили сдвиг эффективности в сторону retention-сценариев: доля повторных заказов в тестируемых сегментах росла, а стоимость привлечения “в первом касании” перестала быть единственным KPI.

Урок
1) “Единый контур” выигрывает у “зоопарка тулов”. Без сервер-side сбора и словаря событий цифры всегда будут спорными.
2) Сквозной ключ — это фундамент RevOps: если вы не связываете события с заказами, вы не управляете выручкой, вы управляете отчётностью.
3) Last-click в 2026 — скорее стартовая точка. Управлять нужно через прирост и измерение влияния, иначе оптимизация превратится в борьбу за видимость.
4) Операционная дисциплина важнее “идеальной модели”: holdout/инкрементальность + еженедельный пересмотр решений превращают аналитику в систему управления, а не в разовый отчёт.

— @MarTechStackRuPro