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

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

Client Assistant (Клиентский помощник)

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

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

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

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

Информация, вычисленная на основе записанных событий. Примеры: профиль пользователя (User Profile), набор предпочтительных местоположений (Preferred Locations), агрегированные оценки.

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

Сырые данные о действиях пользователя. Включают типы: Query Event (запрос), Result Click Event (клик по результату), Ad Click Event (клик по рекламе), Browsing Event (просмотр страницы), Product Event (поиск обзоров продуктов).

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

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

Preferred Locations (Предпочтительные местоположения)

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

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

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

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

Группа связанных Query Sessions из разных браузерных сессий (например, тематически связанные поиски, выполненные в разные дни).

Snooze Function (Функция "отложить")

Возможность для пользователя временно отключить мониторинг и/или запись своих действий.

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

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

Subscription Condition (Условие подписки)

Настройка пользователя, определяющая, разрешено ли записывать (write) и/или использовать (read) определенный тип данных (Data Type) для этого пользователя.

User Information Database (База данных информации о пользователе)

Централизованное хранилище для Event-Based Data, Derived Data и Additional Data пользователя.

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

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

1. Система получает данные пользователя от клиентского приложения. Данные содержат события, каждое из которых имеет тип (data type), указывающий на вид активности (например, запрос, клик).
2. Система обрабатывает выбранные события для создания записей в структуре данных пользователя.
3. Для каждого события определяется subscription condition, связанное как с пользователем, так и с типом данных этого события. У пользователя есть отдельные настройки подписки для разных типов данных.
4. Запись о событии создается в структуре данных пользователя только условно (conditionally creating), в зависимости от subscription condition для данного типа данных. Запись включает уникальный ID события.

Claim 2 (Зависимый): Добавляет snooze condition, который модифицирует subscription condition (позволяет временно приостановить запись).

Claim 4 (Зависимый): Уточняет, что subscription condition контролирует не только запись, но и доступ (чтение) к уже созданным записям в структуре данных.

Claim 5 (Зависимый): Описывает создание производной информации (derived information value) на основе множества записей о событиях.

Claim 7 (Зависимый): Описывает процесс пересчета производной информации при изменении subscription condition. Если подписка на тип данных изменяется (например, пользователь отключает запись истории), производные данные (например, профиль пользователя), зависящие от этого типа данных, должны быть пересчитаны.

Claim 9 (Зависимый): Описывает пересчет производной информации при изменении доступности исходных записей о событиях (например, при удалении истории).

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

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

CRAWLING & Data Acquisition (Сбор данных)
На этом этапе происходит сбор данных, но не из интернета, а от пользователя. Client Assistant на устройстве пользователя мониторит его активность (запросы, клики, просмотры) и отправляет эти данные в систему.

INDEXING & Feature Extraction (Индексирование и извлечение признаков)
Полученные данные обрабатываются и сохраняются в User Information Database. Этот процесс включает:

• Проверку Subscription Condition: запись происходит только если пользователь подписан на данный тип данных.
• Извлечение признаков: вычисление History Score, Stay-time.
• Вычисление Derived Data: система анализирует события для создания профиля пользователя, определения Query Sessions, Session Groups и Preferred Locations. Это может происходить в реальном времени или в пакетном режиме.

QUNDERSTANDING – Понимание Запросов
История запросов пользователя и его профиль (Derived Data) могут использоваться для лучшего понимания текущего запроса и определения намерения.

RANKING / RERANKING (Ранжирование / Переранжирование)
Основное применение патента для SEO. После получения стандартного набора результатов система корректирует их (Adjust Search Results) на основе истории пользователя:

• Повышение (Boosting): Результаты, которые пользователь ранее посещал или кликал, могут быть повышены. Величина бустинга может зависеть от History Score (частота, давность визитов).
• Понижение (Demoting): Результаты, которые ранее показывались, но не были кликнуты, могут быть понижены.
• Добавление результатов: Результаты из истории, релевантные текущему запросу, но отсутствующие в стандартной выдаче, могут быть добавлены.
• Визуальная индикация: Пометка ранее посещенных результатов (дата последнего визита, частота).

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

• События пользователя (Event-Based Data): тип, время, ContentID, Query.
• Настройки подписки пользователя (Subscription Conditions).
• Текущий поисковый запрос.
• Стандартный набор результатов поиска.

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

