Патент описывает инфраструктурный механизм Google для планирования запросов к партнерским системам (например, сайтам бронирования). Система рассчитывает «Ценность» (Utility Value) для каждого запроса на основе его популярности у пользователей и частоты обновления данных. Это позволяет Google запрашивать самые важные данные, не перегружая каналы партнеров.

Описание

Какую проблему решает

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

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

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

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

Система приоритизирует запросы к партнерам следующим образом:

  • Анализ истории изменений: Оценивается, как часто менялась информация (например, цена) для конкретной или похожей комбинации в прошлом (Expected Update Frequency).
  • Анализ популярности: Оценивается, как часто пользователи искали эту информацию на основе истории показов (Expected Impression Weight).
  • Расчет Ценности (Utility Value): Вычисляется показатель ценности для каждого потенциального запроса. В патенте описан расчет как деление популярности на частоту обновлений.
  • Ранжирование и Планирование: Все возможные запросы ранжируются по Utility Value. Система планирует выполнение только запросов с наивысшей ценностью, которые помещаются в установленные партнером лимиты (Bandwidth Constraints), определяя порог (Threshold Utility Value).

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

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

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

Минимальное влияние (1/10). Патент чисто технический и описывает внутренние процессы Google без прямых рекомендаций для SEO. Он касается исключительно управления сбором данных через API в вертикальных сервисах и не имеет отношения к алгоритмам ранжирования органического веб-поиска, краулинговому бюджету сайтов или факторам E-E-A-T.

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

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

Property (Объект)
Сущность, о которой запрашивается информация. Примеры: конкретный отель, авиарейс, аренда жилья, мероприятие.
Itinerary (Маршрут/План)
Конкретные условия или временные рамки использования объекта. Примеры: даты проживания в отеле (старт и окончание) или продолжительность пребывания.
Property-Itinerary Combination (Комбинация Объект-Маршрут)
Конкретное сочетание объекта и маршрута (например, Отель «А» на даты с 5 по 10 января).
Partner System (Партнерская система)
Внешняя система (например, сайт бронирования, авиакомпания), которая владеет данными и отвечает на запросы поисковой системы.
Historical Information Data (Исторические данные)
Записи о прошлых изменениях информации (например, история изменения цен) для комбинаций.
User Impression Histories (История показов пользователям)
Данные о том, как часто и когда пользователи запрашивали у поисковой системы информацию о конкретных комбинациях.
Expected Update Frequency (Ожидаемая частота обновления)
Прогноз того, как часто информация будет меняться. Рассчитывается как средняя ожидаемая скорость изменения (average expected change rate) на основе исторических данных группы похожих комбинаций.
Absolute Impression Weight (Абсолютный вес показов)
Метрика общей популярности объекта (Property). Рассчитывается как общее количество запросов пользователей к объекту в единицу времени (например, в день).
Relative Impression Weight (Относительный вес показов)
Метрика популярности конкретного маршрута (Itinerary) относительно всех других маршрутов (доля от общего числа запросов).
Expected Impression Weight (Ожидаемый вес показов)
Прогноз популярности конкретной комбинации Property-Itinerary. Рассчитывается путем умножения Relative Impression Weight маршрута на Absolute Impression Weight объекта.
Utility Value (Ценность/Полезность)
Итоговая метрика, используемая для ранжирования и выбора запросов. Основана на Expected Update Frequency и Expected Impression Weight.
Bandwidth Constraints (Ограничения пропускной способности)
Лимиты на количество запросов в единицу времени, установленные партнерской системой.
Threshold Utility Value (Пороговое значение ценности)
Минимальное значение Utility Value, используемое для отбора запросов. Устанавливается так, чтобы не превысить Bandwidth Constraints.

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

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

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

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

Utility Value рассчитывается путем деления Expected Impression Weight на Update Frequency.

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

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

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

CRAWLING – Сканирование и Сбор данных (Data Acquisition)
Это основной этап применения патента. Он описывает не стандартное сканирование веб-страниц (краулинг), а механизм управления и планирования запросов (часто через API) к партнерским системам для получения структурированных данных. Цель — оптимизация использования ограниченной пропускной способности.

Взаимодействие компонентов:

  • Компонент планирования запросов (Query Scheduling Component) анализирует исторические данные об изменениях и историю запросов пользователей.
  • На основе этого анализа и Bandwidth Constraints генерируется расписание.
  • Компонент выполнения запросов (Query Component) отправляет запросы во внешние партнерские системы (Partner Systems).

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

  • Текущий список Property-Itinerary Combinations.
  • Historical Information Data (история изменений).
  • User Impression Histories (история популярности запросов).
  • Bandwidth Constraints (ограничения от партнеров).

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

  • Приоритизированное расписание запросов (Query Schedule).
  • Обновленные данные (цены, доступность) в кэше поисковой системы.

