Aviasales: как связали качество поиска с выручкой и не потеряли точность в Amplitude

Aviasales: как связали качество поиска с выручкой и не потеряли точность в Amplitude

В 2025–2026 у Aviasales (продажи авиабилетов) конкуренция сместилась от «кто больше покажет вариантов» к «кто быстрее приводит к бронированию без лишних шагов». Параллельно в privacy-first мире атрибуция стала менее стабильной: last-click хуже отражает путь пользователя, а влияние UI и поисковой логики стало очевиднее измерять внутри продукта. Поэтому бренд пошёл не от рекламных гипотез, а от вопроса: какие события в продукте сильнее всего связаны с бронированием и выручкой — и что именно там ломается?

Задача
1) Разложить воронку поиска на микро-этапы (ввод запроса → уточнение → выдача → выбор → оплата/переход к оплате).
2) Убедиться, что улучшения «скорости/релевантности» не просто растят клики, а приводят к броням и сумме.
3) Свести разрозненные метрики в одну картину для RevOps (маркетинг, продажи и customer success отвечают за выручку совместно): нужен единый набор определений и отчётов.
4) Не уронить точность при изменениях в трекинге и обновлениях интерфейсов.

Решение (как сделали в Amplitude)
— Стандартизировали события и параметры. Для поиска ввели единые event name и параметры вроде:
— `search_query_submitted` (тип запроса, источник экрана)
— `results_impression` (кол-во вариантов, скоринг/ранжирование как параметр)
— `result_clicked` (тип результата: прямой/с пересадкой, ценовой сегмент)
— `checkout_viewed` (наличие страховки/опций, шаг воронки)
— `payment_intent` (статус перехода к оплате)
Важно: фиксировали версию логики/эксперимента отдельным параметром, чтобы потом фильтровать сравнения.

— Построили фиче-варианты на уровне воронки в Amplitude Funnels + Breakdowns.
Ключевая идея: не ограничиваться «поисковым конверсом», а смотреть серию переходов. Например:
1) конверсия ввода запроса → показ результатов
2) конверсия показов → клики по результату
3) конверсия клика → просмотр чека
4) конверсия просмотра чека → payment_intent
Так стало видно, где «обманчивые оптимизации»: иногда растёт кликабельность, но падает переход на оплату.

— Связали продуктовые события с финансовой метрикой через User Properties и Revenue proxy.
Для каждого пользователя собирали свойства (например, «активность в поиске за сессию», «тип маршрута», «история бронирований»). Затем в Amplitude использовали отчёты, которые позволяли сравнить не только долю до checkout, но и распределение выручки по когортам (где checkout_viewed → payment_intent → заказ).

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

Результат
После внедрения модели микро-воронки и привязки к финансовому прокси команда нашла закономерность: один из изменений ранжирования улучшал показатель `result_clicked`, но ухудшал `checkout_viewed` для определённого сегмента маршрутов. Итоговый эффект на выручку оказался нейтральным (а по некоторым когортам — отрицательным) несмотря на рост кликов.
Что сделали: откатили общий релиз и оставили вариант ранжирования для сегмента, где цепочка переходов «клик → просмотр чека → payment_intent» росла одновременно. В итоге по выбранным сегментам конверсия на шаге до checkout увеличилась, а доля “кликов без продолжения” снизилась — именно то, что и влияло на revenue proxy.
…