Что такое повышенный коэффициент в яндекс такси

Тарифы для водителей Яндекс Такси

Зарплата водителя Яндекс Такси зависит от многих факторов. Зная актуальные тарифы и коэффициенты, можно эффективнее планировать рабочее время и больше зарабатывать.

Тарифы для водителей

В службе такси Яндекс установлено несколько тарифов, по которым рассчитывается цена заказа.

Компания самостоятельно относит автомобиль водителя к определенному классу, исходя из его рыночной стоимости, модели и года выпуска:

Наибольшим спросом пользуется «Эконом» – стоит дешевле, получает больше вызовов. Тариф нельзя сменить самостоятельно, его устанавливает сама компания Яндекс.

Важно! Перед работой необходимо не только продемонстрировать автомобиль, но и телефон с gps. Также придется ответить на вопросы экзамена.

Итоговая стоимость зависит также от времени суток и дня недели.

Существует два варианта расчета:

Минимальная цена поездки одинакова для любого времени — 99 рублей (пример для города Москвы). Разница в том, что на дневном тарифе в эту сумму входит 4 минуты и 2 км пути, а на ночном — 3 минуты и 2 км. Дальше поездка рассчитывается одинаково: не более 9 рублей за километр или минуту.

Если клиента придется ждать, цена этой услуги добавляется к базовой сумме за поездку. 3 минуты ожидания бесплатны (зависит от города), а за большее время полагается доплата.

Важно! Если клиенты поехали по маршруту и решили остановиться у магазина, ожидание дольше трех минут также оплачивается дополнительно.

В сервисе Яндекс Такси работают фиксированные цены для поездок в определенные точки. Это аэропорты, вокзалы, некоторые станции метро. На сайте Яндекс можно посмотреть, в каких городах есть такие маршруты. Например, в Москве трансфер из аэропорта обойдется клиенту в 300 рублей за подачу такси и 8 за минуту или километр маршрута.

Если клиент хочет получить дополнительные услуги, их придется оплатить отдельно. К таким опциям относятся:

Опции указываются при оформлении заказа, чтобы водитель мог оценить свои возможности до начала поездки. Услуги «Трезвый водитель» в Яндекс нет, таксисты работают на своих автомобилях.

Комиссия с заказов

После поездки из суммы, оплаченной клиентом, вычитается комиссия. Она складывается из двух составляющих:

Комиссия Яндекс Такси отображается в Таксометре и списывается сразу после поездки. Ее размер отличается в зависимости от региона и класса автомобиля.

Важно! Для Москвы комиссия фиксированная и составляет 18% на тарифах «Эконом», «Комфорт», «Минивэн», «Детский»; 20,47% на тарифах «Комфорт+», «Business» и 16% для тарифа «Premier». В других городах комиссия меняется в зависимости от цены заказа.

Какой процент берет партнер, зависит от политики компании. В среднем процентная ставка — 3-4% от цены поездки. Иногда таксопарки набирают водителей работать за фиксированную сумму и комиссию не берут. Бывают акции с выгодными условиями старта. Точные условия подключения уточняют у своей компании-партнера.

Повышающие коэффициенты и бонусы

Таксисты получают больше, если принимают заказы с надбавками или повышенными коэффициентами.

В каких ситуациях расценки на проезд увеличиваются:

Повышенная стоимость видна через телефон в Таксометре для водителя и в приложении для клиента. При оплате безналичным расчетом по карте стоимость такая же, как и за наличные.

Таким образом, есть два способа увеличить цену заказа:

Надбавка фиксированная и не зависит от длительности заказа. Это бонус, который клиент заплатит в любом случае. В приложении это отражается как «+100 рублей» к цене.

Повышающий коэффициент — это цифра, на которую умножается базовая сумма. Если в приложении указан коэффициент 2, то цена заказа будет увеличена в два раза. Рассчитать новую стоимость просто. Поездка за 100 рублей с коэффициентом 2 будет стоить 200 рублей.

Важно! Увеличенная стоимость отражается на карте фиолетовыми молниями. Зоны низкого спроса — серым цветом. Больше зарабатывают таксисты, работающие в фиолетовых участках карты.

