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

Описание

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

Патент решает проблему сложности повторного нахождения пользователем ранее просмотренного контента и отсутствия эффективной персонализации в стандартной поисковой выдаче. Он предлагает механизм адаптации результатов поиска на основе индивидуальной истории просмотров. Ключевым аспектом является реализация на стороне клиента (client device), что на момент подачи заявки (оригинал в 2003 г.) решало проблемы конфиденциальности и задержек, связанных с обработкой истории на сервере.

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

Запатентована система персонализации поиска, реализованная на стороне клиента. Ядром изобретения является компонент (Browser Assistant Software, например, тулбар или плагин), который пассивно отслеживает активность пользователя и создает локальный индекс посещенных документов (History Database). Эта система модифицирует стандартные результаты поиска, полученные от сервера, путем переранжирования, добавления или удаления элементов на основе локальной истории пользователя.

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

Система работает в двух режимах:

• Фоновый режим (Индексация): Browser Assistant пассивно отслеживает посещаемые документы, индексирует их контент и записывает метрики взаимодействия (частота, время на странице, оценки пользователя).
• Режим поиска (Implicit History Search): Когда пользователь выполняет веб-поиск, система перехватывает результаты от поискового движка (с оценкой search_engine_score). Одновременно выполняется поиск по локальной History Database (генерируя history_score).
• Модификация и Переранжирование: Результаты сравниваются. Если документ есть в истории, его позиция повышается. Это достигается либо путем пересчета оценки ранжирования (new_score) по специальным формулам, либо путем перемещения результата вверх на фиксированное число позиций.

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

Средняя/Высокая. Патент является продолжением заявки от 2003 года. Описанная техническая реализация (строго на стороне клиента, например, через Google Toolbar) в значительной степени устарела. Однако концепция использования истории просмотров и поведенческих сигналов для персонализации поиска остается критически важной в 2025 году. Современные реализации сместились на сторону сервера (используя данные аккаунта Google и Chrome), но заложенные принципы и метрики сохраняют актуальность.

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

Патент имеет высокое значение (7/10) для понимания принципов персонализации и важности поведенческих факторов. Он не влияет на глобальное ранжирование (привлечение нового трафика), но демонстрирует, как вовлеченность (время пребывания, частота визитов) напрямую конвертируется в повышение позиций в персональной выдаче вернувшегося пользователя. Это подчеркивает стратегическую важность UX и работы над удержанием аудитории.

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

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

Browser Assistant Software (Ассистент браузера)

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

History Database (База данных истории)

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

Implicit History Search (Неявный поиск по истории)

Процесс, при котором стандартный веб-поиск автоматически модифицируется с использованием данных из History Database без явного указания пользователя.

search_engine_score (First score)

Исходная оценка ранжирования, присвоенная документу сервером поисковой системы.

history_score (Second score)

Локальная оценка документа, основанная на данных из History Database (релевантность запросу и поведенческие метрики, такие как частота и время доступа).

history_weight (Вес истории)

Коэффициент, определяющий степень влияния history_score на итоговую оценку.

new_score (Final score)

Итоговая оценка ранжирования документа после персонализации, рассчитанная путем комбинации search_engine_score и history_score.

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

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

1. Клиент получает запрос и отправляет его на сервер.
2. Клиент получает от сервера первый набор результатов (Set 1) с первыми оценками (search_engine_score).
3. Клиент выполняет поиск в локальной памяти (History Database) и генерирует второй набор результатов (Set 2) со вторыми оценками (history_score).
4. Система сравнивает наборы и идентифицирует совпадения.
5. Для совпавшего результата генерируется финальная оценка (new_score) путем комбинирования первой оценки и взвешенной второй оценки.
6. Результаты представляются на основе финальной оценки.

Claim 14 и 15 (Зависимые): Определяют конкретные формулы для расчета финальной оценки.

• Claim 14 (Аддитивная модель): new_score = search_engine_score + (history_weight * history_score). Добавление бонуса за историю.
• Claim 15 (Мультипликативная модель): new_score = search_engine_score * (1 + history_weight * history_score). Усиление существующей оценки за счет истории.

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

1. После идентификации совпадений (как в Claim 1).
2. Вместо пересчета оценки, система модифицирует ранг совпавшего результата путем его перемещения на предопределенное количество позиций (predetermined number of positions) к топу выдачи.

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

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

