Как Google фильтрует персонализированные предложения запросов на основе контента просматриваемой страницы

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

Candidate set of search query suggestions (Набор кандидатов в предложения запросов)

Предварительный список предложений, сгенерированный на основе истории поиска пользователя, до его фильтрации по релевантности контенту.

Cosine Similarity Score (Оценка косинусного сходства)

Метрика, используемая для определения тематического сходства между двумя ресурсами путем сравнения их Vocabulary term vectors. Используется для расчета Evaluation Relevance Threshold.

Evaluation Relevance Threshold (Порог релевантности для оценки)

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

Relevance Score (Оценка релевантности)

Числовая мера релевантности предложения запроса контенту просматриваемого ресурса.

Relevancy Criterion (Критерий релевантности)

Условие, которому должно удовлетворять предложение, чтобы считаться релевантным контенту ресурса (например, превышение минимального Relevance Score).

Search History Data (Данные истории поиска)

Агрегированные данные о предыдущей поисковой активности пользователя (логи запросов Query Logs, логи кликов Click Logs, извлеченные темы, домены и сниппеты), связанные с уникальным идентификатором.

Term Frequency Function (Функция частоты термина)

Функция, определяющая частоту терминов из предлагаемого запроса в контенте ресурса. Используется для расчета Relevance Score.

Vocabulary term vector (Вектор терминов словаря)

Векторное представление контента ресурса, где каждый элемент представляет вес (например, частоту) определенного термина (исключая стоп-слова).

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

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

1. Система получает контент первой веб-страницы, на которую перешли по клику на результат поиска.
2. Система получает набор кандидатов (candidate set), основанный на истории поиска (search history data) пользователя.
3. Для каждого кандидата:
   • Вычисляется Relevance Score, измеряющий релевантность кандидата контенту страницы.
   • Определяется, удовлетворяет ли кандидат relevancy criterion.
   • Если ДА, кандидат включается в финальный набор; если НЕТ — исключается.
4. Финальный набор предоставляется пользователю.

Ядро изобретения — фильтрация персонализированных предложений (основанных на истории) по релевантности текущему контенту.

Claim 7 и 8 (Зависимые): Уточняют место выполнения процесса. Claim 7 описывает реализацию на стороне клиента (используя локальную историю), а Claim 8 — на стороне сервера (поисковой системы).

Claim 9 (Зависимый): Расширяет процесс на последующую навигацию (переход по ссылкам с первой страницы).

1. Система получает контент последующего ресурса.
2. Определяется, соответствует ли он Evaluation Relevance Threshold.
3. Если ДА, то процесс из Claim 1 повторяется: кандидаты фильтруются по релевантности контенту этого последующего ресурса.

Это вводит ограничение на глубину или тематическое отклонение навигации.

Claims 10 и 11 (Зависимые): Определяют варианты реализации Evaluation Relevance Threshold.

• Claim 10: Порог определяется как нахождение в пределах N последующих кликов от первого ресурса (ограничение по глубине).
• Claim 11: Порог определяется как превышение минимальной оценки косинусного сходства (cosine similarity score) между векторными представлениями контента первого и последующего ресурсов (ограничение по тематике).

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

1. Система получает контент ресурса и набор кандидатов.
2. Условие 1: Если ресурс является результатом прямого клика с SERP (первый клик):
   • Предложения включаются в финальный набор независимо от контента ресурса (independent of the content of the resource). Фильтрация по контенту не применяется.
3. Условие 2: Если ресурс выбран в пределах N последующих кликов (дальнейшая навигация):
   • Применяется фильтрация на основе relevancy criterion по отношению к контенту ресурса (как в Claim 1).
4. Финальный набор предоставляется пользователю.

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

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

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

QUNDERSTANDING – Понимание Запросов

Система использует Search History Data для понимания долгосрочных интересов пользователя и контекста текущей сессии. Это необходимо для генерации релевантного набора кандидатов (candidate set). Изобретение расширяет этот этап за пределы SERP на страницы ресурсов.

INDEXING – Индексирование и извлечение признаков (Косвенно)

Для работы механизма необходимо анализировать контент просматриваемого ресурса. Это требует доступа к контенту и извлечения признаков (например, частоты терминов или Vocabulary term vectors), что обычно происходит на этапе индексирования или при анализе в реальном времени.

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

• Контент просматриваемого ресурса.
• Уникальный идентификатор пользователя.
• Search History Data (логи запросов, кликов, темы).
• Исходный поисковый запрос.
• Данные о навигации (путь от SERP до текущего ресурса).

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

• Final set of search query suggestions, адаптированный к контенту ресурса и истории пользователя.

На что влияет

