Как Google рассчитывает точные цены на авиабилеты для разных продавцов в рамках одного запроса (Google Flights)

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

Booking Partner (Партнер по бронированию)

Сущность, продающая билет, например, веб-сайт авиакомпании или онлайн-турагентство (OTA).

Booking Partner Specification (Спецификация партнера по бронированию)

Набор данных и правил, определяющих партнера. Включает Point-of-Sale (POS), коды агентств (travel agency code), авиакомпанию-продавца (sales carrier), режим совместимости налогов (tax compatibility mode), ограничения на маршруты и другие конфигурационные параметры.

Computation Record (Запись о вычислении)

Механизм для отслеживания того, что определенное вычисление (например, расчет налога) обращалось к данным, специфичным для партнера (например, к POS).

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

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

Point-of-Sale (POS) (Точка продажи)

Часть спецификации партнера, включающая место продажи и оформления билета (город/страна), коды счетов, авиакомпанию-продавца и т.д. Правила тарифов часто зависят от POS.

Priceable Unit (Ценовая единица)

Группа тарифов, которые могут быть проданы вместе как один билет (например, комбинация тарифа туда и тарифа обратно).

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

Система (например, Google Flights или backend OTA), которая обрабатывает запросы на поиск путешествий и рассчитывает цены.

Unified Booking Partner Specification (Унифицированная спецификация партнера)

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

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

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

1. Получение запроса на путешествие.
2. Извлечение нескольких booking partner specifications, связанных с запросом.
3. Извлечение других применимых данных (рейсы, тарифы, правила).
4. Создание computation record для каждого вычисления, которое определено как требующее данных из конкретной спецификации партнера.
5. Для каждой записи о вычислении: повторение связанного вычисления для аналогичных данных из спецификаций других применимых партнеров с целью генерации тарифов.
6. Пометка (тегирование) каждого сгенерированного тарифа данными, к которым был получен доступ и для которых он действителен (создание tagged generated fares).
7. Возврат помеченных тарифов для использования при генерации итогового ценового решения в ответ на запрос.

Claim 3 (Зависимый): Уточняет, что данные спецификации партнера, к которым обращается система, могут быть основаны на правилах категорий ATPCO (Airline Tariff Publishing Company – стандарт публикации тарифов). Это важно для корректной проверки доступности тарифа или расчета сборов/налогов, которые зависят от партнера.

Claim 6 (Зависимый): Уточняет, что помеченные сгенерированные тарифы используются для создания priceable units (комбинаций тарифов, формирующих билет).

Claim 7 (Зависимый): Уточняет, что метод также применяется для расчета налогов и других сборов, налагаемых перевозчиком, с использованием необходимых данных из спецификаций применимых партнеров.

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

Этот патент описывает внутреннюю инфраструктуру Travel Planning System (TPS), такую как Google Flights, а не основную поисковую систему Google Web Search.

В контексте архитектуры поиска, применение происходит на этапе, который можно условно соотнести с RANKING (Ранжирование / Расчет цен) в рамках вертикали Travel.

• Компоненты системы: Алгоритм выполняется в Travel Planning Engine (TPE) и взаимодействует с базами данных, хранящими данные авиаперевозчиков (Air-Carrier Data), рейсов (Flight Data), тарифов (Fare Data) и правил (Rule).
• Входные данные:
  • Запрос пользователя на путешествие.
  • Список применимых Booking Partner Specifications (включая POS, коды агентств и т.д.).
  • Данные о рейсах, базовых тарифах и правилах их применения (например, правила ATPCO).
• Выходные данные: Набор Tagged Generated Fares — тарифы, аннотированные списком партнеров (POS), для которых они валидны, и точной ценой (включая налоги и сборы) для каждого из этих партнеров.

На что влияет

Патент влияет исключительно на точность, полноту и эффективность результатов в системах поиска авиабилетов и путешествий.

• Конкретные типы контента: Авиабилеты. В патенте также упоминается возможность применения к другим формам планирования путешествий, таким как автомобили, поезда, водный транспорт и бронирование отелей.
• Конкретные ниши или тематики: Travel, E-commerce (продажа билетов и бронирование).

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

• Условия работы алгоритма: Применяется, когда система метапоиска (TPS) должна предоставить цены от нескольких разных продавцов (партнеров) в ответ на один запрос пользователя.
• Триггеры активации: Механизм активируется в тот момент, когда алгоритм расчета цены или проверки доступности тарифа должен обратиться к данным, специфичным для партнера. Например, когда нужно проверить страну продажи (POS) для расчета применимого налога или применения специфического сбора.

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

