Серверная аналитика как фундамент RevOps: как Aviasales синхронизировали GA4, Amplitude и CRM без «магии атриб

Серверная аналитика как фундамент RevOps: как Aviasales синхронизировали GA4, Amplitude и CRM без «магии атрибуции»

В 2026 году многие компании упираются не в количество событий, а в то, что они не сходятся между собой: маркетинг видит одно, продукт — другое, а продажи в CRM — третье. У Aviasales (публично известный кейс в индустрии) это проявилось особенно болезненно после волны изменений в приватности: last-click стал менее надежным, а «красивые» дашборды начали расходиться с фактическими сделками.

Контекст
- Авиа-сегмент с длинным циклом выбора: пользователь может несколько раз возвращаться к поиску/сравнению, прежде чем оформить покупку.
- Рентабельность (маржинальность) зависит не только от конверсии сайта, но и от качества лидов и повторных покупок.
- В переходе эпохи privacy-first атрибуции компаниям выгоднее смотреть на связку: **событие → идентификатор → сессия/путь → оффер/кампания → сделка/выручка**. Если один узел рвётся, RevOps-метрика (выручка/возврат воронки) начинает «плавать».

Задача
Нужно было ответить на три вопроса, которые в реальном бизнесе всегда звучат по-разному, но смысл один:
1) Какие именно действия на сайте лучше всего предсказывают оформление (purchase) и последующее поведение?
2) Почему в одном отчёте «лид дошёл», а в другом — «не дошёл до целевого действия»?
3) Как разорвать зависимость от client-side трекинга (и угадывания) в пользу воспроизводимого server-side потока, чтобы маркетинг и продажи одинаково понимали результат.

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

2) Развели роль инструментов: GA4 как измеритель веб-пути, Amplitude как поведенческий анализ
- GA4 использовали как «сквозной» источник для отчётности по воронкам и когортам, где важно соответствие базовой модели измерений.
- Amplitude применяли для анализа поведения: сегментации по шагам, расчёта retention (удержания) и сравнения групп до и после изменений в UI/флоу.
- Главное — договорились о контракте событий: название, параметры, типы, обязательные поля. Без этого сравнение GA4 vs Amplitude превращается в спор о том, что вообще считать одним и тем же действием.

3) Сшили аналитику с CRM для RevOps-метрики
- В CRM/билинге событие «сделка» (сумма, статус, канал привлечения) связывали с тем, какие пользовательские события предшествовали успеху.
- Маркетинговые кампании начали передаваться как структурированные параметры (идентификаторы кампаний и источников), а не как строка, которую потом приходится «парсить руками».
- Для снижения ошибок атрибуции ввели подход к измерению инкрементальности: не полагались на last-click, а смотрели на рост метрик относительно контрольных/неоднородных групп (в реальных условиях — через методику, которую можно воспроизвести на данных компании).

4) Добавили контроль качества данных (Data QA), иначе всё разваливается незаметно
- Проверяли доли дубликатов, полноту параметров (например, заполненность параметров campaign_id), согласованность временных меток.
- Сделали «алерты» на расхождения между системами: например, если purchase в GA4 начинает расходиться с серверной фиксацией в заказах, дашборды блокировали от интерпретации.

Результат
После внедрения контур стабилизировался, и бизнес-метрики перестали зависеть от «косметики в отчётах».
…