На что влияет

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

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

  • Частота применения: Алгоритм применяется непрерывно или с высокой периодичностью (в патенте упоминаются интервалы в 30 секунд, 5 минут, час, день) для динамической генерации и корректировки расписания запросов к партнерам.
  • Условия работы: Применяется, когда поисковая система зависит от получения данных от партнеров, которые ограничивают пропускную способность своих каналов (API).

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

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

  1. Сбор исходных данных: Система получает текущий список всех известных Property-Itinerary Combinations, связанных с партнерскими системами.
  2. Расчет частоты обновления (Expected Update Frequency):
    1. Для каждой комбинации система анализирует исторические данные похожих комбинаций (например, маршруты той же длительности или с той же датой начала для этого же отеля).
    2. Вычисляется средняя скорость изменения данных (например, Average Daily Change Rate), которая принимается за Expected Update Frequency.
  3. Расчет популярности (Expected Impression Weight):
    1. Система анализирует историю запросов пользователей (User Impressions).
    2. Вычисляется Relative Impression Weight (относительная популярность маршрута) и Absolute Impression Weight (абсолютная популярность объекта).
    3. Рассчитывается Expected Impression Weight для комбинации путем их перемножения.
  4. Расчет Ценности (Utility Value): Для каждой комбинации вычисляется Utility Value. Согласно патенту (Claim 9), это результат деления Expected Impression Weight на Expected Update Frequency.
  5. Определение ограничений: Система определяет текущие Bandwidth Constraints для каждой партнерской системы.
  6. Ранжирование: Комбинации ранжируются на основе их Utility Value (отдельно для каждого партнера).
  7. Определение порога: Система определяет Threshold Utility Value. Порог выбирается так, чтобы суммарное количество запросов для комбинаций выше порога не превышало Bandwidth Constraints (например, использовало 99.5% доступной полосы).
  8. Планирование и Выполнение: Запросы для комбинаций с Utility Value выше порога добавляются в расписание и выполняются. Запросы могут буферизироваться или распределяться по времени для соблюдения лимитов (например, запросов в секунду).

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

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

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

  • Временные факторы: Критически важны. Используются Historical Information Data: даты изменения информации (например, цен), даты начала и окончания маршрутов. Это позволяет рассчитать скорость изменений и прогнозировать обновления.
  • Поведенческие факторы: Используется история запросов пользователей (User Impression Histories) – когда, как часто и какие комбинации запрашивались пользователями. Это используется для оценки популярности.
  • Технические факторы (Системные): Bandwidth Constraints – технические ограничения пропускной способности, предоставляемые партнерами.

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

  • Update Frequency (Expected Update Frequency): Средняя ожидаемая частота изменений (например, изменений в день). Рассчитывается путем усреднения количества изменений за период для группы похожих комбинаций.
  • Relative Impression Weight: Доля популярности маршрута. Формула: (Кол-во запросов по маршруту) / (Общее кол-во запросов ко всем маршрутам).
  • Absolute Impression Weight: Общая популярность объекта в единицу времени. Формула: (Общее кол-во запросов к объекту) / (Период времени).
  • Expected Impression Weight: Прогноз популярности комбинации. Формула: (Relative Impression Weight маршрута) * (Absolute Impression Weight объекта).
  • Utility Value: Итоговая ценность запроса. Формула, явно указанная в патенте (Claim 9 и описание):

Выводы

  1. Патент чисто технический и инфраструктурный. Он описывает внутренние процессы Google по оптимизации сбора данных через API для вертикального поиска (Google Hotels, Flights). Он не содержит прямых рекомендаций для органического SEO.
  2. Отсутствие влияния на органический поиск. Этот патент не имеет практического значения для SEO-специалистов, занимающихся продвижением сайтов в органическом поиске. Он не связан с ранжированием веб-страниц, факторами E-E-A-T или краулинговым бюджетом.
  3. Приоритизация на основе Utility Value. Система интеллектуально выбирает, какие данные запрашивать, используя метрику Utility Value, которая балансирует популярность информации (Impression Weight) и частоту её изменения (Update Frequency).
  4. Специфика расчета Utility Value и оптимизация ресурсов. Согласно формуле, явно описанной в патенте (Ценность = Популярность / Частота Обновления), система отдает предпочтение популярным запросам, данные по которым меняются реже. Это оптимизирует эффективность использования ограниченного канала связи и кэширования, так как данные дольше остаются валидными.
  5. Использование поведенческих данных для сбора информации. Патент подтверждает, что Google активно использует историю запросов пользователей (популярность) для управления своими внутренними инфраструктурными процессами сбора данных.

