SEO HARDCORE
  • Разборы патентов
    • Патенты Google
  • Скоро SEO инструменты
  • Скоро SEO аналитика
  • seohardcore
SEO HARDCORE
назад

Как Google поддерживает контекст в диалоговом поиске, переписывая неполные запросы на основе предыдущих результатов и грамматических шаблонов

REWRITING CONTEXTUAL QUERIES (Переписывание контекстуальных запросов)
  • US20180285444A1
  • Google LLC
  • 2014-08-01
  • 2018-10-04
  • Семантика и интент
  • Описание
  • Разбор
  • Выводы
  • Практика
  • FAQ
  • Похожие

Google использует систему для понимания диалогового поиска. Если пользователь задает последующий неполный запрос (например, «напомни мне за час до этого»), система определяет контекст из предыдущего запроса (например, время рейса). Затем она использует грамматические шаблоны, чтобы переписать неполный запрос в полный и понятный для выполнения действия (например, «установить напоминание на 13:40 для рейса UA 214»).

Описание

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

Патент решает проблему обработки последовательных запросов в рамках одной пользовательской сессии, особенно когда последующие запросы являются неполными (incomplete queries) или контекстуально зависимыми. Система обеспечивает глубокое понимание контекста (deep context understanding), позволяя пользователям взаимодействовать с поиском в более естественной, диалоговой манере (conversational search), не повторяя информацию, которая уже была установлена в предыдущих запросах или результатах.

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

Запатентована система для переписывания контекстуальных запросов. Когда система получает последовательность запросов (Q1, затем Q2) и определяет, что Q2 является неполным без контекста Q1, она идентифицирует грамматический шаблон (template) для Q2. Система извлекает недостающую информацию из контекстуальных данных Q1 (результаты поиска и метаданные) и использует шаблон для переписывания Q2 в полный, действенный запрос (Q3). Этот переписанный запрос Q3 затем используется для выполнения действия (например, поиска, установки напоминания, навигации).

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

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

  • Установление контекста: После первого запроса (Q1) система сохраняет contextual data, включая результаты поиска и связанные метаданные (например, сущности, время, места).
  • Анализ последующего запроса: При получении второго запроса (Q2) система проверяет, является ли он полным и связан ли с контекстом Q1 (например, по времени поступления или совпадению временных форм).
  • Триггер переписывания: Если Q2 неполный (не хватает информации для выполнения действия), он помечается как incomplete query и активируется механизм переписывания.
  • Применение шаблона: Система идентифицирует подходящий грамматический шаблон для Q2 (например, «напомнить [кому] за [время] до [событие]»).
  • Контекстуальное заполнение: Недостающие элементы (labels) шаблона заполняются данными из контекста Q1.
  • Генерация нового запроса: Генерируется полный запрос (Q3), который передается в Action Engine для выполнения.

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

Высокая. Патент напрямую связан с развитием диалогового поиска, Google Assistant, SGE и обработки естественного языка (NLP). Способность поддерживать контекст в рамках сессии и выполнять действия на основе неполных входных данных является центральным элементом современных интеллектуальных систем и голосового поиска.

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

Патент имеет высокое стратегическое значение для SEO (7.5/10), особенно в контексте оптимизации под диалоговый поиск и извлечения сущностей. Он демонстрирует, как Google использует результаты первого запроса в качестве «контекста» для интерпретации последующих действий. Чтобы контент эффективно работал в таких диалоговых сценариях, он должен быть структурирован так, чтобы система могла легко извлекать contextual data (метаданные о сущностях, событиях, времени, локациях). Это подчеркивает критическую важность структурированных данных (Schema.org) и четкого представления информации об объектах.

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

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

