Чтобы выгодно спланировать поездку, нужен месяц: как в tripmydream решили эту проблему

Многие из тех, кто только поверхностно знаком со сферой туризма и продажей авиабилетов в частности, могут искренне удивиться, зачем вообще здесь Data Science (набор конкретных дисциплин из разных направлений, отвечающих за анализ данных и поиск оптимальных решений на их основе — прим. ред.) — берешь все доступные билеты (туры, отели) и продаешь.

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

С чего мы начинали

В tripmydream мы используем Data Science для разных целей:

• чтобы обогатить данные (прогноз цен на авиабилеты и отели),
• помочь пользователям,
• повысить конверсию (рекомендационные модели выбора билета и прогноза динамики цен),
• взаимодействовать с пользователями (прогноз вероятности покупки). 

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

Мы начали развивать Data Science инструменты в tripmydream сразу, как только основали этот стартап. В январе 2013 года мы с женой проводили время на итальянском горнолыжном курорте. Там я в очередной раз столкнулся с отсутствием единого источника достоверной и полезной информации для путешественников.

Я провел несколько исследований и пришел к выводу, что более чем половине путешественников трудно найти подходящие цены на отель и перелёт. Чтобы запланировать и выгодно оплатить поездку, им приходится посещать десятки сайтов в течение 20–30 дней. Эта проблема и подтолкнула создать сервис, который взял бы на себя эту работу.

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

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

Сервис tripmydream мы запустили в мае 2015 года, первыми клиентами были мои друзья, а потом заработало «сарафанное радио» и социальные сети. Меньше чем через год ежемесячная посещаемость сайта составила треть миллиона человек.

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

Вот эта модель рекомендации самого выгодного пакета «перелет + отель» и модель прогноза цены на перелет стали нашими первыми AI-фишками (Artificial Intelligence, искусственный интеллект — прим. ред.). Именно с ними мы выиграли свою первую награду — в 2016 году tripmydream признали лучшим трэвел-стартапом на международном конкурсе Seedstars Summit 2016, который проходил в Швейцарии.

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

Когда вы только начинаете планировать свой отпуск, часто начинаете с вопроса «Куда лететь?». Наш сервис сразу может помочь ответить на этот вопрос.

Рекомендационная модель обрабатывала данные о том, что раньше чаще всего выбирали пользователи tripmydream, ранжировала на лету около миллиона предложений:

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

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

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

Гораздо более комплексной задачей оказалось прогнозировать цены на авиабилеты.

Зачем прогнозировать то, что и так доступно

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

Все регулярные авиакомпании хранят свои тарифы и правила ценообразования в глобальных системах бронирования GDS (Global Distribution System), таких как Galileo, Amadeus, Sabre и других. В момент, когда пользователь ищет билет, на сайте сервиса-агрегатора билетов инициируется запрос в GDS, который на лету формирует список всех доступных вариантов перелета между двумя городами на заданные даты.

Количество таких вариантов — несколько тысяч на один запрос. И, самое важное, — вы не можете одновременно запросить цены на диапазон дат или на список направлений. Одно направление на одну пару дат (дата вылета туда и дата вылета обратно или же просто дата вылета туда в случае перелета в одну сторону) — один запрос. Хотите получить цены на другие даты — новый запрос.

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

Условно говоря, если у вас на сайте 1 000 пользователей сделали по одному поисковому запросу (на конкретные даты и направление), вы должны продать минимум один билет. На 10 000 запросов — 10 билетов и так далее. Если за месяц ваше соотношение проданных билетов к количеству запросов в GDS меньше требуемого, вам могут снизить размер комиссии, наложить штрафы или вообще отключить от системы, в зависимости от условий договора.

Поэтому, если мы хотим предложить пользователям выбор из разных направлений, пусть даже на фиксированные даты, мы не можем сделать одновременно 1 000 запросов. И тут на помощь нам приходит прогнозирование.

Начинали мы с простой модели линейной регрессии, которая использовала такие параметры: сезонность, время до вылета, дни недели вылета и возвращения, авиакомпания, количество стыковок. Модель могла прогнозировать почти любые направления, но имела точность всего около 70 % (под точностью мы подразумеваем погрешность прогноза не более 10 % от реальной цены).

На этом этапе мы определили ключевые проблемы, с которыми не могла совладать модель:

• Мы прогнозировали просто минимальную цену на заданный набор дат. При этом в эти даты авиакомпания могла выполнять несколько рейсов (или даже несколько десятков, если рейсы стыковочные), что значительно повышало разброс в данных.
• Цена на авиабилет существенно зависела от открытых в продаже тарифов (эконом, эконом премиум, бизнес и так далее). Особенно влияли лоукост-тарифы МАУ, на которые цена отличалась в среднем в 3–5 раз относительно следующего тарифа по сетке. И такие тарифы могли открываться и закрываться довольно часто, при этом мы не учитывали этот признак тарифа.
• Модель плохо предсказывала цены на маршрутах с нерегулярным расписаниям рейсов (когда авиакомпания летала только по определенным дням недели).

Кроме этого, анализ поведения и потребностей пользователей сервиса дал нам еще один важный вывод: многим путешественникам важно знать детали перелета уже тогда, когда они подбирают варианты на разные даты, поэтому наш прогноз самого дешевого билета уже становился не актуальным.

