Как Google использует данные о кликах для генерации блока «Связанные запросы» (Related Searches), обеспечивая их качество и разнообразие

Описание

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

Патент решает задачу генерации высококачественных и полезных уточнений запроса (Query Refinements), часто отображаемых как «Связанные запросы» (Related Searches). Цель — помочь пользователям, чей исходный запрос оказался слишком широким, неточным или является началом исследования темы. Система стремится избежать предложений, которые ведут к тем же результатам, что и исходный запрос, или которые слишком похожи друг на друга, обеспечивая реальную пользу и разнообразие (Diversity).

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

Запатентован метод генерации уточнений запроса, основанный на анализе данных о предпочтениях пользователей (User Preference Data), таких как клики и время просмотра. Система оценивает кандидатов по двум ключевым метрикам: Quality Score (степень связанности с исходным запросом через общие результаты) и Diversity Score (ценность новых результатов, которые привносит уточнение). Дополнительно применяется механизм Intra-Suggestion Diversity для обеспечения разнообразия финального набора предложений.

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

Система работает в несколько этапов, преимущественно офлайн:

• Сбор данных: Агрегируются User Preference Data, на основе которых вычисляются метрики качества (Quality of Result Statistics) для пар документ-запрос.
• Идентификация пар: Выявляются пары запросов (Q1, Q2), которые имеют общие документы, выбранные пользователями.
• Расчет Quality Score: Оценивается, насколько значимы общие документы для обоих запросов (мера схожести).
• Расчет Diversity Score: Оценивается, насколько значимы документы, которые есть в выдаче Q2, но отсутствуют в топе Q1 (мера новизны).
• Выбор кандидатов: Если обе оценки превышают пороги, Q2 становится кандидатом. Применяются дополнительные фильтры (например, географический).
• Финальный отбор: Кандидаты ранжируются и фильтруются для обеспечения разнообразия между самими предложениями (Intra-Suggestion Diversity).

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

Высокая. Генерация блока «Связанные запросы» остается важным элементом SERP. Использование поведенческих данных (кликов, dwell time) для понимания связей между запросами и интентами является фундаментальным подходом в современных поисковых системах. Акцент на разнообразии (Diversity) и качестве результатов полностью соответствует текущим приоритетам Google.

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

Патент имеет высокое стратегическое значение (85/100). Он раскрывает механизм, как Google строит карту тематического пространства и пользовательских путей, основываясь не только на семантике текста, но и на поведении пользователей. Это подчеркивает критическую важность оптимизации под удовлетворенность пользователя (User Satisfaction) и генерации положительных User Preference Data для построения Topical Authority.

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

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

Diversity Score (Оценка разнообразия)

Метрика для пары запросов (Q1, Q2), рассчитываемая на основе User Preference Data для документов, которые релевантны Q2, но НЕ релевантны Q1 (или не входят в топ результатов Q1). Отражает новизну информации, которую предлагает Q2.

Intra-Suggestion Diversity Score (Оценка разнообразия внутри предложений)

Метрика, оценивающая разнообразие между топовыми документами нового кандидата на уточнение и группой уже «просмотренных документов» (Seen Documents) от ранее выбранных уточнений. Используется для обеспечения разнообразия финального набора.

Quality of Result Statistic (Статистика качества результата)

Метрика, оценивающая, насколько релевантным пользователи сочли данный документ в ответ на данный запрос. Может включать агрегированные данные о кликах (clicks), времени просмотра (dwell time), взвешенные клики (weighted clicks) или долю кликов (click fraction).

Quality Score (Оценка качества)

Метрика для пары запросов (Q1, Q2), рассчитываемая на основе User Preference Data для документов, которые релевантны ОБОИМ запросам (Q1 и Q2). Отражает схожесть интентов запросов.

Query Pair (Пара запросов)

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

Query Refinement (Уточнение запроса)

Запрос, предлагаемый пользователю в дополнение к результатам поиска по исходному запросу (например, блок «Связанные запросы»).

Seen Documents (Просмотренные документы)

Набор топовых документов, ассоциированных с исходным запросом и/или уже выбранными подтвержденными уточнениями. Используется для расчета Intra-Suggestion Diversity.

User Preference Data (Данные о предпочтениях пользователя)

