Привет, я Дима Алдунин, заместитель руководителя проектного офиса Райдтеха и по совместительству менеджер особенно интересных проектов в области эффективности сервиса.
Долгий поиск машины — одна из самых неприятных ситуаций для пользователя Такси. Сейчас расскажу, как мы улучшали пользовательский опыт в этом сценарии.
Что происходит, когда пользователь нажимает кнопку «Заказать такси»? В идеальном мире за несколько секунд, необходимых водителю на принятие заказа, назначается подходящая машина. В реальности — в каждом четвёртом случае наш пользователь ждёт назначения дольше 30 секунд просто потому, что машины в выбранном тарифе не всегда есть рядом. А это прямой путь к отмене заказа и негативному опыту. Или к перезаказам в других тарифах, которые не только ухудшают пользовательский опыт, но и растят нагрузку на систему.
После исследования проблемы гипотеза родилась довольно быстро: если поиск затянулся, нужно дать пользователю указать все тарифы, в которых он потенциально готов уехать. Как тариф «Самый быстрый», который можно найти в обычном списке тарифов на главном экране Такси, только в тот момент, когда он больше всего нужен.
Легко сказать, сложно сделать
Идея выглядит простой, но её реализация требовала аккуратности. Мы хотим, чтобы пользователь принимал информированное решение, поэтому нужно было научиться правильно считать время подачи, рассчитывать кэшбек баллами Плюса и подсвечивать время подачи там, где оно ниже, чем в выбранном тарифе. В общем — делать всё то, к чему мы привыкли на основном экране заказа.
А под капотом нужно было вмешаться в уже идущий поиск исполнителя. Это при том, что в большинстве случаев для поиска исполнителей мы используем нетривиальное буферное назначение, а бэкенд Такси сам по себе — высоконагруженная распределённая система. В общем, одна ошибка, и у тебя race condition, когда на заказ уже спешат два водителя вместо одного (в этой шутке меньше шутки, чем хотелось бы).
Но хорошие новости в том, что мы:
- Уже избавились от мрачного монолитного наследия вокруг цикла заказа Такси. Сейчас в бэкенде Такси больше 1000 микросервисов, и мы движемся в сторону доменной архитектуры.
- Активно используем подход Backend-Driven UI и значительную часть изменений в интерфейс можем внести без релиза мобильного приложения. А значит, и без ожидания проверки в сторах и других задержек.
В итоге научились показывать пользователям новый экран, на котором они могут принимать информированные решения — добавлять или не добавлять новые тарифы в поиск. Цену и ожидаемое время подачи регулярно пересчитываем, как если бы пользователь собирался сделать новый заказ. А в момент подтверждения добавления тарифа фиксируем цену как при обычном заказе — всё по-честному.
Идём по пути улучшений
Первые эксперименты показали, что пользователи хорошо понимают новую фичу и достаточно активно ей пользуются. После этого про фичу рассказали в выпуске YaC про городские сервисы, и пути назад уже не было.
Важной задачей было подобрать порог, начиная с которого мы считаем, что поиск уже стал достаточно долгим, чтобы предлагать пользователю альтернативы. Мы начинали с весьма консервативных 60 секунд, но через серию экспериментов пришли к 15 секундам. Именно в первые 15 секунд происходит абсолютное большинство взаимодействий пользователя с лентой, и мы не хотим мешать тем, кто уже начал её скроллить. Если пользователь отправился изучать ленту Маркета, предложение добавить тарифы мы ему не покажем — считаем, что он и так уже отлично проводит время.
Следующим интересным вопросом был «что делать с премиальными тарифами?». Готовы ли пассажиры променять S-klasse, а то и Maybach на Москвич 3 или Rio? Как обычно, оказалось, что дьявол кроется в деталях (а точнее, в когортном анализе), и для некоторых городов мы построили отдельные сценарии:
- для Бизнеса показываем все альтернативы;
- для Ultima показываем только премиальные тарифы.
В истории с премиальными тарифами хочется отдельно остановиться на одном прекрасном в своей простоте продуктовом озарении. Изначально мы показывали все тарифы от самого дешёвого к самому дорогому. И конверсия в добавление тарифов у тех, кто изначально выбрал что-то из премиума, была, прямо скажем, не очень.
Мы уже подумывали свернуть эксперимент с ними, когда на одном из синков по проекту прозвучала случайная идея: когда изначальный тариф — премиальный, сортировать предлагаемые тарифы в обратном порядке.
Раскатили эксперимент в тот же день и получили значимый прирост метрик. Люблю рассказывать про этот пример, потому что он хорошо показывает, что в нашей команде не обязательно быть менеджером продукта, чтобы улучшать продукт. И что мы умеем действительно быстро экспериментировать, конечно.
Бесконечность — не предел
У фичи ещё большой путь впереди. Мы движемся к полноценной поддержке тарифа «Вместе». Это непросто технически: у него довольно сложная логика под капотом (почитайте, там интересно) и фактически отдельный подход к поиску исполнителей.
Мы также экспериментируем с фичей в десятках стран по всему миру. Это непросто аналитически: готовы ли пассажиры пересаживаться с мотоциклов в машины? А из Эконома в Комфорт в экваториальном городе, где разница между ними только во включенном кондиционере?
Но чем больше вызовов — тем интереснее задача. За такие задачи я и люблю свою работу. Кстати, приходите к нам работать тоже, мы нанимаем!
