Как Google использует локальную историю поведения пользователя на устройстве для ранжирования результатов имплицитных (неявных) запросов

Описание

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

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

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

Запатентована система и метод для улучшения ранжирования с использованием данных о поведении пользователя на клиенте (client-side behavior data). Ядром изобретения, согласно финальным Claims, является генерация имплицитных запросов на основе мониторинга действий пользователя вне поисковой системы и последующее ранжирование результатов для этих запросов с использованием собранных поведенческих данных: Duration Data, Access Data, URL Data и Trajectory Data.

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

Система работает через Monitoring Engine на устройстве пользователя, который пассивно отслеживает взаимодействие с контентом. Он собирает данные о продолжительности активного просмотра (Duration), частоте и давности доступа (Access), способе доступа (например, ручной ввод URL) (URL Data) и последовательности просмотров (Trajectory). Когда система обнаруживает действие пользователя (например, ввод текста в приложении), которое интерпретируется как информационная потребность, она генерирует Implicit Query. Результаты ранжируются с учетом собранных поведенческих данных, чтобы повысить контент, который система считает наиболее важным для пользователя.

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

Средняя. Патент является продолжением заявок 2003-2004 годов и описывает архитектуру, характерную для продуктов типа Google Desktop Search. Однако концепции использования клиентских поведенческих данных для определения интереса пользователя и генерации имплицитных запросов крайне актуальны для современных систем, таких как Google Discover, Google Assistant, а также для персонализации поиска через данные Chrome и Android.

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

Влияние на SEO высокое (7/10), но косвенное. Патент не описывает алгоритмы основного веб-поиска, но детально раскрывает, какие поведенческие сигналы Google считает индикаторами ценности контента. Понимание того, как Google измеряет и интерпретирует Duration (включая Dwell Time), Access (стабильность интереса) и URL Data (прямой трафик), критически важно для разработки стратегий, направленных на удержание пользователя, повышение вовлеченности и построение бренда.

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

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

Access Data (Данные о доступе)

Метрики частоты и давности доступа к артиклю. Включают количество дней с ненулевым доступом, время с момента последнего доступа и общую частоту.

Article (Артикль)

Любая единица контента: веб-страница, документ, электронное письмо, медиафайл.

Client Behavior Data (Данные о поведении на стороне клиента)

Информация, собранная на устройстве пользователя, отражающая его взаимодействие с артиклями. Включает Duration, Access, URL и Trajectory Data.

Duration Data (Данные о продолжительности)

Данные о времени взаимодействия с артиклем. Включают механизмы для разграничения активного использования (учитывая скроллинг и т.д.) и простоя (Claim 9), а также атрибуцию времени между связанными страницами/доменами.

Hub Article (Артикль-хаб)

Артикль, к которому пользователь часто возвращается как к источнику ссылок на другие артикли (например, главная страница категории).

Implicit Query (Имплицитный/Неявный запрос)

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

Monitoring Engine (Механизм мониторинга)

Компонент на клиентском устройстве, который отслеживает действия пользователя и генерирует Client Behavior Data.

Trajectory Data (Данные о траектории)

Данные о последовательности посещенных артиклей. Используются для идентификации начала сессии (например, страница входа, Claim 19) и Hub Articles.

URL Data (Данные об URL)

Данные о способе доступа к URL: ручной ввод (Typed URL), выбор по гиперссылке или автозаполнение.

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

ВАЖНО: Хотя описание патента широко обсуждает использование поведенческих данных, независимые Claims (1 и 10) ограничивают защиту изобретения применением этих данных строго в контексте обработки имплицитных запросов.

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

1. Система получает implicit search query, сгенерированный на основе Client-side behavior data.
2. Процесс генерации включает:
   • Получение отслеживаемых пользовательских вводов в приложении (НЕ на странице поиска и НЕ в среде поисковой системы). Мониторинг пассивный.
   • Определение, что фраза, введенная пользователем, неявно определяет поисковый запрос (т.е. пользователь что-то ищет).
   • Генерация имплицитного запроса.
3. Идентификация артикля, релевантного имплицитному запросу.
4. Определение Ranking Score для этого артикля, основанного на Client-side behavior data.
5. Упорядочивание и предоставление результатов.

Claim 3 (Зависимый): Уточняет, что Client-side behavior data включает duration data, access data, URL data или trajectory data.

Claims 5-7 (Зависимые): Детализируют Duration Data, включая использование графа URL для пропогации весов (Claim 5) и учет времени, проведенного на связанных страницах или путях запроса (Claims 6, 7).

Claim 8 (Зависимый): Описывает механизм обратной связи (Dwell Time). Система выводит результаты поиска, отслеживает duration data для них и ассоциирует результаты с коротким временем просмотра с более низким ranking score.

Claim 9 (Зависимый): Уточняет измерение Duration Data. Система различает активное использование приложения и простой пользователя (Idle time).

Claim 19 (Зависимый): Уточняет использование Trajectory Data для идентификации веб-страниц, которые начали последовательность (сессию) связанных страниц.

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