• Обновленная User Information Database.
• Переранжированный (персонализированный) набор результатов поиска.
• Визуальные индикаторы истории в SERP.

На что влияет

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

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

• Триггеры активации (Сбор данных): Активируется при любом действии пользователя (запрос, клик, просмотр), при условии, что у пользователя установлен компонент мониторинга (Client Assistant) и он вошел в аккаунт (или используется идентификация по Client ID).
• Условие применения (Сбор данных): Применяется только если Subscription Condition для данного типа данных разрешает запись, и не активна функция Snooze.
• Триггеры активации (Персонализация): Активируется при выполнении поискового запроса, если в User Information Database есть релевантные данные и Subscription Condition разрешает их чтение.

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

Процесс А: Сбор и хранение данных (FIG. 2)

1. Мониторинг: Client Assistant отслеживает активность пользователя и генерирует событие (Event).
2. Передача: Событие отправляется на сервер.
3. Идентификация источника: Сервер определяет пользователя (User ID) и/или устройство (Client ID).
4. Определение типа данных: Определяется тип события (Query, Result Click, Ad Click, Browsing).
5. Проверка подписки: Проверяется Subscription Condition для данного пользователя и типа данных. Также проверяется статус Snooze.
6. Фильтрация (Опционально): Событие проверяется на соответствие фильтрам (например, adult content).
7. Запись: Если подписка активна и фильтры пройдены, событие записывается в User Information Database с присвоением EventID и Timestamp.
8. Пересчет производных данных: Запускается процесс обновления Derived Data (профиль, предпочтения), которые зависят от нового события.

Процесс Б: Персонализация поиска (FIG. 9)

1. Получение запроса: Пользователь вводит поисковый запрос.
2. Стандартный поиск: Запрос выполняется по общему индексу документов.
3. Получение результатов: Формируется стандартный набор результатов.
4. Корректировка на основе истории: Система анализирует User Information Database пользователя (если чтение разрешено подпиской).
   • Идентифицируются результаты в стандартном наборе, которые пользователь посещал ранее.
   • Вычисляются метрики персонализации на основе History Score, частоты визитов, stay-time.
   • Применяется бустинг/демоутинг к оценкам ранжирования этих результатов.
   • Идентифицируются дополнительные релевантные результаты из истории, которые могут быть добавлены в выдачу.
5. Формирование SERP: Результаты переупорядочиваются. Добавляются визуальные индикаторы (дата визита) и специальные блоки с историческими результатами.

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

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

Система собирает и использует следующие данные:

• Контентные факторы: Текст запросов (Query Event). Контент посещенных страниц (используется для определения тематики и генерации Derived Data).
• Технические факторы: URL посещенных страниц (ContentID).
• Поведенческие факторы (Ключевые данные):
  • Клики по результатам поиска (Result Click Event).
  • Клики по рекламе (Ad Click Event).
  • История просмотров страниц вне поиска (Browsing Event).
  • Частота визитов (Frequency).
  • Давность визитов (Recency/Timestamp).
  • Время пребывания на странице (Stay-time).
• Пользовательские факторы:
  • Идентификатор пользователя (User ID) и клиента (Client ID).
  • Настройки подписки (Subscription Conditions).
  • Явные модификации ранжирования пользователем (User-modified ranking value).
  • Аннотации и метки, добавленные пользователем к контенту.

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

• History Score (Оценка истории): Метрика, связанная с событием. Может быть time-based ranking value, который периодически модифицируется (например, уменьшается с течением времени).
• Score (Оценка контента, 532 на FIG. 5): Производная оценка, присваиваемая конкретному ContentID (странице/сайту). Может учитывать:
  • Количество кликов/визитов пользователя на этот ContentID.
  • Оценочное время пребывания (Stay-time).
  • Время с последнего просмотра.
  • Негативное влияние, если контент был показан, но не кликнут.
  • Позитивное влияние, если пользователь посещает похожий контент.
  • Количество прошлых запросов, по которым этот контент был показан.
• Visit Score (Оценка визита): Используется для ранжирования Preferred Locations. Может быть суммой оценок отдельных визитов (instance visit scores), которые уменьшаются со временем.
• Weighting Factors (Весовые коэффициенты): Используются при объединении наборов предпочтительных местоположений (например, своих и чужих) или для ручной корректировки пользователем важности конкретного сайта.

