Как Google оптимизирует Google Flights, рассчитывая цены для разного числа пассажиров за один запрос

Термины и определения

Availability Line (Строка доступности)

Ответ от сервера доступности рейсов на запрос о последовательности перелетов. Показывает количество доступных мест для каждого кода бронирования (например, K3 означает 3 места в классе K) и может содержать условия (например, требование использовать одинаковый код бронирования на всех сегментах).

Booking Code (Код бронирования)

Буквенный код (например, Y, K, L), используемый авиакомпаниями для идентификации класса тарифа и определения правил и стоимости билета.

Diversity Strategy (Стратегия разнообразия)

Набор условий (bins), определяющих подмножество возможных поездок с указанием желаемого количества решений для каждого условия (например, «показать 5 решений для рейсов авиакомпании X с вылетом утром»). Используется для обеспечения разнообразия выдачи.

Generated Fare (GF) (Сгенерированный тариф)

Внутренняя структура данных, создаваемая TPS для представления тарифа. Содержит информацию об условиях применения тарифа.

GF Clone («Клон» GF)

Копия оригинального GF, созданная для обозначения другого максимального количества пассажиров, для которого этот тариф действителен.

Pricing Graph (Граф ценообразования)

Компактная структура данных, используемая TPS для эффективного представления набора возможных ценовых решений (Pricing Solutions).

Pricing Solution (Ценовое решение)

Конечный результат, включающий маршрут (Itinerary) и набор тарифов (Fares), покрывающих перелеты в этом маршруте.

Travel Planning System (TPS) (Система планирования путешествий)

Специализированная поисковая система для поиска и бронирования путешествий, например, Google Flights.

Ключевые утверждения (Анализ Claims)

Claim 1 (Независимый пункт): Описывает основной метод обработки запроса о путешествии для поддержки нескольких вариантов количества пассажиров.

1. Система получает поисковый запрос о путешествии.
2. Извлекаются применимые данные и генерируется множество маршрутов (itineraries).
3. Для каждого маршрута генерируются Availability Lines, указывающие количество доступных мест для различных Booking Codes и условия бронирования.
4. На основе этих данных создается множество Generated Fares (GFs).
5. Система конструирует комбинации GF.
6. Из этих комбинаций генерируются возможные Pricing Solutions.
7. Сгенерированные ценовые решения сохраняются в Pricing Graph.

Claim 4 (Зависимый от 1): Детализирует ключевой шаг оптимизации.

Система вычисляет максимальное количество пассажиров (maximum passenger count), для которого конкретный GF может быть доступен в контексте определенной комбинации рейса и строки доступности. Это является основой для механизма клонирования GF, описанного в спецификации.

Claim 10 (Зависимый от 1): Описывает механизм итеративного извлечения результатов для разного числа пассажиров (K).

Система сканирует Pricing Graph и отключает (disabling) все GFs, которые действительны для менее чем указанного числа пассажиров K. Это ключевой шаг в алгоритме перечисления, позволяющий эффективно фильтровать граф.

Claim 11 и 12 (Зависимые от 10): Детализируют процесс обеспечения разнообразия результатов при итерации.

Для каждого условия разнообразия (diversity condition) система определяет, все ли решения, действительные для K-1 пассажиров, также действительны для K пассажиров. Если нет (т.е. если требования разнообразия не удовлетворены), система перечисляет новые действительные ценовые решения, используя оставшуюся (неотключенную) часть Pricing Graph.

Где и как применяется

Патент описывает инфраструктуру специализированной вертикальной поисковой системы — Travel Planning System (например, Google Flights). Он не относится к архитектуре основного веб-поиска Google.

В контексте архитектуры специализированной TPS, изобретение применяется на следующих этапах:

RANKING (Ранжирование / Расчет цен внутри вертикали)
Основное применение патента. На этом этапе система рассчитывает стоимость маршрутов для разного числа пассажиров. Ключевые процессы: генерация GFs, клонирование GFs на основе максимальной вместимости и построение Pricing Graph. Это оптимизация, позволяющая провести расчеты для N пассажиров за один проход.

