Как Google использует паттерны совместного просмотра документов (Co-visitation) для персонализации поиска и рекомендаций

Описание

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

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

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

Запатентован метод определения связанных документов на основе анализа агрегированных данных о последовательном просмотре. Система строит модель, которая определяет вероятность просмотра документа-кандидата в течение определенного window of time после того, как исходный документ был показан (presented) пользователю на странице результатов поиска (SERP). Рассчитывается Strength of Relationship Score между парами документов, эти оценки агрегируются, позволяя найти наиболее связанные документы для целого набора исходных документов.

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

Система работает в два этапа: офлайн-моделирование и онлайн-применение.

• Офлайн (Моделирование): Анализируются логи поиска. Система отслеживает, какие результаты были показаны пользователю и какие документы он просмотрел вскоре после этого. На основе этих данных строится Model Database, хранящая агрегированные данные о совместном просмотре, часто в виде условных вероятностей P(Viewed_Y | Presented_X).
• Онлайн (Применение): Система (Set Improver Engine) получает исходный набор документов (например, историю просмотров пользователя или результаты текущего запроса). Для каждого документа-кандидата рассчитывается Aggregate Strength of Relationship Score путем суммирования его индивидуальных оценок связи с каждым из исходных документов. Наиболее релевантные кандидаты выбираются и используются для рекомендаций, дополнения выдачи или переранжирования.

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

Высокая. Патент описывает фундаментальные механизмы для систем рекомендаций (типа «пользователи, которые смотрели X, также смотрели Y») и контекстуального поиска (session-based ranking). Понимание намерений пользователя в рамках сессии и предоставление персонализированных рекомендаций являются ключевыми направлениями развития современных поисковых систем.

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

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

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

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

Aggregate Strength of Relationship Score (Агрегированная оценка силы связи)

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

Candidate Documents (Документы-кандидаты)

Набор документов, из которых система выбирает связанные документы.

First Documents / Initial Set (Исходный набор документов)

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

Model Database (База данных модели)

Хранилище агрегированных данных о поведении пользователей. Содержит записи о парах документов (показанный и просмотренный позже) и связанные с ними метрики.

P(g) (Popularity / Популярность)

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

P(g|i) (Conditional Probability / Условная вероятность)

Вероятность того, что документ-кандидат (g) будет просмотрен, при условии, что исходный документ (i) был показан пользователю в результатах поиска. Часто используется как Strength of Relationship Score.

Second Documents / Related Set (Связанный набор документов)

Документы, выбранные из набора кандидатов на основе высоких агрегированных оценок силы связи с исходным набором.

Set Improver Engine (Механизм улучшения набора)

Компонент системы, отвечающий за генерацию связанного набора документов из исходного набора.

Strength of Relationship Score (Оценка силы связи)

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

User Selection Data (Данные о выборе пользователей)

Данные, указывающие, просмотрел ли пользователь документ-кандидат в течение определенного окна времени после того, как исходный документ был показан ему на SERP.

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

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

1. Агрегирование User Selection Data для множества пользователей.
2. Данные определяют, просмотрел ли пользователь документ-кандидат в течение window of time после того, как результат поиска для исходного документа был показан (presented) на SERP в ответ на запрос.
3. Определение Strength of Relationship Score между каждой парой (кандидат, исходный документ) на основе этих агрегированных данных.
4. Расчет Aggregate Strength of Relationship Score для каждого кандидата на основе его индивидуальных оценок.
5. Выбор связанных документов (Second Documents) на основе агрегированных оценок.

Claim 3 (Зависимый от 1): Уточняет процесс агрегации данных.

Данные пользователя масштабируются (усиливаются) с помощью scoring factor, если пользователь просмотрел документ-кандидат после того, как выбрал (кликнул) исходный документ на SERP. Это означает, что клик по исходному документу имеет больший вес, чем просто его показ (impression).

Claim 4 (Зависимый от 1): Уточняет расчет индивидуальной оценки связи.

Расчет включает использование популярности (popularity) документа-кандидата для нормализации Strength of Relationship Score.

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

Strength of Relationship Score определяется как вероятность того, что документ-кандидат будет просмотрен, при условии, что исходный документ был показан пользователю на SERP (условная вероятность P(g|i)).

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

1. Получение данных о том, что пользователь предпочитает (preferred) один или несколько исходных документов.
2. Расчет веса (document weight) для каждого предпочитаемого документа.
3. При расчете Aggregate Strength of Relationship Score индивидуальные оценки связи для предпочитаемых документов взвешиваются с использованием этих весов.

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

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

CRAWLING / INDEXING (Сбор данных и индексирование)
На этих этапах происходит сбор сырых поведенческих данных (логи запросов, показы результатов, клики, последующие просмотры). Офлайн-процессы анализируют эти логи для построения и обновления Model Database, которая хранит связи между документами.