• Специфические запросы: Наиболее полезен для информационных и исследовательских запросов, где пользователь изучает тему, склонен просматривать несколько страниц и уточнять свой запрос по мере получения информации.
• Типы контента: Влияет на страницы с достаточным количеством текста для анализа (статьи, новости, обзоры), где можно рассчитать term frequency или создать vocabulary term vector.

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

Алгоритм применяется при выполнении следующих условий:

• Триггер активации: Пользователь перешел с SERP на ресурс и, возможно, продолжил навигацию.
• Условия работы: Наличие достаточного объема Search History Data для генерации кандидатов.
• Пороговые значения (Evaluation Relevance Threshold): При последующей навигации алгоритм работает, только если текущая страница удовлетворяет порогу (не слишком далеко по N кликам ИЛИ достаточно похожа по контенту на исходную страницу).
• Вариативность активации (Сравнение Claim 1 и Claim 12): Патент предлагает два варианта: фильтрация по контенту применяется сразу (Claim 1) или только начиная со второй страницы навигации (Claim 12).

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

Описанный процесс может выполняться как на клиенте, так и на сервере.

Этап 1: Сбор данных и инициализация

1. Получение запроса и обработка SERP: Пользователь отправляет запрос, система возвращает результаты.
2. Обновление истории: Исходный запрос и связанная информация (например, сниппеты из SERP) сохраняются в Search History Data.
3. Переход на ресурс: Пользователь выбирает результат и запрашивает ресурс. Система получает его контент.
4. Генерация кандидатов: Система генерирует candidate set of search query suggestions, основываясь на Search History Data.

Этап 2: Фильтрация предложений

5. Проверка условий фильтрации (Опционально, согласно Claim 12):
   • Если это первый клик с SERP, система может пропустить фильтрацию по контенту и перейти к Этапу 3.
6. Фильтрация по релевантности: Для каждого кандидата:
   • Вычисляется Relevance Score по отношению к контенту текущего ресурса (например, с использованием Term Frequency Function).
   • Проверяется relevancy criterion (превышает ли Relevance Score порог или входит ли в Топ-N).
   • Кандидат включается или исключается из финального набора.

Этап 3: Отображение и навигация

7. Отображение результатов: Финальный набор предложений отображается пользователю.
8. Последующая навигация: Если пользователь переходит на другую страницу.
9. Проверка порога (Evaluation Relevance Threshold): Система проверяет глубину N кликов ИЛИ косинусное сходство с исходной страницей.
   • Если порог не достигнут: Процесс останавливается.
   • Если порог достигнут: Возврат к Этапу 2 (Шаг 6) для анализа контента новой страницы.

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

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

• Контентные факторы: Текст просматриваемого ресурса. Система анализирует его для определения частоты терминов (term frequency) и создания векторов терминов (vocabulary term vectors), исключая стоп-слова.
• Поведенческие факторы: Search History Data. Включает логи запросов (Query Logs), логи кликов (Click Logs). Также упоминается возможность извлечения данных из сниппетов на SERP, доменных имен и тем (topics), к которым принадлежат предыдущие запросы.
• Пользовательские факторы: Unique identifier (cookie, аккаунт) для связи запросов с историей. Данные навигации (последовательность кликов) для определения глубины сессии.

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

• Relevance Score: Измеряет релевантность предложения запроса контенту. В патенте предлагается использовать Term Frequency Function: частота появления терминов из предложения в контенте ресурса. Для многословных запросов значения могут усредняться.
• Relevancy Criterion: Определяет, включать ли предложение в финальный набор. Варианты реализации:
  • Сравнение Relevance Score с минимальным порогом.
  • Нормализация оценок и выбор Топ-N предложений с наивысшими оценками.
• Evaluation Relevance Threshold: Определяет, активна ли функция при навигации. Варианты расчета:
  • Глубина кликов (N): Количество последующих переходов по ссылкам от исходного результата поиска (например, N=5, 10 или 15).
  • Cosine Similarity Score: Сравнение vocabulary term vectors текущей и исходной страниц для определения тематического сходства. Векторы строятся на основе не-стоп слов, вес термина пропорционален частоте его встречаемости.

1. Контекст как фильтр персонализации: История поиска пользователя определяет его интересы (кандидатов), но контент текущей страницы определяет контекст. Финальные предложения должны быть релевантны и тому, и другому. Персонализированные предложения фильтруются, если они не соответствуют контенту на экране.
2. Методы анализа контента (Classic IR): Для оценки релевантности и сходства контента система использует классические методы Information Retrieval: Term Frequency (для оценки запрос-документ) и Vocabulary Term Vectors с Cosine Similarity (для оценки документ-документ).
3. Отслеживание сессий и дрейф намерений: Google анализирует путь пользователя по сайту после ухода с SERP. Механизм Evaluation Relevance Threshold (ограничение по глубине N кликов или по схожести контента) определяет границы, в которых система считает текущую активность связанной с исходным запросом (определяет дрейф намерений).
4. Разная логика для первого клика (Claim 12): Патент описывает возможность разной логики обработки. Для первого ресурса, выбранного из SERP, предложения могут выдаваться на основе истории без фильтрации по контенту. Фильтрация активируется только при дальнейшей навигации.
5. Гибкость реализации (Клиент/Сервер): Система может работать как на стороне сервера, так и на стороне клиента (браузер или тулбар), что позволяет обрабатывать локальную историю поиска с учетом приватности.

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