Расчет стоимости заказа для водителя складывается из класса автомобиля, тарифа, возможности предоставить особые услуги и дополнительных надбавок. Вы можете самостоятельно выбрать выгодное время для работы, условия, увеличивая свой доход.

Источник

Как перехитрить час пик

И сэкономить, когда спрос на такси выше обычного

В часы пик поездка на такси часто дорожает. Это происходит потому, что принцип работы современных онлайн-сервисов для заказа такси основан на автоматическом балансе спроса (заказов пользователей) и предложения (машин на линии). Количество свободных машин, доступных в конкретное время в районе, где находится пассажир, — это один из главных факторов, влияющих на цену поездки. Если желающих заказать такси больше, чем водителей поблизости, то стоимость поездки автоматически умножается на так называемый повышающий коэффициент.

Повышающий коэффициент автоматически формируется алгоритмом — это временная и вынужденная мера. Во время высокого спроса она помогает воспользоваться такси пассажирам, которые не могут отложить поездку. Иначе система попросту не могла бы найти для них свободную машину. Когда спрос на такси снижается, повышающий коэффициент тоже снижается и исчезает.

Специалисты Яндекс.Такси проанализировали стоимость поездок и количество заказов в часы пик в Москве и составили рекомендации, в какое время лучше заказывать такси, чтобы сэкономить.

Все временные промежутки в тексте приблизительны и могут незначительно варьироваться в зависимости от обстоятельств.

Это самое «горячее» время суток. В Москве рабочий день у большинства организаций начинается в 9:00, поэтому спрос на такси достигает своего пика за полчаса до этого.

Как сэкономить

Выезжайте на работу чуть раньше — например, в 8:15. Тогда поездка будет стоить на 15-20% дешевле.

Проще всего тем, кто не привязан к чёткому расписанию и может выехать на работу позже. Лучшее время для заказа утром — 9:15 (важно помнить, что ближе к 10 утра коэффициент снова немного повысится) или после 10:00.

Повышенный спрос в плохую погоду

Количество заказов активно растёт и в плохую погоду — если идёт дождь, снег, на улице слишком холодно или ветрено. Например, когда в Москве начинается сильный дождь, в течение нескольких минут количество заказов возрастает в 3–4 раза, потому что гораздо больше людей предпочитают ехать «от двери до двери».

И хотя Яндекс.Такси прогнозирует спрос в том числе и с учётом погоды, за несколько минут ни один таксопарк физически не может утроить количество водителей на линии. Повышающий коэффициент в такие дни, особенно в часы пик, может быть больше обычного. В непогоду лучше планировать поездки заранее.

Второй ежедневный час пик — вечерний, когда горожане разъезжаются из офисов. Рабочий день во многих организациях заканчивается в 18:00. За 5-10 минут до этого времени количество заказов резко увеличивается и остается высоким в течение примерно 50 минут.

Но всё-таки максимальный коэффициент вечером не такой высокий, как утром, а спрос на такси — более равномерный.

Как сэкономить

Попробуйте заказывать машину не за 10, а за 20 минут до конца рабочего дня (например, в 17:40) или уже после 19:00.

В это время повышающий коэффициент, как правило, ниже, а стоимость поездки — меньше.

Вечер пятницы или субботы

Отдельно стоит отметить поздние вечера и ночи пятницы и субботы, когда люди едут на вечеринки или домой после них. Это ещё один, третий час пик — он начинается около 22:00 и продолжается до 3:00 субботы или воскресенья. Поездок в это время меньше, чем днём, но и работающих на линии водителей тоже меньше.

Как сэкономить

Лучше всего вызывать такси за 5–20 минут до наступления целого часа. Например, в 0:40–0:45. В это время спрос немного снижается.

Источник

Повышающий коэффициент

Чтобы компенсировать доходность каждого из водителей система применяет повышающие коэффициенты, которые действуют в то время, когда количество заявок резко увеличивается, но автомобилей такси недостаточно. Такой ход стимулирует работников такси более ответственно выполнять свою работу и сразу после одной поездки приступать к другой.