Action Engine (Механизм действий)
Компонент системы, который выполняет конкретные действия в ответ на полный (переписанный) запрос. Примеры действий: search action, reminder action, navigation action.
Contextual Data (Контекстуальные данные)
Информация, связанная с предыдущим запросом (Q1) в сессии. Включает результат поиска, отзывчивый на Q1, и метаданные, связанные с Q1 и этим результатом (например, время события, местоположение сущности).
Contextual Rewrite Engine (Механизм контекстуального переписывания)
Компонент, который генерирует новый полный запрос (Q3) на основе шаблона, текущего запроса (Q2) и контекстуальных данных (из Q1).
Dialog Session Module (Модуль диалоговой сессии)
Компонент, который управляет пользовательскими сессиями и определяет, связаны ли последовательные запросы между собой (например, на основе времени и полноты запроса).
Grammar Rule Module (Модуль грамматических правил)
Компонент, который анализирует запрос (Q2), определяет его грамматическую структуру и выбирает соответствующий шаблон из базы данных.
Incomplete Query (Неполный запрос)
Запрос (Q2), в котором отсутствует информация (additional information), необходимая для выполнения связанного с ним действия, и который требует контекста из предыдущего запроса (Q1) для интерпретации.
Labels (Метки)
Переменные части в грамматическом шаблоне (например, [person], [event time], [location]), которые заполняются данными из текущего запроса или контекста.
Template (Шаблон)
Предопределенная грамматическая структура, хранящаяся в Template Database. Шаблоны связаны с вертикальными категориями (например, «местный поиск», «напоминания») и содержат labels.
User Session (Пользовательская сессия)
Последовательность взаимодействий пользователя с системой в течение определенного периода времени (specific period of time, например, 30-120 секунд).

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

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

  1. Система получает первый запрос (Q1).
  2. Определяются contextual data для Q1 (результат поиска и метаданные).
  3. Система получает второй запрос (Q2), следующий за Q1 в той же сессии.
  4. Система определяет, что Q2 является incomplete query без использования contextual data из Q1. (Это ключевой триггер).
  5. В ответ на это определение:
    1. Определяется конкретный шаблон (particular template), которому соответствует Q2, на основе грамматического правила (grammar rule) Q2.
    2. Генерируется третий запрос (Q3) на основе (i) шаблона, (ii) contextual data из Q1 и (iii) текста Q2.
    3. Q3 предоставляется как входные данные для автоматически генерируемого действенного вывода (actionable output), который является ответом на Q2.

Claim 4 (Зависимый): Описывает организацию шаблонов.

Шаблоны классифицируются по вертикальным категориям (vertical categories), тематикам (subjects) и грамматическим правилам. Система определяет тематику и вертикаль Q2 (используя контекст Q1, если необходимо) и выбирает шаблон, соответствующий этой тематике/вертикали и грамматическому правилу Q2.

Claim 5 (Зависимый): Определяет incomplete query как запрос, в котором отсутствует дополнительная информация, необходимая для выполнения действия. Генерация Q3 включает определение этой недостающей информации из contextual data.

Claim 6 (Зависимый от 5): Уточняет использование сущностей и местоимений.

Если первый запрос относится к сущности (entity), то дополнительная информация для второго запроса может включать соответствующее местоимение (pronoun) для этой сущности, что помогает связать запросы (разрешение кореференции).

Claim 7 (Зависимый): Уточняет один из методов определения связи (Tense Matching).

Система проверяет соответствие грамматического времени (tense) между Q1/результатом Q1 и Q2. Если время совпадает (например, оба в будущем времени), это может указывать на то, что Q2 связан с контекстом Q1 и является неполным без него.

Claim 9 (Зависимый): Детализирует генерацию Q3 с помощью поддерживающих правил.

Система может использовать поддерживающие грамматические правила (supporting grammar rules), связанные с метками. Например, если шаблон содержит относительное время («за час до события»), правило может вычислить точное время для выполнения действия.

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

Изобретение применяется на этапе понимания запроса и тесно связано с данными, полученными на этапе индексирования.