Локальное Индексирование (Client-Side INDEXING)
Browser Assistant непрерывно работает в фоновом режиме, отслеживая активность пользователя (доступ к документам, время, частоту) и индексирует эти данные в локальную History Database. Это происходит независимо от поисковых запросов.

Ранжирование (Server-Side RANKING)
Поисковая система на сервере обрабатывает запрос и генерирует стандартный набор результатов с оценками (search_engine_score). Это входные данные для клиентской системы.

Переранжирование (Client-Side RERANKING)
Основное применение патента. Происходит после получения результатов от сервера, но до их отображения.

1. Перехват: Browser Assistant перехватывает результаты сервера.
2. Локальный Поиск: Выполняется параллельный поиск в History Database.
3. Модификация: Сравнение результатов, расчет history_score и new_score (или изменение позиций), и модификация SERP.

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

• Запрос пользователя.
• Стандартная SERP от сервера с search_engine_score.
• Данные локальной History Database (индекс контента и поведенческие метрики).

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

• Модифицированный (персонализированный) набор результатов поиска.

На что влияет

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

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

• Условие активации: Пользователь выполняет поиск при активном Browser Assistant, и в History Database есть релевантные данные.
• Пороговые значения: В патенте упоминается возможность установки порогов. Например, информация используется для переранжирования, только если пользователь провел на документе более X секунд или посетил его более Y раз. Также может быть порог времени, которое должно пройти с момента доступа.

Пошаговый алгоритм (Implicit History Search)

1. Получение запроса и отправка на сервер: Пользователь вводит запрос, который отправляется поисковой системе.
2. Перехват результатов сервера: Browser Assistant перехватывает возвращенные результаты (Набор 1) с их search_engine_score.
3. Определение терминов запроса: Система определяет термины, использованные в запросе.
4. Локальный поиск: Выполняется поиск по History Database.
5. Ранжирование истории: Локальные результаты (Набор 2) ранжируются для вычисления history_score. Ранжирование основывается на дате, релевантности и метриках предпочтения (длительность, частота, рейтинг).
6. Сравнение наборов: Набор 1 и Набор 2 сравниваются для выявления совпадений.
7. Модификация результатов:
   • Переранжирование (Scoring): Для совпадений рассчитывается new_score (по аддитивной или мультипликативной формуле).
   • Переранжирование (Positioning): Позиция результата поднимается на фиксированное количество мест.
   • Добавление: Результаты из Набора 2, отсутствующие в Наборе 1, могут быть добавлены (например, в начало).
   • Удаление: Результаты с негативным рейтингом или очень коротким временем взаимодействия могут быть удалены.
8. Представление: Модифицированный набор результатов отображается пользователю.

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

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

Система использует данные, собранные локально на клиентском устройстве, и данные, полученные от поисковой системы.

• Поведенческие факторы (Локальные): Критически важные данные для расчета history_score. Включают:
  • Количество посещений документа пользователем (number of times accessed).
  • Даты и время посещений (первое, последнее).
  • Количество времени, проведенное пользователем на документе (amount of time spent).
  • Действия пользователя: печать (printed), добавление в закладки (bookmarked), сохранение (saved).
  • Рейтинг документа пользователем (user rating), например, с помощью кнопок голосования (voting buttons).
• Контентные факторы (Локальные): Текст документа, HTML, заголовок (Title). Индексируются локально для определения релевантности.
• Системные данные (Внешние): search_engine_score от поисковой системы.

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

• history_score (Оценка истории): Рассчитывается локально. Основана на том, насколько предполагается, что документ «нравится» пользователю. Агрегирует поведенческие факторы (частота, время, рейтинг).
• history_weight (Вес истории): Коэффициент, определяющий силу персонализации. Может быть настраиваемым пользователем.
• new_score (Новая оценка): Итоговая оценка. В патенте предложены две основные формулы:
  • Аддитивная: new_score = search_engine_score + history_weight * history_score
  • Мультипликативная: new_score = search_engine_score * (1 + history_weight * history_score)
• Фиксированное смещение позиции: Альтернатива new_score. Перемещение результата вверх на заранее определенное количество позиций.
• Пороги (Thresholds): Минимальное время или частота доступа для учета взаимодействия.

