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

Описание

Какую задачу решает

Патент решает проблему поддержания актуальности динамических данных (например, цен и доступности отелей или авиабилетов) в кеше поисковой системы, получаемых от внешних партнерских систем (Partner Systems). Ключевая сложность в том, что многие партнеры требуют активного опроса (Pull-механизм) и устанавливают строгие ограничения на пропускную способность (Bandwidth Constraints), например, лимит запросов в секунду (QPS). Изобретение позволяет интеллектуально выбирать, какие данные запрашивать, чтобы максимизировать актуальность информации для пользователей, не нарушая технических ограничений партнеров.

Что запатентовано

Запатентована система гранулярного планирования запросов к API партнеров. Система рассчитывает Utility Value (Ценность) для каждой потенциальной комбинации объекта и маршрута (Property-Itinerary Combination), например, конкретного отеля на конкретные даты. Эта ценность определяется на основе прогнозируемой частоты обновления информации (Expected Update Frequency) и прогнозируемого спроса пользователей (Expected Impression Weight). Запросы с наибольшей ценностью приоритизируются и выполняются в рамках доступной пропускной способности.

Как это работает

Система работает в несколько этапов:

• Прогноз частоты обновлений (F): Анализируется история изменения данных (например, цен) для конкретной и похожих комбинаций, чтобы предсказать будущую частоту изменений (Expected Update Frequency).
• Прогноз спроса (I): Анализируется история поисковых запросов пользователей (User Impression Histories), чтобы предсказать популярность комбинации (Expected Impression Weight).
• Расчет ценности (Utility Value, U): На основе прогнозов рассчитывается ценность запроса. В патенте (Claim 9) защищена формула: U = I / F.
• Ранжирование и Ограничения: Все потенциальные запросы ранжируются по Utility Value. Устанавливается пороговое значение (Threshold Utility Value) так, чтобы запросы выше порога укладывались в Bandwidth Constraints партнера.
• Выполнение: Запросы выше порога планируются и выполняются, обновляя кеш поисковой системы.

Актуальность для SEO

Высокая для вертикальных поисковых продуктов Google (Hotels, Flights, Events). Эффективное управление сбором данных от тысяч партнеров с ограниченными техническими возможностями API остается критически важной инфраструктурной задачей для поддержания качества и актуальности этих сервисов в 2025 году.

Важность для SEO

Патент имеет минимальное прямое влияние на традиционные SEO-стратегии (Оценка 2/10). Он описывает внутреннюю инфраструктуру вертикального поиска, а не механизмы сканирования или ранжирования общего веб-контента. Он важен для понимания того, как Google взаимодействует с поставщиками данных в этих вертикалях (и почему данные могут устаревать), но не предлагает конкретных действий для оптимизации обычных веб-сайтов.

Детальный разбор

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

Property (Объект)

Единица контента, предоставляемая партнером. Примеры: конкретный отель, авиарейс, билет на концерт.

Itinerary (Маршрут)

Конкретные условия использования объекта. Примеры: даты заезда и выезда в отеле.

Property-Itinerary Combination (Комбинация Объект-Маршрут)

Конкретное предложение. Пример: Бронирование Отеля А с 5 по 10 декабря.

Partner System (Партнерская система)

Внешняя система (например, сайт бронирования, система авиакомпании), которая предоставляет данные поисковой системе по запросу через API (Pull-механизм).

Expected Update Frequency (Ожидаемая частота обновления, F)

Прогноз того, как часто информация (например, цена) будет меняться. Основан на анализе исторических данных (Average Expected Change Rate) для этой и похожих (similar) комбинаций.

User Impression Histories (История показов пользователям)

Логи поисковых запросов, используемые для анализа спроса.

Relative Impression Weight (Относительный вес показа)

Метрика популярности конкретного маршрута (Itinerary) по сравнению с другими маршрутами.

Absolute Impression Weight (Абсолютный вес показа)

