Парсинг цен на авиабилеты и отели

Материал носит информационный характер и не является юридической консультацией. Цены в travel-сегменте динамичны и зависят от контекста запроса, условий тарифа и правил источника.

В travel “цена” — это не одно число. Для авиабилетов на итог влияет багаж, тарифные условия и сборы. Для отелей — тип номера, питание, предоплата, отмена и налоги. Если собрать цену без контекста, вы получите красивые графики, но неверные решения: “подешевело” из-за тарифа без багажа, “подорожало” из-за другого типа номера, “нет доступности” из-за того, что изменился состав гостей.

Авиабилеты и отели — это разные миры

Авиабилеты: что определяет цену

• маршрут (origin/destination), даты, one-way или round-trip;
• состав пассажиров (ADT/CHD/INF);
• класс (cabin/class);
• багаж: включен/не включен, размеры/вес;
• тариф: возврат/обмен, штрафы;
• пересадки, длительность, авиакомпания, рейс;
• итоговая цена с налогами и сборами (и желательно отдельно базовая цена, если источник отдает).

Отели: что определяет цену

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

Если вы сравниваете разные условия, вы сравниваете разные продукты.

Зачем бизнесу мониторинг (и кому это нужно)

1. Метапоиск/агрегатор: контроль конкурентных предложений и конверсии.
2. Тревел-агентство: динамика цен по направлениям, подбор лучших окон.
3. Корпоративные закупки: контроль средней цены по маршрутам и соблюдение политики.
4. Revenue-подход: поиск периодов выгодных тарифов и дефицита.
5. Маркетинг: алерты на промо и распродажи по направлениям/городам.
6. Контроль каналов: parity-проверки (насколько цена/условия совпадают между каналами).
7. Контроль качества поставщиков: доступность, стабильность, “резкие исчезновения” инвентаря.
8. Продуктовая аналитика: почему пользователи выбирают альтернативы (не только цена).

Источники данных: что предпочесть

Для travel лучше думать не “где взять цену”, а “какой канал даст стабильность”.

Приоритет обычно такой:

1. Партнерские/официальные API (авиа/отели)
2. Фиды и прайс-выгрузки поставщиков
3. Официальные инструменты партнеров (кабинеты, отчеты, если вы партнер и это разрешено)
4. Публичные страницы — только если это соответствует правилам источника и вы делаете сбор бережно

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

Минимальный датасет: что фиксировать, чтобы цены были сравнимыми

Общее (обязательно)

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

Авиабилеты (обязательно)

• origin/destination, даты, one-way/round-trip;
• пассажиры (ADT/CHD/INF);
• класс (cabin/class);
• багаж (включен/нет), базовые условия тарифа (возврат/обмен);
• итоговая цена с налогами и сборами (и отдельно base price, если есть);
• сегменты: время вылета/прилета, пересадки, авиакомпания, номер рейса (если нужно для сопоставления).

Отели (обязательно)

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

Почему “цена меняется сама”: факторы волатильности

1. Наличие (fare/room availability): места/номера заканчиваются — цена меняется.
2. Тарифные правила: возвратность и багаж легко “маскируют” реальное удешевление/удорожание.
3. Налоги и сборы: часто добавляются “на последнем шаге” или в другом блоке.
4. Гео и валюта: курс и региональные правила могут менять итог.
5. Персонализация и A/B: разные пользователи видят разные предложения.
6. Кэш и задержки: вы меряете не “сейчас”, а “как обновилось”.
7. Пакеты и комплектации: у отелей меняется питание/условия отмены; у билетов — багаж и правила обмена.
8. Разные каналы: метапоиск, поставщик и агент дают разные комиссионные и условия.

Именно поэтому мониторинг строят на стандартизированных запросах и правилах сравнимости.

Частота обновления и хранение истории

Рекомендация для travel: хранить историю по “стандартизированным запросам”.

• Авиа: маршрут + даты + пассажиры + класс (+ багаж/тарифный профиль).
• Отели: город/объект + даты + гости + тип номера (+ питание/отмена).

Частота зависит от ценности и волатильности:

• ближние даты и топ-направления — чаще (несколько раз в день);
• дальние даты и длинный хвост — реже (1 раз в день/неделю);
• промо-периоды — временно чаще.