RANKING / RERANKING (Ранжирование и Переранжирование)
Механизм активно применяется на этих этапах для модификации результатов поиска:

• Session-Based Ranking (Ранжирование на основе сессии): Система использует документы, просмотренные в текущей сессии, для переранжирования результатов по текущему запросу. Это форма краткосрочной персонализации.
• Result Augmentation (Дополнение результатов): Система может дополнять стандартный набор результатов связанными документами, найденными с помощью этого механизма, даже если они не были изначально отобраны как релевантные запросу.

QUNDERSTANDING (Понимание Запросов)
Может использоваться для генерации предлагаемых запросов (Suggested Queries). Система находит связанные документы, а затем идентифицирует запросы, которые часто приводят к этим документам.

METASEARCH (Метапоиск и Смешивание)
Используется для генерации блоков рекомендаций (Suggested Documents), которые могут отображаться на SERP или в других интерфейсах (например, тулбарах).

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

• Исходный набор документов (First Documents).
• Model Database (агрегированные поведенческие данные).
• (Опционально) Веса для исходных документов (document weights).

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

• Связанный набор документов (Second Documents).
• (Опционально) Агрегированные оценки связи (Aggregate Strength of Relationship Scores).

На что влияет

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

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

• Триггеры активации: Механизм может активироваться при получении нового поискового запроса в рамках активной сессии (для переранжирования), при запросе рекомендаций (например, через тулбар) или для дополнения стандартной выдачи.
• Временные рамки: Ключевым условием является временное окно (window of time) между показом первого документа и просмотром второго. В патенте упоминаются различные варианты: фиксированный период (например, 2 часа, 24 часа) или длительность пользовательской сессии.

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

Процесс генерации связанного набора документов (работа Set Improver Engine):

1. Получение исходных данных: Система получает исходный набор документов (First Documents) и доступ к Model Database.
2. Определение кандидатов: Идентифицируется набор документов-кандидатов (Candidate Documents). Это могут быть все документы в индексе или подмножество, связанное с исходными документами в модели.
3. Расчет индивидуальных оценок связи: Для каждой пары (Документ-кандидат G, Исходный документ I) система определяет Strength of Relationship Score.
   • Извлекаются агрегированные данные из модели (например, P(G|I)).
   • Применяется масштабирование (scoring factor), если исходный документ был кликнут, а не просто показан.
   • (Опционально) Применяется нормализация по популярности P(G).
4. Расчет агрегированных оценок: Для каждого документа-кандидата G индивидуальные оценки суммируются (или взвешенно суммируются, если используются веса Wi) для получения Aggregate Strength of Relationship Score S(G).
   Пример формулы: S(g) = Σ Wi * P(g|i).
5. Нормализация и масштабирование агрегированных оценок: Агрегированные оценки могут быть дополнительно нормализованы по популярности P(G) или масштабированы (например, через логарифмирование).
6. Выбор связанных документов: Система выбирает Second Documents из набора кандидатов. Это может быть Топ-N документов с наивысшими агрегированными оценками или все документы, чья оценка превышает заданный порог.

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

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

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

• Поведенческие факторы:
  • Показы (Impressions): Данные о том, что результат поиска для исходного документа был показан пользователю на SERP.
  • Просмотры (Views/Clicks): Данные о том, что пользователь просмотрел документ-кандидат.
  • Временные метки: Время показа и время просмотра (используется для определения window of time).
  • Выбор (Selection): Данные о том, был ли исходный документ кликнут пользователем (используется для бустинга).
  • Dwell Time (Опционально): Продолжительность просмотра документа. Может использоваться как фильтр или вес.
  • Пользовательские предпочтения (Опционально): Явные или неявные сигналы о предпочтении исходных документов (используются для взвешивания).
• Системные данные:
  • Запросы, в ответ на которые были показаны документы.

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

• Strength of Relationship Score (P(g|i)): Рассчитывается на основе агрегированных данных. Например, делением количества пользователей, которые просмотрели G после показа I, на общее количество пользователей, которым был показан I.
• Popularity (P(g)): Общая частота просмотра документа G всеми пользователями. Используется для нормализации.
• Document Weight (Wi): Вес, присваиваемый исходному документу I. Может зависеть от предпочтений пользователя, времени просмотра или ранга документа в исходной выдаче.
• Aggregate Strength of Relationship Score (S(g)): Рассчитывается по формулам агрегации. Примеры из патента:
  • Простая сумма: S(g) = Σ P(g|i)
  • Взвешенная сумма: S(g) = Σ Wi * P(g|i)
  • Нормализованная взвешенная сумма: S(g) = [Σ Wi * P(g|i)] / P(g) (упрощенная версия).

Выводы