Метрика общей популярности объекта (Property) по всем маршрутам (например, запросов в день).

Expected Impression Weight (Ожидаемый вес показа, I)

Прогнозируемое количество запросов для конкретной Property-Itinerary Combination. Вычисляется на основе относительного и абсолютного весов.

Utility Value (Ценность/Полезность, U)

Ключевая метрика для приоритизации запросов. Рассчитывается на основе Expected Impression Weight и Expected Update Frequency.

Bandwidth Constraints (Ограничения пропускной способности)

Технические лимиты на количество запросов, установленные партнерской системой (например, Queries Per Second — QPS).

Threshold Utility Value (Пороговое значение ценности)

Минимальное значение Utility Value, при котором запрос будет запланирован. Устанавливается так, чтобы не превысить Bandwidth Constraints.

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

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

1. Система обрабатывает множество комбинаций Property-Itinerary. Для каждой комбинации выполняется:
• Определение количества исторических изменений для группы похожих комбинаций.
• Расчет Update Frequency (средняя ожидаемая скорость изменения) на основе этих данных.
• Определение Relative Impression Weight маршрута и Absolute Impression Weight объекта на основе User Impression Histories.
• Расчет Expected Impression Weight комбинации.
• Определение использования пропускной способности (Bandwidth Usage) для выполнения запроса.
• Расчет Utility Value на основе Expected Impression Weight и Update Frequency.
2. Комбинации ранжируются для каждого партнера по их Utility Value.
3. Определяется Threshold Utility Value для каждого партнера. Порог устанавливается так, чтобы суммарный объем запросов выше порога не превышал Bandwidth Constraints партнера.
4. Система выполняет запросы (conducts queries) для комбинаций со значением выше установленного порога.

Claim 9 (Зависимый от 1): Уточняет метод расчета Utility Value.

Расчет Utility Value включает деление (dividing) Expected Impression Weight (I) на Update Frequency (F). Формула: U = I / F.

Это ключевой и контринтуитивный момент патента. Поскольку частота обновления (F) находится в знаменателе, увеличение частоты изменений (например, частая смена цен) *снижает* общую ценность (Utility Value) запроса при прочих равных. Система предпочитает тратить ограниченные ресурсы на обновление популярных объектов со стабильными ценами.

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

Изобретение является инфраструктурным механизмом для вертикального поиска (Google Hotels, Google Flights) и не применяется в стандартном веб-поиске.

CRAWLING – Сканирование и Сбор данных (Data Acquisition)
Это основная область применения. Патент описывает механизм планирования сбора данных (Crawl Scheduling) через API (API fetching), а не традиционный веб-краулинг. Он определяет, какие данные запрашивать у партнеров и с какой частотой, оптимизируя использование ресурсов (API Query Budget).

INDEXING – Индексирование и извлечение признаков
Система использует исторические данные (частоту изменений цен, историю показов пользователям), которые хранятся и обрабатываются на этом этапе, для расчета прогнозных метрик (Utility Value). Полученные свежие данные поступают в индекс вертикального поиска.

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

• Список объектов (Properties) и маршрутов (Itineraries).
• Исторические данные об изменениях информации (цены, доступность).
• История пользовательских запросов (User Impression Histories).
• Bandwidth Constraints (лимиты QPS) от партнеров.

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

• Оптимизированное расписание запросов (Query Schedule) для каждого партнера.
• Свежие данные в кеше поисковой системы.

На что влияет

• Конкретные типы контента и Ниши: Влияет исключительно на вертикали, зависящие от получения данных в реальном времени через API. Основные примеры в патенте: Отели (hotel data), Авиабилеты (flight or other transportation data) и Мероприятия (event data).
• Актуальность данных (Freshness): Напрямую влияет на то, насколько актуальными будут цены и информация о доступности в результатах вертикального поиска Google.

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