INDEXING – Индексирование и извлечение признаков
На этом этапе система должна извлекать и индексировать метаданные и сущности из ресурсов. Эта информация позже используется как contextual data, когда ресурс появляется в результатах поиска по первому запросу (Q1). Четкость и структурированность данных критичны.

QUNDERSTANDING – Понимание Запросов
Основное место применения патента. Dialog Session Module отслеживает сессию. Grammar Rule Module анализирует входящий запрос Q2 на предмет полноты и грамматической структуры. Если Q2 неполный, Contextual Rewrite Engine использует контекст Q1 и шаблоны из Template Database для генерации Q3. Это процесс переписывания запроса на основе контекста сессии в реальном времени.

RANKING / Action Execution
Переписанный запрос (Q3) передается либо в стандартную систему ранжирования (если это поисковое действие), либо в специализированный Action Engine (для напоминаний, навигации и т.д.). Исходный запрос Q2 не используется для ранжирования напрямую.

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

  • Первый запрос (Q1) и его контекстуальные данные (результаты, метаданные).
  • Второй запрос (Q2).
  • База данных шаблонов (Template Database).
  • Данные о пользовательской сессии (тайминги).

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

  • Третий, переписанный запрос (Q3), который является полным и действенным.

На что влияет

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

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

Алгоритм активируется при выполнении нескольких условий в рамках одной пользовательской сессии:

  • Временные рамки: Второй запрос (Q2) должен поступить в течение определенного периода времени после первого (Q1) (например, 30-120 секунд).
  • Триггер активации (Incompleteness): Ключевое условие — второй запрос (Q2) должен быть идентифицирован как incomplete query. То есть, он не содержит всей информации, необходимой для выполнения предполагаемого действия.
  • Наличие контекста и связи: Должны существовать релевантные contextual data от Q1, которые могут заполнить пробелы в Q2. Система может проверять связь через лингвистические сигналы (местоимения) или совпадение времени (tense matching).
  • Наличие шаблона: Для Q2 должен быть найден подходящий грамматический шаблон в Template Database.

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

Процесс обработки диалоговой сессии

  1. Получение первого запроса (Q1): Система получает Q1 и начинает пользовательскую сессию.
  2. Определение контекстуальных данных Q1: Система выполняет поиск по Q1 и определяет результаты. Извлекаются метаданные (сущности, время, локации и т.д.) из результатов. Эти данные сохраняются как contextual data сессии.
  3. (Опционально) Предварительный выбор шаблонов: На основе контекста Q1 система может заранее определить набор вероятных последующих шаблонов.
  4. Получение второго запроса (Q2): Система получает Q2.
  5. Проверка временных рамок: Система проверяет, поступил ли Q2 в течение установленного времени сессии. Если нет, Q2 обрабатывается как новый независимый запрос.
  6. Проверка полноты Q2 (Incompleteness Check): Система анализирует Q2, чтобы определить, достаточно ли в нем информации для выполнения действия.
    • Если Q2 полный: Q2 обрабатывается независимо.
    • Если Q2 неполный: Переход к следующему шагу.
  7. Определение ассоциации с контекстом: Система подтверждает, что неполный Q2 связан с контекстом Q1. Это может включать проверку соответствия времени (tense matching) или наличия местоимений, ссылающихся на сущности из Q1.
  8. Выбор шаблона: Модуль грамматических правил анализирует Q2 и выбирает наиболее подходящий шаблон.
  9. Заполнение меток шаблона: Система определяет информацию для меток в шаблоне. Часть информации берется из Q2, а недостающая часть — из contextual data Q1.
  10. Генерация третьего запроса (Q3): Механизм контекстуального переписывания генерирует Q3, подставляя заполненные метки в шаблон. Могут применяться поддерживающие грамматические правила (например, расчет точного времени из относительного).
  11. Выполнение действия: Q3 передается в Action Engine для выполнения (поиск, напоминание и т.д.).

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

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

