Как Google использует историю поиска и браузинга пользователя для персонализации и изменения результатов выдачи

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

Client Assistant (Клиентский ассистент)

Локально резидентная программа на клиентском устройстве (например, плагин для браузера или тулбар), предназначенная для перехвата или определения действий пользователя и передачи их на сервер.

ContentID (Идентификатор контента)

Идентификатор контента, связанного с событием. Для клика по результату или просмотра страницы это может быть URL или идентификатор документа. Для рекламы это может быть идентификатор объявления или его целевой страницы (landing page).

Derived Data (Производные данные)

Информация, выведенная из данных о событиях (Event-Based Data). Например, профиль пользователя, Score для ContentID или агрегированные оценки.

Event-Based Data (Данные о событиях)

Записанные действия пользователя. Включают типы: Query Event, Result Click Event, Ad Click Event, Browsing Event, Product Event.

History Score (Оценка истории)

Оценка, присваиваемая событию. Может быть основана на времени, прошедшем с момента записи события (например, уменьшаться со временем).

Preferred Locations (Предпочитаемые локации)

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

Prior Activities (Прошлые действия)

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

Query Session (Сессия запросов)

Набор связанных запросов (и ассоциированных с ними событий, таких как клики), выполненных в течение одного сеанса браузинга (browsing session).

Score (Оценка Контента)

Производная оценка, присвоенная контенту (ContentID). Может основываться на количестве кликов пользователя, времени пребывания (stay-time), времени с последнего просмотра, а также на положительной или отрицательной обратной связи (кликнул или проигнорировал).

Search Result Ranking Value (Оценка ранжирования результата поиска)

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

Session Group (Группа сессий)

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

Stay-time (Время пребывания)

Оценка времени, которое пользователь провел, просматривая контент. Используется как фактор при расчете Score контента и определении Preferred Locations.

User Information Database

База данных, хранящая информацию об активности пользователя, включая Event-Based Data и Derived Data.

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

Патент содержит несколько ключевых независимых пунктов, описывающих разные аспекты персонализации. Анализ основан на финальных утвержденных Claims (1-10).

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

1. Система получает текущий запрос от пользователя.
2. Идентифицируется набор релевантных результатов для текущего запроса.
3. Система идентифицирует один или несколько прошлых запросов этого пользователя, которые похожи на текущий, но отличаются от него (similar to, but different from).
4. Определяются результаты, соответствующие этим прошлым запросам (prior search results).
5. Система находит те из prior search results, которые отсутствуют в наборе результатов текущего запроса.
6. Текущие результаты и найденные отсутствующие прошлые результаты объединяются (combined search results).
7. Объединенный набор возвращается пользователю.

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

1. Система получает запрос и идентифицирует набор результатов поиска.
2. Система идентифицирует history event, релевантное текущему запросу.
3. Это событие должно быть одним из: (а) ранее выбранная пользователем реклама, (б) прошлый запрос пользователя (отличающийся от текущего), или (в) ранее просмотренный обзор продукта.
4. Система возвращает пользователю и стандартные результаты поиска, и идентифицированное историческое событие.

Claim 7 (Независимый пункт): Описывает комплексный метод, включающий дополнение и переранжирование (Reranking) на основе истории.

1. [Шаги включают логику, аналогичную Claim 1: идентификация и добавление отсутствующих результатов из прошлых похожих сессий].
2. Возврат результатов включает:
   • Объединение текущих и отсутствующих прошлых результатов в combined set.
   • Идентификация в этом объединенном наборе результатов, которые ранее уже возвращались пользователю в ответ на прошлые запросы.
   • Модификация search result ranking value этих идентифицированных результатов на основе прошлых действий (prior activities) пользователя с ними.
   • Упорядочивание объединенного набора в соответствии с модифицированными оценками ранжирования.

Claims 8, 9, 10 (Зависимые от 7): Детализируют логику модификации ранжирования.

• Claim 8: Оценка ранжирования увеличивается, если пользователь ранее выбирал (кликал) этот результат.
• Claim 9: Оценка ранжирования увеличивается пропорционально количеству раз, когда пользователь посещал страницу, связанную с результатом.
• Claim 10: Оценка ранжирования уменьшается, если пользователь ранее не выбрал (проигнорировал) этот результат, когда он был ему показан.

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

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

INDEXING (Фоновый процесс сбора данных)
Система ведет собственную базу данных пользовательской активности (User Information Database), отдельную от основного веб-индекса. Происходит постоянный сбор Event-Based Data (через Client Assistant или серверные логи) и расчет Derived Data (например, профилей пользователей, Preferred Locations, Scores для контента). Это может происходить как в реальном времени, так и периодически (офлайн).