Причинами для увеличения коэффициента являются:

Когда начинает действовать повышающий коэффициент, Таксометр учитывает его в каждом чеке, умножая сумму на него. То есть, если фиксированная сумма чека составляет 200 рублей, то после действия коэффициента в 1,4 она составит 280 рублей.

Что такое молния?

Для обозначения районов с повышенным спросом на услуги такси, а следовательно, где действует повышающий коэффициент, то эта точка на Карте спроса обозначается фиолетовой молнией. Порядок распределения заказов между водителями такси ничем не отличается от обычного режима. В приоритете, соответственно, водители с высоким рейтингом и большим количеством выполненных заказов.

Что такое серые пятна?

Серая зона на карте означает, что в этом районе нет заказов, и не ожидается в ближайшее время, поэтому ехать в него нет смысла. Для увеличения дохода лучше отправляйтесь в фиолетовые зоны.

Источник

Динамическое ценообразование, или Как Яндекс.Такси прогнозирует высокий спрос

Раньше для вызова такси приходилось звонить на разные номера диспетчерских служб и ждать подачу машины полчаса или даже больше. Теперь сервисы такси хорошо автоматизированы, а среднее время подачи автомобиля Яндекс.Такси в Москве около 3-4 минут. Но стоит пойти дождю или закончиться массовому мероприятию, и мы вновь можем столкнуться с дефицитом свободных машин.

Меня зовут Скогорев Антон, я руковожу группой разработки эффективности платформы в Яндекс.Такси. Сегодня я расскажу читателям Хабра, как мы научились прогнозировать высокий спрос и дополнительно привлекать водителей, чтобы пользователи могли найти свободную машину в любое время. Вы узнаете, как формируется коэффициент, влияющий на стоимость заказа. Там всё далеко не так просто, как может показаться на первый взгляд.

Задача динамического ценообразования

Самая главная задача динамического ценообразования – предоставлять возможность заказать такси всегда. Достигается она с помощью коэффициента surge pricing coefficient, на который умножается рассчитанная цена. Мы называем его просто «сурдж». Важно сказать, что сурдж не только регулирует спрос на такси, но и помогает привлечь новых водителей, чтобы повысить предложение.

Если выставить сурдж слишком большим – мы снизим спрос слишком сильно, будет избыток свободных машин. Если выставить слишком низким – пользователи будут видеть «нет свободных машин». Нужно уметь выбирать такой коэффициент, при котором мы будем ходить по тонкому льду между отсутствием свободных машин и низким спросом.

От чего этот коэффициент должен зависеть? Сходу на ум приходит зависимость от количества машин и заказов вокруг пользователя. Теперь можно просто поделить количество заказов на количество водителей, получить коэффициент и какой-то формулой (возможно, линейной) превратить его в наш сурдж.

Но в этой задачке есть небольшая проблема – считать заказы вокруг пользователя может быть уже слишком поздно. Ведь заказ – это почти всегда уже занятая машина, а значит, повышение нашего коэффициента всегда будет запаздывать. Поэтому мы считаем не созданные заказы, а намерения заказать машину – пины. Пин – это метка «А» на карте, которую ставит пользователь, запуская наше приложение.

Сформулируем задачу: нам нужно считать мгновенные значения машин и пинов в какой-то точке пользователя.

Считаем количество пинов и машин вокруг

Когда положение пина меняется (пользовать выбирает точку «А»), приложение пользователя присылает в бекенд новые координаты и небольшую простыню дополнительной информации, которая помогает оценивать пин более точно (например, выбранный тариф).

Мы стараемся придерживаться микросервисной архитектуры, где каждый микросервис занимается обособленными задачами. Подсчетом сурджа занимается микросервис Surger. Он регистрирует пины, сохраняет их в базу данных, а также обновляет слепок пинов в оперативной памяти, в которую они достаточно неплохо умещаются. Отставание кэша при такой работе всего несколько секунд, что приемлемо в нашем случае.

При регистрации каждый пин асинхронно складывается в MongoDb с TTL Index, где TTL – «время жизни» пина, при котором мы считаем его активным для подсчета повышающего коэффициента. Пользователь не ждет, пока мы совершаем эти действия. Даже если что-то пойдет не так, потерять пин не такая большая трагедия.