Данные, отражающие взаимодействие пользователя с результатами поиска. Хранятся в виде логов (Result Selection Logs) и обрабатываются для формирования наборов данных (tuples), например: <Запрос, Документ, Quality of Result Statistic>.

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

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

1. Система получает группу пар запросов (Q1, Q2).
2. Для каждой пары вычисляется Quality Score на основе User Preference Data для документов, релевантных ОБОИМ запросам.
3. Если Quality Score удовлетворяет порогу качества, вычисляется Diversity Score на основе User Preference Data для документов, релевантных Q2, но НЕ Q1.
4. Если Diversity Score удовлетворяет порогу разнообразия, Q2 ассоциируется с Q1 как кандидат на уточнение (Candidate Refinement).
5. Географическая фильтрация: Процесс ассоциации включает проверку: определяется, содержит ли Q2 ссылку на географическое местоположение. Если да, то Q2 ассоциируется с Q1 ТОЛЬКО если Q1 также содержит ссылку на географическое местоположение.

Система использует поведенческие данные для оценки как схожести (Quality), так и различия (Diversity). Ключевым является требование новизны результатов для уточнения. Дополнительно вводится строгий фильтр, предотвращающий предложение локализованных уточнений для общих (не локализованных) запросов.

Claim 3 (Зависимый от 1): Описывает процесс выбора финального набора уточнений из кандидатов, обеспечивая разнообразие между ними (Intra-Suggestion Diversity).

1. Получается упорядоченный список Candidate Refinements для запроса.
2. Инициализируется группа Seen Documents.
3. Кандидаты обрабатываются по порядку. Для каждого кандидата вычисляется Intra-Suggestion Diversity Score — оценка разнообразия между топовыми документами кандидата и Seen Documents.
4. Если оценка удовлетворяет порогу, кандидат становится подтвержденным уточнением (Confirmed Refinement), а его топовые документы добавляются в Seen Documents.

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

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

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

INDEXING – Индексирование и извлечение признаков
На этом этапе происходит сбор и обработка логов поведения пользователей (Result Selection Logs). Система агрегирует User Preference Data и рассчитывает Quality of Result Statistics для пар запрос-документ. Эти данные сохраняются в базе данных (Model Database).

QUNDERSTANDING – Понимание Запросов (Офлайн)
Основное применение патента. Специализированный движок (Refinement Engine) выполняет всю логику генерации уточнений:

1. Генерация карты: Строится карта связей (Document-to-Query-to-Document Map) на основе User Preference Data.
2. Выбор кандидатов: Идентифицируются пары запросов, рассчитываются Quality Score и Diversity Score, применяется первичная фильтрация (включая географическую).
3. Фильтрация кандидатов: Кандидаты ранжируются, и применяется фильтрация по Intra-Suggestion Diversity для формирования финального набора Confirmed Refinements.

Результаты сохраняются в базе данных уточнений (Refinement Database).

METASEARCH – Метапоиск и Смешивание
Во время выполнения запроса пользователя система извлекает предварительно рассчитанные Confirmed Refinements из Refinement Database и формирует блок «Связанные запросы» на странице результатов.

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

• Агрегированные User Preference Data (логи кликов, время взаимодействия).
• Наборы данных (tuples) вида <Запрос, Документ, Quality of Result Statistic>.

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

• База данных уточнений (Refinement Database), связывающая исходные запросы с набором ранжированных и диверсифицированных Confirmed Refinements.

На что влияет

• Специфические запросы: Наибольшее влияние оказывается на информационные, исследовательские и неоднозначные запросы, где пользователи часто нуждаются в помощи для уточнения интента или изучения темы.
• Географические факторы: Патент явно описывает механизм фильтрации (Claim 1), который блокирует показ локализованных уточнений (например, «пицца в Москве») для общих запросов (например, «пицца»), если исходный запрос не содержит геолокации.

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

• Условия работы: Алгоритм генерации работает офлайн, периодически анализируя накопленные поведенческие данные.
• Пороговые значения: Алгоритм использует несколько порогов для принятия решений:
  • Quality Threshold: Связь между запросами должна быть достаточно сильной.
  • Diversity Threshold: Уточнение должно привносить достаточно новизны.
  • Intra-Suggestion Diversity Threshold: Уточнение не должно дублировать уже выбранные предложения.

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

Процесс разделен на две основные фазы: Генерация Кандидатов и Фильтрация Кандидатов.

