Собесов

Aviasales Booking — метрики экрана выбора доп. услуг

Продуктовая аналитикаМетрики продуктаСредняяMiddle

Условие

Перед вами шаг воронки бронирования билетов на Aviasales: экран выбора дополнительных услуг (возврат, обмен, страховка, уведомление). Партнёры продают через нас не только билеты, но и сопутствующие услуги.

Воронка выглядит так:

  1. Заполнение данных пассажиров.
  2. Выбор дополнительных услуг ← этот шаг.
  3. Выбор места.
  4. Оплата заказа.

Вопросы:

  1. Какие действия пользователя на этом экране вы стали бы логировать? Какие метрики вы посчитали бы по этим логам? Считайте, что технических ограничений нет — собирайте всё.
  2. Какие из метрик наиболее важные? Как их рост или падение влияют на экономику продукта?
  3. Какие продуктовые изменения можно сделать, чтобы улучшить эти метрики?

Решение

Шаг 1. Карта событий (логирование)

Все события — с user_id, session_id, order_id, ts, platform, app_version, experiment_buckets, traffic_source. Дальше — что специфично для экрана:

a) Просмотр экрана

  • extras_screen--shown — сам факт показа экрана (с services_offered — какие услуги показаны, в каком порядке, по какой цене).
  • extras_screen--viewport — какие услуги попали в видимую область (для long-list / accordion).
  • extras_card--shown — каждая карточка услуги (для расчёта view-rate каждой).

b) Взаимодействие с услугой

  • extras_card--click — клик по карточке (раскрыли подробности).
  • extras_card--info_view — посмотрели описание (модалка/expand).
  • extras_card--toggle — добавили/убрали в заказ (добавили → состояние selected: true/false).
  • extras_card--qty_change — для услуг с количеством (страховка по числу пассажиров).
  • extras_dependent_change — пользователь изменил что-то в зависимой услуге (например, страховку при is_return = 1).

c) Выход с экрана

  • extras_screen--continue — нажал «продолжить» (с selected_services и total_extras_amount).
  • extras_screen--skip — нажал «пропустить» (если есть отдельная кнопка).
  • extras_screen--back — назад.
  • extras_screen--exit — закрыл/ушёл с сайта без действия.
  • extras_screen--time_spent — время на экране (вычисляется при выходе).

d) Платформенно-специфичное

  • scroll_depth_pct — насколько проскроллили длинный список.
  • card_hover (desktop) — задержка на услуге.
  • tooltip--shown — нативные подсказки.

Шаг 2. Метрики

Воронка (бинарные)

  • extras_view_rate = пользователи, увидевшие экран / увидевшие шаг 1 (заполнение пассажиров). Если падает — что-то с маршрутизацией.
  • extras_engagement_rate = пользователи, которые взаимодействовали (клик/тогл/инфо) / увидели экран. Это «насколько экран живой».
  • extras_attach_rate = пользователи, добавившие хотя бы одну услугу / увидевшие экран. Главный север для монетизации.
  • extras_skip_rate = ушли без выбора / увидели экран. = 1 − attach_rate, но удобно как отдельная метрика.
  • continue_rate = нажали «продолжить» / увидели экран. Должен быть ≈100%, иначе у нас дроп со страницы.

Per-service

  • view_rate_service_X = увидевшие конкретную карточку.
  • click_rate_service_X = кликнули / увидели карточку.
  • attach_rate_service_X = выбрали / увидели.
  • uplift_per_service_X = средний доп. revenue с показа (per-shown).

Деньги

  • avg_extras_per_order — среднее число услуг на заказ.
  • extras_revenue_per_order — средняя выручка по услугам на заказ.
  • extras_profit_per_order — профит на заказ (важнее, потому что разные услуги имеют разную маржу).
  • take_rate = extras_revenue / order_price — какую долю чека составляют апсейлы.

Поведение

  • time_on_screen (median) — слишком быстро = не разобрались; слишком медленно = трудно выбрать.
  • scroll_depth_p50 — до какой строки доскроллили.
  • info_view_rate — % раскрытий описания.
  • toggle_off_rate — сколько раз сначала добавили, потом убрали (сомнения).

