Согласна, деталей про алгоритмы в статье получилось не очень много — иначе я бы эту статью никогда не закончила писать)
С точки зрения маршрутизации мы используем стандартный карточный роутер.
С точки зрения матчинга -- оптимизируем время и пробег водителя. Т.е. для ответа на вопрос “надо ли склеить эту пару заказов” мы идем в роутер, получаем три основных цифры: - на сколько увеличится время первого (и второго) пользователя, если поехать за попутчиком - сколько времени сэкономит водитель, если повезет два заказа вместе (а не отдельно)
Далее эти цифры чуть корректируем:
- взвешиваем на вероятности того что пользователи не отменят заказ - нормируем на первоначальную длину заказов - поправляем на коэффициент “ожиданий” (вдруг дальше будет еще более классный (=попутный) попутчик для этого пассажира) - … - получаем итоговый скор
В соответствии с этим скором принимаем решение о матче.
Это очень классная мысль: действительно есть пользователи, которые не спешат и готовы переждать моменты высокого спроса, чтобы уехать дешевле. Для таких случаев у нас уже в продукте есть опция “Подождать” — в ней подача машины занимает больше времени чем обычно, но поездка обходится дешевле. Это происходит за счет того, что назначенный на такой заказ водитель еще не закончил предыдущую поездку, причем точка Б предыдущего заказа находится рядом с вами — так водитель не совершает холостого пробега, а вы при этом получаете небольшую скидку.
Действительно, контролировать соблюдение требований тарифа сложно. Мы многократно предупреждаем пользователя о правилах на этапе заказа — но нарушения все равно случаются. Одна из мыслей, как можно минимизировать эту проблему: попросить пассажиров давать фидбек о попутчиках, в том числе если попутчик был не один.
Но мы открыты к любым идеям — как иначе простимулировать пассажиров не нарушать правила тарифа)
Согласна, деталей про алгоритмы в статье получилось не очень много — иначе я бы эту статью никогда не закончила писать)
С точки зрения маршрутизации мы используем стандартный карточный роутер.
С точки зрения матчинга -- оптимизируем время и пробег водителя. Т.е. для ответа на вопрос “надо ли склеить эту пару заказов” мы идем в роутер, получаем три основных цифры:
- на сколько увеличится время первого (и второго) пользователя, если поехать за попутчиком
- сколько времени сэкономит водитель, если повезет два заказа вместе (а не отдельно)
Далее эти цифры чуть корректируем:
- взвешиваем на вероятности того что пользователи не отменят заказ
- нормируем на первоначальную длину заказов
- поправляем на коэффициент “ожиданий” (вдруг дальше будет еще более классный (=попутный) попутчик для этого пассажира)
- …
- получаем итоговый скор
В соответствии с этим скором принимаем решение о матче.
Это очень классная мысль: действительно есть пользователи, которые не спешат и готовы переждать моменты высокого спроса, чтобы уехать дешевле. Для таких случаев у нас уже в продукте есть опция “Подождать” — в ней подача машины занимает больше времени чем обычно, но поездка обходится дешевле. Это происходит за счет того, что назначенный на такой заказ водитель еще не закончил предыдущую поездку, причем точка Б предыдущего заказа находится рядом с вами — так водитель не совершает холостого пробега, а вы при этом получаете небольшую скидку.
Все верно! Чем меньше вероятность найти попутчика — тем ниже скидка. Например на коротких маршрутах скидка редко превышает 10%
Действительно, контролировать соблюдение требований тарифа сложно. Мы многократно предупреждаем пользователя о правилах на этапе заказа — но нарушения все равно случаются. Одна из мыслей, как можно минимизировать эту проблему: попросить пассажиров давать фидбек о попутчиках, в том числе если попутчик был не один.
Но мы открыты к любым идеям — как иначе простимулировать пассажиров не нарушать правила тарифа)