Практика

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

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

Не применимо к органическому SEO.

Контекст для партнеров (не SEO): Для компаний, предоставляющих данные в Google (например, через Google Hotels), патент подчеркивает важность наличия стабильных API. Если пропускная способность (Bandwidth Constraints) низкая, Google будет вынужден выборочно запрашивать данные, отдавая приоритет наиболее популярным и реже меняющимся вариантам согласно расчету Utility Value.

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

Не применимо к органическому SEO. Патент не направлен против каких-либо SEO-тактик.

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

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

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

Практических примеров для SEO нет.

Пример работы инфраструктуры Google (Иллюстрация расчета Utility Value):

Сценарий: Google планирует запросы к API сайта бронирования (Партнер).

  1. Анализ вариантов:
    • Вариант А (Популярный отель, ближайшие выходные): Популярность (Impression Weight) = 1000 запросов/день. Частота обновления (Update Frequency) = 0.5 изменений/день (меняется раз в 2 дня).
    • Вариант Б (Менее популярный отель, через месяц): Популярность = 500 запросов/день. Частота обновления = 0.1 изменений/день (меняется раз в 10 дней).
  2. Расчет Utility Value (Популярность / Частота):
    • Utility А = 1000 / 0.5 = 2000.
    • Utility Б = 500 / 0.1 = 5000.
  3. Приоритизация: Вариант Б имеет более высокую ценность (Utility Value), так как он достаточно популярен, но его данные меняются реже, что делает его более эффективным для кэширования и экономии пропускной способности.
  4. Результат: Если у партнера есть ограничение пропускной способности, и нужно выбрать только один запрос, Google запросит данные по Варианту Б.

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

Влияет ли этот патент на ранжирование моего сайта в органической выдаче Google?

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

Относится ли описанный механизм к краулинговому бюджету (Crawl Budget) моего сайта?

Нет. Патент описывает управление «бюджетом запросов» к API партнеров (Bandwidth Constraints). Это технически отличается от того, как часто Googlebot сканирует страницы вашего веб-сайта (краулинговый бюджет для веб-сканирования).

Что в контексте патента означают термины «Property» и «Itinerary»?

Property (Объект) — это конкретная сущность, например, отель, авиарейс или концертный зал. Itinerary (Маршрут) — это конкретные условия использования этого объекта, чаще всего временные рамки, например, даты проживания в отеле или дата вылета рейса. Вместе они образуют Property-Itinerary Combination.

Что такое «Utility Value» и как она рассчитывается?

Utility Value (Ценность) — это метрика для определения важности выполнения конкретного запроса данных. Согласно Формуле изобретения (Claim 9), она рассчитывается путем деления ожидаемой популярности (Expected Impression Weight) на ожидаемую частоту обновления (Expected Update Frequency).

Если Utility Value считается как Популярность / Частота Обновления, не значит ли это, что Google предпочитает устаревшие данные?

Согласно этой формуле, система действительно отдает приоритет популярным данным, которые меняются реже (имеют низкую Update Frequency). Это может показаться нелогичным с точки зрения обеспечения максимальной свежести, но это оптимально с точки зрения эффективности использования ограниченного канала связи. Получив данные, которые редко меняются, система может дольше хранить их в кэше, экономя ресурсы на повторные запросы.

Как система определяет, что информация скоро изменится (Expected Update Frequency)?

Система анализирует исторические данные (Historical Information Data) о том, как часто менялась информация для похожих комбинаций в прошлом. Например, если цены на 5-дневное пребывание в определенном отеле исторически менялись в среднем раз в 10 дней, система будет использовать эту частоту для прогнозирования.

Как система определяет популярность элемента (Impression Weight)?

Популярность определяется на основе истории показов пользователям (User Impression Histories). Система рассчитывает популярность объекта в целом (Absolute Impression Weight) и популярность конкретного маршрута (Relative Impression Weight). Их произведение дает ожидаемый вес показов для конкретной комбинации.

Где конкретно используются эти механизмы?

