#ML_in_business
🏷️ Ценообразование: часть 2. Как мы делали dynamic pricing в Яндекс.Такси
🗓️ Во-первых, вспомним про контекст 2017 года, когда в такси появлялся ML в ценообразовании. Был ряд крупных игроков, среди которых Gett, Uber и Яндекс.Такси, которые довольно активно конкурировали. Особенно последние два. Каждый игрок на рынке имел свою тарификацию за километр и за минуту (которые постепенно у всех примерно сошлись), итоговая цена - это стоимость времени плюс стоимость расстояния.
🤔 Можно ли здесь накинуть 20% сверх вашей ценовой политики «просто так» и «потому что купят»? Скорее нет, потому что не купят. Откроют соседнее приложение и закажут там дешевле. А вот когда действительно есть простор для конкуренции, так это когда водители в районе кончились. Если вы можете увезти клиента, а конкурент нет - клиент достанется вам.
💡 Отсюда возникает идея: динамическое ценообразование должно делать так, чтобы водителей всегда хватало, т.е. срезать часть спроса. Здесь есть серьезный плюс и для клиента: если такой прайсинг работает, то клиент всегда сможет уехать на такси, пусть иногда и за дорого.
Таким образом, если водителей много, оставляем обычные цены, а вот если водителей становится меньше, чем спрос на поездки, умножаем базовую цену на повышающий коэффициент. Коэффициент должен выводить систему в состояние баланса: в пик спроса количество освобождающихся рядом водителей должно быть примерно равно количеству заказов, которые сделают в ближайшее время.
⚖️ Уравнение, которое описывает это состояние динамического равновесия (мы называли его «уравнение баланса»), можно записывать по-разному, дорабатывать и модифицировать. Этим занималась команда эффективности платформы под руководством Саши Аникина (ныне СЕО Яндекс.Go).
Моя же команда делала прогнозные ML-модели, которые были нужны для уравнения. Например, про водителей мы еще понимаем, кто и когда закончит поездку в заданном районе. А вот про пассажиров действительно нужно прогнозировать, с какой вероятностью пин превратиться в заказ (в зависимости от цены). Дальше суммируем вероятности в заданном районе, чтобы получить матожидание заказов, и подбираем такую цену, чтобы нам хватило притока водителей в район эти заказы вывезти.
Уравнение баланса можно усложнять и усложнять. Например, можно учесть, что как только водители видят сурдж на карте, они начинают специально переезжать в район подороже. Или можно добавлять вероятность того, что водитель все равно не возьмет заказ. Или вероятность отмены.
☝️Но идейно простой модели уже достаточно, чтобы решать основную задачу - всегда давать пассажиру уехать. Это когда у вас есть такси по цене х2 вы огорчаетесь. А вот я вас уверяю, если все уехали по х1, а вы просто не уедете - это куда обиднее :) Недавно попадал в такую ситуацию в другой стране, совсем не понравилось.
Задавайте в комментариях вопросы про модели ценообразования, в следующем посте я отвечу на популярные мифы и то, что еще поместится в пост :)
P.S.: скорее всего, сейчас алгоритмы уже совсем поменялись, все-таки прошло много времени и рынок теперь другой, но несколько лет с 2017 все работало как-то так
🏷️ Ценообразование: часть 2. Как мы делали dynamic pricing в Яндекс.Такси
🗓️ Во-первых, вспомним про контекст 2017 года, когда в такси появлялся ML в ценообразовании. Был ряд крупных игроков, среди которых Gett, Uber и Яндекс.Такси, которые довольно активно конкурировали. Особенно последние два. Каждый игрок на рынке имел свою тарификацию за километр и за минуту (которые постепенно у всех примерно сошлись), итоговая цена - это стоимость времени плюс стоимость расстояния.
🤔 Можно ли здесь накинуть 20% сверх вашей ценовой политики «просто так» и «потому что купят»? Скорее нет, потому что не купят. Откроют соседнее приложение и закажут там дешевле. А вот когда действительно есть простор для конкуренции, так это когда водители в районе кончились. Если вы можете увезти клиента, а конкурент нет - клиент достанется вам.
💡 Отсюда возникает идея: динамическое ценообразование должно делать так, чтобы водителей всегда хватало, т.е. срезать часть спроса. Здесь есть серьезный плюс и для клиента: если такой прайсинг работает, то клиент всегда сможет уехать на такси, пусть иногда и за дорого.
Таким образом, если водителей много, оставляем обычные цены, а вот если водителей становится меньше, чем спрос на поездки, умножаем базовую цену на повышающий коэффициент. Коэффициент должен выводить систему в состояние баланса: в пик спроса количество освобождающихся рядом водителей должно быть примерно равно количеству заказов, которые сделают в ближайшее время.
⚖️ Уравнение, которое описывает это состояние динамического равновесия (мы называли его «уравнение баланса»), можно записывать по-разному, дорабатывать и модифицировать. Этим занималась команда эффективности платформы под руководством Саши Аникина (ныне СЕО Яндекс.Go).
Моя же команда делала прогнозные ML-модели, которые были нужны для уравнения. Например, про водителей мы еще понимаем, кто и когда закончит поездку в заданном районе. А вот про пассажиров действительно нужно прогнозировать, с какой вероятностью пин превратиться в заказ (в зависимости от цены). Дальше суммируем вероятности в заданном районе, чтобы получить матожидание заказов, и подбираем такую цену, чтобы нам хватило притока водителей в район эти заказы вывезти.
Уравнение баланса можно усложнять и усложнять. Например, можно учесть, что как только водители видят сурдж на карте, они начинают специально переезжать в район подороже. Или можно добавлять вероятность того, что водитель все равно не возьмет заказ. Или вероятность отмены.
☝️Но идейно простой модели уже достаточно, чтобы решать основную задачу - всегда давать пассажиру уехать. Это когда у вас есть такси по цене х2 вы огорчаетесь. А вот я вас уверяю, если все уехали по х1, а вы просто не уедете - это куда обиднее :) Недавно попадал в такую ситуацию в другой стране, совсем не понравилось.
Задавайте в комментариях вопросы про модели ценообразования, в следующем посте я отвечу на популярные мифы и то, что еще поместится в пост :)
P.S.: скорее всего, сейчас алгоритмы уже совсем поменялись, все-таки прошло много времени и рынок теперь другой, но несколько лет с 2017 все работало как-то так