RERANKING (Переранжирование / Диверсификация внутри вертикали)
На этапе финального формирования выдачи система использует Pricing Graph для быстрого извлечения лучших решений для конкретного числа пассажиров K. Здесь применяются Diversity Strategies. Механизм итеративного отключения GFs (Claim 10) позволяет быстро переранжировать результаты при изменении K.

Входные данные:

• Поисковый запрос о путешествии (пункты назначения, даты).
• Структурированные данные: Air-Carrier Data, Flight Data (расписание), Fare Data (тарифы и правила).
• Данные о доступности мест (Availability Lines) и Booking Codes.

Выходные данные:

• Pricing Graph, содержащий все возможные Pricing Solutions с указанием максимального количества пассажиров для каждого решения.
• Набор перечисленных Pricing Solutions, удовлетворяющих Diversity Strategy для заданного диапазона пассажиров (1..N).

На что влияет

• Конкретные типы контента: Влияет исключительно на результаты поиска авиабилетов в специализированных системах (Google Flights). Не влияет на веб-страницы, статьи, товары в органическом поиске.
• Специфические запросы: Влияет на транзакционные запросы, связанные с покупкой авиабилетов.
• Конкретные ниши: Авиаперевозки и онлайн-бронирование. В патенте также упоминается потенциальное применение к поездам, автомобилям и бронированию жилья.

Когда применяется

• Условия работы алгоритма: Применяется при обработке запросов в TPS, когда система настроена на расчет цен для диапазона количества пассажиров (от 1 до N) в рамках одного запроса.
• Триггеры активации: Запрос пользователя на поиск авиабилетов. В патенте упоминается, что этот режим часто активируется для запросов на 1 пассажира, чтобы проактивно рассчитать цены для большего числа людей (например, для кэширования).
• Ограничения: Алгоритм предполагает, что все пассажиры в одном бронировании должны использовать один и тот же Booking Code на каждом сегменте перелета.

Пошаговый алгоритм

Процесс А: Построение Pricing Graph (Обработка запроса)

1. Получение запроса и данных: Система получает запрос и извлекает применимые данные (рейсы, тарифы, правила).
2. Генерация маршрутов: Генерируются возможные маршруты (itineraries).
3. Получение доступности: Для маршрутов запрашиваются Availability Lines (количество мест по кодам бронирования).
4. Конструирование оригинальных GFs: Создаются исходные объекты Generated Fares.
5. Вычисление максимальной вместимости (Ключевой шаг): Для каждого GF вычисляются все возможные максимальные количества пассажиров на основе минимального наличия мест в соответствующем Booking Code по всем сегментам маршрута.
6. Клонирование GFs (Ключевой шаг): Для каждого уникального максимума (кроме самого большого) создается «клон» GF, помеченный этим пределом. Оригинальный GF помечается самым большим возможным максимумом.
7. Конструирование комбинаций GF: Оригинальные и клонированные GFs комбинируются для покрытия полных маршрутов и формирования Pricing Solutions.
8. Сохранение в Pricing Graph: Все ценовые решения эффективно сохраняются в Pricing Graph.

Процесс Б: Перечисление и Диверсификация (Вывод результатов)

Этот процесс выполняется итеративно для K от 1 до N (максимальное количество пассажиров).

1. Инициализация (K=1): Перечисляются действительные ценовые решения для 1 пассажира для удовлетворения Diversity Strategy.
2. Итерация (для K от 2 до N):
   1. Фильтрация графа (Ключевой шаг): Сканируется Pricing Graph, и отключаются (disable) все GFs, которые действительны для менее чем K пассажиров.
   2. Проверка разнообразия: Для каждого условия Diversity Strategy проверяется, действительны ли решения, найденные для K-1 пассажиров, также и для K пассажиров (т.е. не были ли они отключены на шаге 2.1).
   3. Обработка условий:
      • Если ДА: Условие маркируется как выполненное для K. Диапазон пассажиров для этих решений расширяется.
      • Если НЕТ: Система перечисляет новые действительные решения из оставшейся части Pricing Graph для неудовлетворенных условий разнообразия.