1. Персонализация как ключевой слой ранжирования: Патент описывает детальный механизм, как история пользователя напрямую модифицирует результаты поиска. Это не просто фильтр, а система переранжирования, которая может повышать или понижать результаты на основе предыдущего взаимодействия.
2. Гранулярный контроль пользователя (Subscription-Based): Система построена на принципе явного согласия (подписки) на сбор и использование разных типов данных. Это означает, что уровень персонализации зависит от настроек приватности пользователя.
3. Важность поведенческих сигналов: Система явно учитывает клики, повторные визиты, частоту и потенциально stay-time (время пребывания) как индикаторы предпочтений пользователя. Это подтверждает важность вовлеченности для SEO.
4. Производные профили и предпочтения: Google не просто хранит историю, но и генерирует Derived Data — профили интересов и списки Preferred Locations (автоматическое избранное). Ранжирование может опираться на эти производные данные.
5. Понимание сессий и пути пользователя: Введение концепций Query Sessions и Session Groups показывает, что Google анализирует связь между запросами во времени и по тематике, стремясь понять общий контекст и задачу пользователя.
6. Кросс-девайсная идентификация: Патент предусматривает механизм объединения истории с разных устройств (Client IDs) в единый профиль пользователя (User ID), что критически важно для целостной персонализации.

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

• Стимулирование повторных визитов и лояльности: Поскольку система повышает (boost) ранее посещенные сайты, критически важно становиться Preferred Location для целевой аудитории. Используйте email-маркетинг, ретаргетинг и создавайте качественный контент, к которому пользователи захотят вернуться.
• Оптимизация вовлеченности и Post-Click Experience: Учитывая упоминание stay-time и негативное влияние некликнутых результатов, необходимо фокусироваться на создании привлекательных сниппетов (для получения клика) и качественного контента на странице (для удержания пользователя).
• Построение тематического авторитета (Topical Authority): Так как система строит профиль интересов пользователя (Derived Data) и группирует сессии по темам (Session Groups), сайт, полностью покрывающий тематику, с большей вероятностью станет предпочтительным источником в этой области для пользователя.
• Анализ SERP с учетом персонализации: При анализе позиций и конкурентов необходимо понимать, что выдача сильно персонализирована. Используйте инструменты мониторинга позиций в режиме инкогнито для получения базовой картины, но учитывайте, что реальные пользователи видят иную выдачу.
• Оптимизация под путь пользователя (User Journey): Анализируйте, как пользователи перемещаются по вашему сайту и какие запросы приводят их к вам в рамках одной сессии. Создавайте контент, который отвечает на последующие вопросы пользователя, чтобы удерживать его на сайте и увеличивать количество взаимодействий в рамках Query Session.

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

• Использование кликбейта и обманчивых сниппетов: Получение клика с последующим быстрым уходом пользователя может негативно сказаться на stay-time и оценке предпочтений. Система может интерпретировать это как негативный опыт.
• Игнорирование юзабилити и скорости загрузки: Плохой пользовательский опыт ведет к коротким сессиям, что снижает вероятность того, что сайт будет классифицирован как Preferred Location.
• Фокус только на привлечении нового трафика: Стратегии, направленные исключительно на привлечение новых пользователей без работы над их удержанием, менее эффективны в условиях сильной персонализации, описанной в патенте.

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

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

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

Сценарий: Повышение позиций для лояльного пользователя в E-commerce

1. Действие пользователя: Пользователь ищет "купить кофемашину Nespresso", кликает на сайт StoreA.com, проводит там 5 минут (stay-time), изучая модель. Позже он посещает StoreA.com еще раз через поиск по бренду.
2. Действие системы: Google записывает эти события в User Information Database. Система обновляет Derived Data, повышая оценку StoreA.com для этого пользователя и классифицируя его как потенциальный Preferred Location для покупок техники.
3. Следующий запрос: Через неделю пользователь ищет "капсулы Nespresso".
4. Результат (Персонализация): Хотя StoreA.com может занимать 5 позицию в нейтральной выдаче по этому запросу, для данного пользователя система применяет бустинг (Adjust Search Results) на основе предыдущего положительного взаимодействия. StoreA.com показывается на 1 или 2 позиции.
5. Ожидаемый результат для SEO: Увеличение конверсии и трафика за счет повышения видимости для лояльной аудитории.