Антишум обязателен: не реагировать на единичный скачок, а использовать “окно подтверждения” (например, 2–3 последовательных измерения или устойчивое изменение в течение N часов).

Пайплайн мониторинга

Сбор → Валидация → Нормализация → История → Метрики → Алерты → Действия

• Валидация: пустые цены, невозможные значения, неверная валюта, “обнулились сборы”.
• Нормализация: приводим тарифы/номера к сравнимым категориям (“с багажом/без”, “отмена бесплатная/нет”, “завтрак включен/нет”).
• История: временные ряды по стандартизированным запросам.
• Метрики: медианы/квантили, волатильность, доля доступности.
• Алерты: пороги + антишум + исключения.

Таблица №1: фактор → как искажает сравнение → как учитывать

Фактор	Как искажает сравнение	Как учитывать
Багаж	“дешевле”, но без багажа	хранить признак багажа, сравнивать в одном профиле
Возврат/обмен	“дешевле”, но с жесткими правилами	классифицировать тариф по гибкости
Налоги/сборы	итоговая цена “вдруг выросла”	хранить total и компоненты отдельно
Пересадки	дешево, но долго/неудобно	фиксировать число пересадок и длительность
Разные классы	бизнес сравнили с эконом	фиксировать cabin/class строго
Тип номера	у отеля разные категории	сравнение по одинаковой категории/кроватям
Питание	“дешевле”, но без завтрака	хранить board, сравнивать по одному варианту
Отмена/предоплата	цена ниже из-за жестких условий	фиксировать cancellation/prepay
Гео/валюта	разные цены из-за региона/курса	фиксировать регион и валюту, нормализовать курсом (при необходимости)
Персонализация	разные пользователи видят разное	мерить в стандартизированном режиме, избегать персональных купонов
Кэш	“ложные” скачки	повторная проверка, окно подтверждения
Разные каналы	комиссии/условия отличаются	сравнивать каналы как разные продукты или приводить к единой базе правил

Таблица №2: сигнал → интерпретация → действие

Сигнал	Интерпретация	Действие
Цена упала на X% по маршруту	промо или смена тарифа	проверить багаж/возвратность, подтвердить окном
Пропала доступность	закончились места/номера или ограничение канала	переключить источник/поставщика, пометить дефицит
Цена выросла на ближние даты	дефицит	алерт для закупки/рекомендаций, пересчитать прогноз
Появился “очень дешевый” билет	возможно без багажа/жесткий тариф	сравнить по профилю тарифа, не смешивать с “все включено”
Отель “подешевел”	сменились условия отмены/питание	нормализовать по пакетам, сравнивать одинаковые условия
Скачут сборы	ошибка источника/валидации	проверить раздельные компоненты, включить флаг качества
Резко выросла волатильность	промо-период или нестабильность канала	увеличить частоту на период, усилить антишум
Разъехалась валюта	курс/регион	фиксировать валюту, при необходимости приводить к базовой
“Дешево” только в одном канале	разные комиссии/правила	маркировать канал, не смешивать с прямыми поставщиками
Доля доступности падает	рынок “выкупают”	сигнал для маркетинга/продаж/управления предложениями

Пошаговый план внедрения

1. Определите цель: какие решения должны улучшиться (маркетинг, закупка, parity, рекомендации).
2. Составьте список направлений/городов и стандартизированные запросы (что именно сравниваем).
3. Выберите источники: в приоритете партнерские API/выгрузки.
4. Зафиксируйте правила сравнимости (багаж/тариф/отмена/питание/налоги).
5. Определите частоту и глубину дат (ближние чаще, дальние реже).
6. Постройте дашборд и алерты с антишумом.
7. Введите регламент действий: кто реагирует и что считается “правильной реакцией”.

Чек-лист перед стартом

• цель и KPI определены;
• список стандартизированных запросов согласован;
• источники данных выбраны (предпочтительно API/выгрузка);
• фиксируется полный контекст (пассажиры, багаж, тариф; номер, питание, отмена);
• total price учитывает налоги и сборы (и хранится раздельная структура, если возможно);
• настроены валидация и контроль качества;
• хранится история и параметры запроса;
• частота дифференцирована (топ/хвост, ближние/дальние даты);
• алерты используют окно подтверждения;
• ключи API и доступы хранятся безопасно (роль-доступ, логирование);
• есть план на изменения форматов/источников.