• Обеспечение четкой тематической фокусировки контента: Поскольку система использует Term Frequency и векторные представления для определения контекста страницы, контент должен быть четко сфокусирован на теме. Это повышает вероятность того, что система рассчитает высокий Relevance Score для предложений запросов, связанных с вашей тематикой.
• Использование ясной и релевантной терминологии: Насыщение контента релевантными терминами и сущностями помогает системе (включая этот алгоритм) правильно интерпретировать содержание страницы и ее сходство с другими страницами (Vocabulary term vector).
• Оптимизация внутренней перелинковки для тематической связности: Система отслеживает навигацию и использует cosine similarity (Claim 11) между страницами, чтобы определить, сохраняется ли контекст сессии. Внутренние ссылки должны вести на тематически близкие страницы. Резкие тематические сдвиги при навигации могут привести к превышению Evaluation Relevance Threshold.
• Оптимизация под поисковые сессии: Понимайте путь пользователя (User Journey). Оптимизируйте контент так, чтобы он соответствовал как исходному запросу, так и потенциальным последующим уточнениям, которые Google может предложить, основываясь на содержании вашей страницы.

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

• Смешивание несвязанных тем на одной странице (Content Dilution): Это затруднит системе определение четкого контекста страницы. Relevance Score для конкретных запросов будет низким, так как ни один кандидат не достигнет relevancy criterion.
• Использование вводящей в заблуждение внутренней перелинковки: Размещение ссылок на совершенно не связанные по тематике страницы. Если тематическое сходство (cosine similarity) между страницей входа и целевой страницей низкое, система определит, что контекст пользователя изменился (Claim 11).
• Поверхностный контент (Thin Content): Контент с недостаточным количеством релевантных терминов может не обеспечить достаточный Relevance Score для генерации контекстных предложений.

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

Этот патент подтверждает стратегическую направленность Google на понимание всего пути пользователя (Search Journey) и контекста сессии, а не только отдельных запросов и страниц. Для SEO это означает, что оптимизация должна учитывать не только привлечение пользователя из поиска, но и поддержку его информационной потребности после клика. Стратегия должна фокусироваться на создании тематических кластеров и обеспечении логичной, тематически связанной навигации внутри сайта, чтобы соответствовать моделям, которые Google использует для анализа сходства контента и отслеживания контекста сессии.

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

Сценарий 1: Фильтрация предложений на основе контента

Пользователь ищет "лучшие пляжи Бали". В его истории много запросов о бюджетных путешествиях ("хостелы Бали", "дешевые перелеты").

1. Переход на статью: Пользователь кликает на вашу статью "Топ-10 пляжей Бали".
2. Генерация кандидатов (на основе истории): Система генерирует: "хостелы на Бали", "дешевые авиабилеты на Бали", "аренда скутера на Бали".
3. Фильтрация по контенту:
   • Если ваша статья сфокусирована только на люксовых отелях и ресторанах, предложения "хостелы на Бали" получат низкий Relevance Score и будут отфильтрованы.
   • Действие SEO: Если ваша аудитория — бюджетные путешественники, убедитесь, что статья упоминает варианты недорогого жилья рядом или советы по экономии. Это повысит Relevance Score для целевых предложений.

Сценарий 2: Ограничение по схожести контента (Evaluation Relevance Threshold)

1. Исходный контекст: Пользователь читает статью о "Влиянии рецессии на BigCo" (Ресурс 1).
2. Навигация: Пользователь кликает на ссылку, ведущую на домашнюю страницу BigCo (Ресурс 2).
3. Проверка порога: Система сравнивает Cosine Similarity между Ресурсом 1 и Ресурсом 2. Сходство достаточное. Генерация предложений (например, "вакансии BigCo") продолжается, но фильтруется по контенту Ресурса 2.
4. Дальнейшая навигация: С домашней страницы пользователь переходит на страницу обзора нового продукта BigCo (Ресурс 3).
5. Проверка порога: Система сравнивает Cosine Similarity между Ресурсом 1 и Ресурсом 3. Сходство низкое (статья о рецессии vs обзор продукта). Порог не пройден.
6. Результат: Система прекращает генерировать подсказки, связанные с исходным контекстом рецессии/вакансий, так как интент пользователя изменился.