← Все статьи
Вариант использования 5 минут чтения

Мониторинг тарифов: данные о ценах в реальном времени на масштабе

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

travelfare monitoringuse caseanti-botdata collection

Авиакомпании меняют цены сотни раз в день. Не на всю авиакомпанию, а на каждый маршрут. Один перевозчик может корректировать тарифы для тысяч направлений на основе спроса, цен конкурентов, остатка мест и времени до вылета. Для сервисов, зависящих от точных цен (метапоисковики, OTA, корпоративные платформы), это создает конкретную проблему: данные, собранные час назад, уже неактуальны.

Проблема не нова. Однако то, как авиакомпании и OTA защищают свои тарифы, кардинально изменилось за последние 18 месяцев.

Проблема

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

Слои защиты накапливаются. Фингерпринтинг на уровне соединений отсекает клиенты без браузерного профиля до того, как они успевают отправить первый header. JavaScript-челленджи блокируют запросы без возможности исполнения кода. Rate limiting ограничивает любой трафик, похожий на автоматический. Цены также зависят от страны отправки запроса, поэтому для получения реальных цифр требуются proxy в нужных локациях.

Кроме того, многие сайты загружают тарифы динамически. Отображаемой цены нет в исходном HTML-ответе. Она рендерится на стороне клиента после серии вызовов API, передачи session tokens и cookie. Обычный GET-запрос возвращает пустую страницу.

По данным аналитической компании QL2, отслеживание тарифов в промышленных масштабах требует обработки более 600 миллионов точек данных ежедневно (кейс Oxylabs). Это серьезная инженерная задача. Технические требования также постоянно растут. Исследование Vercara 2025 года классифицировало сбор тарифов как отдельную категорию атак, от которой авиакомпании активно защищаются, внедряя ML-системы обнаружения, настроенные специально против автоматических запросов цен.

Что в итоге требуется команде по работе с данными?

Подход FourA

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

FourA решает обе задачи. С помощью unblocker: true сигнатура запроса полностью соответствует сетевому профилю современного браузера, поэтому сайты авиакомпаний видят стандартное браузерное соединение вместо HTTP-библиотеки. Для ресурсов, требующих полноценного выполнения JavaScript (формы поиска рейсов, динамические виджеты цен), наш продукт Browser запускает полноценные экземпляры браузера.

Но пройти первичную защиту, это лишь половина задачи. Сайты бронирования показывают цены в зависимости от локации. Перелет из Лондона в Нью-Йорк имеет разную стоимость для пользователей из Великобритании, Германии или США. Умная маршрутизация proxy автоматически выбирает подходящий тип и геолокацию proxy, отслеживая процент успешных запросов для каждого хоста и определяя оптимальные конфигурации для каждого целевого домена.

Типичная конфигурация мониторинга тарифов через наш API выглядит следующим образом:

curl -X POST https://api.foura.ai/request/proxy \
  -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "method": "GET",
    "url": "https://example-airline.com/api/fares?from=LHR&to=JFK",
    "unblocker": true,
    "followRedirects": 5,
    "validate": {
      "status": {"accept": [200]},
      "data": {"fail": ["blocked", "captcha"]}
    },
    "timeout_ms": 30000
  }'

Флаг unblocker внедряет полный набор браузерных header и соответствующую сигнатуру request. Блок validate указывает API автоматически повторять попытку, если в response возвращается страница с проверкой вместо тарифов. Ротация proxy происходит под капотом.

Валидация response для данных о тарифах важнее, чем кажется. Отклоненный request, который возвращает статус 200 со страницей верификации, выглядит как успешный, пока вы не проверите контент. Правила validate отлавливают такие ложные срабатывания до того, как они испортят ваш датасет.

Для команд, отслеживающих тысячи маршрутов, этот процесс запускается по расписанию. Отправьте request к API, проверьте response, сохраните данные о тарифах. Если request завершился ошибкой, FourA повторяет попытку через другой proxy перед тем, как вернуть ошибку. Панель аналитики показывает процент успешных запросов по доменам в реальном времени, поэтому вы сразу узнаете, когда целевой сайт изменит защиту.

Результаты

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

  • Успешность 93-97% на сайтах крупных авиакомпаний и OTA, включая ресурсы со сложными JS-проверками
  • Медианное время ответа менее 2 секунд для стандартных запросов тарифов, 4-8 секунд для страниц с рендерингом JS
  • Географически точные цены из более чем 50 стран без необходимости управлять списками proxy вручную
  • Снижение затрат на инженерную поддержку на 80% по сравнению с собственной инфраструктурой сбора данных

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

Главный вывод

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

То, для чего раньше требовалась отдельная команда инфраструктуры (управление proxy, фермы браузеров, ротация сигнатур), теперь укладывается в один вызов API. Вопрос для команд данных заключается не в том, автоматизировать ли сбор тарифов. Вопрос в том, продолжать ли строить эту инфраструктуру самостоятельно или передать ее платформе, созданной именно для этой задачи. Если ваша команда тратит больше времени на поддержку скраперов, чем на анализ тарифов, ответ очевиден.

Подробнее о том, как устроена маршрутизация proxy под капотом, читайте в нашем материале Умная маршрутизация proxy. А если вас интересуют глобальные изменения в этой сфере, ознакомьтесь со статьей Состояние сбора веб-данных в 2026 году.