Эти механизмы используются в бэкенде вертикальных поисковых систем, таких как Google Hotels, Google Flights, и других сервисах, которые агрегируют данные о ценах и доступности от множества внешних партнеров (Partner Systems).

Могу ли я как SEO-специалист повлиять на метрики, описанные в этом патенте?

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

Зачем SEO-специалисту знать об этом патенте?

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

Похожие патенты

Как Google оптимизирует Google Flights, рассчитывая цены для разного числа пассажиров за один запрос
Патент Google, описывающий внутренний алгоритм систем планирования путешествий (например, Google Flights). Он позволяет эффективно рассчитывать стоимость авиабилетов для разного количества пассажиров в рамках одного поискового запроса, учитывая наличие мест по конкретным кодам бронирования. Это оптимизирует вычислительные ресурсы и ускоряет обновление результатов при изменении числа путешественников.
  • US20160042301A1
  • 2016-02-11
Как Google интерпретирует общие запросы о путешествиях и преобразует их в структурированные данные для вертикального поиска (Google Flights/Hotels)
Google анализирует запросы на естественном языке (например, «отпуск в Европе летом»), введенные в основной поиск. Система определяет вероятность туристического интента и предполагает недостающие параметры (отправление, назначение, даты), используя историю пользователя и тренды. Если уверенность высока, запрос структурируется и направляется в специализированный движок (например, Google Flights), минуя стандартный веб-поиск.
  • US9430571B1
  • 2016-08-30

  • Семантика и интент

  • Персонализация

Как Google эффективно обновляет Граф Знаний в реальном времени при изменении фактов
Патент Google описывает инфраструктурный механизм для поддержания актуальности Графа Знаний. Когда в базу добавляется или удаляется факт (связь между сущностями), система мгновенно определяет, какие сохраненные запросы (коллекции) затронуты, и эффективно пересчитывает результаты, минимизируя нагрузку на базу данных.
  • US9626407B2
  • 2017-04-18

  • Knowledge Graph

  • Свежесть контента

  • Семантика и интент

Как Google рассчитывает точные цены на авиабилеты для разных продавцов в рамках одного запроса (Google Flights)
Патент Google, описывающий внутренний механизм систем планирования путешествий (например, Google Flights). Он позволяет эффективно и точно рассчитывать стоимость авиабилетов, учитывая разные правила (цены, налоги, ограничения) для разных продавцов (авиакомпаний и агентств) в рамках одного поискового запроса, избегая ошибок и высоких вычислительных затрат.
  • US20160042300A1
  • 2016-02-11
Как Google использует данные о закладках, сообществах и поведении пользователей для персонализации и контекстуализации поиска
Патент описывает раннюю систему персонализации поиска, которая собирает и анализирует закладки (content pointers) пользователей и групп, организованные в иерархические категории. Эта информация используется для создания профилей интересов (content vectors), которые затем применяются для дополнения поисковых запросов (query augmentation) и переранжирования результатов (contextualization) с учетом личного контекста, интересов сообщества и недавней активности пользователя.
  • US7031961B2
  • 2006-04-18

  • Персонализация

  • Поведенческие сигналы

  • Семантика и интент

Популярные патенты

Как Google идентифицирует экспертов на основе их активности и позволяет фильтровать выдачу по их контенту
Google использует систему для идентификации людей (членов социальной сети), тесно связанных с темой запроса, на основе их активности (посты, взаимодействия, репосты) и квалификации. Система отображает этих людей в специальных блоках (Display Areas) рядом с результатами поиска, позволяя пользователям просматривать их профили или фильтровать выдачу, чтобы увидеть только контент, созданный, одобренный или прокомментированный этими экспертами.
  • US9244985B1
  • 2016-01-26

  • EEAT и качество

  • Поведенческие сигналы

  • SERP

Как Google определяет географическую зону релевантности бизнеса на основе реального поведения пользователей (Catchment Areas)
Google определяет уникальную "зону охвата" (Catchment Area) для локального бизнеса, анализируя, из каких географических точек пользователи кликали на его результаты в поиске. Эта динамическая зона заменяет фиксированный радиус и используется для фильтрации кандидатов при локальном поиске, учитывая известность бренда, категорию бизнеса и физические препятствия.
  • US8775434B1
  • 2014-07-08

  • Local SEO

  • Поведенческие сигналы