3. Завершение: После достижения K=N процесс останавливается.

Какие данные и как использует

Данные на входе

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

• Данные о рейсах (Flight Data): Расписание, номера рейсов, пункты отправления и назначения.
• Данные о тарифах (Fare Data): Стоимость тарифов и условия их применения (правила).
• Данные авиаперевозчиков (Air-Carrier Data).
• Данные о доступности (Availability Data): Критически важные данные, получаемые через Availability Lines. Включают Booking Codes и количество доступных мест для каждого кода на каждом рейсе.

Какие метрики используются и как они считаются

• Maximum Passenger Count (Максимальное количество пассажиров для GF): Вычисляется для каждого GF путем анализа Availability Lines. Это минимальное количество доступных мест в соответствующем Booking Code на всех сегментах маршрута, покрываемого этим GF.
• K (Текущее количество пассажиров): Переменная, используемая в итеративном процессе перечисления результатов (от 1 до N).
• Стоимость (Price): Основная метрика для ранжирования Pricing Solutions.
• Удовлетворение Diversity Conditions: Метрики, определяющие, соответствует ли набор результатов требованиям Diversity Strategy.

Патент описывает внутренние процессы Google, специфичные для вертикали Google Flights, без прямых рекомендаций для SEO.

1. Фокус на вычислительной эффективности: Основная цель изобретения — оптимизация производительности Travel Planning System. Система минимизирует вычислительные затраты, рассчитывая цены для разного числа пассажиров за один запрос, а не запуская множество отдельных запросов.
2. Ключевой механизм — GF Cloning: Инновация заключается в создании «клонов» тарифов (Generated Fares) с разными ограничениями по количеству мест. Это позволяет обрабатывать ограничения доступности на ранних этапах.
3. Эффективное хранение и извлечение данных: Использование Pricing Graph в сочетании с итеративным процессом (от K=1 до N), где недействительные тарифы последовательно отключаются, обеспечивает быстрое формирование выдачи для любого K без повторного выполнения поиска.
4. Специализация вертикального поиска: Патент демонстрирует сложность инфраструктуры вертикальных сервисов Google. Алгоритмы Google Flights функционируют независимо от основного веб-поиска и используют совершенно другие наборы данных.
5. Отсутствие связи с общим SEO: Патент не содержит информации о стандартных механизмах ранжирования Google (релевантность, качество контента, ссылки, E-E-A-T). Он полностью сосредоточен на логике авиационного ценообразования и оптимизации баз данных.

ВАЖНО: Патент является инфраструктурным и специфичным для продукта Google Flights. Он не дает практических выводов для SEO-специалистов, работающих над продвижением сайтов в основном веб-поиске Google.

Best practices (это мы делаем)

Для SEO-специалистов, работающих в общем веб-поиске, прямых рекомендаций на основе этого патента нет.

Worst practices (это делать не надо)

Патент не описывает SEO-тактики или манипуляции, против которых он мог бы быть направлен.

Стратегическое значение

Стратегическое значение для SEO минимально. Патент иллюстрирует инженерный подход Google к оптимизации производительности и улучшению пользовательского опыта в специализированных поисковых продуктах. Это подтверждает, что вертикальные сервисы работают на основе собственных алгоритмов, отличных от основного веб-индекса. SEO-стратегия для органического поиска не влияет на работу алгоритмов, описанных в этом патенте.

Практические примеры

Практических примеров применения данного патента в работе SEO-специалиста нет, так как он описывает внутреннюю логику расчета цен на авиабилеты в Google Flights.