Server-side tracking

Сжатие атрибуции: как мы перевели e-commerce с client-side на server-side и перестали “терять” конверсии

Компания: средний e-commerce бренд (категория FMCG/товары для дома) с ростом рекламных закупок и просадкой точности аналитики после обновлений браузеров и ограничений на cookie.

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

Решение: внедрили server-side tracking с опорой на first-party данные и сделали атрибуцию воспроизводимой.
— Настроили сбор событий “Путь покупателя” на сервер: просмотр карточки, добавление в корзину, начало оформления, оплата/успешная покупка.
— Провели унификацию идентификаторов: если раньше часть связок “терялась” на клиенте, то теперь связка “покупка ↔ сессия ↔ идентификатор пользователя” формируется в backend-слое и отправляется в хранилище/аналитику единообразно.
— Разграничили роли: клиент отправляет событие и минимальный контекст, сервер обогащает по правилам (utm-параметры, сессионные признаки, версия сайта, согласия на измерения).
— Поставили валидацию: сравнили потоки client-side vs server-side по контрольным событиям (доли полученных purchase-событий, согласованность revenue-полей, частота дублей, корректность времени).
— Подготовили основу для “пересборки” измерений в духе incrementality: вместо споров о последнем клике — фокус на управляемых изменениях (что именно считается результатом и как это измеряется при разных тестах креативов/аудиторий).

Конкретный результат (что видно по цифрам после запуска):
— Доля корректно зафиксированных покупок выросла, потому что часть событий перестала “обрываться” на клиенте: по итогам двух недель стабильной работы доля purchase-событий в server-side была выше относительно client-side в сопоставимых срезах.
— Снизилось число расхождений между рекламной платформой и внутренней аналитикой: разница по суммарной выручке на покупку уменьшилась за счет того, что событие и параметры формируются в одном месте, а не зависят от браузерных ограничений.
— Уменьшилось количество дублей/сбоев: унификация схемы событий и контрольные правила сократили “шум” в воронке (в первую очередь на этапах start checkout → purchase).

Урок для читателя:
1) Server-side — это не “ещё один пиксель”, а способ сделать измерение воспроизводимым. Если бизнес принимает решения по разным датасетам, роли server-side в том, чтобы устранить асимметрию.
2) Не начинайте с красивых отчётов — начните с сопоставимости ключевых событий (особенно purchase): выверка полей, времени, идентификаторов и дедупликации экономит месяцы.
3) В 2026 году, когда SEO уходит в Topical Authority и растут AI-overviews, а в performance усиливается privacy-first атрибуция, маркетингу важнее не “где последний клик”, а “что мы реально управляли” и как это измеряется. Server-side tracking — база для таких разговоров и для связки с RevOps (маркетинг, продажи и customer success за общий результат).

Если хотите, могу дать чек-лист этапов: как построить схему событий, какие контрольные метрики валидации смотреть в первые 7–14 дней и как подготовить данные для incrementality-экспериментов без смены всей отчётности “в один вечер”.

— @ServerSideTrackingRuPro

1 view06:49