Обратная сторона авиабилета. Как Туту.ру помогает подобрать оптимальный тариф

    image


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


    В это же время появились бюджетные «безбагажные тарифы». На самом деле, полностью безбагажными их назвать нельзя: по закону РФ, пассажир имеет право провезти с собой до 10 кг личных вещей. И здесь есть интересный момент: закон не регулирует, каким образом пассажир перевозит эти 10 кг — в салоне самолета или в багажном отсеке. Как известно, в салон нельзя брать множество вещей: например, жидкость более 100 мл, маникюрные ножницы, пилочку и некоторые гаджеты. Даже если тариф включает провоз багажа, каждая авиакомпания сама определяет максимальный вес и размеры багажа и ручной клади на одного пассажира.


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


    Цены на билеты многих авиакомпаний не выглядели привлекательно на фоне экономического кризиса, отнюдь не дешевеющих тарифов на поезда и появления «Победы», которая действительно сбила цены на многих направлениях. Например, до появления лоукостера я летал в Чебоксары и обратно за 8–10 тысяч рублей, а сейчас полет обойдется в 3–6 тысяч.


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


    К тому моменту мы уже показывали клиентам, можно ли сдать или обменять билеты. С багажом все оказалось сложнее.


    На вкус и цвет GDS’a нет


    Данные по багажу мы получаем от систем бронирования (GDS — Global Distribution System), что накладывает некоторые ограничения. Во-первых, мы работаем с несколькими GDS, а также с агрегаторами GDS, и это требует поддержки решения для каждой из систем.


    Во-вторых, исторически сложились два типа авиакомпаний. Одни ограничивают максимальный багаж по весу, а другие — по числу мест. Например, «Аэрофлот» дает ограничение по числу мест, и из GDS нам поступают малоинформативные данные о багаже: «1 piece» без информации о максимальном весе.


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


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


    Есть и совсем сложные случаи, например, авиакомпания Оренбуржье заносит в GDS информацию, что разрешен багаж весом не более 10 кг. При этом рейсы выполняются на самолётах Ан-2, у которых нет багажного отделения, поэтому взять запрещенные к провозу в салоне вещи не получится. В данном случае мы показываем пользователям, что на рейсе нет багажа, но разрешена ручная кладь весом до 10кг.


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


    Пример текста тарифных правил
    UNLESS OTHERWISE SPECIFIED
      CHANGES
        ANY TIME
          CHANGES PERMITTED.
             NOTE -
              CHARGE EUR 50.00 FOR REISSUE/REVALIDATION
              ----------
              NO CHILD DISCOUNT APPLIES / INFANT WITHOUT A
              SEAT - NO CHARGE.
              ----------
              CHANGES PERMITTED BEFORE ORIGINALY SCHEDULED
              FLIGHT
              ----------
              THE TICKET MUST BE REVALIDATED OR REISSUED AT THE
              SAME TIME WHEN THE BOOKING IS CHANGED.
              ----------
              THE CHANGE FEE APPLIES PER TRANSACTION. THE
              CHANGE FEE MUST BE COLLECTED AT THE SAME TIME
              WHEN THE BOOKING IS CHANGED
              ----------
              WHEN COMBINING ON A HALF ROUNDTRIP BASIS THE
              PENALTY RULES FOR EACH FARE COMPONENT APPLY.
              CHARGE HIGHEST PENALTY FEE OF ALL CHANGED FARE
              COMPONENTS.
              ----------
              IN CASE OF REISSUE-REROUTING/UPGRADE-
              WHEN THE FIRST FARE COMPONENT IS CHANGED CURRENT
              FARES VALID AT THE TIME OF REISSUE MUST BE USED.
              OTHERWISE HISTORICAL FARES VALID AT THE TIME OF
              ISSUANCE OF PREVIOUS TICKET MUST BE USED.
              -----------
              IN CASE OF RE-ROUTING -
              NEW BASE FARE MUST BE EQUAL OR HIGHER THAN
              PREVIOUS FARE AND FARE DIFFERENCE HAS TO BE
              COLLECTED. WHEN NEW ITINERARY RESULTS IN LOWER
              FARE - UPGRADE TO A LEVEL WHICH IS AT LEAST EQUAL
              AS THE BASE FARE OF PREVIOUS TICKET.
              ----------
              FARE DIFFERENCE AND A CHANGE FEE WILL BE
              COLLECTED.
              ----------
              CHANGES PERMITTED ONLY WITHIN SAME OR HIGHER
              BRAND.
              ----------
              ALL PROVISIONS OF THE NEW FARE MUST BE COMPLIED
              WITH.
              ----------
              ONCE A FARE COMPONENT HAS BEEN COMPLETED FARE
              BREAK POINTS CAN NOT BE CHANGED.
              ----------
              THE NON-REFUNDABLE AMOUNT -FARE/YQ/YR - OF THE
              ORIGINAL TICKET WILL BE NON-REFUNDABLE AND HAS TO
              BE INSERTED IN THE ENDORSEMENT BOX OF THE NEW
              TICKET.
              ----------
              NO SHOW - NOT PERMITTED
              ----------
              IF PASSENGER IS NO SHOW - FINNAIR HAS A RIGHT
              TO CANCEL ONWARD OR RETURN RESERVATION.
              ----------
              NAME CHANGES PERMITTED. APPLIES ONLY TO ITINERARY
              WITH FLIGHTS MARKETED AND OPERATED BY AY.
      CANCELLATIONS
        BEFORE DEPARTURE
          CHARGE 50 PERCENT FOR CANCEL/REFUND.
             NOTE -
              NO CHILD DISCOUNT APPLIES / INFANT WITHOUT A
              SEAT - NO CHARGE.
              ----------
              UNUSED YR/YQ FEES WILL BE REFUNDED.
              ----------
              THE MOST RESTRICTIVE REFUND CONDITIONS APPLY WHEN
              COMBINING ON A HALF ROUNDTRIP BASIS.
              ----------
              FULL REFUND PERMITTED IN CASE OF-
              - REJECTION OF VISA. EMBASSY STATEMENT REQUIRED.
              - DEATH OF PASSENGER OR FAMILY MEMBER.
              WAIVERS MUST BE EVIDENCED BY DEATH CERTIFICATE.
              ----------
              NO SHOW - NOT PERMITTED.
        AFTER DEPARTURE
          TICKET IS NON-REFUNDABLE.
             NOTE -
              UNUSED YR/YQ FEES ARE REFUNDABLE.
              ----------
              THE MOST RESTRICTIVE REFUND CONDITIONS APPLY WHEN
              COMBINING ON A HALF ROUNDTRIP BASIS.
              ----------
              NO SHOW - NOT PERMITTED.

    Мы уже знали, как определять по таким текстам условия обмена и возврата и даже до какого срока они возможны: у одних компаний до окончания регистрации, у других — не позднее, чем за 48 часов до вылета и т.д. Для этого мы сохраняли тексты тарифных правил по всем заказам, которые сделали наши пользователи. Затем простая, но автоматическая система находила в сохраненных текстах меняющиеся от заказа к заказу части, вроде суммы штрафа за возврат, и вырезала их. От полученного текста с пропусками вычислялся некоторый хеш, и затем исходные, т.е. без пропусков, правила группировались по этому хешу. Практически каждый заказ после оплаты просматривался операторами нашего контакт-центра. Операторы читали конкретный текст правил, определяли в нем условия обмена и возврата, и ставили в соответствии с хешем этого текста удобоваримое описание Например, «Возврат возможен не более чем за 24 часа до вылета». Впоследствии, когда очередной клиент делал заказ, и для текста тарифных правил вычислялся хеш, мы уже могли показать понятные условия обмена и возврата. Но на этапе поиска это решение опять-таки не подходило: информация приходила уже на этапе оформления заказа.


    Новая система тарифов


    Разработку нового решения мы начали с простейшей системы, умеющей показывать ограничения только для авиакомпаний S7 и Уральские Авиалинии. Они первыми в России перешли на новую систему тарифов. Как работала старая система: допустим, авиакомпания открывает продажу на рейс, который будет выполнять самолет на 300 человек. Эти 300 мест разбиваются на 10-20 так называемых классов бронирования (не путать с классами обслуживания: Эконом, Бизнес, Первый и т.д.). Каждый класс фактически определяет услуги, предлагаемые авиакомпанией: норму провоза багажа, включенное питание, возможность выбора места, а также обмена и возврата билета и т.д. В зависимости от набора услуг меняется и стоимость тарифов в этом классе. Причем на разных рейсах внутри одного класса бронирования набор услуг может отличаться.


    Новая система тарифных семейств (еще их называют брендированными тарифами) проще. Классы бронирования остаются, но за доступные опции отвечает код тарифа, а именно его название; конкретный класс бронирования и рейс на это уже не влияют. Например, у S7 есть 4 тарифных семейства: Эконом Базовый — невозвратный и только с ручной кладью, Эконом Гибкий — возвратный и с включенным багажом 23 кг, Бизнес Базовый — невозвратный, без доступа в бизнес-зал и с одним местом багажа до 32 кг и Бизнес Гибкий — возвратный, с доступом в бизнес-зал и двумя местами по 32 кг. Отличить их друг от друга очень просто: в коде тарифов семейства Базовый есть подстрока BS, а в коде тарифов семейства Гибкий — подстрока FL. Класс бронирования уже не отвечает за доступные опции. Например, если осталось 9 мест по классу бронирования N, то на эти места можно купить билеты и с багажом, и без него.


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


    Разработка собственного решения


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


    image


    Например, вы летите из Челябинска в Рим с пересадкам в Москве и Дюссельдорфе. На сегменте Челябинск — Москва вы летите собственным рейсом авиакомпании S7 — S7-8. На сегменте Москва — Дюссельдорф самолет принадлежит S7, но на билете у вас указан рейс авиакомпании AirBerlin и номер AB-5911. Значит, на этом сегменте оперирующий перевозчик — S7, а маркетинговый — AirBerlin и такая комбинация называется codeshare-соглашением. Дальше из Дюссельдорфа до Рима вы летите собственным рейсом AB-8718 AirBerlin. При этом весь перелет из Челябинска в Рим оформлен одним электронным билетом, который продала вам авиакомпания AirBerlin несмотря на то, что на первом сегменте вы летите собственным рейсом S7. В данном случае AirBerlin является валидирующим перевозчиком, т.е. авиакомпанией, которая по взаимному соглашению с другими авиакомпаниями-участниками перелета оформляет билет и будет осуществлять взаиморасчеты. Такое соглашение называется interline. Чаще всего валидирующая компания является и маркетинговой на каком-нибудь из сегментов, однако бывают случаи, когда отличаются все три авиакомпании — оперирующая, маркетинговая и валидирующая.


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


    Даже в рамках одной авиакомпании часто встречаются исключения на конкретном направлении и даже по конкретному аэропорту. Например, у Qatar Airways норма бесплатного провоза багажа в эконом-классе для рейсов из России — 1 место весом не более 30 кг, а для рейсов из США — 2 места не более чем по 23 кг каждое. У многих компаний меняются нормы багажа на рейсах на Ближний Восток — в Турцию и Египет. Есть и совсем исключительные случаи, когда на каком-нибудь отдельном направлении право устанавливать нормы багажа и взимать плату за их превышение выкупает не относящаяся к авиакомпании фирма.


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


    Внедряем механизм FRule


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


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


    Представляет он из себя вот что. Допустим, у нас есть функция от N переменных. Сначала мы задаем


    $F(x_1, x_2, \ldots, x_N) = C = Const$


    Затем фиксируем какую-нибудь переменную $x_i = z$ и задаем


    $F(x_1, x_2, \ldots, x_{i-1}, z, x_{i+1}, \ldots , x_N) = C_1$


    А, например, для $x_i = w$ задаем


    $F(x_1, x_2, \ldots, x_{i-1}, w, x_{i+1}, \ldots , x_N) = C_2$


    Дальше фиксируем $x_j$ и продолжаем процесс, по сути переходя от общего к частному. Затем на вход этой функции подаются какие-либо данные. В случае с определением нормы багажа это данные полетного сегмента: откуда, куда, когда, какие авиакомпании, код тарифа и т. д. Здесь есть один нюанс: переменные в функции $F$ могут быть неравнозначны между собой. Рассмотрим простейший случай функции двух переменных $F(x_1, x_2)$. Пусть мы задали


    $ F(x_1, x_2) = \left\{ \begin{array}{ll} 1 & \textrm{если } x_1 = 0\\ 2 & \textrm{если } x_2 = 0\\ 3 & \textrm{если } x_1 = 1, x_2 = 1\\ 4 & \textrm{если } x_1 = 1, x_2 = 2\\ 5 & \textrm{если } x_1 = 2, x_2 = 1\\ 6 & \textrm{иначе} \end{array} \right. $


    Для заданной таким образом функции $F(0, 0)$ не определено. Чтобы избавиться от таких неопределенностей мы используем предустановленную систему приоритетов: мы говорим, что значения определенные для набора, в котором фиксирована только $x_1$, приоритетнее, чем значения, определенные для набора, в котором фиксирована только $x_2$. При этом значения, определенные для набора, в котором фиксированы и $x_1$, и $x_2$, приоритетнее значений, определенных для наборов, в которых фиксирована только одна из переменных. Таким образом, $F(0, 0) = 1$. Эти приоритеты обычно проистекают из предметной области и бизнес-логики, например, очевидно, что указание города приоритетнее указания страны.


    Прежде чем разрабатывать решение для продакшена, мы решили проверить его «на коленке», и не зря. Физически механизм FRule представляет собой набор соответствий «параметры — значение» функции $F$, хранящийся в MySQL. Исходя из приоритетов наборов при обращении к FRule, выполняются нехитрые запросы до того момента, пока не будет найден результат, который затем кэшируется. Для первоначальных задач конфигурирования этого более чем хватало. Выяснилось, что задачу определения опций необходимо дорабатывать. Оказалось, что для расчета багажа всех предложений по маршруту Москва — Санкт-Петербург на один день потребовалось 20 минут. Пересмотрев систему приоритетов и убрав оттуда избыточные и неиспользуемые наборы, мы сократили его до 3 минут. Однако это все равно было много.


    Узким местом оказалась MySQL, а точнее, количество и накладные расходы на запросы, которые мы ей посылали в том случае, если результата для конкретного предложения нет в кэше. Для каждого предложения мы начинали искать совпадения: сначала по наиболее частному набору, затем переходили ко все более и более общим наборам. Приведем пример, чтобы представить масштаб бедствия. Сейчас у нас 288 наборов с разным приоритетом. Предложений по поиску на одно направление могут быть сотни и тысячи, и несмотря на то, что не все они будут показаны пользователю, обрабатывать требуется все.


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


    Рассмотрим, что за структуру мы строим. Вернемся к нашему примеру функции $F$ от двух переменных. Для нее мы определили такой приоритет наборов:


    $[x_1, x_2], [x_1], [x_2], []$


    Напомню, что самый верхний набор является самым частным — если для всех входящих в него полей есть явно заданное значение функции, то оно и будет использовано. По сути, мы преобразуем плоскую табличку, хранящуюся в базе данных, в набор деревьев для каждого набора переменных. Рассмотрим процесс построения набора деревьев для набора $[x_1, x_2]$. Сначала запросом типа


    SELECT * FROM t WHERE x1 IS NOT NULL AND x2 IS NOT NULL

    Мы получаем из базы данных все строки, для которых определены и $x_1$, и $x_2$. Затем группируем их по значению переменной $x_1$. Затем правила в каждой группе группируем по переменной $x_2$, и т.д. Таким образом, для наиболее частного набора $[x_1, x_2]$ строим такой набор деревьев:


    [
        [1] =>  [
            [1] => 3,
            [2] => 4
        ],
        [2] =>  [
            [1] => 5
        ]
    ]

    Эту процедуру повторяем для каждого набора переменных. Например, для набора $[x_1]$ мы выберем правила запросом


    SELECT * FROM t WHERE x1 IS NOT NULL AND x2 IS NULL

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


    В итоге для функции $F$ получаем такой набор деревьев:


    [
        [
            [1] =>  [
                [1] => 3,
                [2] => 4
            ],
            [2] =>  [
                [1] => 5
            ]
        ],
        [
            [0] => [
                [NOT_SPECIFIED] => 1
            ]
        ],
        [
            [NOT_SPECIFIED] => [
                [0] => 2
            ]
        ],
        [
            [NOT_SPECIFIED] => [
                [NOT_SPECIFIED] => 6
            ]
        ]
    ]

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



    Кэширование данных


    На самом деле, строить набор деревьев при каждом вызове FRule было бы странно — его можно один раз посчитать и запомнить. Кроме того, у нас несколько серверов, на которых может выполняться эта задача, так что неплохо было бы еще и передавать набор деревьев между ними. Для кэширования и синхронизации между серверами вычисленных значений мы используем memcache. Однако обращаться каждый раз к memcache, чтобы забрать из него набор, дорого — реальные наборы занимают несколько мегабайт и нет никакого смысла гонять их по сети. Поэтому кроме memcache мы используем еще и APCu (а до перехода на PHP7 — xCache). Если сервер построил или получил из memcache набор деревьев, то он сохранит его в APCu и в следующий раз возьмет оттуда.


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


    Что мы в итоге получили



    У пользователя, для выдачи которого нет данных в кэше, вычисление данных о тарифных опциях занимает от долей секунды до 15-20 секунд на очень больших выдачах, где много рейсов и много пересадок. Вскоре после выхода бэкенд-части на бой наши фронтенд-разработчики сделали фильтры по багажу, возможности обмена и возврата, благодаря чему клиенты могут сразу отсечь неинтересные им предложения. По статистике, новыми фильтрами пользуются порядка 10% посетителей, а интересуются параметрами багажа и возвратности 15%. Теперь пользователям не приходится долго искать тот же рейс, но с багажом или возможностью возврата. Мы научились отображать краевые случаи, например, авиакомпания «Полярные авиалинии» суммарно разрешает взять 20 кг багажа, из которых не более 5 — в ручную кладь.


    Вот пример результатов нашей работы. Мы помогаем купить билеты не только по традиционным маршрутам в Санкт-Петербург, Сочи или Симферополь, но у нас довольно популярны и региональные направления. Посмотрим на рейс авиакомпании Алроса из Красноярска в Мирный:



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


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


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

    Туту.ру

    536,00

    Tutu.ru — сервис путешествий №1 в России.

    Поделиться публикацией
    Комментарии 23
      +4
      А нет ли идеи предложить какой-нибудь API для авиакомпаний, через который они смогут сами обновлять информацию о тарифах и рейсах? И попытаться заманить их на свою площадку, чтобы они действовали в активном режиме, заполняя данные по факту их изменения у себя.
        +3
        Сомнительная затея… Мало кто развивает продажу билетов со своего сайта, а тут идти к агрегатору, изучать api… возня…
        Крупные игроки развиваются сами, мелкие никак))
          +1
          Такая идея есть. Но и в GDS сейчас развиваются инструменты, которые позволят авиакомпаниям заносить максимум информации в едином формате
            0
            Сейчас это так и работает. Авиакомпании вносят информацию о рейсах, тарифах и пр. в GDS, с которой работают. А аггрегаторы, коим является Туту.ру, могут запрашивать эту информацию из того GDS, с которым(и) заключен контракт и хотят работать. Аггрегаторов тьма тьмущая, а работают они с авиакомпаниями коссвенно через GDS, которых может быть несколько, но обычно одной. Так вот авиакомпания итак вносит все, что надо и хочет в единую GDS (или в 2,3… если на рынке несколько GDS), зачем авиакомпании вносить повторно всю эту информацию еще в десятки аггрегаторов? Да даже если так сделать, бронирование все равно проходит через GDS, и Вы не сможете скормить GDS'у запрос, в котором нет чего-то согласно их АПИ.
          • НЛО прилетело и опубликовало эту надпись здесь
              +2
              Предложений по авиабилетам много, и клиент сам выбирает самый удобный и выгодный путь для оформления билета. На то и рынок :) Кто-то ищет в первую очередь наименьшую цену, а кто-то — удобство и качество обслуживания. Все билеты оформляются через единую систему, поэтому в плане надежности никакой разницы при покупке билета на сайте авиакомпании или Туту.ру нет.

              Вопрос о продаже билетов на электрички, естественно, обсуждается
              • НЛО прилетело и опубликовало эту надпись здесь
                  0
                  Удобство только в том, что это аггрегатор сразу по нескольким авиакомпаниям, или даже по разным GDS, на одни и те же параметры поиска. Если в нужный Вам день, независимо от времени, есть 10 рейсов от разных авиакомпаний из нужной точки отправления в нужную точку прибытия, Вам будет удобнее всю эту информацию искать на сайтах 10 авиакомпаний? Аггрегатор даст Вам все 10 вариантов, из которых и выбирайте. Если Вы «смекалистее» обывателя, то найдя самый подходящий Вам рейс в аггрегаторе, введите его параметры уже на сайте соответствующей авиакомпании и забронируйте там, возможно будет дешевле.
                  • НЛО прилетело и опубликовало эту надпись здесь
                      0
                      Дело в том, что это аггрегатор один из.
                      Но, судя хотя бы по тому, что мне наши начальник производства и зам дира из командировки принесли авансовые отчеты на почти 15% меньше, чем им было выдано, жадный.
                      И рассказ о внутренностях сервиса в этом случае помогает мало.
                    0
                    Ну если аггрегатор зарекомендован и известен, то да. Но никто Вам не мешает заключить с GDS контракт, разработать сервис с подключением к их АПИ, возвращать пользователям Вашего сервиса результаты поиска, а на шаге бронирования и оплаты не бронировать Pnr в GDS, а деньги за это взять :)
                    0
                    Собственно, статья про это. Вы выбираете удобство или дешевизну. Все эти улучшения требуют ресурсов. И да, вы сами решаете, хотите вы купить билет на 400р дешевле, но при этом не понимая, что вас ожидает на стойке регистрации, либо готовы доплатить за сервис и получить полную информацию и качественное сопровождение на протяжении всей поездки.
                      0

                      А что вас должно ожидать на стойке авиакомпании при покупке билета с сайта авиакомпании и получении соответствующего электронного билета?

                        +1
                        Так в чем удобство то? Туту будет решать проблемы вроде личного консьержа? Где там сопровождение? Полно сайтов ищущих стыковки, они как-то умудряются не брать комиссию.

                        С билетами на поезд вообще жесть, как-то помню смотрел расписание поездов на туту, они предложили билеты на три тысячи (!) дороже чем на сайте РЖД, при стоимости билета около 5-и. Что там за VIP-сопровождение такое?
                      0
                      А видны ли рейсы с пересадками по соглашению М2?
                      Там цена на сегменты может быть ниже и существенно…
                      В кассах такие штуки видны, а вот по агрегаторам интересно…
                        0
                        Да, есть М1-М2. Помечаем их отдельно как «Заказ раздельными билетами» внизу карточек.
                          0
                          Да, мы продаем М2. Вот, например, здесь первое предложение от Ямала и Нордстара — М2
                            0
                            Ага вижу.

                            А чего-то дороже выходит, чем покупка двух билетов:
                            Надым-Москва
                            Москва-Анапа

                            И у нордстара есть вариант подешевле, но с меньшим багажом — такой билет уже не взять на сайте при поиске Надым-Анапа?
                              +1
                              Про то, что М2 дороже — разобрался…
                              М2 заводят аэропорты, а ценник может меняться у авиакомпаний и аэропорт просто не успеет за изменениями…

                              Но вот второй вопрос остаётся и я бы даже его расширил:
                              Если мне не нужен багаж и(или) возвратность, а прямого рейса нет(слишком дорогой), то мне следует искать билеты двумя поисками?
                                0
                                M2 в данном случае получается дороже из-за того, что с тарифом Ямала не может быть скомбинирован самый дешевый тариф Нордстара — на М2 комбинация тарифов BFHOW и BOW2, а по отдельности — BFHOW и NOW2. А если взять сумму BFHOW и BOW2, то суммы совпадут.

                                По второму вопросу — да, в ряде случаев имеет смысл поискать сегменты по отдельности. Особенно это может быть заметно на комбинациях внутреннего и заграничного рейсов. Но надо помнить, что при такой покупке авиакомпании не несут взаимной ответственности: авиакомпания второго сегмента не пересадит пассажира на другой рейс, если рейс на первом сегменте опоздал и стыковка нарушилась. Также придется получать багаж и заново регистрировать его. В некоторых случаях могут возникнуть еще и визовые трудности
                                  0
                                  По первому вопросу:
                                  Ямал. Надым-Москва 9693
                                  image
                                  +
                                  Нордстар. Москва-Анапа 6419 и 7430
                                  Нордстар картинка
                                  =
                                  М2(Ямал+Нордстар) 18186
                                  картинка М2


                                  Видать каких-то билетов я не вижу, т.к. сумма не совпадает…

                                  По второму:
                                  Да, такое бывает.
                                  Лично сталкивался, когда в декабре 2010 в Домодедово коллапс случился и из Пулково рейсы отменяли/задерживали, пришлось возвраты оформлять и брать новый билет, чтобы успеть на второй рейс из Москвы.
                                  Но если запас времени между рейсами есть и не случилось форс-мажора, то всё ок в большинстве случаев.

                                  Спасибо за ответы)
                                    0
                                    Да, вы его не видите, потому что из всех тарифов с одинаковыми опциями мы показываем только самый дешевый. И в данном случае получилось так, что тариф BOW2 с ограничениями в 10кг на багаж дороже тарифа NOW (это за 7430), у которого разрешенный багаж — 20кг
                          –2
                          image

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

                          Самое читаемое