Патент описывает систему, работающую преимущественно на стороне клиента, но концепции применимы к архитектуре персонализированного поиска.

CRAWLING & INDEXING (Сбор данных и Извлечение признаков на Клиенте)
Monitoring Engine постоянно отслеживает действия пользователя на устройстве, собирает Client Behavior Data и сохраняет их в локальном Data Store. Происходит ассоциация поведенческих сигналов с конкретными артиклями (URL, документами).

QUNDERSTANDING – Понимание Запросов
Ключевой этап для Claims этого патента. Система анализирует текущий контекст пользователя (ввод текста вне поиска) для обнаружения информационной потребности и генерации Implicit Query. Это механизм проактивного поиска.

RANKING / RERANKING (Персонализация)
Когда запрос (имплицитный или явный) получен, рассчитывается Ranking Score. Он в значительной степени зависит от Client Behavior Data, связанных с релевантными артиклями. Это позволяет персонализировать выдачу, отдавая предпочтение контенту, с которым пользователь взаимодействовал наиболее позитивно. Также применяется механизм обратной связи (Dwell Time, Claim 8).

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

• Текущие действия пользователя (ввод текста, активные приложения).
• База данных Client Behavior Data (Duration, Access, URL, Trajectory).

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

• Сгенерированный Implicit Query (если применимо).
• Персонализированный набор результатов поиска с Ranking Scores, скорректированными на основе поведения.

На что влияет

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

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

• Триггеры активации (для Implicit Query): Когда система обнаруживает в действиях пользователя (например, при наборе текста) фразу, которая указывает на информационную потребность (Claim 1).
• Условия применения (для Ранжирования): Когда для релевантных артиклей существуют накопленные Client Behavior Data.
• Временные рамки: Сбор данных происходит постоянно. Генерация запросов и ранжирование происходят в реальном времени.

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

Процесс А: Сбор данных (Фоновый режим)

1. Мониторинг действий: Monitoring Engine отслеживает взаимодействие пользователя с Articles.
2. Определение Duration Data: Фиксация времени на артикле. Применение логики для исключения времени простоя (Claim 9) и учета активности. Атрибуция времени, проведенного на связанных страницах, к основному домену.
3. Определение Access Data: Фиксация частоты доступа, подсчет количества дней с доступом, фиксация времени последнего доступа.
4. Определение URL Data: Фиксация метода доступа (ручной ввод, клик, автозаполнение).
5. Определение Trajectory Data: Анализ последовательности доступа для идентификации сессий (начало/конец) и Hub Articles.
6. Хранение данных: Сохранение данных в Client Behavior Data Database.

Процесс Б: Обработка имплицитного запроса (Реальное время)

1. Обнаружение триггера: Система анализирует текущие действия пользователя (например, ввод текста вне поисковой строки).
2. Генерация имплицитного запроса: Если обнаружена информационная потребность, система генерирует Implicit Query (Claim 1).
3. Определение релевантных артиклей: Поиск кандидатов, соответствующих запросу.
4. Получение поведенческих данных: Для каждого кандидата извлекаются связанные Client Behavior Data.
5. Расчет Ranking Score: Ranking Processor вычисляет оценку на основе поведенческих данных (повышение за ручной ввод URL, частое посещение, длительное активное время просмотра).
6. Упорядочивание и представление: Артикли сортируются и представляются пользователю.

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

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

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

• Поведенческие факторы (Client-Side):
  • Время, проведенное на артикле (Duration Data).
  • Активность во время просмотра (скроллинг, клики) для верификации внимания (Claim 9).
  • Частота посещений и количество уникальных дней посещения (Access Data).
  • Время с момента последнего доступа (Access Data).
  • Метод доступа к URL (URL Data): ручной ввод (Typed URL), автозаполнение, переход по ссылке (из веба или email).
  • Последовательность посещенных артиклей (Trajectory Data).
  • Роль артикля в сессии: стартовая страница, хаб (Claim 19).
• Пользовательские факторы:
  • Текущий контекст и ввод текста в приложениях для генерации Implicit Query (Claim 1).

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

Система использует сложные метрики для оценки интереса пользователя:

• Взвешенная продолжительность (Weighted Duration): Время на странице корректируется с учетом активности пользователя. Также используется атрибуция времени: часть времени, проведенного на подстраницах или связанных страницах (в пределах N кликов), может атрибутироваться к основной странице или домену (Claims 5, 6, 7).
• Dwell Time / Обратная связь (Feedback): Время просмотра результата поиска. Короткое время взаимодействия ассоциируется с более низким Ranking Score (Claim 8).
• Стабильность доступа (Access Stability): Предпочтение отдается артиклям, которые посещаются стабильно в течение многих дней (Метрика: Количество дней с >0 доступов), а не тем, которые были посещены много раз за короткий период.
• Затухание интереса (Interest Decay): Важность артикля уменьшается со временем с момента последнего доступа. Патент предлагает использовать различные функции для этого: линейные, экспоненциальные или кусочные (piecewise).
• Намерение доступа (Access Intent): Оценка на основе URL Data. Ручной ввод URL получает значительно больший вес, чем переход по ссылке из веба.
• Структурная важность (Trajectory Significance): Артикли в начале траектории (Claim 19) или являющиеся хабами получают повышенный вес.