Горячий кэш строится с индексом по геохэшу. Мы группируем все пины по геохэшу, а затем собираем пины для нужного радиуса вокруг точки заказа.

С машинами мы поступаем также, но в другом сервисе под названием Tracker, в который Surger просто ходит с вопросом «а сколько водителей находятся в этом радиусе».

Так мы считаем мгновенные значения коэффициента.

Кэширование

Кейс: вы стоите в Москве на Садовом кольце и хотите заказать машину. При этом цена прыгает достаточно часто и это раздражает.

Уже зная механику, можно понять, что такое может быть из-за того, что на условном светофоре скапливаются водители в момент запроса сурджа и также быстро оттуда уезжают. Из-за этого сурдж и цена могут заметно «прыгать».

Чтобы избежать подобного, мы кэшируем значение сурджа по пользователям. Когда пользователь приходит за сурджом, мы смотрим – есть ли для этого пользователя сохраненное значение сурджа в допустимом радиусе (линейный обход по всем сохраненным сурджам пользователя). Если есть – отдаем его, иначе рассчитываем новый и также сохраняем.

Работало это неплохо, но бывают и другие ситуации.

Кейс: 2 пользователя запрашивают сурдж. Один заказывает на 30 секунд позже другого, когда машины со светофора из прошлого кейса уже уехали. Получаем картину, где 2 пользователя, заказывающие почти одновременно, могут иметь заметно отличающийся сурдж.

И тут мы переходим от кэша по пользователю на кэш по позиции. Теперь, вместо того чтобы кэшировать значение сурджа только по пользователю, мы начинаем кэшировать его по уже знакомому нам геохэшу. Так мы почти чиним проблему. Почему почти? Потому что могут быть отличия на границах геохэшей. Но проблема не такая существенная, потому что у нас есть сглаживание.

Сглаживание

Возможно, читая кейс про светофор, вам пришла в голову мысль, что это как-то нечестно – считать мгновенный сурдж, зависящий от светофора. Мы тоже так считаем, поэтому придумали, как исправить ситуацию.

Мы решили позаимствовать у машинного обучения метод ближайших соседей для задачи регрессии для того, чтобы определить, как сильно значение мгновенного сурджа отличается от того, что сейчас происходит вокруг.

Этап обучения, как и в формальном описании метода, состоит в запоминании всех объектов – в нашем случае рассчитанных значений сурджа в пине, мы всё это и так уже делаем на момент загрузки всех пинов в кэш. Дело за малым – посчитать мгновенное значение, сравнить его со значением в зоне и договориться, что мы не можем отклоняться от значения в зоне слишком сильно.

Так мы получаем систему с быстрым откликом на происходящие события и позволяющую быстро считать значение повышающего коэффициента.

Водительская карта сурджа

Для коммуникации с водителем нам нужно уметь отображать карту сурджа в приложении водителя – таксометре. Это дает водителю обратную связь о том, есть ли спрос в зоне, где он находится сейчас, и куда ему стоит двигаться, чтобы получить наиболее дорогие заказы. Для нас же это значит, что больше водителей приедут в зону с повышенным спросом и урегулируют его.

Мы живем с парадигмой, что устройство водителя – это достаточно слабое устройство. Поэтому рендеринг гексагональной сетки сурджа лежит на стороне бекенда. Клиент приходит в бекенд за тайлами. Это порезанные растровые картинки для непосредственного отображения на карте.

У нас есть отдельный сервис, который периодически забирает слепки пинов из микросервиса Surger и рассчитывает всю метаинформацию, необходимую для рендеринга гексагональной сетки: где какой гексагон и какой сурдж в каждом.

Заключение

Динамическое ценообразование – это постоянный поиск баланса между спросом и предложением, чтобы пользователям всегда были доступны свободные машины, в том числе за счет механизма привлечения дополнительных водителей в районы с высоким спросом. Например, мы сейчас работаем над более глубоким применением машинного обучения для расчета сурджа. В рамках одной из задач этого направления учимся определять вероятность конвертации пина в заказ и учитывать эту информацию. Работы здесь хватает, поэтому мы всегда рады новым специалистам в команде.

