Наверняка каждый из нас был в ситуации, когда во время непогоды или после многолюдного футбольного матча цены на такси в приложении были значительно выше обычного. При таких обстоятельствах было бы здорово найти попутчика, чтобы разделить цену поездки, но непонятно, как это сделать.
Меня зовут Полина Белобородова, в Яндекс Go я руковожу командой аналитики новых продуктов в рамках эффективности платформы. И сегодня расскажу про то, как мы придумывали, тестировали и запускали тариф для поездок с попутчиками «Вместе».
Казалось бы, внедрить функцию объединения поездок довольно просто, но в итоге она потребовала много исследовательской работы и экспериментов. Нам нужно было учесть множество вещей: как сделать двойной маршрут удобным и выгодным для водителя, насколько охотно пользователи будут соглашаться на поездку с попутчиком, сильно ли увеличится время поездки и другие моменты. Но в итоге нам удалось найти ответы на эти вопросы.
Про спрос и предложение
Итак, у нас есть одна машина и два пассажира, которые хотят в плохую погоду добраться до дома на такси.
Что делать?
С точки зрения закона спроса и предложения можно было бы придумать несколько гипотетических вариантов. Например:
Предложить машину тому пользователю, которому надо уехать срочно. Представьте, что на одну машину претендуют два пользователя, но один едет позавтракать в другой район, а второй опаздывает в аэропорт.
Алгоритм не может знать, кому из пользователей такси нужнее. Но, видя высокий спрос, временно повышает коэффициент — это помогает привлечь больше водителей в район. А пользователь для себя принимает решение: ехать по цене с повышающим коэффициентом, потому что спешит, или подождать и уехать позднее.
Или можно простимулировать водителей, чтобы они были более мотивированы выезжать в город и брать заказы. Например, если мы знаем, что в районе X рано утром всегда не хватает водителей, может применяться такая субсидия, как минимальная гарантированная стоимость заказа, чтобы увеличить предложение и привлечь в этот район больше водителей.
Это рабочие способы со своими плюсами и подводными камнями. Компания уже использует их и другие механики. Но благодаря современным технологиям появляется совсем иное решение — вырастить общую эффективность системы, попытавшись вывезти больше пассажиров тем же количеством водителей. Например, добавив возможность ездить с попутчиками. Этим мы и занялись.
Что такое карпулинг
Если двум пассажирам примерно по пути и они готовы поехать вместе, алгоритм может «склеить» два таких заказа. Так как водителю придётся забрать и завезти двух людей в разные места, такая поездка будет чуть дольше (примерно на 10 минут), но зато дешевле для каждого пассажира — выгода до 40% по сравнению с Экономом. При этом и водителю будет выгодно — примерно за одно и то же время он выполнит два заказа и, соответственно, заработает больше.
Эта концепция называется «карпулинг», и она не новая. В Яндексе мы уже работали над такими вариантами несколько лет назад. Но теперь захотелось доработать карпулинговую модель по целому ряду важных параметров.
MVP 1.0. От доставки посылок до совместных поездок
Новый подход к тарифу «Вместе» состоялся около полутора лет назад. По законам хорошего стартапа мы задумались о MVP (Minimal Viable Product). Есть много способов найти попутчика и разделить цену поездки. Люди уже сейчас договариваются о совместных поездках через соседские чаты. Но нам в Яндексе хочется сделать решение повседневных задач потоковым, бесперебойным и масштабируемым с помощью технологий. И вот какая идея появилась.
В Яндексе множество сервисов. И наряду с Такси существует, например, Яндекс Доставка. Что, если попробовать «склеить» поездку пассажира на Экономе и заказанную кем-то доставку? Прелесть в том, что если сделать такой MVP правильно — это будет абсолютно незаметно и безболезненно и для тех, кто заказал такси, и для тех, кто заказал доставку. Это позволит нам без сложных доработок пользовательского приложения проверить алгоритмы матчинга и протестировать, как будет работать идея в целом.
Что мы имеем в виду, когда говорим тут про правильный MVP? Это тот, который работает бесшовно и никак не ухудшает и не меняет пользовательский опыт. Мы тестировали подход очень осторожно — на картинке видно, что поездка на такси как бы «вложена» в доставку. Севший в машину пользователь не сталкивался с тем, что водитель выходил из машины, чтобы забрать или отнести посылку, для него это выглядело как обычная поездка.
Но это про опыт пользователя такси. А как обеспечить хороший опыт пользователю Доставки? Убедиться в том, что время конкретной доставки не увеличивается. Для этого мы «приклеивали» только очень попутные заказы — те, что проходили практически по одному и тому же маршруту с доставкой.
MVP протестировали в городах-миллионниках — Самаре, Новосибирске, Екатеринбурге и других. Выяснили: это работает.
Осталось только научиться «склеивать» не такси и доставку, а два заказа такси — и дело сделано? Как обычно, в реальности всё было сложнее.
Когда мы «приклеиваем» доставку к заказу такси, никто из пользователей этого не замечает. А вот два пассажира, если посадить их в одну машину, очевидно, это заметят.
Поездка с другим человеком может выглядеть менее приятной, чем поездка в одной машине с небольшой посылкой. В голову сразу приходят вопросы о личном комфорте. А что, если мне попадётся словоохотливый попутчик? А что, если моя поездка будет дольше, чем обычно?
Эти возражения понятны и реальны, поэтому перед потенциальной поездкой с попутчиком пользователя нужно предупредить обо всех особенностях такой поездки. Понятно, что согласятся далеко не все — кто-то торопится, а кто-то едет в компании друзей и займёт в машине все места.
Но если пользователи будут соглашаться неохотно, то слишком много поездок в тарифе будет без попутчиков и проект не решит стоящие перед нами задачи.
Как «полечить» потенциальную проблему низкой плотности заказов? У нас было несколько идей:
Предзаказы на совместные поездки. Хорошая идея, но, планирование поездки заранее на точное время — это специфический сценарий.
Негарантированные скидки. Если поездка была с попутчиком — скидка будет, если нет — цена как в тарифе «Эконом». Но возможно, люди, проехавшие без скидки, будут менее склонны снова пользоваться тарифом. Позволит ли такая модель растить его популярность и повышать плотность заказов для водителей?
Тариф, который появляется в приложении, если соблюдены определённые условия поездки. В этом варианте мы покажем тариф «Вместе» только для тех маршрутов, на которых вероятность найти попутчика высока.
В итоге, выбирая между этими вариантами, предпочли третий. Вот как он работает.
Работа алгоритмов
Здесь в игру вступают алгоритмы, которые делают нынешний «Вместе» гораздо эффективнее его предшественников. В тот момент, когда пользователь только поставил точку Б, ещё до заказа, с таймингом в десятые доли секунды система находит рядом с пользователем всех возможных кандидатов в попутчики, анализируя множество факторов. Точно ли время в пути у пользователя увеличится не больше чем на 10 минут? Выгодно ли водителю везти два заказа в связке или в конкретном случае ему лучше взять один отдельный заказ?
Сначала алгоритм анализирует машины такси рядом, проверяет, нет ли в них уже потенциального попутчика, тоже согласившегося на совместную поездку, и, если такой человек есть, оценивает попутность маршрутов. Если рядом попутчиков не оказалось, приложение оценивает вероятность того, что они подсядут позднее. Например, если поездка достаточно длинная и проходит по маршруту с высокой плотностью заказов в среднем, вероятность будет выше.
Если попутчика нет и вероятность, что он найдётся, оценена алгоритмом как низкая, в приложении нельзя будет выбрать «Вместе».
Именно с этим решением мы вышли с MVP 2.0 в Бишкеке.
MVP 2.0. Выход в Бишкек
Совместные поездки уже больше года доступны в столице Киргизии. Мы выбрали Бишкек, потому что там уже есть наш сервис, плотность заказов достаточно высокая, а дорожная «сетка» хорошо подходит для тестирования карпулинга.
Одной из ключевых метрик при оценке эффективности для нас было повышение match rate.
Match rate — это доля поездок, в которых успешно нашёлся попутчик, так, чтобы поездка действительно оказалась «совместной».
Одна из проблем, с которыми мы столкнулись, — приложение для водителей Яндекс Про не поддерживало ведение двух заказов одновременно. Если MVP с доставкой можно было безболезненно протестировать без доработки, то дальше нам было важно сделать хороший продукт для пользователей и водителей и вырастить match rate. Поэтому мы научили Яндекс Про оперировать двумя заказами одновременно, но автономно друг от друга. Благодаря этому теперь водитель мог, скажем, связаться с любым из пользователей в случае необходимости.
Также это позволило нам обрабатывать не только «вложенные» заказы, как в описанном выше кейсе с Доставкой. Теперь второй заказ не обязательно должен был заканчиваться в пределах маршрута первого, а значит, мы получили больше вариативности, чтобы растить число совместных поездок.
А ещё мы научились отдавать предпочтение более качественным «матчам», то есть поездкам, максимально выгодным и удобным как для пользователей, так и для водителей. Для этого мы использовали динамические скидки.
Вот как они работают: если мы хотим, чтобы в системе рождалось больше «хороших матчей», надо стимулировать их бо́льшими скидками. Пользователи охотнее станут соглашаться на такие поездки, водителю они тоже будут выгоднее, ведь чем качественнее «матч», тем больше пробега он экономит.
Алгоритм оценивает качество «матча», анализирует, сколько времени сэкономит водитель на таком заказе, какой доход получит, — исходя из этого рассчитывается размер скидки. Всё это очень быстро — за доли секунды, которое проходят между тем, как человек поставил точку Б, и тем, как на экране появились доступные тарифы с актуальными ценами.
Продолжаем улучшать
Чтобы и дальше улучшать водительский и пользовательский опыт, тариф нужно было выводить в новые города, и летом совместные поездки стали доступны в некоторых российских миллионниках.
Одной из главных наших задач стал более точный прогноз вероятности найти попутчика и более качественные «матчи». Например, представьте, что вы вызываете такси из ТЦ. Приезжает водитель, вы садитесь, машина выезжает с парковки на шоссе и в этот момент к заказу «приклеивается» попутчик — он хочет уехать из того же ТЦ. Водителю приходится идти на разворот.
Чтобы уменьшить такие ситуации, мы стали искать попутчика как можно раньше — поиск начинается в тот момент, когда водитель только получил заказ и ещё едет по направлению к первому пользователю. Это даёт нам дополнительное время для перебора всех возможных «матчей» и поиска наиболее близкого к идеальному.
Также мы стали использовать ML-модель, чтобы точнее прогнозировать вероятность найти попутчика. В расчёт берётся ситуация на дорогах, спрос на такси, плотность заказов в определённых районах и другие признаки вплоть до того, бывали ли уже «матчи» попутчика на этом маршруте.
Возможностей много, но механику ещё есть куда дорабатывать. Представьте ситуацию, в которой вы едете из «Москва Сити» на Цветной бульвар. В начале поездки приложение предложит водителю два маршрута — один по ТТК, а другой через центр. По ТТК доехать можно на минуту быстрее, но, если ехать через центр, нам с гораздо большей вероятностью удастся найти попутчика. Если мы точно уверены, что путь через центр не сильно увеличит общее время в дороге, мы могли бы предлагать водителю не просто несколько маршрутов на выбор, но и подсвечивать преимущества каждого: один быстрее, зато на другом, скорее всего, найдётся попутчик и такая поездка будет для него выгоднее.
Сейчас тариф «Вместе» запущен в 12 городах. В РФ это Москва и Санкт-Петербург, Ярославль, Саратов, Екатеринбург, Самара, Тюмень и Волгоград. Чтобы воспользоваться им, пользователям нужно соблюдать определённые правила — например, быть одному, ехать без багажа и опций вроде детского кресла.
Сейчас у нас более 2 миллионов поездок в месяц по этому тарифу. Впереди у нас ещё много задач, связанных с матчингом попутчика до назначения машины и оптимизацией алгоритмов матчинга, — как и во всех новых технологиях, здесь много сложностей, но и потенциал развития и улучшения тоже очень большой.
