Поисковая машина

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

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

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

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

Вторая серьезная проблема — это нагрузки, которые испытывают веб-сайты агентств и авиакомпаний – участников метапоиска. Каждый посетитель сайта метапоиска, выбрав маршрут и условия полета, инициирует поток запросов к сайтам участников с тем, чтобы определить, по какой цене предлагает данный участник соответствующий перелет. В результате нагрузка на сайт участника достигает сотен тысяч и даже миллионов запросов в сутки, в зависимости от количества метапоисков, в которых участвует агентство или авиакомпания. И вот тут, помимо высоких требований к программно-аппаратной среде сайта, обнаруживается еще один подводный камень, известный как проблема «look-to-book» или L2B.

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

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

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

SIG берет на себя поток поисковых запросов от ИПП, сохраняя показатель L2B на приемлемо низком уровне даже при подключении к метапоисковикам. Рассмотрим, каким образом это достигается.

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

Режим внутреннего поиска и позволяет использовать SIG в качестве поисковой машины.

На рис. представлена внутренняя архитектура SIG в достаточно упрощенном виде.

Архитектура SIG

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

Запрос, который Процессор приложений идентифицирует как поисковый, поступает в Процессор поиска. Для формирования ответного сообщения Процессор поиска располагает необходимыми информационными ресурсами. Во-первых, это база данных, включающая мировое расписание, тарифы, таксы аэропортов, курсы валют и другую информацию, которую поставляют отраслевые информационные системы, такие как OAG, Innovata, ATPCO, IATA, а также Российская ЦРТ в составе ТКП.

Во-вторых, это кэш наличия мест на рейсах, который содержит актуальную информацию. Актуальность достигается благодаря высокой интенсивности потока запросов, проходящих через Процессор поиска (сегодня это 5 – 7 миллионов запросов в сутки), и, конечно, благодаря уникальному алгоритму обновления кэша. Если информация в кэше оказывается не достаточно «свежей», в систему бронирования передается уточняющий запрос. Также для этой цели используются сообщения SSIM и NAVS от инвенторных систем авиакомпаний, позволяющие уточнить количество свободных мест на рейсе по классам и кодам бронирования.

SIG зарекомендовал себя как высоко эффективная поисковая машина. В этом качестве SIG используется крупнейшими Российскими авиакомпаниями Аэрофлотом и ЮТэйр, а также ведущими игроками на рынке онлайн трэвел услуг, такими как biletix.ru, svyaznoy.travel, tutu.ru, onetwotrip.com, portbilet.ru и др.

В SIG23 реализованы различные схемы обработки поисковых запросов благодаря которым ответные сообщения формируются оптимальным образом как с точки зрения пользователя, так и с точки зрения коммерческих интересов владельца ИПП:

  1. Внешний поиск
  2. Параллельный поиск
  3. Собственный или внутренний поиск
  4. После поиска
  5. Сложный маршрут
  6. Составной поиск

Внешний поиск

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

  • указать авиакомпанию, по рейсам которой будет осуществляться поиск;
  • распределить авиакомпании по разным GDS. Например, для отечественных авиакомпаний поиск будет осуществляться в Сирене-Трэвел, а для зарубежных - в одной из GDS;

Параллельный поиск

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

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

Собственный или внутренний поиск

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

Собственный поиск

Преимущества собственного поиска

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

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

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

После поиска (валидация результатов поиска)

После получения ответа от системы бронирования для каждого варианта перевозки на основе предварительных настроек SIG23 производятся следующие действия:

  • выбор системы бронирования/стока оформления перевозки
  • коррекция начисленных сборов в зависимости от выбранных системы/стока
  • проверка специфических ограничений авиакомпаний (например, компания HY запрещает оформление в классах ниже K)
  • перепроверка наличия мест
  • проверка наличия интерлайн-соглашений между перевозчиками

Перепроверка наличия мест

Системы резервирования используют собственный кэш наличия мест, поэтому их данные не всегда достоверны. В связи с этим после получения ответов на поисковые запросы целесообразно сделать выборочные проверки. Это, во-первых, позволяет избежать фиктивных предложений от GDS/CRS, а во-вторых, позволяет актуализировать кэш SIG23. 

Поскольку проверять 100% ответов слишком затратно, то в SIG23 реализован механизм эвристической подборки алгоритмов перепроверки, который учитывает статистику ошибочных бронирований по компаниям.

Сложный маршрут

Сложный маршрут – это поиск на перевозку сложнее чем RT (туда-обратно). 
Сложный маршрут

Составной поиск

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

Вариант А. Представление маршрута RT как OW+OW. Например, Москва — Сочи на рейсе и на стоке одной авиакомпании, а Сочи — Москва на рейсе и на стоке другой авиакомпании.

Вариант B. Представление сложного маршрута как двух независимых. Например, маршрут «Якутск — Мадрид через Москву и обратно» оформляется между Якутском и Москвой на рейсах а/к Якутия на стоке ТКП, а между Москвой и Мадридом на рейсах а/к Iberia на стоке BSP.

Разработано в ТАИС