Патент фокусируется на обработке запросов и использовании контекста, а не на факторах ранжирования контента. Он использует следующие типы данных:

  • Контентные/Структурные факторы (в виде Contextual Data): Система полагается на данные, извлеченные из результатов поиска по Q1. Это включает текст результата и, что критически важно, метаданные, связанные с ним (сущности, даты, время, локации). Это подчеркивает важность структурированных данных и четкого представления информации на страницах.
  • Поведенческие факторы: Query Logs и Selection Logs могут использоваться офлайн для генерации или уточнения грамматических шаблонов.
  • Временные факторы: Время между запросами (Q1 и Q2) используется для определения границ пользовательской сессии. Грамматическое время (tense) самих запросов используется для подтверждения их контекстуальной связи.
  • Пользовательские факторы: Запросы привязаны к уникальному идентификатору пользователя или устройства для отслеживания сессии.
  • Лингвистические факторы: Грамматическая структура запросов, использование местоимений (pronouns).

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

Патент не описывает расчет метрик ранжирования, но описывает следующие критерии и процессы:

  • Определение границ сессии: Используется пороговое значение времени (например, 30-120 секунд) между запросами.
  • Оценка полноты запроса (Incompleteness): Определяется, содержит ли запрос всю необходимую информацию для выполнения действия. Это основано на грамматическом анализе и требованиях конкретных действий/шаблонов. Если ключевые метки не могут быть заполнены из самого запроса, он считается неполным.
  • Выбор шаблона: Основан на сопоставлении грамматической структуры запроса Q2 с шаблонами в Template Database, с учетом вертикали и тематики контекста.
  • Соответствие времени (Tense Matching): Сравнение грамматического времени (настоящее, будущее) между Q1/его результатом и Q2 для подтверждения контекстуальной связи.
  • Поддерживающие грамматические правила: Применяются для трансформации данных при генерации Q3 (например, преобразование относительного времени в абсолютное: «за 1 час до 14:40» -> «в 13:40»).

Выводы

  1. Контекст сессии как основа для интерпретации запросов: Google активно пытается связать последовательные запросы в диалог. Если текущий запрос неполный, система ищет недостающую информацию не только в тексте предыдущего запроса, но и в его результатах и связанных метаданных.
  2. Критичность извлечения метаданных (Contextual Data): Способность системы поддерживать диалог напрямую зависит от качества contextual data, извлеченных из результата первого запроса (Q1). Если Google не может извлечь четкие метаданные (время, место, сущность) из страницы, он не сможет использовать эту страницу как контекст для последующих действий.
  3. Грамматические шаблоны для действий: Google использует предопределенные шаблоны (Templates), связанные с конкретными вертикалями (местный поиск, рейсы, спорт) и действиями (напоминания, навигация), для интерпретации и переписывания неполных запросов.
  4. Определение «неполноты» запроса как триггер: Запрос считается неполным (incomplete query), если он не содержит достаточно информации для выполнения действия. Это ключевой триггер для активации механизма контекстуального переписывания.
  5. Переписывание запроса перед выполнением: Неполный запрос (Q2) не обрабатывается напрямую. Вместо этого он переписывается в полный запрос (Q3), который затем используется для поиска или выполнения действия.
  6. Лингвистические сигналы для валидации связи: Система использует сложные лингвистические маркеры, такие как временная форма (tense) и местоимения (pronouns), для подтверждения связи между запросами.

