Amplitude cookbook: как Aviasales переупаковал продуктовые события в единую карту ценности и поднял конверсию

Amplitude cookbook: как Aviasales переупаковал продуктовые события в единую карту ценности и поднял конверсию в бронирование

Контекст
Aviasales — типичный метапоисковик с длинной цепочкой до целевого действия: пользователь не просто “переходит”, а проходит сценарий выбора (маршрут → даты → пассажиры → оформление). В конце 2020-х (и особенно в 2026) усложнилась атрибуция: privacy-first подходы и рост доли “нулевых” (zero-click) сценариев сделали влияние последнего клика менее надежным. Команда решила, что главный риск — не в маркетинговом канале, а в разрыве между тем, как продукт измеряет путь к бронированию, и тем, как маркетинг пытается оптимизировать воронку.

Задача
1) Свести разрозненные события (по страницам, кликам и API-запросам) в “единую карту ценности” — от намерения до бронирования.
2) Научиться быстро отвечать на вопросы RevOps-формата (маркетинг–продажи–customer success): *что именно ускоряет путь до целевого действия и снижает потери на ключевых шагах?*
3) Уменьшить хаос в интерпретации: одна и та же логика должна одинаково считаться в аналитике продукта и в маркетинговой оптимизации.

Решение
Шаг 1. Пересобрали событийную модель под JTBD (работу, которую выполняет пользователь)
В Amplitude выделили 5 уровней событий:
— **Intent** (намерение): выбор маршрута, старт выбора дат
— **Consideration** (рассмотрение): просмотр вариантов, изменение параметров
— **Progress** (прогресс): открытие страницы ввода данных, шаг с подтверждением
— **Commit** (фиксация): начало оформления, создание брони (booking initiated)
— **Outcome** (результат): успешное бронирование (booking completed) и фейлы с причинами

Важно: события по “ошибкам” разнесли на категории (не “что-то пошло не так”, а, например, “платеж не прошёл”, “не прошла валидация формы”, “тайм-аут подтверждения”). Это резко упростило работу с удержанием и повторными попытками.

Шаг 2. Добавили “временные окна” для сценариев, а не просто funnels
Funnels часто ломаются из‑за того, что люди возвращаются и меняют параметры. Поэтому сделали паттерны в Amplitude:
— сценарий “намерение → прогресс” с учетом возвратов в шаги
— контроль длительности сессии: где задержки чаще всего приводят к выходу
— сегменты по устройствам и источнику входа (без ожиданий, что last-click все объяснит)

Шаг 3. Верифицировали измерения через когорты и контрольную группу
Чтобы не оптимизировать “на шум”, внедрили проверку изменений метрик:
— когорты пользователей, которые дошли до Commit, и сравнение конверсии Outcome
— мониторинг изменения распределения причин фейлов после продуктовых релизов
— отдельно смотрели, не сместилась ли конверсия просто за счет изменения состава аудитории (а не качества сценария)

Результат
После приведения событий к единой логике команда получила измеримую управляемость:
— конверсия из Commit в Outcome стала стабильнее между релизами (меньше “скачков” из-за неконсистентных событий)
— доля непроясненных фейлов снизилась: когда ошибки стали типизированными, воронка перестала “падать в пустоту”
— время до выявления узкого места сократилось: вместо долгих разборов логов продуктовых команд стали использовать Amplitude-отчеты по причинам и шагам сценария
По внутренним цифрам (за квартал после внедрения модели событий) конверсия в бронирование выросла на **несколько процентов** именно там, где раньше было сложно договориться: на стыке маркетингского “привели” и продуктового “довели”.

Урок
1) Единая карта ценности важнее количества событий. Лучше 15 событий, которые строго соответствуют этапам сценария, чем 200 кликов, которые невозможно согласовать.
2) Для длинных путей используйте не только воронки, а сценарии с окнами и когортами: возвраты — это нормальная часть поведения.
3) Типизируйте ошибки как продуктовую классификацию — иначе вы оптимизируете “в общем”, а не “на причинах”.
4) В 2026 RevOps требует метрик, которые понимают все стороны: Amplitude помогает, когда события одинаково описывают намерение, прогресс и исход.
…