QUNDERSTANDING – Понимание Запросов
Компоненты понимания запросов используются для определения того, является ли текущий запрос «похожим, но отличающимся» от предыдущих запросов пользователя (Claim 1). Это требует семантического сравнения текущего запроса с историей.

RANKING / RERANKING (Основное применение)
Основная логика патента применяется на финальных стадиях ранжирования или на этапе переранжирования (персонализации).

1. Получение базовых результатов: На этапе RANKING генерируется стандартный набор результатов.
2. Персонализация (Переранжирование): На этапе RERANKING система применяет механизмы, описанные в Claim 7. Оценки ранжирования модифицируются на основе истории взаимодействий (повышение за клики/посещения, понижение за игнорирование, согласно Claims 8-10).
3. Дополнение (Augmentation): Система также может выполнять дополнительный поиск по истории пользователя (Claim 1), чтобы найти релевантные результаты из прошлых похожих запросов и добавить их в текущую выдачу.

METASEARCH – Метапоиск и Смешивание
Механизмы из Claim 2 применяются на этом этапе. Система смешивает стандартные результаты поиска с историческими событиями (прошлые релевантные запросы, клики по рекламе, обзоры продуктов), отображая их в интерфейсе SERP (например, в отдельном блоке My Search History results, показанном на FIG. 10).

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

• Текущий запрос пользователя.
• Базовый набор результатов поиска с их оценками ранжирования.
• История пользователя (User Information Database): прошлые запросы, клики, данные браузинга, Derived Data (Scores, Preferred Locations).

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

• Персонализированный набор результатов поиска с модифицированными оценками ранжирования.
• Дополнительные блоки в SERP, отображающие релевантные исторические события.

На что влияет

• Специфические запросы: Наибольшее влияние оказывается на запросы, которые пользователь задает повторно или которые похожи на его прошлые поисковые сессии (информационные, исследовательские запросы).
• Конкретные типы контента: Влияет на все типы контента, с которыми пользователь взаимодействовал ранее, включая веб-страницы, рекламу (Ad Click Event) и обзоры продуктов (Product Event).
• Пользовательский опыт: Напрямую влияет на SERP конкретного пользователя, делая его уникальным по сравнению с неперсонализированной выдачей (фрагментация SERP).

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

• Условия применения: Алгоритмы применяются, когда у пользователя есть записанная история (он идентифицирован, например, через логин User ID или cookie Client ID), и система может найти релевантные прошлые взаимодействия, связанные с текущим запросом или его результатами.
• Триггеры активации: Получение нового поискового запроса от идентифицированного пользователя.
• Конфиденциальность и Snooze: Система учитывает настройки подписки пользователя на запись истории. Пользователь может отключить запись определенных типов данных или использовать функцию "snooze" для временного отключения мониторинга/записи активности.

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

Процесс А: Модификация результатов поиска (Real-time)

1. Получение запроса и идентификация: Система получает текущий поисковый запрос и идентифицирует пользователя и его историю (User Information Database).
2. Генерация базовых результатов: Запрос выполняется по репозиторию документов, генерируется базовый набор результатов с исходными оценками ранжирования.
3. Идентификация исторических взаимодействий (Переранжирование):
   • Система проверяет каждый результат в базовом наборе на предмет прошлых взаимодействий пользователя.
   • Если результат ранее посещался/кликался, его оценка ранжирования увеличивается (Boost, Claims 8, 9). Увеличение может быть пропорционально частоте посещений или stay-time.
   • Если результат ранее был показан, но проигнорирован, его оценка ранжирования уменьшается (Demote, Claim 10).
4. Идентификация прошлых похожих запросов (Дополнение):
   • Система ищет в истории прошлые запросы, похожие на текущий, но отличающиеся от него.
   • Определяются результаты этих прошлых запросов.
   • Идентифицируются прошлые результаты, отсутствующие в текущем базовом наборе.
5. Объединение и финальное ранжирование:
   • Базовый набор (с модифицированными оценками) объединяется с идентифицированными отсутствующими прошлыми результатами.
   • Объединенный набор сортируется по итоговым оценкам ранжирования.
6. Отображение контекста (Параллельный процесс):
   • Система идентифицирует релевантные исторические события (прошлые запросы, клики по рекламе, обзоры).
   • Эти события форматируются для отображения (например, в отдельном блоке).
7. Предоставление ответа: Персонализированная выдача и блоки контекста возвращаются пользователю.