Практика

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

  • Оптимизация для извлечения сущностей (Entity Extraction): Убедитесь, что ключевые сущности (продукты, события, организации, локации) и их атрибуты (время, дата, адрес, цена) представлены на странице четко и однозначно. Это позволяет Google легко извлекать их как contextual data после первого запроса (Q1).
  • Активное использование структурированных данных (Schema.org): Внедряйте подробную микроразметку (например, Event, Flight, LocalBusiness, Product). Это напрямую помогает системе извлекать точные метаданные, которые необходимы для заполнения меток (labels) шаблонов действий в последующих запросах.
  • Оптимизация под диалоговый поиск и многоэтапные сессии: Создавайте контент, который дает четкие ответы и поддерживает развитие диалога. Анализируйте, как пользователи ищут информацию последовательно, и оптимизируйте контент так, чтобы он отвечал не только на первый вопрос, но и предоставлял контекст для ожидаемых следующих шагов (например, от поиска информации к действию).
  • Обеспечение лингвистической и темпоральной четкости: Используйте ясный язык и правильные временные формы. Поскольку система использует tense matching для связи запросов, контент должен быть написан так, чтобы его временной контекст был очевиден (например, анонс предстоящего события должен использовать будущее время).

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

  • Неоднозначное представление информации: Размещение ключевой информации (например, времени работы или адреса) только в виде изображений или в неструктурированном тексте затрудняет извлечение contextual data.
  • Игнорирование микроразметки для событий и локаций: Отсутствие Schema.org снижает вероятность того, что ваш контент будет эффективно использоваться в диалоговых сессиях, требующих точных данных для выполнения действий (напоминания, навигация).
  • Фокус только на ключевых словах без учета сущностей и действий: Оптимизация под текстовые совпадения без учета лежащих в их основе сущностей и связанных с ними действий (Actionable Intents) неэффективна для систем, описанных в патенте, которые оперируют шаблонами и метаданными.

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

Патент подтверждает движение Google от простого поиска информации к выполнению действий и диалоговому взаимодействию (Conversational AI / Search as an Assistant). Для SEO это означает, что оптимизация должна выходить за рамки традиционного ранжирования и фокусироваться на том, насколько хорошо контент поддерживает выполнение задач пользователя (Task Completion). Стратегический приоритет смещается в сторону семантического SEO: понимания сущностей, их атрибутов и связанных с ними действий. Сайты, которые предоставляют четкие, структурированные данные, будут предпочтительнее в качестве источника контекста для Google Assistant и SGE.

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

Сценарий: Оптимизация страницы мероприятия для поддержки диалогового поиска и действий

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

  1. Анализ взаимодействия: Пользователь ищет Q1: «Концерт [Исполнитель] в [Город]». Наш сайт ранжируется на первой позиции.
  2. Оптимизация Contextual Data: Внедрена микроразметка Event с точными данными:
    • startDate: [Точная дата и время]
    • location (Place): [Название площадки, полный адрес]
  3. Результат взаимодействия: Пользователь задает Q2: «Как туда добраться?».
  4. Обработка системой: Система определяет Q2 как incomplete query (не указано место назначения). Она идентифицирует шаблон навигации «get directions to [destination location]». Система извлекает точный адрес площадки из contextual data (благодаря Schema.org).
  5. Переписанный запрос (Q3): «Проложить маршрут до [Точный адрес площадки]».
  6. Ожидаемый результат: Google успешно выполняет навигационное действие (navigation action), используя наш сайт как надежный источник контекста.

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

Что такое «неполный запрос» (incomplete query) в контексте этого патента?

Это запрос (Q2), который сам по себе не содержит всей необходимой информации для выполнения предполагаемого действия. Например, запрос «Напомни мне за час до начала» является неполным, так как неясно, что именно начинается. Система должна обратиться к контексту предыдущего запроса (Q1), чтобы понять смысл Q2 и выполнить действие.

Как этот патент влияет на важность структурированных данных (Schema.org)?

Он значительно повышает их важность. Структурированные данные являются основным способом предоставления contextual data (метаданных о сущностях, времени, локациях), которые система извлекает из результатов первого запроса (Q1). Эти данные затем используются для заполнения пробелов (labels) в последующем неполном запросе (Q2). Без четких метаданных система не сможет эффективно поддерживать диалог.

Применяется ли этот механизм только к голосовому поиску?

Нет. Хотя он критически важен для голосового поиска и Google Assistant, где диалоговое взаимодействие является нормой, механизм применяется к любой пользовательской сессии (включая текстовый поиск), где обнаруживается последовательность связанных запросов, и последующий запрос является неполным.

