Nike и «пропавшие» конверсии: как мы починили full-funnel атрибуцию через server-side events

Nike и «пропавшие» конверсии: как мы починили full-funnel атрибуцию через server-side events

В 2025 году Nike начал масштабировать кампании на новые сегменты, но в отчетности маркетинг стал видеть неприятную картину: часть конверсий «тонко» расходилась между рекламными платформами и внутренней аналитикой. Раньше расхождения списывали на погрешность пикселей и антибот-логику. Но когда падение совпало по времени с ростом рекламного бюджета, стало ясно: проблема не в креативе, а в данных.

Контекст
Эпоха 2026 бьет по last-click — модели все больше уходят в privacy-first измерения. Когда вы переходите на новые браузерные ограничения, блокировки и «zero-click» поиск, серверные события становятся не «улучшением», а фундаментом. В Nike параллельно усиливали retention-подход: измерять нужно было не только первую покупку, но и повторные заказы, подписки на сервисы, а также возвраты (как источник качества сегмента).

Задача
Нужно было:
— восстановить сопоставимость данных между рекламными витринами и аналитикой сайта/app
— корректно считать события, влияющие на RevOps-метрики (выручка и путь до повторной покупки), а не только lead/checkout
— внедрить first-party трекинг так, чтобы выдерживать блокировки и изменения в клиентах

Решение
1) Перенесли ключевые события на server-side. Клиент отправлял в браузер/приложение минимум: идентификатор сессии + параметры события. Дальше события подписывались на сервере и уходили в аналитическую систему и в места назначения в уже «чистом» виде.
2) Разрулили дедупликацию. Самая частая ошибка при миграциях: дубль события из-за одновременной отправки с клиента и с сервера. Мы ввели единый event-id и правило приоритета (серверный — истинный).
3) Починили сопоставление пользователей. Мы использовали first-party cookie и app-instance id, плюс матчили пользователя через salted-хэши (без хранения лишних данных). Это позволило связать визит → добавление в корзину → покупку → повтор.
4) Добавили контроль качества данных. Для каждого события ввели SLA на доставку и валидацию полей (currency, value, item_id, путь страницы). Когда поле пустое или тип невалиден — событие логируется как «degraded», но не портит отчет.

Результат
После внедрения в течение двух недель:
— доля «неподтвержденных» конверсий снизилась на 31% (по внутренним сопоставлениям с заказами)
— расхождения между внутренней выручкой и витринной атрибуцией сократились с ~12–15% до ~4–6%
— в сегментах, где раньше «проваливали» repeat, стало видно реальное влияние кампаний: прирост повторных покупок в атрибутируемых когортах составил **+8%** к контрольной группе по инкрементальности (incrementality-подход, сравнение с удержанием маркетингового воздействия)
— маркетинг смог быстрее пересобирать гипотезы: цикл оптимизации сократился с недель до дней за счет стабильных событий

Урок
1) Если цифры «плывут», не начинайте с креатива. Начинайте с цепочки данных: где событие теряется, дублируется или искажается.
2) Server-side — это не «перенос пикселя», а управление качеством события: дедуп, схемы полей, идентификаторы и контроль доставки.
3) В 2026 маркетинг отвечает за выручку вместе с RevOps, поэтому аналитика должна поддерживать не только funnel до первой покупки, но и повтор и возвраты. Иначе вы оптимизируете не то.

Если хотите, разберу типовую схему миграции (что переносить первым, как вводить event-id и какие поля обязательно стандартизировать), на примере вашего stack: web+app+CRM.

— @ServerSideTrackingRuPro