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

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

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

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

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

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

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

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

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

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

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

Набор сайтов или страниц, автоматически идентифицированных как важные для пользователя на основе его истории (implicit favorites). Ранжирование основано на частоте, давности визитов и Stay-time.

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

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

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

Объединение тематически связанных Query Sessions из разных периодов времени (разных Browsing Sessions). Отражает долгосрочный интерес пользователя к теме.

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

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

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

Хранилище, содержащее Event-Based Data и Derived Data для конкретного пользователя.

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

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

1. Система идентифицирует часть исторической активности пользователя.
2. Из этой активности выделяются как минимум две отдельные сессии (first session и second session).
3. Внутри каждой сессии идентифицируются одна или несколько группировок (groupings) связанных действий.
4. Система ассоциирует (связывает) идентифицированную группировку из первой сессии с группировкой из второй сессии.

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

Claim 4 (Зависимый от 1): Описывает применение этого анализа в поиске.

1. Получение поискового запроса и стандартных результатов поиска.
2. Идентификация ассоциированной группировки (из Claim 1), релевантной запросу.
3. Одновременное отображение этой ассоциированной группировки и стандартных результатов поиска.

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

Claim 7 (Зависимый от 1): Уточняет механизм связывания группировок.

Ассоциация происходит, когда оценка схожести (similarity score) между группировками из разных сессий превышает определенный порог.

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

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

INDEXING – Индексирование (Пользовательских данных)
Система собирает Event-Based Data (запросы, клики, браузинг) и индексирует их в User Information Database. На этом этапе (офлайн или в режиме, близком к реальному времени) вычисляются Derived Data: профили интересов, Query Sessions, Session Groups и Preferred Locations.

QUNDERSTANDING – Понимание Запросов
Система выполняет глубокий анализ истории пользователя для выявления долгосрочных интересов (Session Groups). Эта информация может использоваться для лучшего понимания контекста текущего запроса.

RANKING – Ранжирование
Генерируется стандартный (неперсонализированный) набор результатов поиска.

RERANKING / METASEARCH – Переранжирование и Смешивание
Основной этап применения патента. Система использует данные из User Information Database для корректировки стандартных результатов:

1. Корректировка оценок (Reranking): Оценки ранжирования результатов модифицируются. Результаты, которые пользователь ранее посещал или которые являются Preferred Locations, могут быть повышены (boosted). Результаты, которые ранее показывались, но не были выбраны, могут быть понижены (demoted).
2. Смешивание и Отображение (Blending/Presentation): Релевантные результаты из истории могут отображаться в отдельном блоке (My Search History results) или использоваться для визуальной индикации (например, дата последнего визита) на SERP.

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

• Текущий поисковый запрос и стандартные результаты поиска.
• Данные из User Information Database (История событий, Session Groups, Preferred Locations).
• Идентификатор пользователя (User ID) или клиента (Client ID/Cookie).

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

• Персонализированный набор результатов поиска (с измененным порядком, аннотациями и/или добавленными блоками).

На что влияет

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

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

• Условия работы: Алгоритм применяется, когда пользователь идентифицирован и у него активна запись истории.
• Триггеры активации: Наличие в стандартной выдаче результатов, с которыми пользователь ранее взаимодействовал, или наличие в истории релевантных Session Groups/Preferred Locations.
• Исключения: Пользователь может управлять подпиской (subscription information) на запись разных типов данных или активировать режим "snooze" (временная остановка записи активности).

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

Процесс А: Сбор и обработка истории (Фоновый/Офлайн процесс)

1. Мониторинг и передача: Отслеживание активности пользователя и отправка данных на сервер.
2. Идентификация и проверка подписки: Определение пользователя и проверка разрешений на запись данных (учет snooze).
3. Сохранение: Запись Event-Based Data в User Information Database.
4. Пересчет производных данных: Обновление Derived Data (например, Preferred Locations, History Score).
5. Анализ сессий:
   • Идентификация Browsing Sessions (периоды активности).
   • Идентификация Query Sessions (кластеризация связанных запросов внутри сессии).
   • Идентификация Session Groups (связывание схожих Query Sessions из разных периодов на основе similarity score).

Процесс Б: Персонализация поисковой выдачи (В реальном времени)

1. Получение запроса и стандартных результатов: Система выполняет стандартный поиск.
2. Анализ истории: Поиск в User Information Database релевантных данных (предыдущие визиты, Preferred Locations, Session Groups).
3. Корректировка результатов:
   • Вычисление и применение оценок истории.
   • Переранжирование результатов (повышение/понижение).
4. Аннотирование и дополнение: Добавление визуальных индикаторов посещений и/или формирование отдельного блока с результатами из истории.
5. Предоставление ответа: Отправка персонализированной выдачи пользователю.

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

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

Система полагается преимущественно на поведенческие данные пользователя.