Фаза А: Генерация Кандидатов (Candidate Refinement Selection)

1. Получение пар запросов: Система анализирует карту связей (Query-Document Map). Выбирается документ D. Идентифицируются все запросы, связанные с D (пользователи кликали на D по этим запросам). Генерируются все возможные пары запросов (Q1, Q2) из этого набора.
2. Расчет Quality Score: Для пары (Q1, Q2) идентифицируются документы, релевантные обоим запросам. Quality Score рассчитывается путем агрегации (например, суммирования) Quality of Result Statistics этих общих документов.
3. Фильтрация по качеству: Если Quality Score не удовлетворяет порогу качества, пара отбрасывается. (Примечание: порог может быть ниже, если Q2 является суперстрокой Q1).
4. Расчет Diversity Score: Идентифицируются документы, которые релевантны Q2, но НЕ входят в топ результатов Q1. Diversity Score рассчитывается путем агрегации Quality of Result Statistics этих уникальных для Q2 документов.
5. Фильтрация по разнообразию: Если Diversity Score не удовлетворяет порогу разнообразия, пара отбрасывается.
6. Географическая фильтрация: Проверяется, содержит ли Q2 геолокацию. Если да, а Q1 нет, пара отбрасывается.
7. Сохранение кандидата: Если пара прошла все фильтры, Q2 сохраняется как Candidate Refinement для Q1.

Фаза Б: Фильтрация и Ранжирование Кандидатов (Candidate Refinement Filtering)

1. Ранжирование кандидатов: Для Q1 все его Candidate Refinements ранжируются (например, по Quality Score, популярности запроса или CTR).
2. Инициализация: Создается пустой набор Confirmed Refinements. Инициализируется набор Seen Documents (например, топовыми документами Q1 или топовыми документами самого высокоранжированного кандидата).
3. Итеративный отбор (Intra-Suggestion Diversity): Кандидаты обрабатываются в порядке ранжирования.
   • Для текущего кандидата (C) рассчитывается Intra-Suggestion Diversity Score между его топовыми документами и текущим набором Seen Documents.
   • Если оценка удовлетворяет порогу (т.е. кандидат достаточно отличается от уже выбранных):
     • Кандидат C добавляется в Confirmed Refinements.
     • Топовые документы C добавляются в Seen Documents.
4. Завершение: Процесс продолжается до достижения желаемого числа уточнений или до конца списка кандидатов.

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

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

Система полностью полагается на поведенческие факторы, собранные поисковой системой и записанные в Result Selection Logs.

• Поведенческие факторы (User Preference Data): Это критически важные данные. Включают:
  • Запрос (Q).
  • Выбранный документ (D).
  • Время просмотра документа (Dwell Time, T). Используется для взвешивания кликов (например, длинные и короткие клики).
  • Язык (L) и Страна (C) пользователя (для сегментации данных).
  • Данные об импрессиях (показах) документов, включая те, которые не были выбраны.
  • Дополнительные данные: позиции кликов, информация о сессии, IP-адрес, User Agent.
• Географические факторы: Используются данные о географических объектах в тексте запроса для применения географического фильтра (Claim 1).

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

• Quality of Result Statistic: Агрегированная оценка релевантности документа запросу. Патент упоминает варианты расчета:
  • Среднее или сумма взвешенных долгих кликов (weighted long clicks).
  • Доля кликов (Click fraction): например, число кликов, деленное на число показов (impressions).
• Quality Score: Рассчитывается для пары запросов (Q1, Q2). Это агрегация (например, сумма или среднее) Quality of Result Statistics для документов, общих для Q1 и Q2.
• Diversity Score: Рассчитывается для пары запросов (Q1, Q2). Это агрегация Quality of Result Statistics для документов, которые релевантны Q2, но не входят в топ результатов Q1.
• Intra-Suggestion Diversity Score: Рассчитывается между кандидатом и набором Seen Documents. Метод расчета аналогичен Diversity Score.
• Пороговые значения (Thresholds): Используются для всех трех ключевых оценок. Устанавливаются эмпирически для баланса между количеством и качеством уточнений.

Выводы