Если вам интересно узнать о какой-то части этой большой темы более детально, то пишите в комментариях. Отзывы и идеи тоже приветствуются!

Источник

Динамическое ценообразование, или Как Яндекс.Такси прогнозирует высокий спрос

Пользователи Яндекс.Такси часто обзывают «яшу» нехорошими словами за «развод», «грабительские цены» и т.д. в условиях высокого спроса. Думаю им, да и моим бывшим коллегам — таксистам будет интересно прочитать, зачем это сделано и как это работает. Техническую часть можно промотать, там немного )

Статья размещена сегодня на Хабре.

Раньше для вызова такси приходилось звонить на разные номера диспетчерских служб и ждать подачу машины полчаса или даже больше. Теперь сервисы такси хорошо автоматизированы, а среднее время подачи автомобиля Яндекс.Такси в Москве около 3-4 минут. Но стоит пойти дождю или закончиться массовому мероприятию, и мы вновь можем столкнуться с дефицитом свободных машин.

Меня зовут Скогорев Антон, я руковожу группой разработки эффективности платформы в Яндекс.Такси. Сегодня я расскажу читателям Хабра, как мы научились прогнозировать высокий спрос и дополнительно привлекать водителей, чтобы пользователи могли найти свободную машину в любое время. Вы узнаете, как формируется коэффициент, влияющий на стоимость заказа. Там всё далеко не так просто, как может показаться на первый взгляд.

Задача динамического ценообразования

Самая главная задача динамического ценообразования – предоставлять возможность заказать такси всегда. Достигается она с помощью коэффициента surge pricing coefficient, на который умножается рассчитанная цена. Мы называем его просто «сурдж». Важно сказать, что сурдж не только регулирует спрос на такси, но и помогает привлечь новых водителей, чтобы повысить предложение.

Если выставить сурдж слишком большим – мы снизим спрос слишком сильно, будет избыток свободных машин. Если выставить слишком низким – пользователи будут видеть «нет свободных машин». Нужно уметь выбирать такой коэффициент, при котором мы будем ходить по тонкому льду между отсутствием свободных машин и низким спросом.

От чего этот коэффициент должен зависеть? Сходу на ум приходит зависимость от количества машин и заказов вокруг пользователя. Теперь можно просто поделить количество заказов на количество водителей, получить коэффициент и какой-то формулой (возможно, линейной) превратить его в наш сурдж.

Но в этой задачке есть небольшая проблема – считать заказы вокруг пользователя может быть уже слишком поздно. Ведь заказ – это почти всегда уже занятая машина, а значит, повышение нашего коэффициента всегда будет запаздывать. Поэтому мы считаем не созданные заказы, а намерения заказать машину – пины. Пин – это метка «А» на карте, которую ставит пользователь, запуская наше приложение.Сформулируем задачу: нам нужно считать мгновенные значения машин и пинов в какой-то точке пользователя.

Сформулируем задачу: нам нужно считать мгновенные значения машин и пинов в какой-то точке пользователя.

Считаем количество пинов и машин вокруг

Когда положение пина меняется (пользовать выбирает точку «А»), приложение пользователя присылает в бекенд новые координаты и небольшую простыню дополнительной информации, которая помогает оценивать пин более точно (например, выбранный тариф).

Мы стараемся придерживаться микросервисной архитектуры, где каждый микросервис занимается обособленными задачами. Подсчетом сурджа занимается микросервис Surger. Он регистрирует пины, сохраняет их в базу данных, а также обновляет слепок пинов в оперативной памяти, в которую они достаточно неплохо умещаются. Отставание кэша при такой работе всего несколько секунд, что приемлемо в нашем случае.

Несколько слов про базу данных

При регистрации каждый пин асинхронно складывается в MongoDb с TTL Index, где TTL – «время жизни» пина, при котором мы считаем его активным для подсчета повышающего коэффициента. Пользователь не ждет, пока мы совершаем эти действия. Даже если что-то пойдет не так, потерять пин не такая большая трагедия.