Что такое «шаблоны» (Templates) и как они используются?

Шаблоны — это предопределенные грамматические структуры, связанные с конкретными действиями и вертикалями (например, «проложить маршрут до [место назначения]» для навигации). Когда система обнаруживает неполный запрос, она находит подходящий шаблон и заполняет его метки (например, [место назначения]), используя контекст из предыдущего запроса.

Как система определяет, что два запроса связаны между собой?

Используется несколько критериев. Во-первых, запросы должны следовать друг за другом в течение короткого периода времени (сессия). Во-вторых, второй запрос должен быть идентифицирован как неполный. В-третьих, могут использоваться лингвистические сигналы, такие как соответствие грамматического времени (tense matching) или использование местоимений (pronouns), ссылающихся на предыдущий контекст.

Как SEO-специалист может оптимизировать контент для этого механизма?

Ключевая стратегия — оптимизировать контент для максимально четкого извлечения сущностей и их атрибутов. Используйте подробную микроразметку, четко указывайте даты, время, адреса и другую фактическую информацию. Также важно прорабатывать сценарии пользовательских путей (User Journeys), понимая, какие действия пользователь может захотеть совершить после получения информации.

Что произойдет, если Google не сможет извлечь качественные метаданные из моего сайта после первого запроса?

Если метаданные (contextual data) неясны или отсутствуют, система не сможет использовать ваш сайт в качестве контекста для интерпретации последующего неполного запроса. Это приведет к неудаче в выполнении действия пользователя или к тому, что система запросит у пользователя уточнение, что ухудшает пользовательский опыт в диалоговом поиске.

Влияет ли этот патент на ранжирование?

Напрямую он не описывает алгоритмы ранжирования. Он сосредоточен на этапе Понимания Запросов (QUNDERSTANDING). Однако сайты, которые лучше поддерживают такие диалоговые взаимодействия (предоставляя четкий контекст для выполнения действий), могут косвенно получать преимущества, так как они лучше отвечают на интент пользователя, особенно в голосовом поиске и при использовании ассистентов.

Как этот патент связан с SGE (Search Generative Experience)?

SGE часто предполагает диалоговое взаимодействие и обработку последующих уточняющих вопросов (follow-up questions). Механизмы, описанные в этом патенте, лежат в основе способности SGE понимать контекст разговора и генерировать ответы или выполнять действия, опираясь на то, что было сказано ранее, даже если пользователь не повторяет всю информацию.

Что такое «поддерживающие грамматические правила» (supporting grammar rules)?

Это правила, которые помогают трансформировать данные при переписывании запроса (Claim 9). Например, если пользователь говорит «напомни мне за час до этого», а контекстное время события — 14:40, поддерживающее правило выполнит вычисление и перепишет запрос как «установить напоминание на 13:40». Это обеспечивает точность выполнения действия.

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

Как Google интерпретирует последовательные запросы для автоматического уточнения поискового намерения пользователя
Google использует механизм для понимания контекста сессии, анализируя последовательные запросы (например, Q1: [рестораны в Москве], затем Q2: [итальянские]). Система автоматически объединяет их в уточненный запрос (Q3: [итальянские рестораны в Москве]), основываясь на исторических данных о том, как пользователи обычно уточняют запросы. Это позволяет системе лучше понимать намерение пользователя в диалоговом режиме.
  • US9116952B1
  • 2015-08-25
  • Семантика и интент

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

Как Google запоминает вопросы без авторитетного ответа и автономно сообщает его позже через Ассистента
Патент Google описывает механизм для обработки запросов, на которые в момент поиска нет качественного или авторитетного ответа. Система запоминает информационную потребность и продолжает мониторинг. Когда появляется информация, удовлетворяющая критериям качества (например, в Knowledge Graph), Google автономно доставляет ответ пользователю, часто встраивая его в следующий диалог с Google Assistant, даже если этот диалог не связан с исходным вопросом.
  • US11238116B2
  • 2022-02-01
  • Knowledge Graph

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

  • EEAT и качество

