Зворотний бік авіаквитка. Як Туту.ру допомагає підібрати оптимальний тариф

1. На смак і колір GDS'a немає
2. Нова система тарифів
3. Розробка власного рішення
4. Впроваджуємо механізм FRule
5. кешування даних
6. Що ми в результаті отримали

Навесні 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, то на ці місця можна купити квитки і з багажем, і без нього.

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

Розробка власного рішення

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

Наприклад, ви летите з Челябінська в Рим з пересадки в Москві і Дюссельдорфі. На сегменті Челябінськ - Москва ви летите власним рейсом авіакомпанії 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 змінних. Спочатку ми задаємо

Потім фіксуємо якусь змінну і задаємо

А, наприклад, для задаємо

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

Для заданої таким чином функції не визначене. Щоб позбутися від таких невизначеностей ми використовуємо встановлену систему пріоритетів: ми говоримо, що значення певні для набору, в якому фіксована тільки , Приоритетнее, ніж значення, визначені для набору, в якому фіксована тільки . При цьому значення, визначені для набору, в якому фіксовані і , і , Приоритетнее значень, визначених для наборів, в яких фіксована тільки одна з змінних. Таким чином, . Ці пріоритети зазвичай є наслідком предметної області та бізнес-логіки, наприклад, очевидно, що вказівка ​​міста приоритетнее вказівки країни.

Перш ніж розробляти рішення для продакшена, ми вирішили перевірити його «на коліні», і не дарма. Фізично механізм FRule являє собою набір відповідностей «параметри - значення» функції , Що зберігається в MySQL. Виходячи з пріоритетів наборів при зверненні до FRule, виконуються нехитрі запити до того моменту, поки не буде знайдений результат, який потім кешируєтся. Для початкових завдань конфігурації цього більш ніж вистачало. З'ясувалося, що завдання визначення опцій необхідно допрацьовувати. Виявилося, що для розрахунку багажу всіх пропозицій по маршруту Москва - Санкт-Петербург на один день потрібно 20 хвилин. Переглянувши систему пріоритетів і прибравши звідти надлишкові і невикористовувані набори, ми скоротили його до 3 хвилин. Однак це все одно було багато.

Вузьким місцем виявилася MySQL, а точніше, кількість і накладні витрати на запити, які ми їй надсилали в тому випадку, якщо результату для конкретного пропозиції немає в кеші. Для кожної пропозиції ми починали шукати збіги: спочатку по найбільш приватному набору, потім переходили до все більш і більш загальним наборам. Наведемо приклад, щоб уявити масштаб лиха. Зараз у нас 288 наборів з різним пріоритетом. Пропозицій з пошуку на один напрямок можуть бути сотні і тисячі, і не дивлячись на те, що не всі вони будуть показані користувачеві, обробляти потрібно все.

Для вирішення цієї проблеми ми вирішили перенести обчислення на бекенд. Обчислення значень складається з двох частин. Перша - це побудова якоїсь спеціальним чином організованої структури. Друга - обчислення значень виходячи з цієї структури.

Розглянемо, что за структуру ми будуємо. Повернемося до нашого прикладу Функції від двох змінніх. Для неї ми визначили такий пріоритет наборів:

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

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

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

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

Цю процедуру повторюємо для кожного набору змінних. Наприклад, для набору ми виберемо правила запитом

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

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

В результаті для функції отримуємо такий набір дерев:

[[[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 правил, що значною мірою покриває наш асортимент. Звичайно, залишаються ще пропозиції, для яких у нас поки не заведені правила - особливо це стосується тих напрямків і пропозицій, за якими у нас рідко шукають і купують. Для того, щоб контент-менеджери могли оперативно дізнаватися про такі пропозиції, ми розробили спеціальну систему логування: варто прийти значенням тієї чи іншої опції, яка відрізняється від значення в нашій базі знань або якої в ній немає, протягом години контент-менеджери про це дізнаються. Для підтримки бази в актуальному стані наші контент-менеджери постійно взаємодіють з авіакомпаніями і перевіряють, чи немає змін на офіційних сайтах, телефонують з їх представниками.

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