Выводы

1. Имплицитный поиск как основное изобретение: Финальная версия патента (B2) защищает именно механизм генерации запросов на основе действий пользователя вне поисковой строки и ранжирование результатов для этих запросов с использованием поведенческих данных. Это основа проактивных систем.
2. Глубокий анализ поведения пользователя: Патент детально описывает, как Google интерпретирует поведение пользователя как сигнал интереса. Это не просто учет кликов, а сложный анализ контекста взаимодействия.
3. Duration ≠ Простое время на странице: Система измеряет «активное» время, исключая простои (Claim 9). Кроме того, время агрегируется: активность на дочерних страницах может повышать оценку основного домена.
4. Подтверждение Dwell Time: Claim 8 явно подтверждает использование Dwell Time (короткое время взаимодействия с результатом поиска) как негативного сигнала для ранжирования.
5. Контекст доступа имеет значение (Typed URL): Способ доступа к контенту является сильным сигналом намерения. Ручной ввод URL ценится значительно выше, чем переход по ссылке.
6. Траектория и роль страницы: Система анализирует последовательность посещений (Trajectory), чтобы определить роль страницы в сессии. Стартовые страницы и страницы-хабы получают дополнительный вес.

Практика

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

Хотя патент фокусируется на клиентской системе, описанные сигналы интереса пользователя крайне важны для SEO, так как они лежат в основе систем персонализации и оценки качества взаимодействия.

• Оптимизация под активное взаимодействие (Active Duration): Стимулируйте взаимодействие с контентом (скроллинг, клики, использование интерактивных элементов). Недостаточно просто удерживать пользователя на странице, если он неактивен (Claim 9).
• Минимизация коротких кликов (Dwell Time): Убедитесь, что сниппеты и заголовки точно соответствуют содержанию страницы. Контент должен удовлетворять интент пользователя, чтобы избежать быстрого возврата на выдачу (Claim 8).
• Построение бренда и прямого трафика (Typed URL): Развивайте бренд так, чтобы пользователи вводили ваш домен вручную. Это сильнейший сигнал намерения и интереса (URL Data).
• Стимулирование стабильного возврата (Access Stability): Создавайте контент и функционал, который мотивирует пользователей возвращаться на сайт регулярно, в разные дни. Стабильный интерес ценится выше, чем разовый всплеск.
• Оптимизация архитектуры под «Хабы» (Hub Articles): Создавайте страницы-хабы, которые служат отправной точкой для изучения темы. Система может атрибутировать активность с дочерних страниц к странице-хабу (Trajectory Data).

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

• Использование кликбейта: Привлечение трафика с помощью обманчивых заголовков приведет к коротким сессиям (плохой Dwell Time), что явно ведет к понижению рейтинга (Claim 8).
• Искусственное удержание пользователя без вовлечения: Попытки увеличить время на сайте без реального взаимодействия неэффективны, так как система стремится отличать активное время от простоя (Claim 9).
• Фокус на одноразовом трафике: Полагаться только на трафик, приходящий по ссылкам, менее эффективно для построения сигналов долгосрочного интереса, чем стимулирование прямых заходов или регулярных возвратов.

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

Патент подтверждает, что Google обладает механизмами для глубокого анализа поведения пользователей на уровне отдельных устройств и использует эти данные для оценки интереса и персонализации. Для SEO это означает, что стратегии должны быть направлены на обеспечение глубокого, стабильного и долгосрочного взаимодействия с сайтом. Построение бренда, прямого трафика и лояльной аудитории становится измеряемым фактором ранжирования в персонализированной выдаче. Также патент указывает на развитие проактивного поиска (Implicit Queries), интегрированного в пользовательский контекст.

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

Сценарий 1: Атрибуция времени (Duration Data Aggregation)

1. Ситуация: Пользователь заходит на главную страницу блога (blog.com), проводит там 10 секунд, переходит на статью (blog.com/article1) и активно читает ее (скроллит) 5 минут.
2. Действие системы: Система фиксирует короткое время на blog.com и длительное активное время на blog.com/article1.
3. Применение алгоритма: Система применяет логику атрибуции (Claims 5, 6, 7). Часть времени (5 минут), проведенного на дочерней странице, атрибутируется к основному домену (blog.com).
4. Результат: Общая оценка интереса к blog.com увеличивается за счет активности на связанных страницах, повышая его в персонализированной выдаче.

Сценарий 2: Сравнение по методу доступа (URL Data)

1. Ситуация: Пользователь посещает два сайта: Site A и Site B.
2. Действие пользователя: Site A он находит через поиск (клик по ссылке). Site B он вводит вручную в адресную строку (Typed URL).
3. Действие системы: Monitoring Engine фиксирует разные методы доступа (URL Data).
4. Результат: При последующих запросах система присвоит Site B более высокий Ranking Score (при прочих равных), так как ручной ввод URL интерпретируется как более сильный сигнал интереса.

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