1. Поведенческие сигналы определяют связи между запросами: Патент демонстрирует, как Google строит карту связанных запросов, основываясь на том, куда кликают пользователи, а не только на семантическом анализе текстов. Если пользователи часто переходят на одни и те же документы по разным запросам, эти запросы считаются связанными (Quality Score).
2. Двойное требование: Связь и Новизна: Для того чтобы запрос стал уточнением, недостаточно быть просто связанным. Он должен предлагать пользователю новые, качественные результаты, которых не было в исходной выдаче (высокий Diversity Score). Это фильтр против слишком похожих или бесполезных уточнений.
3. Разнообразие внутри блока уточнений (Intra-Suggestion Diversity): Google активно стремится к тому, чтобы предложенные уточнения были разнообразны между собой. Итеративный процесс отбора гарантирует, что каждое добавленное уточнение привносит новизну по сравнению с уже выбранными.
4. Защита от нерелевантной локализации: В патенте описан строгий механизм (Claim 1): система не будет предлагать локализованные уточнения (например, «ресторан в Берлине») для общих запросов (например, «ресторан»), если пользователь не указал локацию в исходном запросе.
5. Важность удовлетворенности пользователя: Все ключевые метрики основаны на Quality of Result Statistics. Это подчеркивает, что документы, получающие положительные поведенческие сигналы (например, долгие клики), являются основой для построения связей в поиске.

Практика

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

• Оптимизация под удовлетворенность пользователя (User Satisfaction): Поскольку весь механизм основан на User Preference Data, критически важно создавать контент, который полностью отвечает на запрос и стимулирует положительные поведенческие сигналы (высокий CTR, длительное время взаимодействия). Это повышает Quality of Result Statistic ваших документов.
• Построение Topical Authority через кластеризацию контента: Создавайте контент, охватывающий смежные интенты и подтемы. Это увеличивает вероятность того, что ваши документы будут релевантны как исходному, так и уточняющим запросам, тем самым усиливая связь между этими запросами в глазах Google (повышая Quality Score через ваш контент).
• Анализ блока «Связанные запросы» для расширения семантики: Изучайте, какие уточнения предлагает Google. Это прямой сигнал о том, какие темы система считает связанными (на основе поведения пользователей) и достаточно разнообразными. Интегрируйте эти темы в свою контент-стратегию.
• Создание разнообразного контента для разных углов темы: Учитывая Diversity Score и Intra-Suggestion Diversity, важно покрывать тему с разных сторон. Если вы создаете несколько страниц по одной теме, убедитесь, что они нацелены на разные интенты и предлагают уникальную ценность.

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

• Игнорирование поведенческих метрик: Фокус только на тексте и ссылках без учета того, как пользователи взаимодействуют с контентом. Низкие Quality of Result Statistics не позволят вашему контенту участвовать в формировании связей между запросами.
• Создание дублирующего или слишком похожего контента (Каннибализация): Создание множества страниц, которые отвечают на один и тот же интент, неэффективно. Механизмы Diversity Score и Intra-Suggestion Diversity предпочитают результаты, которые привносят новизну.
• Нерелевантная локализация контента (для общих сайтов): Попытка оптимизировать общие информационные статьи под конкретные города может быть неэффективной, так как патент описывает фильтр (Claim 1), блокирующий показ локализованных уточнений для общих запросов.

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

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

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

Сценарий 1: Применение фильтров Quality и Diversity

1. Исходный запрос (Q1): «Уход за орхидеями».
2. Кандидат А: «Как поливать орхидеи». У них много общих качественных результатов (Высокий Quality Score). Кандидат А также имеет уникальные качественные результаты про графики полива (Высокий Diversity Score). Результат: Принят как уточнение.
3. Кандидат Б: «Уход за цветами орхидеи». Почти все результаты совпадают с Q1 (Высокий Quality Score). Уникальных результатов мало (Низкий Diversity Score). Результат: Отклонен как слишком похожий.

Сценарий 2: Применение географического фильтра

1. Исходный запрос (Q1): «Ремонт iPhone».
2. Кандидат А: «Ремонт iPhone в Берлине». Q1 не содержит локации, Q2 содержит. Результат: Отклонен согласно географическому фильтру (Claim 1).
3. Исходный запрос (Q2): «Ремонт iPhone в Мюнхене».
4. Кандидат Б: «Замена стекла iPhone Мюнхен». Оба запроса содержат локацию. Результат: Проходит географический фильтр (далее оценивается по Quality/Diversity).

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