Как Google использует контекст поисковой сессии для исправления ошибок и уточнения запросов пользователя
Google использует механизм для интеллектуального исправления ошибок в запросах (опечаток или неверно употребленных слов), опираясь на контекст текущей поисковой сессии. Вместо стандартного исправления по словарю, система анализирует предыдущие запросы пользователя, чтобы понять его намерение, и предлагает вариант исправления, который соответствует теме поиска.
  • US7953746B1
  • 2011-05-31
  • Семантика и интент

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

Как Google предугадывает ваш следующий запрос и заранее показывает его результаты в текущей выдаче
Google анализирует агрегированную историю поисковых сессий, чтобы предсказать, какой запрос пользователь введет следующим. Система может выполнить этот предполагаемый запрос (Inferred Action) заранее и встроить его результаты непосредственно в текущую страницу выдачи. Этот механизм часто активируется при показе персональных данных или Панелей знаний и учитывает контекст (время, сезон) и интересы пользователя.
  • US20170116284A1
  • 2017-04-27
  • Семантика и интент

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

  • SERP

Как Google предсказывает ваш следующий запрос на основе контента, который вы просматриваете, и истории поиска других пользователей
Google использует систему контекстной информации, которая анализирует контент на экране пользователя (например, статью или веб-страницу) и предсказывает, что пользователь захочет искать дальше. Система не просто ищет ключевые слова на странице, а использует исторические данные о последовательностях запросов (Query Logs). Она определяет, что другие пользователи искали после того, как вводили запросы, связанные с текущим контентом, и предлагает эти последующие запросы в качестве рекомендаций.
  • US20210232659A1
  • 2021-07-29
  • Семантика и интент

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

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

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

Как Google A/B тестирует и оптимизирует сниппеты (заголовки, описания, изображения) для повышения CTR
Google использует механизм для оптимизации отображения контента (сниппетов). Система показывает разные варианты заголовков, описаний или изображений для одной и той же ссылки разным пользователям или на разных платформах. Затем она измеряет кликабельность (CTR) каждого варианта и выбирает наиболее эффективный для дальнейшего использования, учитывая также тип устройства пользователя.
  • US9569432B1
  • 2017-02-14
  • SERP

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

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

Как Google использует время взаимодействия пользователя с сайтом (Dwell Time) для расчета оценки качества всего сайта
Google использует агрегированные данные о продолжительности визитов пользователей на сайт для расчета метрики качества этого сайта (Site Quality Score). Система измеряет время взаимодействия (включая Dwell Time — время от клика в выдаче до возврата обратно), фильтрует аномальные визиты и нормализует данные по типам контента. Итоговая оценка используется как независимый от запроса сигнал для ранжирования и принятия решений об индексировании.
  • US9195944B1
  • 2015-11-24
  • Поведенческие сигналы

  • Индексация

  • SERP

Как Google обучает ИИ-модели для автоматической оценки качества сайтов на основе данных асессоров и предвзятой выборки
Патент Google, описывающий фундаментальную методологию создания систем оценки качества сайтов. Google использует машинное обучение (например, SVM), чтобы найти корреляции между оценками асессоров и измеримыми сигналами сайта (PageRank, клики). Для повышения точности применяется метод «предвзятой выборки» (Biased Sampling): система намеренно собирает больше оценок для сайтов среднего качества («сложных случаев»), чем для очевидно плохих или хороших.
  • US8442984B1
  • 2013-05-14
  • SERP

  • EEAT и качество

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

Как Google использует историю навигации и клики по рекламе для генерации ключевых слов, гео-таргетинга и выявления MFA-сайтов
Патент Google, описывающий три механизма, основанных на анализе поведения пользователей (selection data). Система использует путь навигации пользователя для генерации новых ключевых слов для рекламы, улучшает гео-таргетинг объявлений на основе предпочтений пользователей, а также выявляет низкокачественные сайты (MFA/манипулятивные) по аномально высокому CTR рекламных блоков.
  • US8005716B1
  • 2011-08-23
  • Поведенческие сигналы

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

  • Антиспам