Выводы

1. Персонализация как слой поверх основного ранжирования: Патент четко разделяет стандартное ранжирование (search_engine_score) и персонализированное переранжирование (history_score). Персонализация может существенно изменить выдачу для конкретного пользователя.
2. Поведенческие сигналы как индикатор предпочтений: Система явно использует поведенческие метрики — время на сайте (Dwell Time), частоту повторных визитов и явные оценки — как ключевые индикаторы качества взаимодействия. Патент подтверждает их использование в контексте персонализации.
3. Множественные механизмы бустинга: Предусмотрены различные способы повышения предпочтительных результатов: аддитивный и мультипликативный пересчет оценки, а также фиксированный сдвиг позиций. Это дает гибкость в применении персонализации.
4. Клиентская реализация: Описанная реализация фокусируется на обработке данных на стороне клиента для снижения задержек и решения проблем конфиденциальности (актуально для периода подачи патента).
5. Лояльность конвертируется в ранжирование: Для SEO это означает, что формирование лояльной аудитории и стимулирование положительного опыта взаимодействия напрямую влияет на видимость сайта в персональной выдаче этих пользователей.

Практика

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

• Фокус на вовлеченности и удержании (User Engagement & Retention): Ключевая стратегия – создавать контент и UX, которые стимулируют длительное взаимодействие и повторные визиты. Согласно патенту, amount of time spent и frequency напрямую увеличивают history_score, что приводит к повышению позиций сайта в персонализированной выдаче для вернувшихся пользователей.
• Построение бренда и лояльности: Развитие сильного бренда критически важно. Чем чаще пользователь выбирает ваш сайт и чем лучше его опыт, тем сильнее будет эффект персонализации по широкому спектру запросов.
• Создание контента, достойного сохранения: Стимулируйте пользователей сохранять ваш контент или добавлять его в закладки. Патент упоминает отслеживание действий bookmarked и saved как сильных сигналов предпочтения.
• Оптимизация UX и удовлетворенности: Обеспечение положительного пользовательского опыта критично для формирования высокого history_score и предотвращения негативных сигналов.

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

• Привлечение нецелевого трафика и кликбейт: Если пользователь быстро покидает сайт (короткое время пребывания), это фиксируется негативно. Патент предполагает, что документы, посещенные лишь кратковременно (accessed only briefly), могут быть понижены или удалены из персональной выдачи пользователя.
• Игнорирование User Experience (UX) и скорости загрузки: Плохой пользовательский опыт приводит к ухудшению поведенческих метрик (время на сайте, частота визитов), что негативно сказывается на history_score.
• Фокус только на привлечении нового трафика: Стратегии, игнорирующие работу с существующей аудиторией, упускают возможность использовать механизмы персонализации для улучшения видимости сайта.

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

Патент подтверждает, что Google рассматривает поведение пользователя на сайте как важный индикатор качества для целей персонализации. Для Senior SEO-специалистов это означает, что стратегия не может фокусироваться только на достижении ТОП-1 в универсальной выдаче. Необходимо обеспечивать высокое качество взаимодействия, так как это напрямую влияет на видимость сайта для лояльной аудитории. Долгосрочный успех зависит не только от привлечения, но и от удержания пользователей.

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

Сценарий: Персонализация выдачи на основе предыдущего вовлечения

1. Первичное взаимодействие: Пользователь ищет «как настроить гитару». Он посещает Сайт А (подробное руководство) и проводит там 6 минут. Затем он посещает Сайт Б (короткая статья) и проводит там 45 секунд.
2. Локальная индексация: Browser Assistant записывает это в History Database. Сайт А получает высокий history_score из-за большой продолжительности сессии, а Сайт Б — низкий.
3. Последующий поиск: Через неделю пользователь ищет «лучшие струны для акустической гитары».
4. Стандартная выдача: В стандартной выдаче Сайт А находится на 7-й позиции.
5. Персонализация: Система идентифицирует Сайт А в истории с высоким history_score и применяет формулу пересчета (например, мультипликативную). new_score значительно увеличивается.
6. Результат: Сайт А перемещается с 7-й позиции на 1-ю или 2-ю позицию в выдаче для этого пользователя благодаря сильным персональным сигналам.

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