Как Google автоматически изучает синонимы, анализируя последовательные запросы пользователей и вариации анкорных текстов
Google использует методы для автоматического определения синонимов, акронимов и эквивалентных фраз. Система анализирует логи запросов: если пользователь быстро меняет запрос, сохраняя часть слов (например, с «отели в париже» на «гостиницы в париже»), система учится, что «отели» и «гостиницы» эквивалентны. Также анализируются вариации анкорных текстов, указывающих на одну и ту же страницу.
  • US6941293B1
  • 2005-09-06

  • Семантика и интент

  • Ссылки

Как Google динамически формирует Панели Знаний, выбирая блоки информации на основе истории поисковых запросов пользователей
Google использует гибридный подход для создания структурированных страниц о сущностях (например, Панелей Знаний). Система анализирует исторические данные о том, что пользователи чаще всего ищут об этой сущности или её классе. На основе этого анализа динамически выбираются блоки информации (например, «Награды», «Саундтрек»), которые дополняют стандартный набор данных, позволяя автоматически адаптировать выдачу под актуальные интересы аудитории.
  • US10110701B2
  • 2018-10-23

  • Knowledge Graph

  • Поведенческие сигналы

  • Персонализация

Как Google использует поведение пользователей для определения синонимичности фраз в запросах, связанных с сущностями
Google анализирует поведение пользователей (клики по результатам поиска), чтобы определить, означают ли разные фразы одно и то же, когда они связаны с одним типом сущности (например, «достопримечательности в <Город>» против «места для посещения в <Город>»). Если пользователи кликают на одни и те же документы для разных фраз, система считает эти фразы эквивалентными, что помогает Google понимать синонимы и улучшать результаты поиска.
  • US10073882B1
  • 2018-09-11

  • Семантика и интент

  • Поведенческие сигналы

Как Google использует историю физических перемещений пользователя для фильтрации и персонализации результатов поиска
Google может собирать и хранить историю физических перемещений пользователя (Location History). Патент описывает интерфейс, позволяющий пользователю осознанно включать свои прошлые местоположения (например, «места, где я был на прошлой неделе») в качестве фильтра для нового поискового запроса, чтобы сделать результаты более релевантными личному опыту.
  • US8874594B2
  • 2014-10-28

  • Персонализация

  • Поведенческие сигналы

  • Local SEO

Как Google классифицирует запросы как навигационные или исследовательские, чтобы регулировать количество показываемых результатов
Google использует систему для динамического определения количества отображаемых результатов поиска. Система классифицирует запрос как навигационный (поиск конкретного места/ресурса) или исследовательский (поиск вариантов). Классификация основана на анализе компонентов оценки релевантности (совпадение по названию vs. категории) и энтропии исторических кликов. При навигационном интенте количество результатов сокращается.
  • US9015152B1
  • 2015-04-21

  • Семантика и интент

  • Поведенческие сигналы

  • Local SEO

Как Google определяет скрытый интент сессии, используя универсальные уточняющие слова, и переранжирует выдачу
Google идентифицирует универсальные слова-модификаторы (например, «фото», «отзывы», «pdf»), которые пользователи часто добавляют к разным запросам. Если такое слово появляется в сессии, система определяет скрытый интент пользователя. Затем Google переранжирует выдачу, основываясь на том, какие документы исторически предпочитали пользователи с таким же интентом, адаптируя результаты под контекст сессии.
  • US8868548B2
  • 2014-10-21

  • Семантика и интент

  • Поведенческие сигналы

  • Персонализация

Как Google извлекает, обрабатывает и индексирует анкорный текст, контекст и атрибуты входящих ссылок для ранжирования целевых страниц
Фундаментальный патент, описывающий инфраструктуру Google для обработки ссылок. Система извлекает анкорный текст, окружающий контекст и атрибуты форматирования (аннотации) из исходных страниц и инвертирует эти данные в структуру "Sorted Anchor Map". Это позволяет индексировать целевую страницу по тексту ссылок, указывающих на нее, используя эту внешнюю информацию как сигнал релевантности.
  • US7308643B1
  • 2007-12-11

  • Ссылки

  • Индексация

  • Техническое SEO

Как Google использует личные интересы пользователя для понимания неопределенных запросов и персонализации рекомендаций
Google использует механизм для интерпретации неопределенных запросов или команд (например, «Я голоден» или «Мне скучно»), когда контекст неясен. Если система не может определить конкретное намерение пользователя только из текущего контента (например, экрана приложения), она обращается к профилю интересов пользователя (User Attribute Data) и его местоположению, чтобы заполнить пробелы и предоставить персонализированные рекомендации или выполнить действие.
  • US10180965B2
  • 2019-01-15

  • Персонализация

  • Семантика и интент

  • Local SEO