• Частота применения: Система работает постоянно или с высокой периодичностью для непрерывного управления потоком запросов к API. В патенте упоминаются интервалы пересчета от 30 секунд до часа или дня.
• Условия работы: Необходимость поддержания актуальности кеша данных при наличии ограничений пропускной способности у партнеров, использующих Pull-механизм обновления.

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

Процесс планирования запросов:

1. Сбор исходных данных: Система получает список доступных Property-Itinerary Combinations и актуальные Bandwidth Constraints для каждого партнера.
2. Расчет Expected Update Frequency (F):
• Для каждой комбинации извлекаются исторические данные об изменениях.
• Идентифицируются похожие комбинации (например, той же длительности пребывания).
• Рассчитывается средняя скорость изменений (Average Expected Change Rate) для этой группы. Это значение становится Expected Update Frequency (F).
3. Расчет Expected Impression Weight (I):
• Извлекается история пользовательских запросов.
• Рассчитывается Relative Impression Weight для маршрута (популярность дат).
• Рассчитывается Absolute Impression Weight для объекта (популярность отеля/рейса).
• Вычисляется Expected Impression Weight (I) (обычно путем перемножения относительного и абсолютного весов).
4. Расчет Utility Value (U):
• Для каждой комбинации рассчитывается Utility Value (U). Согласно Claim 9, это U = I / F.
5. Ранжирование и Фильтрация:
• Для каждого партнера комбинации ранжируются по убыванию Utility Value.
• Определяется Threshold Utility Value. Система выбирает порог так, чтобы суммарное потребление пропускной способности запросами выше порога не превышало Bandwidth Constraints.
6. Планирование и Выполнение:
• Запросы для комбинаций выше порога добавляются в расписание (Query Schedule). Запросы могут быть сгруппированы (буферизованы) для эффективности.
• Система выполняет запросы и обновляет кеш полученными данными.

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

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

• Временные факторы (Historical Data): Исторические данные об изменении информации (цены, доступность). Критически важны для прогнозирования Expected Update Frequency. Учитывается дата изменения и дата начала маршрута.
• Поведенческие факторы (User Behavior): Логи поисковых запросов (User Impression Histories). Используются для прогнозирования спроса и расчета Expected Impression Weight.
• Технические факторы (System Constraints): Bandwidth Constraints, предоставленные партнерскими системами (лимиты QPS). Определяют общий объем доступных запросов.

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

• Expected Update Frequency (F): Прогнозная скорость изменения данных. Считается как среднее количество изменений за период времени на основе исторических данных для группы похожих комбинаций.
• Absolute Impression Weight: Популярность объекта. Считается как общее количество показов (запросов) объекта за период времени.
• Relative Impression Weight: Популярность маршрута. Считается как доля показов конкретного маршрута от общего числа показов.
• Expected Impression Weight (I): Прогнозный спрос на комбинацию. $I = \text{Absolute Impression Weight} \times \text{Relative Impression Weight}$
• Utility Value (U): Ценность выполнения запроса. Формула, защищенная в Claim 9: $U = \frac{I}{F}$

Выводы

1. Инфраструктурный фокус, не SEO: Патент описывает внутренние процессы сбора данных для вертикального поиска (Hotels, Flights). Он не имеет прямого отношения к ранжированию в органическом веб-поиске.
2. Оптимизация ресурсов и нагрузки: Основная цель — эффективное использование ограниченной пропускной способности (Bandwidth Constraints) партнерских API для поддержания актуальности кеша Google.
3. Логика приоритизации (Критически важно): Согласно формуле из Claim 9 (Utility Value = Спрос / Частота Обновлений), система приоритизирует запросы контринтуитивно. Высокая частота обновлений (F) снижает Utility Value (U) при прочих равных. Это означает, что Google предпочтет обновить данные для очень популярного предложения со стабильной ценой, чем для популярного предложения с часто меняющейся ценой.
4. Прогнозирование на основе истории: Система полагается на анализ исторических данных для прогнозирования как поведения пользователей (спроса), так и поведения партнеров (частоты изменения цен), используя данные похожих маршрутов (Similar Itineraries) для повышения точности.
5. Влияние популярности: Спрос (Expected Impression Weight) является ключевым фактором (числитель). Предложения с низким спросом с меньшей вероятностью будут часто обновляться, что объясняет, почему данные по нишевым запросам в вертикальном поиске часто устаревают.

