Хороший сервис для заказа такси должен быть безопасным, надёжным и быстрым. Пользователь не станет вдаваться в детали: ему важно, чтобы он нажал кнопку «Заказать» и как можно быстрее получил машину, которая доставит его из точки А в точку Б. Если рядом нет машин — сервис должен сразу об этом сообщить, чтобы у клиента не складывалось ложных ожиданий. Но если плашка «Нет машин» будет высвечиваться слишком часто, то логично, что человек просто перестанет пользоваться этим сервисом и уйдёт к конкуренту.
В этой статье я хочу рассказать о том, как при помощи машинного обучения мы решали задачу поиска машин на территории с малой плотностью (проще говоря — там, где, на первый взгляд, нет машин). И что из этого вышло.
Предыстория
Чтобы вызвать такси, пользователь совершает несколько простых действий, а что при этом происходит во внутренностях сервиса?
| Пользователь | Этап | Бэкенд Яндекс.Такси |
|---|---|---|
| Выбирает точку отправления | Пин | Запускаем упрощённый поиск кандидатов — поиск на пине. На основе найденных водителей предсказывается время приезда — ETA в пине. Рассчитывается повышающий коэффициент в данной точке. |
| Выбирает точку назначения, тариф, требования | Оффер | Строим маршрут и рассчитываем цены на все тарифы с учётом повышающего коэффициента. |
| Нажимает кнопку «Вызвать такси» | Заказ | Запускаем полноценный поиск машины. Выбираем наиболее подходящего водителя и предлагаем ему заказ. |
Про ETA в пине, расчёт цены и выбор наиболее подходящего водителя мы уже писали. А это история о поиске водителей. Когда создаётся заказ, поиск происходит два раза: на пине и на заказе. Поиск на заказе проходит в два этапа: набор кандидатов и ранжирование. Сначала находятся свободные водители-кандидаты, ближайшие по дорожному графу. Потом применяются бонусы и фильтрации. Оставшиеся кандидаты ранжируются, и победителю приходит предложение заказа. Если он соглашается, то назначается на заказ и едет к точке подачи. Если отказывается, то предложение приходит следующему. Если кандидатов больше нет, то поиск запускается заново. Это продолжается не более трёх минут, после чего заказ отменяется — сгорает.
Поиск на пине похож на поиск на заказе, только заказ не создаётся и сам поиск выполняется лишь один раз. Также используются упрощённые настройки числа кандидатов и радиуса поиска. Такие упрощения нужны, потому что пинов на порядок больше, чем заказов, а поиск — довольно тяжёлая операция. Ключевой момент для нашей истории: если во время предварительного поиска на пине подходящих кандидатов не нашлось, то мы не разрешаем сделать заказ. По крайней мере, раньше было так.
Вот что видел пользователь в приложении:
Поиск машин без машин
Однажды у нас появилась гипотеза: возможно, в некоторых случаях заказ всё же можно выполнить, даже если на пине не нашлось машин. Ведь между пином и заказом проходит какое-то время, а поиск на заказе более полный и иногда повторяется несколько раз: за это время свободные водители могут появиться. Ещё мы знали обратное: если водители нашлись на пине, то ещё не факт, что они найдутся при заказе. Порой они исчезают или все отказываются от заказа.
Чтобы проверить эту гипотезу, мы запустили эксперимент: перестали проверять наличие машин во время поиска на пине для тестовой группы пользователей, т. е. у них появилась возможность сделать «заказ без машин». Результат получился довольно неожиданным: если машина не находилась на пине, то в 29% случаев она находилась позже — при поиске на заказе! Более того, заказы без машин не сильно отличались от обычных по частоте отмен, оценкам и прочим показателям качества. Число заказов без машин составило 5% всех заказов, но чуть более 1% всех успешных поездок.
Чтобы понять, откуда берутся исполнители этих заказов, посмотрим на их статусы во время поиска на пине:
- Свободен: был доступен, но по каким-то причинам не попал в кандидаты, например был слишком далеко;
- На заказе: был занят, но успел освободиться или стать доступным для заказа по цепочке;
- Занят: возможность принимать заказы была отключена, но потом водитель вернулся на линию;
- Недоступен: водителя не было в сети, но он появился.
Добавим надёжности
Дополнительные заказы — это замечательно, однако 29% успешных поисков означают, что в 71% случаев пользователь долго ждал и в итоге никуда не уехал. Хотя с точки зрения эффективности системы в этом нет ничего ужасного, но на самом деле, пользователь получает ложную надежду и тратит время, после чего расстраивается и (возможно) перестаёт пользоваться сервисом. Чтобы решить эту проблему, мы научились предсказывать вероятность того, что машина на заказе будет найдена.
Схема такая:
- Пользователь ставит пин.
- Проводится поиск на пине.
- Если машин нет — предсказываем: может быть, они появятся.
- И в зависимости от вероятности даём или не даём сделать заказ, но предупреждаем, что плотность машин в этом районе и в это время маленькая.
В приложении это выглядело так:
Использование модели позволяет аккуратней создавать новые заказы, не обнадёживать человека напрасно. То есть регулировать соотношение надёжности и числа заказов без машин с помощью precision-recall модели. Надёжность сервиса влияет на желание и дальше пользоваться продуктом, т. е. в итоге всё сводится к числу поездок.
Предположим, мы делаем тест (классификатор) на какую-то редкую и опасную болезнь. По результатам теста мы или отправляем пациента на более подробное обследование, или говорим: «Здоров, иди домой». Для нас отправить домой больного человека гораздо хуже, чем зря обследовать здорового. То есть мы хотим, чтобы тест срабатывал для как можно большего количества реально больных людей. Эта величина называется recall =. У идеального классификатора recall равен 100%. Вырожденная ситуация — отправлять на обследование всех, тогда recall тоже будет 100%.
Бывает и наоборот. Например, мы делаем тестирующую систему для студентов, и в ней есть детектор списывания. Если вдруг на какие-то случаи списывания не сработает проверка, то это неприятно, но не критично. С другой стороны, крайне плохо незаслуженно обвинять студентов в том, чего они не совершали. То есть нам важно, чтобы среди положительных ответов классификатора было как можно больше правильных, возможно, в ущерб их количеству. Значит, нужно максимизировать precision = . Если срабатывания станут происходить на всех объектах, то precision будет равен частоте определяемого класса в выборке.
Если алгоритм выдаёт числовое значение вероятности, то, подбирая разные пороги, можно добиться разных значений precision-recall.
В нашей задаче ситуация следующая. Recall — число заказов, которое мы можем предложить, precision — надёжность этих заказов. Вот так выглядит precision-recall кривая нашей модели:
Есть два крайних случая: не разрешать заказывать никому и разрешать заказывать всем. Если не разрешать никому, то recall будет 0: мы не создаём заказов, но зато никакой из них не станет провальным. Если разрешать всем, то recall будет 100% (мы получим все возможные заказы), а precision — 29%, т. е. 71% заказов окажутся плохими.
В качестве признаков мы использовали различные параметры точки отправления:
- Время/место.
- Состояние системы (число занятых машин всех тарифов и пинов в окрестности).
- Параметры поиска (радиус, число кандидатов, ограничения).
Подробнее о признаках
Концептуально мы хотим различить две ситуации:
- «Глухой лес» — машин тут в это время не бывает.
- «Не повезло» — машины есть, но вот при поиске подходящих не оказалось.
Один из примеров «Не повезло» — если в пятницу вечером в центре большой спрос. Заказов много, желающих много, водителей на всех не хватает. Может получиться так: в пине подходящих водителей нет. Но буквально через секунды они появляются, потому что в это время в этом месте очень много водителей и их статус постоянно меняется.
Поэтому хорошими фичами оказались различные показатели системы в окрестностях точки А:
- Общее число машин.
- Число машин на заказе.
- Число недоступных для заказа машин в статусе «Занят».
- Число пользователей.
Ведь чем больше вокруг машин, тем более вероятно, что какая-нибудь из них станет доступна.
На самом деле для нас важно, чтобы не просто находились машины, но и совершались успешные поездки. Поэтому можно было предсказывать вероятность успешной поездки. Но решили так не делать, потому что эта величина сильно зависит от пользователя и водителя.
В качестве алгоритма обучения модели применяли CatBoost. Для обучения использовали данные, полученные из эксперимента. После внедрения пришлось собирать обучающие данные, иногда позволяя небольшому числу пользователей делать заказ вопреки решению модели.
Итоги
Результаты эксперимента получились ожидаемыми: использование модели позволяет значимо увеличить число успешных поездок за счёт заказов без машин, но при этом не просадить надёжность.
На данный момент механизм запущен во всех городах и странах и с его помощью происходит около 1% успешных поездок. Причём в некоторых городах с небольшой плотностью машин доля таких поездок доходит до 15%.
Другие посты о технологиях Такси
- Как мы распределяем заказы между водителями в Яндекс.Такси
- Динамическое ценообразование, или Как Яндекс.Такси прогнозирует высокий спрос
- Как с помощью компьютерного зрения оценить состояние автомобиля. Опыт Яндекс.Такси
- Как Яндекс.Такси прогнозирует время подачи автомобиля с помощью машинного обучения
Комментарии (41)
Koroed
14.05.2019 14:07Когда вы уже внедрите хоть какой-нибудь алгоритм, который бы вычислял водителей которые взяли заказ но не едут на него Или едут вообще не туда? Такой заказ вполне можно автоматический передать другому водителю.
Кейс когда после заказа тебе звонит водитель и говорит что он сломался, спустило колесо или просто говорит что он тебя везти не собирается потому что ему не уперлось ехать в аэропорт в 4 утра и пустым возвращаться обратно у вас никак не обрабатывается.
Нельзя указать при заказе на ближайшее время что мне не нужен водитель который будет ехать ко мне 15 минут и я все равно не буду его ждать и отменю заказ. Кстати такая ситуация тоже встречается часто, независимо от количества машин рядом. Добавили бы какое-нибудь максимальное время ожидания.
Заставить водителя подъехать точно к указанной точке вообще похоже нерешаемая задача. Зачем ждать меня на другой стороне улицы или в соседнем дворе для меня загадка.
Sanovskiy
14.05.2019 14:15Проблема в том, что серьёзно наказать водителя за косяки почти никак нельзя. Они регистрируют новый аккаунт на брата/жену/тестя и продолжают косячить.
Пару месяцев назад заказывал такси, так мало того, что водила приняв заказ уехал в другую сторону на 15 километров (заказ я не отменял уже из любопытства). Он спустя полтора часа таки подал машину, начал поездку без меня и завершил её через пару километров.
Поддержка, конечно же, отработала и вернула деньги на карту, но сомневаюсь, что водитель больше не работает в этой сфере.Koroed
14.05.2019 14:19Ну если бы этот кейс обрабатывался то братья и жены у водителя кончились бы довольно быстро. А сейчас яндекс даже при всем желании не сможет посчитать сколько заказов отменяется по такой схеме.
ITurchenko
15.05.2019 10:23Проблема в том, что серьёзно наказать водителя за косяки почти никак нельзя. Они регистрируют новый аккаунт на брата/жену/тестя и продолжают косячить.
Агрегатору достаточно мониторить аккаунт водителя (телефон/паспортные данные/итп) И автомобиль (госномер/птс/итп). Считать что в течении года автомобиль закреплен за этим водителем, если это частник. Если это таксопарк — выставлять претензии таксопарку в целом с расценками для юрлиц, потом они пусть сами как хотят с водителем проблему решают.
Всё, проблема решена. Но делать этого мы конечно не будем.
sergey-b
17.05.2019 00:10И тут мы плавно подходим к тому, что проблему надо решать не программно, а организационно, т. е. выходить из зоны комфорта, заключать договора с водителями и таксопарками и нести по ним ответственность.
Ну уж нет. Пусть лучше пассажиры в экран по полчаса тыкают.
teemour
14.05.2019 14:18А как вообще водитель получает заказ если он не хочет ехать? Там что обязаловка?
Koroed
14.05.2019 14:21Я полагаю что водитель не видит точную точку назначения. Ему просто пишут примерное время, которое потребуется на заказ. Ну что-то вроде «заказ от Красной площади, ехать примерно на 30 минут». А в какую именно сторону он не знает. Может в популярное место, а может в промзону.
remzalp
14.05.2019 14:39Просто видит условный заказ, но детали его узнаёт только после взятия заказа.
YaMishar
14.05.2019 14:47Ну вроде точку он видит. Он же переспрашивает — «На 3ью улицу Строителей?».
Меня однажд не посадили в минивен (просто не обратил внимания с прошлой поездки, что стоит семейный тариф) мотивировав тем, что «зачем вам одному кататься в большой машине». Пришлось ещё стоять под дождём.
После этого я перешёл к альтернативному аггрегатору, и пока не жалею. Пользуюсь Я.Такси в редких случаях, когда у альтернативного долго ждать.tundrawolf_kiba
14.05.2019 15:54Ну вроде точку он видит. Он же переспрашивает — «На 3ью улицу Строителей?».
Они видят только когда подъезжают к точке отправления. Хотя вот читал вроде Яндекс в некоторых регионах тестирует бонусную программу, и водители с рейтингами 4.9 и выше смогут видеть точку прибытия сразу, когда появляется предложение заказа.
dmitryvolkovtaxi
14.05.2019 16:56+1Здравствуйте! Я из команды поддержки Яндекс.Такси. Водитель не должен так поступать, хотим разобраться в этой ситуации.
Напишите, пожалуйста, подробности нам на почту: blogs@taxi.yandex.ru.
x67
14.05.2019 15:28- Определенно стоит понимать, что в не очень популярной зоне ожидания клиента скромнее и скорее всего, если у него нет альтернатив поездке на такси, ему придется искать авто какое то время, а потом ждать приезда. Значит для таких зон можно чуть увеличивать допуски для заказов по цепочке — время ожидания будет предсказуемее для пользователя
- Определенно стоит учитывать автомобили на заказе, которые едут в зону поиска, ведь почти всегда известна точка назначения, а значит за время поиска такой автомобиль может стать доступным для заказа по цепочке
- Определенно стоит смягчить ваши фильтры для водителей в непопулярных зонах, а в определенных случаях их не должно быть вообще — клиент должен получить услугу и это важнее, чем ваша "воспитательная" система для водителей.
- Определенно стоит иметь понимание по количеству расчетов стоимости поездки в определенной зоне в определенное время, так как эта переменная позволит оценить потребность в такси и независима от предложения, а значит показывает более реальную картинку спроса
- Определенно стоит без кнутов и пряников показывать таксистам, оказавшимся в непопулярной зоне, где недалеко они могут пригодиться, дабы они перетягивались при необходимости в зоны, где спрос, расчитанный по п.4 выше предложения — это удобно и водителям и вам и клиентам
Warrangie
14.05.2019 16:34Скажите, а как с такой системой поиска получилось так, что я нажимал на поиск и через пару секунд поиск останавливался и выскакивал алерт с текстом что-то вроде «нет свободных машин» или вообще «нет машин». У меня хватило терпения все-таки донажимать до того как машина действительно появится, но меня это сильно бесило.
vomar Автор
14.05.2019 18:50Похоже на какие-то сбои. С такой системой поиск либо начинается, либо нет, прерывается только по достаточно большому таймауту.
Если такое будет повторяться, напишите в поддержку, например на blogs@taxi.yandex.ru.
aborouhin
14.05.2019 18:30Чтобы помочь «территориям с малой плотностью» (сам в такой живу, коттеджная застройка, от МКАД 30 км) и самим увеличить охват клиентов с таких территорий — лучше бы Вы сделали опцию заказа на будущее время. Из-за отсутствия этой возможности вынужден для поездок, где опоздание критично неприемлемо (в аэропорт в основном), по старинке заказывать такси из местной службы по телефону, что неудобно, дороже, но надёжнее.
У Гетт такая опция есть — но там свои фокусы: искать водителя они начинают только за полчаса до указанного времени, а этак в 4 часа ночи ни одного желающего ехать к нам, что неудивительно, зачастую не находится. Хотя, может, час-два назад кто-то как раз приехал в нашу сторону и предпочёл бы вздремнуть, дождавшись моего заказа, чем возвращаться пустым.vlad49
14.05.2019 19:01Люто поддерживаю. Необходима возможность заказать машину на определенное время и быть уверенным, что она железно и гарантированно приедет, вне зависимости от плотности территории, пробок, высокого спроса, загрузки, времени и других факторов. Чтобы водитель осознанно принял решение о поездке в это место хотя бы за 3-4 часа, а не за 15 минут — и если там не окажется — все кары на него бы обрушивались какие только можно. А клиенту дополнительную уверенность придавало бы сообщение — «Водитель найден и выедет к вам через 3 часа 25 минут. Позвонить ему?»
Видимо, весь AI и ML Яндекса пока на такое неспособен. Только старый добрый живой диспетчер в службе заказа.sergey-b
17.05.2019 00:16Для такой опции нужен резерв из машин, чтобы, если основная машина не смогла подъехать в указанное время к указанному месту, автоматически направлялась дежурная машина из резерва.
Aingis
15.05.2019 11:00Так было уже. Отменили. Потому что это был всего лишь автоматический поиск по наступлении времени. И когда машина не находилась, это вызывало лютый батхёрт.
Заказ ко времени сам по себе противоречит модели снижения цены за счёт потока распределённых заказов. Так что да, хотите гарантии — заказывайте в таксопарке заранее, где вас будет ждать водитель, за дополнительную плату.aborouhin
15.05.2019 12:38Ну, во-первых, я не говорю про снижение цены. Можно за опцию заказа ко времени делать наценку. За то, чтобы не связываться с таксопарком, где надо делать три звонка и не принимают карточки (а, как назло, именно в этот день у меня нет налички и/или у водителя нет сдачи — а банкоматы в нашей «территории с малой плотностью» отнюдь не на каждом углу), вполне разумно переплатить. Это будет другая модель, но, в конце концов, должен же кто-то этих динозавров с телефонными диспетчерскими добить окончательно даже в этом сегменте.
Во-вторых, в ряде случаев подобная опция ещё и приведёт-таки к снижению издержек. Опять же, особенно в малопопулярных территориях, откуда до оживлённых мест ехать далеко и пустым — невыгодно, так что водитель предпочёл бы подождать более поздний заказ, если бы он таковые видел, а то и вообще заранее подбирать два последовательных заказа «туда» и «обратно». Заказы-то эти сами по себе на фоне коротких поездок по городу дорогие.sergey-b
17.05.2019 00:21У этих динозавров есть то, чего нет у Яндекса, — машины, которыми они распоряжаются. Диспетчер таксопарка дает водителю задание ехать туда-то к такому-то времени, и с вероятностью 99% водитель это задание выполнит. А Яндекс публикует кота в мешке: "Эй, есть заказ неизвестно куда. Кто желает взять?" — и ждет, когда кто-то откликнется. Естественно, никакие долгосрочные прогнозы в такой модели невозможны.
gleb_l
14.05.2019 20:52Можно cделать статистическое предположение, сколько времени проходит в среднем (по всем пользователям, или только для текущего) между событиями Пин и Заказ, и прогнозировать доступность такси по событию Пин, но на время в будущем, равное текущему + среднее время между этими двумя событиями. Для свободных водителей можно считать среднее время между взятиями заказов, а для занятых на момент Пин вблизи точки вызова — ожидаемое время окончания текущего заказа, исходя из конечной точки маршрута. В итоге будем иметь модель краткосрочного прогноза доступности такси, которой можно дать больший вес в часы пик. Чтобы лишний раз не напрягать бакенд, от фронта можно получать сигналы активности юзера (типа, как от мессенджеров typing...) — о том, что после события Пин идет выбор точки назначения. Тем клиентам, от которых идет событие выбора точки или параметров поездки, давать большую вероятность совершения поездки (то есть появления события Заказ)
PeoneEr
15.05.2019 07:44Вот вам еще один кейс, который никак не обрабатывается и что делать я не знаю.
Я живу в закрытом городе, для въезда в который нужен пропуск. Яндекс явно знает, что это за город и что туда нужны пропуска. Но когда я пытаюсь уехать из соседнего города и вызываю машину ЯТакси мне попадаются водители, которые не имеют пропуска в город.
В связи с этим вырисовывается ряд проблем:
- Водители просто не берут заказ
- Взяв заказ, водитель через какое-то время от него отказывается
- Взяв заказ, водитель приезжает на пин и тут выясняется, что у него нет пропуска, хотя я этот вопрос задаю в чат сразу же, как только водитель берет заказ
и крайне редко случается четвертый кейс: у водителя таки есть пропуск и я спокойно еду домой.
В кейсах 1 и 2 я остаюсь искать машину дальше, в кейсе 3 я еду до кпп и с кпп вызываю еще одну машину.
В чем проблема вызвать машину до кпп сразу, а потом пересесть? Малый процент водителей всё же хочет туда ехать, т.к «пустой» пробег будет довольно велик, хотя и ценник на такую поездку в районе 400р, что для нашего города вполне приличная цена за такси. Я по своему городу больше 150р никогда не платил.
В связи с этим, мб стоит ввести какие-то идентифицирующие параметры, возможно, основанные на машинном обучении: если человек во время работы бывал в нашем городе, значит у него есть право заезда туда. Ну или как-то так, вплоть до явного указания при наличии закрытых городов рядом. Пусть я лучше буду искать машину 20-40 минут, зато водитель с большей вероятностью будет иметь пропуск, чем я буду попусту бегать на улицу и ждать машину.
dovg
15.05.2019 11:16О, самое время начать ныть.
Яндекс, в больших городах с такси проблем нет. Но недавно вы пришли ко мне на малую родину, сильно уронили цены и случилась вполне ожидаемая вещь.
Ночью в пригород никто не хочет ехать, и это даже понятно: за 10-километровую поездку предлагается заплатить меньше 200 рублей, при этом таксист точно знает, что из условного Нововятска заказов до утра точно не будет. То есть обратно он поедет пустым.
Я бы очень хотел, чтобы в приложении была кнопка «двойной тариф» или даже «тройной тариф», которая бы позволила мне повысить цену, но все-таки уехать, а не сидеть в баре ночью одному, зато дешево.
Сейчас я эту проблему решаю так: вызываю такси до соседнего дома, а уже потом голосом водителю говорю: поехали в %SUBURBAN_NAME% за 500 рублей. Еще ни один не отказался.
Было бы классно, если бы это могло делать приложение за меня, избавляя меня от необходимости коммуницировать с водителями.
LumberJack
15.05.2019 12:41Тут палка о двух концах: В одном не менее известном агрегаторе, однофамильце пулемёта, сделали такую кнопку. В результате водители, видя заказ по «базовой» цене просто не берут его, пока заказчик не поднимет цену поездки хотя б рублей на 20-30, причём по карте видно, что свободные машины есть.
dovg
15.05.2019 12:43Рынок всё расставит по местам. Если таксисты не берут заказ, значит считают, что это невыгодно. Это их право.
Я прошу дать мне возможность заплатить больше, разве это плохо?
Кстати еще в одном агрегаторе есть «приоритетный режим», но он добавляет к цене поездки всего 30-50 рублей, что в моем случае не производит требуемого эффекта.
dm9
15.05.2019 13:21Довольно забавно, что единственная техническая, обучающая и потенциально полезная информация про precicion/recall стыдливо спрятана под спойлер.
SergeyMarkelov
15.05.2019 20:441. Поддерживаю двумя руками предложение aborouhin и vlad49 ввести опцию предварительного заказа на будущее время!
В Uber предварительные заказы возможны (английская ссылка, русская). Но деликатно написано: «Вы можете запланировать поездку почти во всех городах присутствия Uber. Проверьте в своем приложении, доступно ли планирование поездок в вашем районе.»
В России Uber работает по технологии Яндекса, предварительных заказов нет — и это создает изрядное неудобство тем, кто регулярно ездит с дачи в Московской области в Москву. Кругом лес, машин нет, агрегировать нечего — но вызвать такси иногда нужно. Сейчас для этого приходится раз в 5 минут проверять приложение — и за полчаса-час проезжает машина в радиусе поиска, удается ее вызвать. Бессмысленная деятельность по монотонному тыканью в приложение раздражает. Когда Яндекс выпустил приложение Uber Russia, он многое улучшил по сравнению с обычным Uber — но в этом месте есть неочевидное ухудшение. В обычном Uber надпись «нет свободных машин» является кнопкой, на нее можно нажать (и Uber будет искать машины какое-то время — вдруг появятся?). В Uber Russia надпись «нет свободных машин» вообще не кнопка, на нее нельзя нажать.
В Lyft (второй после Uber агрегатор в США с долей в 30%) тоже есть предварительные заказы (Scheduled Ride).
Но вернемся в Московскую область. Если нужно с дачи уехать ночью, даже и часа постоянной проверки приложения может не хватить, приходится заниматься «подманиванием»: с одного телефона вызывать машину к деревне, которая полпути до железнодорожной станции (у которой машины есть). Когда машина подъезжает к деревне, нужно одновременно на первом телефоне отменить заказ, и на втором вызвать уже на дачу. Так машина приезжает.
Заниматься этим хлопотно, да и морально стыдно. Оставляю потом водителю повышенные чаевые, чтобы он не расстраивался. Но другого пути гарантированно вызвать Яндекс-такси на дачу ночью — не вижу.
Если разработчики Uber и Lyft как-то смогли предварительные заказы запрограммировать — значит и разработчики Яндекс наверняка смогут!
2. Кроме предварительного заказа, хочу внести предложение по улучшению в срочные. Вместо надписи «нет свободных машин» показывать объективную картину — ОК, в обычной окрестности машин нет, но ведь в какой-то большей окрестности они есть? Сделайте мне предложение! Вероятно, такая поездка обойдется дороже из-за долгой подачи (а может и нет, если поездка далекая, водитель будет готов на долгую подачу). Почему бы не показывать пользователю: «эконом может приехать через 40 минут и стоить будет XXX, минивэн через 72 минуты по цене YYY». Может быть, меня устроит и время подачи, и цена? Мне же все равно как-то надо уехать после вечеринки на даче у друзей…
Вижу 2 возможных контраргумента, почему Яндекс может не хотеть вводить такой сервис:
— Страх снижения репутации (пользователь увидит, что Яндекс предлагает подать машину за 45 минут, ха-ха-ха). На мой взгляд, так не будет. Если я на даче, кругом машин объективно нет — не только у Яндекса, но и у других агрегаторов. Если Яндекс может подать машину за 45 минут, а другой агрегатор за 60 или вообще не может — я уеду на Яндексе и буду доволен.
— Страх, что найдутся «шутники», которые будут вызывать водителя в далекий коттеджный поселок, и в последнюю минуту отменять заказ. Если водитель ехал до заказа долго — Яндексу придется компенсировать водителю подачу. Что ж, «шутники» бывают, увы — но ведь Яндекс знает обо мне все. В частности, знает что у меня было более 1000 заказов Яндекс-такси, и ни разу ни один водитель не пожаловался на проблемы с оплатой. Кроме того, Вы видите, что у меня есть Яндекс-деньги в заведомо достаточном количестве. Вы можете заблокировать стоимость подачи у меня на Яндекс-кошельке или на карточке. А если у пользователя хорошая личная статистика, можно и при наличной оплате давать ему возможность делать заказы со сверхдлинной подачей.
Вот скриншот, чего хотелось бы: рядом с этой дачей машин не было ни у Яндекса, ни у Ситимобиля. Их вообще в разумной близости нет, объективно. Но Яндекс пишет «нет свободных машин», а Ситимобиль дал возможность заказать водителя с подачей 37 минут, чем я и воспользовался (хотя в целом лоялен Яндексу, Ваш сервис мне больше нравится).
Особенно остро стоит эта проблема, когда в области нужен минивэн. В Москве они есть, в области — почти никогда нет. Для большой семьи с детьми заказывать 2 машины — крайне неудобно, лучше подождать, переплатить, но все-таки получить минивэн. Яндекс многое улучшил в мире такси — но в этом месте ухудшил, заказывать минивэн на дачу в Серебряно-Прудский район Московской области стало труднее (раньше были мелкие местные игроки, у некоторых были минивэны; сейчас большая часть из них уже разорилась, не выдержав конкуренции, а у оставшихся минивэнов нет). Фактически сейчас приходится, когда из Москвы едешь на дачу на минивэне, спрашивать водителя, сможет ли он забрать в такой-то день? У меня уже много телефонов таких водителей собралось. Они забывают, уезжают в другой район, у них меняются планы, с ними надо торговаться о цене — все это хлопотно. Хочется иметь возможность сделать срочный заказ (пусть и со сверхдолгой подачей минивэна) и хочется иметь возможность сделать предварительный заказ — оба хоть по какой-то (пусть и более высокой) цене, но с высокой вероятностью приезда такси. Конечно, 100% недостижимо в реальном мире, но чтобы на это можно было положиться.
3. Можно ли спросить Вас, vomar, пожалуйста — почему свернут эксперимент с совместными поездками по тарифу Яндекс.Комбо? Планируется ли восстановить этот тариф? В США в тех городах, где ввели совместные поездки по тарифам Uber Pool и Express Pool, на них приходится 25% оборота. В Lyft тоже есть тариф для совместных поездок (Shared Ride), есть и аналог Express Pool (Shared Saver).
Скажем, из аэропорта Домодедово в Москву вполне уместно было бы ездить на Яндекс.Комбо (для тех, кто с небольшой сумкой из командировки возвращается), разве нет? А в минивэне можно и 2 пары с чемоданами посадить комфортно. Или так — впереди дачный сезон. От станции электрички заказывать такси до дачи — мало кто будет (ездящие электричкой небогаты). Но если от приехавшей электрички можно будет сесть в Яндекс.Комбо, которое довезет тебя прямо до дачи дешево (пусть и завезет заодно кого-то в соседний дачный поселок) — думаю, этим многие пользовались бы.
И в конце хочу поблагодарить. Несмотря на описанные сложности, я пользуюсь Яндекс/Uber каждый день, и в целом Ваше приложение сделало жизнь моей семьи лучше. Спасибо Вам!
nomadmoon
15.05.2019 21:52Если кто то в теме, подскажите, есть ли такси которые лояльно относятся к перехватчикам (или даже может API дают) и позволяют ездить только на свободном взятии заказов (т.е. чтобы меня вообще не назначали). Согласен ездить задешево, но только на моих условиях, по количеству заказов вообще пофигу, даже если один раз за ночь скатаюсь — уже отлично.
Такси Максим, такси Мини — как там сейчас с этим?
P.S. Хабаровск.
YaMishar
У меня пара вопросов.
А почему предлагается только одному водителю? В результате пользователь ждёт какое-то время (может водитель в это время вышел из машины фары протереть). В результате получается задержка в нахождении. Не лучше ли при ранжировании посылать 3-5 лидерам, если их ранк в поиске сравним? А если ранки отличаются, то скажем послать первому, с небольшой задержкой второму и т.д.
Второй вопрос скорее организационный. Если я заказываю из Шереметьево машину, я знаю, что вот — в 50м от меня целая парковка забитая машинами Я-Такси. Я вижу в них водителей. Но при заказе мне находится машина, которая едет ко мне потом 10 минут. Эти водители — не на линии?
vomar Автор
Если предлагать сразу нескольким водителям, то придётся для большей части из них потом отменять заказ. Не хочется лишний раз дёргать водителя, особенно за рулём.
В аэропортах из-за разных особенностей заказы распределяются немного иначе — в порядке очереди водителей. Поэтому иногда может назначаться не ближайшая машина.
YaMishar
Погодите. Вы же себе противоречите. У вас же в тексте
Я не вижу ничего суперопасного в том, что вместо кнопки «взять заказ» у водителя будет «предложить себя». А у пользователя получится преимущество даже выбрать из предложенных вариантов (по рейтингу или по автомобилю, если такое требуется). Чисто как идея — вы можете такое открывать скажем лояльным пользователям только. После 100-1000 поездок. Но мне лично сейчас непонятно, почему мой заказ принимает водитель, который едет из Шереметьево в сторону Ленинградки. И я жду его 10-12 инут, пока он развернётся и проедет всё Международное шоссе ещё раз.
putnik
Ваша идея, когда заказ кидается на пять водителей, и пользователь в это время выбирает, на какой машине поедет, не очень рабочая. На время выбора нужно блокировать для этих водителей заказы. То есть, если я в том же районе заказал сразу после вас, то буду ждать, пока вы себе выбираете.
Losted
Вполне рабочая. Taxify так работает в европах, насколько я помню
YaMishar
Я прелагаю так делать для лояльных пользователей. Как-то надо лояльность поддерживать? да и время выбора ограничить 5-10с. Эир не сильно повлияет в сравнении с тем, что сейчас я могу например получить вариант «машина приедет через 12 минут», потом я отказываюсь, повторяю поиск и тут же получаю «приедет через 3 минуты»
imm
вы бы всё-таки определились, что в приоритете — клиенты, или кривой алгоритм на который все плюются (зато одобренный руководством).
вот сложно что-ли дёрнуть не одного водителя из очереди, а 3-5 стоящих N минут водителей рядом? неужели у вас проблемы с анализом текущего состояния водителя?
для чего заставлять клиента ждать овер 10 минут, когда рядом скучающих машин — полстоянки? для чего дёргать уехавшего водителя?
vomar Автор
Водители тоже наши пользователи. Мы не хотим дёргать 3-5 водителей ради того чтобы сократить время поиска на несколько секунд.
Неизвестно, что это были за водители на стоянке. Они могли быть не на линии, работать с другим агрегатором, не подходить по классу или каким-то ограничениям. Или для них через некоторое время появится заказ.
Из-за очереди может иногда страдать время ожидания. Но водителям стало удобнее ожидать заказы около аэропорта. Из-за этого увеличивается число водителей. Следовательно уменьшается повышающий коэффициент и для конечного пользователя падает цена поездки.
Accounter
Еще в аэропортах таксисты не любят получать оплату картой. Пример: знакомый заказал такси с оплатой корпоративной картой. Делал заказ трижды, так каждый таксист, когда узнавал, что оплата картой — отменял заказ. В результате три-четыре отмены заказа — и потенциального клиента заблокировали в приложении. Таксисты, наверное, заминусовали его карму в приложении где-то.