В новой версии сервиса, которая увидела свет в мае 2019 года и предлагала поиск билетов на гибкие даты и направления, мы решили отказаться от старой модели прогноза и начать работу над новой — моделью прогноза цены на конкретный билет.

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

Цены мы получали помимо прогноза и из других источников:

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

Но именно прогноз помог нам увеличить количество доступных вариантов в 10 раз.

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

Через две недели мы уже получили первые результаты — модель на основе алгоритма Random Forest («Случайный Лес». Больше деревьев — более устойчивый лес. Так же алгоритм создает деревья решений для выборок данных, получает прогноз по каждой из них и выбирает лучшее решение, — прим. ред.) выполняла один цикл обучения и прогноза на 200 направлений примерно за 10 часов с точностью около 60 %.

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

Мы оптимизировали код и сократили время выполнения вдвое, что позволило нам увеличить количество дат и авиакомпаний в прогнозе. Но с количеством направлений мы решили остановиться на числе 200. Финальная версия отрабатывает 8 часов и генерирует 40 млн. цен за сутки с точностью около 85 %.

С чем мы столкнулись 

Прежде всего, это прогнозирование цен на лоукосты. Характер ценообразования для лоукост-авиакомпаний отличается от регулярных прежде всего по двум пунктам:

• Цены могут меняться намного чаще и более гибко реагировать на статус заполненности того или иного рейса.
• Стоимость рейса в обе стороны всегда состоит из суммы отдельных билетов в один конец туда и обратно.

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

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

Для более популярных направлений у нас было больше поисков в истории и, соответственно, больше цен в тренировочной выборке. Мы обратили внимание на то, что для направлений, по которым у нас было меньше данных, точность была очень низкой и нас не устраивала. Экспериментальным путем мы определили минимальный лимит в 10 000 цен в тренировочной выборке за две недели.

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

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

Типичный пример такого направления — Киев-Денпасар (Бали) или Киев-Бангкок. Увеличение объема данных в тренировочной выборке с 5 до 15 тысяч записей в таких случаях давало в среднем повышение точности прогноза на 5–10 %. 

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

Последним элементом пазла модели стал микро-сервис «Расписание». Чтобы прогнозировать цену на билет, нужно понимать, какие вообще есть билеты — какой рейс, по каким дням и в какое время летит.

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

Все эти модели в комплексе дали нам дополнительно, как я уже упоминал выше, около 40 млн. новых цен в сутки, что позволило увеличить количество живых поисков на сайте (на конкретное направление и даты) на 20%.

Разве Booking.com не дает цены сразу на все отели?

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

Мы пошли по проторенной предыдущей моделью дорожке. И в случае с отелями результат получился даже более высоким. С одной стороны, сыграло роль то, что цены на подавляющее большинство отелей в отличие от перелетов не меняются так часто. Но с другой — мы в очередной раз убедились, как важно понимать, как работает бизнес в сфере, где вы пытаетесь что-то прогнозировать. И что один из важнейших этапов в построении модели — feature engineering (конструирование признаков).

В случае с отелями создание одной новой «фичи» путем простой арифметической операции над двумя уже существующими позволило сразу поднять точность модели на 20 %. В финальном варианте модель за два часа прогнозирует пять млн. предложений с точностью 90 % на погрешности 10 % и с точностью 85 % на погрешности 5 %.

Можно ли спрогнозировать, как поведет себя цена на перелет в будущем

А что, если путешественник знает, куда лететь, когда лететь, но предложенная цена кажется завышенной? И на этот вопрос мы также стараемся дать ответ. Мы уже начали работу над новой моделью, которая может спрогнозировать, как изменится цена на конкретный авиабилет в ближайшие 14 дней — вырастет, упадет или останется неизменной.

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

Что можно узнать о пользователях

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

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

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

На этапе анализа данных мы сразу столкнулись с проблемой, что у нас очень много новых пользователей. Это в первую связано с тем, что каждому новому устройству мы присваивали новый хэш (англ. hash function от hash — «превращать в фарш». Преобразует массив входных данных произвольной длины в выходную строку установленной длины, — прим. ред.), а ведь один и тот же пользователь может заходить с разных устройств и браузеров.

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

На основе наших данных нам удалось построить базовую модель предсказания вероятности, с которой пользователь совершить целевое действие в ближайшие N дней. Возник вопрос: как оценивать модель?

Оценивать по обычной точности мы не можем, наши классы очень несбалансированные (до этапа покупки билета доходит небольшая часть пользователей). В нашей задаче не так страшно совершить ошибку второго рода (предсказать что пользователь не купит билет, а он в итоге его купит), поэтому можно в самом простом варианте оценивать, какое количество верно положительных прогнозов среди общего количества положительных прогнозов. На первом этапе этот показатель составлял около 75 %.

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

Первые были более склонны к покупке, но почти не приносили прибыли. Вторые покупали в среднем после пяти заходов на сайт, но их средний чек был существенно выше. Поэтому мы решили разделить пользователей на категории по «прибыльности» (не приносят прибыль, средний чек в среднем до $100, средний чек $100-300, средний чек 300-500$, средний чек $500–1 000, средний чек свыше $1 000) и переопределить свою целевую переменную – теперь мы прогнозируем, в какую категорию попадет наш пользователь.

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

Так что, Data Science принесет мне миллионы?

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