Горячий кэш строится с индексом по геохэшу. Мы группируем все пины по геохэшу, а затем собираем пины для нужного радиуса вокруг точки заказа.

С машинами мы поступаем также, но в другом сервисе под названием Tracker, в который Surger просто ходит с вопросом «а сколько водителей находятся в этом радиусе».

Так мы считаем мгновенные значения коэффициента.

Кейс: вы стоите в Москве на Садовом кольце и хотите заказать машину. При этом цена прыгает достаточно часто и это раздражает.

Уже зная механику, можно понять, что такое может быть из-за того, что на условном светофоре скапливаются водители в момент запроса сурджа и также быстро оттуда уезжают. Из-за этого сурдж и цена могут заметно «прыгать».

Чтобы избежать подобного, мы кэшируем значение сурджа по пользователям. Когда пользователь приходит за сурджом, мы смотрим – есть ли для этого пользователя сохраненное значение сурджа в допустимом радиусе (линейный обход по всем сохраненным сурджам пользователя). Если есть – отдаем его, иначе рассчитываем новый и также сохраняем.

Работало это неплохо, но бывают и другие ситуации.

Кейс: 2 пользователя запрашивают сурдж. Один заказывает на 30 секунд позже другого, когда машины со светофора из прошлого кейса уже уехали. Получаем картину, где 2 пользователя, заказывающие почти одновременно, могут иметь заметно отличающийся сурдж.

И тут мы переходим от кэша по пользователю на кэш по позиции. Теперь, вместо того чтобы кэшировать значение сурджа только по пользователю, мы начинаем кэшировать его по уже знакомому нам геохэшу. Так мы почти чиним проблему. Почему почти? Потому что могут быть отличия на границах геохэшей. Но проблема не такая существенная, потому что у нас есть сглаживание.

Возможно, читая кейс про светофор, вам пришла в голову мысль, что это как-то нечестно – считать мгновенный сурдж, зависящий от светофора. Мы тоже так считаем, поэтому придумали, как исправить ситуацию.

Мы решили позаимствовать у машинного обучения метод ближайших соседей для задачи регрессии для того, чтобы определить, как сильно значение мгновенного сурджа отличается от того, что сейчас происходит вокруг.

Этап обучения, как и в формальном описании метода, состоит в запоминании всех объектов – в нашем случае рассчитанных значений сурджа в пине, мы всё это и так уже делаем на момент загрузки всех пинов в кэш. Дело за малым – посчитать мгновенное значение, сравнить его со значением в зоне и договориться, что мы не можем отклоняться от значения в зоне слишком сильно.

Так мы получаем систему с быстрым откликом на происходящие события и позволяющую быстро считать значение повышающего коэффициента.

Водительская карта сурджа

Для коммуникации с водителем нам нужно уметь отображать карту сурджа в приложении водителя – таксометре. Это дает водителю обратную связь о том, есть ли спрос в зоне, где он находится сейчас, и куда ему стоит двигаться, чтобы получить наиболее дорогие заказы. Для нас же это значит, что больше водителей приедут в зону с повышенным спросом и урегулируют его.

Мы живем с парадигмой, что устройство водителя – это достаточно слабое устройство. Поэтому рендеринг гексагональной сетки сурджа лежит на стороне бекенда. Клиент приходит в бекенд за тайлами. Это порезанные растровые картинки для непосредственного отображения на карте.

У нас есть отдельный сервис, который периодически забирает слепки пинов из микросервиса Surger и рассчитывает всю метаинформацию, необходимую для рендеринга гексагональной сетки: где какой гексагон и какой сурдж в каждом.

Динамическое ценообразование – это постоянный поиск баланса между спросом и предложением, чтобы пользователям всегда были доступны свободные машины, в том числе за счет механизма привлечения дополнительных водителей в районы с высоким спросом. Например, мы сейчас работаем над более глубоким применением машинного обучения для расчета сурджа. В рамках одной из задач этого направления учимся определять вероятность конвертации пина в заказ и учитывать эту информацию. Работы здесь хватает, поэтому мы всегда рады новым специалистам в команде.

Источник