1. Получение запроса: Система получает запрос на путешествие (например, Бостон-Лондон-Бостон).
2. Идентификация партнеров: Определяется список релевантных партнеров и извлекаются их спецификации. (Пример: POS#1: продавец AA, страна США; POS#2: продавец BA, страна Великобритания).
3. Извлечение базовых данных: Извлекаются данные о доступных рейсах и базовых тарифах, применимых к этим рейсам.
4. Отслеживание вычислений (Computation Tracking): Система начинает обработку тарифов и правил. Когда вычисление (например, проверка правила «сбор $150, если продано за пределами США») обращается к данным партнера (страна в POS), создается computation record.
5. Селективное повторение (Selective Recomputation): Вычисление, которое зависело от данных партнера, повторяется для спецификаций других партнеров.
6. Генерация тарифов (GF Generation): Создаются объекты Generated Fare. Если базовый тариф H1 стоит $600, то для POS#1 (США) создается GF за $600, а для POS#2 (Великобритания) создается GF за $750 (с учетом сбора $150).
7. Тегирование (Tagging): Каждый GF помечается списком партнеров (POS), для которых он действителен. (GF#1 $600 для POS#1; GF#2 $750 для POS#2).
8. Расчет налогов (Опционально): Аналогичный процесс селективного повторения и тегирования применяется для расчета налогов и сборов, зависящих от POS.
9. Формирование ценовых единиц (Priceable Unit Construction): Система комбинирует тарифы (например, туда и обратно) для формирования полного билета (Priceable Unit). Ключевое условие: комбинируемые тарифы должны иметь хотя бы одного общего партнера (общий POS). Например, GF, валидный только для AA, нельзя скомбинировать с GF, валидным только для BA.
10. Возврат решения: Система возвращает итоговые ценовые решения с указанием точных цен для каждого партнера.

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

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

Патент фокусируется на инфраструктуре расчета цен в Travel-вертикали и не описывает факторы ранжирования, используемые в веб-поиске.

• Данные о партнерах (Partner Data): Booking Partner Specifications. Это критически важные данные, включающие: Point-of-Sale (POS) (место продажи, страна), коды агентств (travel agency code), авиакомпания-продавец (sales carrier), режим совместимости налогов (tax compatibility mode).
• Данные о тарифах и правилах (Fare and Rule Data): Fare Data, Rule. Правила, определяющие условия применения тарифа, которые часто зависят от POS. В патенте упоминаются правила ATPCO, например, Category 15 («безопасность») и Category 12 («сборы»).
• Данные о рейсах (Flight Data): Flight Data, Air-Carrier Data. Информация о расписании и перевозчиках.

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

Система не использует метрики ранжирования в традиционном понимании SEO (такие как релевантность или авторитетность). Она использует логические проверки и арифметические вычисления для определения валидности и стоимости тарифа.

• Валидность тарифа (Fare Validity): Определяется путем проверки соответствия правил тарифа (Rule) данным в спецификации партнера (Booking Partner Specification).
• Стоимость тарифа (Fare Cost): Рассчитывается на основе базовой цены плюс применимые налоги и сборы. Механизм селективного повторения используется для эффективного расчета этих налогов и сборов, которые могут варьироваться в зависимости от партнера (POS).

Патент описывает внутренние процессы системы планирования путешествий (например, Google Flights) и не содержит прямых рекомендаций для SEO в основном поиске Google.

1. Эффективность через селективность: Ключевое изобретение — это способность обрабатывать множество вариаций цен в одном запросе. Вместо повторения всего запроса для каждого партнера, система повторяет только те вычисления, которые зависят от спецификаций партнера (например, расчет налога, зависящего от страны продажи).
2. Точность превыше унификации: Система разработана для устранения ошибок ценообразования, которые возникали при попытке объединить правила всех партнеров в один запрос (Unified Booking Partner Specification). Это гарантирует, что пользователь видит точную цену и налоги для конкретного продавца.
3. Тегирование результатов как основа системы: Механизм пометки сгенерированных тарифов (Generated Fares) информацией о том, для каких партнеров (POS) они действительны, является основой для последующего корректного формирования билетов (Priceable Units).
4. Фокус на вертикальном поиске: Этот патент демонстрирует сложность и специфику инфраструктуры, необходимой для работы вертикальных поисковых систем (в данном случае — метапоиска авиабилетов), которая фундаментально отличается от инфраструктуры общего веб-поиска.

Патент является инфраструктурным для вертикали Travel и не дает практических выводов для SEO-специалистов, занимающихся продвижением сайтов в основном органическом поиске Google.

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

Информация в патенте не применима к стандартным практикам SEO.

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

Информация в патенте не позволяет выделить неэффективные или опасные SEO-тактики.

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

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

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

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