Сегменты

Все метрики обязательно считать с разрезами:

  • по платформе (desktop / ios / android),
  • по is_return (туда / туда-обратно),
  • по booking_depth (последний день / неделя / месяц вперёд),
  • по гео (origin / destination),
  • по сегментам пользователей (новый / повторный, премиум / бюджет).

Шаг 3. Какие метрики самые важные

Топ-3 для бизнеса:

  1. extras_attach_rate — главная метрика монетизации экрана. Растёт → растёт extras_revenue_per_order. Падает → нужно срочно пересмотреть UI/услуги.
  2. extras_revenue_per_order или extras_profit_per_order — деньги, которые экран «делает».
  3. continue_rate (или 1 − exit_rate) — гард: нельзя жертвовать конверсией в оплату ради апсейла. Если attach_rate +20%, но continue_rate −10% — это минус.

Эконом-эффект:

  • Каждая дельта +1 п.п. к attach_rate при базе 1M заказов/мес и среднем профите 200 ₽/услуга = +2 млн ₽/мес.
  • Падение continue_rate на 0.5 п.п. (=5000 заказов в месяц) при средней комиссии 300 ₽ = −1.5 млн ₽/мес. Поэтому balance.

Шаг 4. Идеи для роста метрик

Контентно-продуктовые

  • Контекстуальная подача: при is_return = 0 уведомление о дате не нужно — убрать из выдачи; при destination = TR / EG — страховка приоритетна.
  • Бандлы услуг (страховка + уведомление − 10%) — повышает attach.
  • Социальные доказательства: «70% пассажиров на этот рейс берут возврат» — эффект якоря.
  • Defaults: страховка предвыбрана (с возможностью отказа). Известный «дарк-паттерн», но эффективный — нужно балансировать жалобами.
  • Ценовая лестница: показать «эконом / стандарт / премиум» страховку — даёт компромисс по середине (decoy effect).

Технические

  • Уменьшить время загрузки — long load кладёт continue_rate.
  • Sticky CTA «продолжить» — на мобайле часто прокручивают вниз и теряют кнопку.
  • Preload доп. услуг — чтобы экран не дожидался ответа партнёра.

Аналитические

  • CUPED для уменьшения дисперсии в A/B на attach_rate.
  • Multi-armed bandit для динамической оптимизации порядка карточек.
  • Per-service propensity model — показывать только релевантные услуги (cuts noise, повышает attach).

A/B-эксперименты

  • Тест A/B порядка услуг (по attach_rate / по revenue).
  • Тест добавления/удаления карточки.
  • Тест дизайна (карточки vs список).
  • Тест умного заголовка («рекомендуем» vs «дополнительно»).

Подводные камни

  1. shown ≠ «реально увидел». На мобайле карточка может быть «технически в DOM», но не в viewport. Используйте Intersection Observer.
  2. Гард continue_rate всегда первый. Не оптимизируйте attach без guard на воронку до оплаты.
  3. extras_revenue_per_order искажается составом трафика. CUPED по pre-period revenue.
  4. take_rate растёт, если падает order_price — может быть фальшивая метрика. Лучше абсолют и % от GMV.
  5. Self-selection. Кто видел этот экран — те, кто уже прошёл шаг 1 (мотивированные). Не сравнивайте attach_rate со всеми пользователями.
  6. Логирование с фронта может теряться (PWA, ad-блокировщики). Серверная подтверждающая логика обязательна для денежных метрик.

Эталонный ответ

Логи: shown / engagement / per-card / continue / skip / scroll / time. Метрики: attach_rate (главная), revenue/profit per order, continue_rate (guard) + per-service breakdown. Рост: контекстуализация, бандлы, defaults, social proof, A/B порядка карточек. Все метрики — с разрезами по платформе, маршруту, глубине, новизне пользователя.

Хочешь увидеть разбор?

Зарегистрируйся бесплатно — откроется развёрнутое решение этой задачи и ещё 4 на выбор.

Зарегистрироваться и увидеть разбор
Уже есть аккаунт? Войти