Цікава інформація

Як працює динамічне ціноутворення в таксі на прикладі Яндекс Таксі

Як працює динамічне ціноутворення в таксі

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

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

Завдання динамічного ціноутворення

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

Якщо виставити сурдж занадто великим – ми знизимо попит дуже сильно буде надлишок вільних машин. Якщо виставити занадто низьким – користувачі будуть бачити «немає вільних машин». Потрібно вміти вибирати такий коефіцієнт, при якому ми будемо ходити по тонкому льоду між відсутністю вільних машин і низьким попитом.

Від чого цей коефіцієнт повинен залежати? Одразу на думку спадає залежність від кількості машин і замовлень навколо користувача. Тепер можна просто поділити кількість замовлень на кількість водіїв, отримати коефіцієнт і якийсь формулою (можливо, лінійної) перетворити його в наш сурдж.

У форумі таксі: Як працює динамічне ціноутворення в таксі

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

Сформулюємо задачу: нам потрібно вважати миттєві значення машин і пінів в якійсь точці користувача.

Вважаємо кількість пінів і машин навколо

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

Ми намагаємося дотримуватися мікросервісної архітектури, де кожен мікросервіс займається відокремленими завданнями. Підрахунком сурджа займається мікросервіс Surger. Він реєструє піни, зберігає їх у базу даних, а також оновлює зліпок пінів в оперативній пам’яті, в яку вони досить непогано вміщаються. Відставання кешу при такій роботі всього кілька секунд, що прийнятно в нашому випадку.

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

З машинами ми чинимо також, але в іншому сервісі під назвою Tracker, в який Surger просто ходить з питанням «а скільки водіїв знаходяться в цьому радіусі».

Так ми вважаємо миттєві значення коефіцієнта.

Кешування

Кейс: ви стоїте в Москві на Садовому кільці і хочете замовити машину. При цьому ціна стрибає досить часто і це дратує.

Вже знаючи механіку, можна зрозуміти, що таке може бути із-за того, що на умовному світлофорі скупчуються водії у момент запиту сурджа і також швидко звідти виїжджають. З-за цього сурдж і ціна можуть помітно «стрибати».

Щоб уникнути подібного, ми кешуємо значення сурджа за користувачам. Коли користувач приходить за сурджом, ми дивимося, чи є для цього користувача збережене значення сурджа в допустимому радіусі (лінійний обхід по всіх збережених сурджам користувача). Якщо є – віддаємо його, інакше розраховуємо новий і також зберігаємо.

Працювало це непогано, але бувають і інші ситуації.

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

І тут ми переходимо від кешу користувачеві на кеш по позиції. Тепер, замість того щоб кешувати значення сурджа тільки користувачеві, ми починаємо кешувати його по вже знайомому нам геохэшу. Так ми майже чиним проблему. Чому майже? Тому що можуть бути відмінності на кордонах геохэшей. Але проблема не така суттєва, тому що у нас є згладжування.

Згладжування

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

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

Етап навчання, як і у формальному описі методу, полягає в запам’ятовуванні всіх об’єктів, у нашому випадку розрахованих значень сурджа в піні, ми всі це і так вже робимо на момент завантаження всіх пінів в кеш. Справа за малим – порахувати миттєве значення, порівняти його зі значенням в зоні і домовитися, що ми не можемо відхилятися від значення в зоні занадто сильно.

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

Водійська картка сурджа

Для комунікації з водієм нам потрібно вміти відображати карту сурджа в додатку водія – таксометрі. Це дає водієві зворотний зв’язок про те, чи є попит в зоні, де він знаходиться зараз, і куди йому потрібно рухатися, щоб отримати найбільш дорогі замовлення. Для нас же це означає, що більше водіїв приїдуть в зону з підвищеним попитом і врегулюють його.

Ми живемо з парадигмою, що пристрій водія – це досить слабке пристрій. Тому рендеринг гексагональної сітки сурджа лежить на стороні бек-ендом. Клієнт приходить у бекенд за тайлами. Це порізані растрові картинки для безпосереднього відображення на карті.

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

Висновок

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

Tags

Related Articles

Back to top button
Close
Close