Процесс Б: Сбор данных и расчет метрик (Фоновый процесс)

1. Мониторинг активности: Client Assistant или серверный компонент мониторит действия пользователя.
2. Передача и прием данных: Информация об активности передается в поисковую систему.
3. Обработка данных: Система определяет идентификатор пользователя и тип данных (Query, Result Click, Ad Click, Browsing).
4. Фильтрация: Проверяются настройки подписки и фильтры (например, функция "snooze").
5. Обновление базы данных: Информация записывается в User Information Database.
6. Перерасчет производных значений (Derived Data): Обновляются метрики, зависящие от новых данных (например, Score контента, Preferred Locations, профиль пользователя, группировка в Query Sessions).

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

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

Система использует обширный набор данных о поведении пользователя.

• Контентные факторы: Текст прошлых запросов (Query Event). URL посещенных страниц (Result Click, Browsing Event), идентификаторы рекламы (Ad Click Event), обзоры продуктов (Product Event). Также используются аннотации или метки, добавленные пользователем к контенту.
• Поведенческие факторы (Ключевые):
  • Клики (Click-throughs): По результатам поиска и по рекламе.
  • Игнорирование: Факт показа результата без последующего клика (используется как отрицательный сигнал, Claim 10).
  • Частота посещений: Количество посещений определенного URL или сайта (используется как положительный сигнал, Claim 9).
  • Stay-time (Время пребывания): Оценка времени, проведенного на странице/сайте.
  • Браузинг (Browsing Event): Посещения страниц вне контекста поиска.
• Временные факторы: Время и дата каждого события (Timestamp). Используется для определения свежести взаимодействия (date of the last visit).
• Пользовательские факторы: Идентификатор пользователя (User Identifier), идентификаторы клиентских приложений (Client Identifier). Патент описывает механизм связывания нескольких Client ID с одним User ID для кросс-девайс трекинга (FIG. 16).

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

• Search Result Ranking Value (Модифицированная оценка): Исходная оценка ранжирования результата модифицируется на основе истории пользователя. Увеличивается при положительной обратной связи (клики, частота посещений) и уменьшается при отрицательной (игнорирование).
• Score (Оценка Контента): Метрика, рассчитываемая для ContentID в Derived Data. Учитывает количество кликов, stay-time, время с последнего просмотра. Негативно влияет, если контент был показан, но не выбран. Позитивно влияет, если пользователь посещает похожий контент.
• Visit Score (Оценка посещения): Используется для ранжирования Preferred Locations. Может быть суммой оценок отдельных посещений (instance visit score), при этом оценка отдельного посещения может уменьшаться со временем.
• Query Similarity (Схожесть запросов): Метрика для определения того, насколько прошлый запрос похож на текущий (Claim 1). Может рассчитываться с помощью edit distance, стемминга, исправления ошибок, семантического маппинга или схожести наборов возвращаемых документов.
• History Score (Оценка события): Метрика, присваиваемая событию, часто основанная на времени (устаревание).

1. Персонализация как ключевой слой ранжирования: Патент демонстрирует, что история пользователя является критически важным фактором, который может изменять стандартное ранжирование. Выдача для активного пользователя может значительно отличаться от "чистой" выдачи.
2. Явный учет отрицательной обратной связи (Игнорирование): Система не только повышает ранее посещенные ресурсы, но и явно понижает (Demote) те результаты, которые были показаны пользователю, но проигнорированы (Claim 10). Это подчеркивает важность CTR в контексте персонализации.
3. Дополнение выдачи (Augmentation) для повышения полноты: Если текущий запрос сформулирован иначе, чем прошлый похожий запрос, система может добавить в выдачу релевантные результаты из прошлого, которые не попали в текущий SERP (Claim 1). Google стремится показать пользователю то, что он считал полезным ранее.
4. Важность удержания (Stay-time) и частоты: Время пребывания на сайте (stay-time) и частота посещений (Claim 9) явно упоминаются как факторы для расчета Score контента и определения Preferred Locations. Это подтверждает важность поведенческих факторов на сайте.
5. Неявные предпочтения (Preferred Locations): Система автоматически определяет предпочтения пользователя на основе его поведения, создавая персонализированный граф интересов без явного указания со стороны пользователя. Сайты, попавшие в этот список, получают преимущество.
6. Кросс-девайс трекинг и унификация данных: Патент описывает механизм связывания активности с разных устройств (Client IDs) и из разных источников (включая рекламу и общий браузинг) с одним аккаунтом (User ID), что обеспечивает целостную персонализацию.

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

