Ретеншн без «магии»: как мы собрали server-side события и восстановили LTV-разрез в e-commerce (case breakdown

Ретеншн без «магии»: как мы собрали server-side события и восстановили LTV-разрез в e-commerce (case breakdown)

Бренд/компания
Российский e-commerce (категория: товары повседневного спроса, цикл покупки — повторный). Маркетинг работал по набору кампаний и промокодов, но в аналитике «разъезжались» ключевые вещи: факт доставки/оплаты, корректный источник заказа и итоговая ценность клиента.

Задача
1) Перестать терять часть воронки в вебе и приложении из‑за блокировщиков, отказов и ограничений браузеров.
2) Собрать first-party событийную модель так, чтобы можно было строить когортные разрезы по доставленным заказам и реальной оплате.
3) Пересобрать атрибуцию для оптимизации: уходить от last-click к более устойчивому view на вклад каналов (в рамках доступных данных).

Решение
1) Server-side tracking как «источник истины»
— События с клиента (клики, просмотр карточки, добавление в корзину, начало оформления) отправлялись на сервер, а не напрямую в измерительную систему.
— На server-side происходили валидации (формат параметров, обязательные ключи), дедупликация и привязка к user/session_id.
— Для событий покупки добавили коррекцию: заказ фиксируется только после подтверждения статуса (оплата/закрытие), а не на момент нажатия «оплатить».

2) Единая схема событий и параметры качества
— В карточке события строго описали состав параметров: идентификаторы заказа, корзины/композиции, валюта, скидка/промокод (как *код*, а не как «картинка к баннеру»), а также канал-источник, который формируется по правилам на стороне сайта.
— Это позволило устранить типовую проблему: кампании с одинаковыми названиями в разных источниках начинали «смешиваться» в отчетах.

3) Консолидация клиента и когорт в first-party
— Стали использовать одинаковые идентификаторы на этапах: регистрация/логин/аноним до входа.
— При переходе из гостя в авторизованного пользователя сервер объединял историю по соответствию идентификаторов. В результате когорты начали строиться не «по кнопке», а по факту жизненного цикла.

4) RevOps-логика для ценности, а не для клика
Маркетинг не пытался «дожать» цифры показами. Вместо этого оптимизация опиралась на то, что влияет на выручку после первого визита: повторные покупки и их маржа. Для этого построили сегменты по статусам и времени между заказами.

Конкретный результат
— Веб- и app-данные перестали «рассыпаться» между платформами: доля полных purchase-событий (с ключевыми параметрами заказа) выросла, а расхождения между отчетами по статуса заказа сократились.
— Когорты по retention стали воспроизводимыми: повторные покупки начали попадать в правильные группы по типу промо и источнику привлечения.
— На уровне оптимизации кампаний стало понятно, какие каналы дают не просто первый заказ, а **возврат с измеряемой ценностью (LTV)** — в сегментах, где ранее аналитика переоценивала last-click из‑за потерь событий.

Урок для читателя
1) В 2026 задача не «подключить пиксель», а построить систему, где покупка подтверждается событием правильного статуса. Server-side — это способ сделать измерение устойчивым к приватности и техническим сбоям.
2) События без валидации и дедупликации всегда будут спорить между собой. Дисциплина схемы (что считается заказом, когда событие считается финальным) важнее частоты отправки.
3) Для e-commerce, где средний чек под давлением экономии, нельзя оптимизироваться только под первую покупку. Нужно переводить фокус на retention/LTV и строить когорты так, чтобы они не ломались при смене браузера или обновлении SDK.
4) Атрибуция становится инженерной задачей: приоритет — консистентность данных и инкрементальные (по смыслу) подходы, а не «клик ради клика».

Если хотите, могу в следующем посте дать шаблон server-side схемы событий для e-commerce: какие именно параметры хранить, как формировать финал покупки и как избежать смещения когорт при переходе user из гостя в авторизованного.

— @ServerSideTrackingRuPro