• Поведенческие факторы (Ключевые данные):
  • Queries: Тексты прошлых запросов.
  • Result Clicks: Клики по стандартным результатам поиска.
  • Ad Clicks: Клики по рекламным объявлениям.
  • Browsing Events: Посещение страниц (URL) вне контекста поиска.
  • Stay-time: Оценка длительности пребывания пользователя на странице.
  • Impressions без клика: Факт показа результата без последующего клика (используется как возможный негативный сигнал для понижения).
• Временные факторы: Timestamp для каждого события. Используется для определения сессий, частоты (Frequency), давности (Recency) и расчета метрик, зависящих от времени (time-decay).
• Пользовательские факторы: User Identifier, Client Identifier (Cookie), настройки приватности (подписки, snooze). Пользовательские аннотации и метки к контенту.

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

• History Score: Метрика для оценки важности события. Может уменьшаться (затухать) с течением времени.
• Similarity Score (Оценка схожести): Метрика для определения связи между Query Sessions. Если превышает порог, сессии объединяются в Session Group. Рассчитывается на основе схожести запросов и/или контента.
• Score (Оценка для ContentID/Preferred Locations): Производная оценка важности контента для пользователя. Факторы расчета включают:
  • Частоту посещений.
  • Stay-time (время пребывания).
  • Давность последнего визита.
  • Негативные сигналы (пропуск клика при показе).
• Visit Score (Оценка посещения): В одном из вариантов реализации — сумма оценок отдельных визитов (instance visit scores), где оценка каждого визита уменьшается со временем.

1. Персонализация как прямой фактор ранжирования: Патент детально описывает инфраструктуру для глубокой персонализации. История взаимодействий пользователя используется для переранжирования его индивидуальной выдачи, включая повышение (boosting) и понижение (demoting) результатов.
2. История как долгосрочный контекст (Session Groups): Система анализирует не просто отдельные события, а выстраивает контекст, объединяя связанные действия в Query Sessions и связывая их во времени (Session Groups). Это позволяет понимать долгосрочные задачи и интересы пользователя.
3. Неявные индикаторы интереса (Stay-time и Frequency): Время пребывания на странице (stay-time) и частота визитов рассматриваются как ключевые показатели интереса пользователя.
4. Автоматическое определение важных ресурсов (Preferred Locations): Система автоматически формирует список предпочитаемых ресурсов (неявные закладки) на основе метрик вовлеченности. Эти сайты получают преимущество в ранжировании для данного пользователя.
5. Агрегация данных с разных устройств: Предусмотрен механизм связывания нескольких идентификаторов клиента (устройств/браузеров) с одним аккаунтом пользователя для создания полной истории активности.
6. Влияние рекламы на историю: Клики по рекламе (Ad Clicks) записываются и анализируются наравне с органическими кликами, влияя на профиль пользователя и определение Preferred Locations.

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

• Фокус на удержании пользователя (Retention) и построении бренда: Ключевая стратегия. Повторные визиты, частота и длительность взаимодействия (stay-time) увеличивают вероятность попадания сайта в Preferred Locations и обеспечивают буст в персональной выдаче пользователя. Работа над лояльностью аудитории критически важна.
• Оптимизация вовлеченности и Stay-time: Создавайте контент и UX, которые максимально удерживают пользователя на сайте. Уменьшение показателя отказов и предотвращение pogo-sticking положительно влияют на восприятие сайта как предпочтительного.
• Оптимизация сниппетов для высокого CTR: Критически важно мотивировать пользователя совершить первый клик. Если пользователь видит сайт в выдаче, но игнорирует его, патент предлагает использовать это как негативный сигнал для будущей персонализации (понижение).
• Создание тематических хабов для поддержки сессий: Механизмы Query Sessions и Session Groups группируют связанные активности. Создание обширного контента, поддерживающего пользователя на всех этапах решения задачи, помогает сайту стать релевантным для всей Session Group.

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

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

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

Патент подтверждает фундаментальный сдвиг к персонализированному поиску. Для Senior SEO-специалистов это означает, что метрики, основанные на "чистых" позициях в ТОПе, могут быть обманчивы. Стратегически более важно фокусироваться на общем качестве трафика, вовлеченности (engagement) и удержании (retention). Долгосрочная стратегия должна быть направлена на превращение сайта в Preferred Location для целевой аудитории путем построения сильного бренда и обеспечения превосходного пользовательского опыта.

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

Сценарий: Персонализированное повышение авторитетного источника

1. Контекст: Пользователь регулярно читает новости на сайте NewsPortalA.com, проводя там значительное время. Система классифицирует NewsPortalA.com как Preferred Location для этого пользователя.
2. Новый запрос: Пользователь вводит общий запрос о текущем событии, например, "выборы в Германии".
3. Стандартное ранжирование: В нейтральной выдаче NewsPortalA.com находится на 5 позиции.
4. Применение механизма: Система распознает, что NewsPortalA.com является Preferred Location для пользователя и релевантен запросу.
5. Результат: Система модифицирует выдачу для этого пользователя, повышая NewsPortalA.com на 1 или 2 позицию и/или добавляя аннотацию о частоте посещений ("Вы часто посещаете этот сайт").