Практика

ВАЖНО: Патент является инфраструктурным и не дает практических выводов для традиционного SEO. Следующие пункты применимы ТОЛЬКО для компаний (OTA, авиакомпании, сети отелей), которые передают данные в Google через API (используя Pull-механизм) для участия в вертикальном поиске.

Best practices (Для поставщиков данных)

• Оптимизация частоты обновления цен (с учетом U=I/F): Поскольку слишком частые изменения цен (высокая Update Frequency, F) математически *понижают* Utility Value согласно формуле из патента, это может уменьшить частоту запросов от Google. Поставщикам следует избегать избыточных технических обновлений, если фактическая цена не изменилась, чтобы не создавать «шум» в данных.
• Стимулирование спроса: Увеличение популярности объекта (повышение Impression Weight, I) напрямую повышает Utility Value. Маркетинговые активности, увеличивающие спрос на платформе Google, приведут к более частому обновлению данных.
• Обеспечение достаточной пропускной способности API: Убедитесь, что ваши Bandwidth Constraints (лимиты QPS) достаточны для обработки запросов Google. Более широкий канал позволит Google снизить Threshold Utility Value и чаще обновлять данные, включая менее приоритетные предложения.
• Эффективная обработка групповых запросов: Патент упоминает буферизацию и группировку запросов. Убедитесь, что ваш API эффективно обрабатывает групповые запросы (например, запрос цен для нескольких отелей на одну дату) для максимизации эффективности обмена данными.

Worst practices (Для поставщиков данных)

• «Шумное» или чрезмерно волатильное ценообразование: Постоянное изменение цен на минимальные суммы может создать искусственно высокую Update Frequency (F). Согласно формуле U=I/F, это снизит Utility Value и ухудшит актуальность ваших данных в кеше Google по сравнению с более стабильными конкурентами.
• Установление слишком низких лимитов QPS: Жесткие Bandwidth Constraints вынудят Google установить высокий Threshold Utility Value, что приведет к устареванию данных по большинству ваших предложений.

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

Патент демонстрирует техническую сложность поддержания актуальности данных в реальном времени. Он подтверждает, что Google использует сложные data-driven модели для управления сбором данных, рассматривая его как задачу оптимизации ресурсов (API Query Budget). Ключевое стратегическое значение для партнеров заключается в понимании формулы U=I/F: Google предпочитает тратить ограниченные ресурсы на обновление популярных и относительно стабильных предложений.

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

Сценарий: Влияние частоты изменения цен на приоритет обновления (на основе формулы U=I/F)

Партнерская система имеет ограничение пропускной способности. Google рассчитывает Utility Value для двух отелей.

Отель А (Популярный, Стабильные цены):

• Expected Impression Weight (I): 1000 запросов/день.
• Expected Update Frequency (F): 0.2 изменений/день (цены меняются раз в 5 дней).
• Utility Value (U=I/F): 1000 / 0.2 = 5000.

Отель Б (Популярный, Волатильные цены):

• Expected Impression Weight (I): 1000 запросов/день.
• Expected Update Frequency (F): 5.0 изменений/день (цены меняются 5 раз в день).
• Utility Value (U=I/F): 1000 / 5.0 = 200.

Результат: Несмотря на одинаковую популярность, Utility Value Отеля А (5000) значительно выше, чем у Отеля Б (200). Google запланирует обновление данных для Отеля А в первую очередь. Отель Б рискует отображаться с устаревшей ценой, если не хватит пропускной способности.

Вопросы и ответы