1. Поведенческие связи доминируют: Патент описывает систему, которая устанавливает связи между документами исключительно на основе паттернов совместного просмотра пользователями (co-visitation). Анализ контента или ссылочная структура не используются в этом конкретном механизме.
2. Показ (Impression) vs. Клик (Selection): Основной механизм (Claim 1) срабатывает, даже если исходный документ был только показан на SERP, но не кликнут. Однако, если пользователь кликнул на исходный документ перед просмотром кандидата, эта связь получает значительное усиление (scoring factor, Claim 3).
3. Нормализация по популярности критична: Система использует общую популярность документа P(g) для нормализации оценок (Claim 4). Это предотвращает доминирование глобально популярных ресурсов (например, Wikipedia, Amazon) в рекомендациях, если связь не является специфичной для исходного контекста.
4. Контекст и Временное окно: Связь устанавливается только в том случае, если просмотр произошел в течение определенного временного окна (window of time) после показа, что обеспечивает актуальность и контекстуальную релевантность связи.
5. Многоцелевое применение: Описанный механизм является базовым и используется для разных задач: дополнение выдачи (Augmentation), переранжирование в рамках сессии (Session-based ranking) и генерация рекомендаций (Suggested Documents/Queries).

Практика

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

• Оптимизация под User Journey (Путь пользователя): Необходимо проектировать контент и структуру сайта, понимая не только изолированный интент пользователя, но и его вероятные следующие шаги. Анализируйте, откуда приходят пользователи и куда они уходят. Сайт должен стремиться стать частью релевантной цепочки просмотров в своей нише.
• Удовлетворение эволюционирующего интента: Для сложных тематик создавайте кластеры контента, которые отвечают на последовательные вопросы пользователя. Это увеличивает вероятность того, что ваш контент будет высоко ранжироваться при активации session-based ranking, когда пользователь уточняет свой запрос в рамках сессии.
• Повышение специфичности связей (Beating Normalization): Чтобы получать трафик из рекомендаций, недостаточно быть просто популярным сайтом. Необходимо иметь сильные и специфичные связи с конкретными тематиками. Создавайте узкоспециализированный, глубокий контент, который часто просматривается совместно с другим релевантным контентом в нише.
• Анализ совместной встречаемости в нише: Изучайте, какие сайты часто просматриваются пользователями до или после вашего. Если вы обнаружите сильные паттерны, это может указывать на возможности для создания контента, который перехватит этот интерес.

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

• Создание тупиковых страниц (Dead-end pages): Страницы, которые удовлетворяют интент, но не предлагают пользователю логического продолжения пути (внутри сайта или вовне), уменьшают вероятность формирования сильных поведенческих связей, используемых в этом патенте.
• Изолированная оптимизация под запрос: Фокус исключительно на попадании в Топ по конкретному запросу без учета контекста сессии. Такой подход может привести к потере позиций, если система активирует session-based ranking и предпочтет результаты, лучше соответствующие предыдущим действиям пользователя.
• Нагон нецелевого трафика для повышения популярности P(g): Общая популярность используется для нормализации (деления), а не для бустинга. Увеличение P(g) без увеличения специфичных связей P(g|i) может даже снизить итоговую агрегированную оценку.

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

Этот патент подтверждает стратегическую важность поведенческих факторов в понимании связей между документами. Он демонстрирует, как Google использует «мудрость толпы» (wisdom of the crowds) для выявления релевантности, которая не может быть определена через текст или ссылки. Для SEO это означает, что долгосрочная стратегия должна быть направлена на интеграцию сайта в естественные пути исследования информации пользователями в интернете. Понимание контекста сессии становится не менее важным, чем понимание отдельного запроса.

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

Сценарий 1: Session-Based Ranking (Переранжирование в рамках сессии)

1. Действие пользователя: Пользователь ищет «лучшие треккинговые ботинки» (Query 1) и просматривает несколько обзоров (First Documents).
2. Следующий запрос: Через 5 минут пользователь ищет «Йосемити» (Query 2).
3. Действие системы: Система определяет, что Query 2 находится в той же сессии. Она использует просмотренные обзоры ботинок (First Documents) для генерации связанных документов (Second Documents) с помощью Set Improver Engine. В Second Documents попадают статьи о походах и маршрутах в Йосемити.
4. Результат: Система переранжирует результаты для Query 2, повышая статьи о походах (которые есть в Second Documents) и понижая общую информацию о парке (отели, история). Пользователь видит выдачу, адаптированную под его текущий интерес к походам.

Сценарий 2: Suggested Documents (Рекомендации)

1. Действие пользователя: Пользователь в течение недели читал статьи о выборе ипотеки и использовании онлайн-калькуляторов (история просмотров = First Documents).
2. Действие системы: Система рекомендаций (например, в Google Discover или аналогичном сервисе) использует эту историю для генерации связанных документов. Model Database показывает сильную связь между чтением об ипотеке и последующим просмотром сайтов о страховании недвижимости.
3. Результат: Система предлагает пользователю статьи на тему «Как сэкономить на страховании недвижимости», даже если он явно не искал эту тему.

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