• Оптимизация под вовлечение и удержание (Retention): Создавайте контент, который удерживает пользователя на сайте (увеличивает stay-time). Качественный UX и внутренняя перелинковка способствуют этому. Чем выше вовлеченность, тем выше вероятность бустинга при следующих запросах пользователя и классификации сайта как Preferred Location.
• Максимизация CTR на SERP: Критически важно работать над сниппетами (Title, Description, разметка). Поскольку игнорирование результата в выдаче является сигналом для понижения (Claim 10) в рамках персонализации, необходимо добиваться клика, если страница показана.
• Построение тематического авторитета и широкого охвата: Создавайте контент, который отвечает на смежные и похожие запросы в рамках одной темы. Это увеличивает вероятность того, что ваш сайт будет добавлен в выдачу через механизм дополнения (Claim 1), если пользователь ищет информацию по вашей теме, используя разные формулировки.
• Стимулирование повторных визитов и построение бренда: Работайте над лояльностью аудитории. Частота посещений напрямую влияет на Score контента (Claim 9). Используйте разные каналы (рассылки, соцсети) для возврата пользователей, так как Browsing Events (не только поисковые клики) также учитываются.
• Анализ Product Reviews и Рекламы: Если вы работаете с сайтами обзоров или активно используете контекстную рекламу, помните, что взаимодействие с этим контентом также записывается (Ad Click Event, Product Event) и влияет на общую картину предпочтений пользователя (Claim 2).

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

• Использование кликбейта и обманчивых сниппетов: Привлечение трафика, который быстро покидает сайт (низкий stay-time), может негативно сказаться на Score контента и уменьшить вероятность бустинга в будущем для этого пользователя.
• Ранжирование по нерелевантным запросам: Попадание в выдачу по запросам, где ваш контент не интересен пользователю, приведет к игнорированию результата. Накопление таких сигналов может привести к понижению сайта в персонализированной выдаче этого пользователя (Claim 10).
• Фокус только на привлечении нового трафика: Игнорирование стратегии удержания. Если большинство визитов являются первыми и последними, сайт не получит преимуществ от механизмов персонализации и будет уступать конкурентам в выдаче лояльных пользователей.

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

Патент подтверждает стратегическую важность построения долгосрочных отношений с пользователем. SEO смещается от разовой оптимизации страницы под запрос к созданию ресурса, который становится "предпочитаемым" (Preferred Location) для пользователя в определенной тематике. Поведенческие факторы, как на выдаче (CTR, игнорирование), так и на сайте (stay-time, частота визитов), играют решающую роль в формировании персонализированной выдачи. Стратегия должна быть направлена на максимальное вовлечение и лояльность.

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

Сценарий 1: Повышение за счет повторных визитов и Stay-time (Claims 8, 9)

1. Ситуация: Пользователь ищет "как настроить гитару". Он кликает на сайт А, проводит там 5 минут (высокий stay-time), изучая детальное руководство.
2. Действие системы: Google записывает Result Click Event, рассчитывает stay-time и увеличивает Score для этого URL в профиле пользователя.
3. Результат: Через неделю пользователь ищет "лучшие струны для акустики". Сайт А получает бустинг в выдаче этого пользователя и поднимается выше конкурентов, даже если имеет более слабые стандартные сигналы ранжирования.

Сценарий 2: Понижение за игнорирование (Claim 10)

1. Ситуация: Пользователь ищет "рецепт пасты карбонара". Сайт Б находится на 3 позиции. Пользователь просматривает выдачу, но кликает на сайты 1, 2 и 4, игнорируя сайт Б.
2. Действие системы: Google фиксирует, что результат был показан, но не выбран (отрицательная обратная связь).
3. Результат: При следующем поиске этого же или похожего рецепта, оценка ранжирования сайта Б для этого пользователя будет понижена.

Сценарий 3: Дополнение выдачи (Augmentation, Claim 1)

1. Ситуация: В прошлом пользователь искал "симптомы дефицита витамина D" и нашел полезную статью на сайте В.
2. Текущий запрос: Пользователь ищет "почему я постоянно устаю зимой". Стандартные алгоритмы не ранжируют статью с сайта В высоко по этому запросу.
3. Действие системы: Google определяет, что текущий запрос похож на прошлый запрос (семантически связаны), но отличается. Система видит, что релевантный результат с сайта В отсутствует в текущей выдаче.
4. Результат: Система добавляет статью с сайта В в текущую выдачу, повышая полноту ответа для пользователя.