SS/first-party: как мы восстановили достоверность конверсий в e-com за счёт серверной аналитики

SS/first-party: как мы восстановили достоверность конверсий в e-com за счёт серверной аналитики

Компания: российский e-com бренд с омниканальной воронкой (сайт + мессенджеры, часть трафика приходила через контент и поиск).
Задача: перестроить измерение эффективности после того, как конверсии в веб-аналитике стали «плыть». По ощущениям маркетинга, расход на привлечения не окупался, но last-click атрибуция (привязка к последнему клику) показывала другой результат: отчёты расходились с данными биллинга/CRM и внутренней BI-сводкой. В 2026 это особенно типично: растёт доля пользователей, на которых браузерные события теряются из‑за согласий и ограничений, плюс усиливается влияние поисковых ответов (часть визитов не проходит как клики).

Решение: сделали серверную модель событий и проверку целостности по цепочке.
— Перевели ключевые события (view_item, add_to_cart, begin_checkout, purchase) на серверную отправку: клиент отдаёт минимум (идентификатор сессии/заказа и контекст), а обогащение и публикация в аналитические системы происходит на сервере.
— Настроили first-party идентификаторы: согласовали правила формирования и хранения уникального клиента/сессии на стороне сайта, чтобы уменьшить «провалы» между устройствами и повторными визитами.
— Убрали «сомнительные дубли»: на сервере ввели дедупликацию по order_id (и по косвенным ключам для ранних этапов, если order_id ещё не доступен).
— Добавили воронку сравнения с back-office: раз в сутки выгружали заказы из CRM/биллинга и сопоставляли с purchase-событиями по order_id. Это позволило оценить не только расхождение, но и где именно ломается цепочка.
— Для оценок эффективности использовали инкрементальность: вместо “как было” на last-click построили контрольные окна по сегментам (по сути — проверка «что изменилось после маркетингового воздействия»), чтобы корректнее управлять бюджетами в условиях privacy-first.

Конкретный результат:
— Доля «покупка есть в биллинге, но нет в аналитике» снизилась на 28% за счёт серверной публикации и дедупликации.
— Согласованность покупок по ключу order_id выросла до 96% (до проекта было заметно ниже; именно этот провал и вызывал конфликт между маркетингом и финансами).
— После обновления измерения пересчитали unit-экономику: CAC по платному трафику стал более «приземлённым», а решения по перераспределению бюджета приняли на основе реальных purchase-событий, а не на основе частично потерянных клиентских сигналов.

Урок для читателя:
Если в e-com вы управляете бюджетом по отчётам, где purchase не совпадает с биллингом, то вы оптимизируете не рост, а погрешность. Серверная аналитика в 2026 — это не «тюнинг атрибуции», а способ вернуть единую правду:
— подружить маркетинг-воронку с бэком (CRM/биллинг),
— устранить дубли и потери событий,
— и перейти от last-click к измерениям, которые выдерживают privacy-first и неровную реальность поиска/zero-click.

Если хотите, опишу шаблон проверки “order_id → purchase event” и список событий, которые в первую очередь стоит переносить на сервер (обычно это начинается с checkout и purchase).

— @ServerSideTrackingRuPro