Как Google снижает влияние ссылок с аффилированных сайтов и PBN для борьбы с манипуляциями в ранжировании
Патент Google описывает систему ранжирования, которая идентифицирует группы сайтов под общим контролем (аффилированные узлы или PBN). Система резко снижает вес ссылок внутри такой группы и ограничивает общее влияние группы на другие сайты, учитывая только одну, самую сильную ссылку от всей группы. Также описывается механизм "Доверенных авторитетов", чьи ссылки передают максимальный вес независимо от количества исходящих ссылок.
  • US8719276B1
  • 2014-05-06
  • Антиспам

  • Ссылки

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

Как Google использует анализ аномалий в показах и кликах для выявления фейковых локальных бизнес-листингов (Map Spam)
Google анализирует статистику взаимодействий (кликов) для групп связанных бизнес-листингов (Common Business). Система вычисляет статистически нормальный уровень активности и устанавливает порог (Anomaly Detection Threshold). Резкий всплеск активности выше этого порога (например, на два стандартных отклонения) сигнализирует о наличии фейковых или спамных листингов, созданных для манипуляции локальной выдачей.
  • US20150154610A1
  • 2015-06-04
  • Local SEO

  • Антиспам

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

Как Google использует контекст пользователя в реальном времени и машинное обучение для переранжирования результатов поиска
Google использует систему для прогнозирования истинного намерения пользователя на основе его текущего контекста (местоположение, время, среда, недавние действия) и исторических данных о поведении других пользователей в аналогичных ситуациях. Система переранжирует стандартные результаты поиска, чтобы выделить информацию (особенно "Search Features"), которая наиболее соответствует прогнозируемому намерению.
  • US10909124B2
  • 2021-02-02
  • Семантика и интент

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

  • SERP

Как Google использует язык интерфейса пользователя и поведенческие сигналы для определения языковой релевантности документа
Google определяет, для носителей каких языков релевантен документ, анализируя агрегированные данные о кликах. Система изучает, какой языковой интерфейс поиска (например, google.fr или google.de) использовали пользователи, кликнувшие на результат. Учитывая поведенческие факторы, такие как время пребывания на странице (Dwell Time) и позиция клика, Google рассчитывает Оценку Языковой Релевантности. Это позволяет определить целевую аудиторию страницы независимо от языка ее контента.
  • US9208231B1
  • 2015-12-08
  • Мультиязычность

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

  • SERP

Как Google игнорирует часто меняющийся контент и ссылки в нем, определяя "временные" блоки шаблона сайта
Google использует механизм для отделения основного контента от динамического шума (реклама, виджеты, дата). Система сравнивает разные версии одной страницы, чтобы найти часто меняющийся контент. Затем она анализирует HTML-структуру (путь) этого контента и статистически определяет, является ли этот структурный блок "временным" для всего сайта. Такой контент игнорируется при индексации и таргетинге рекламы, а ссылки в нем могут не учитываться при расчете PageRank.
  • US8121991B1
  • 2012-02-21
  • Индексация

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

  • Структура сайта

Как Google использует паттерны просмотра пользователей (Co-Visitation) и временную близость для определения тематики нетекстового контента (изображений и видео)
Google использует механизм для понимания контента без текста (изображения, видео), анализируя, какие другие (текстовые) страницы пользователи посещают в рамках той же сессии. Ключевые слова с этих текстовых страниц заимствуются и присваиваются нетекстовому ресурсу. Критически важным фактором является время перехода: чем быстрее пользователь перешел между ресурсами, тем больший вес получают ключевые слова.
  • US8572096B1
  • 2013-10-29
  • Поведенческие сигналы

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

  • Мультимедиа

seohardcore