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

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

Adjusting Engine (Механизм корректировки)

Онлайн-компонент системы, который сравнивает текущую поисковую сессию с историческими паттернами и корректирует ранжирование результатов. Также называется Contextual Search Engine.

Click Logs (Логи кликов)

Данные, фиксирующие, какие элементы контента были выбраны (кликнуты) пользователями в ответ на запросы.

Content Item (Элемент контента)

Результат поиска (например, веб-страница, документ, медиафайл).

Content Terminus (Конечная точка контента)

Элемент контента (например, URL), который пользователи статистически значимо выбирают в конце определенного Query Path. Это точка завершения поисковой задачи.

Context (Контекст)

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

Mining Engine (Механизм анализа данных)

Офлайн-компонент системы, который обрабатывает Query Logs и Click Logs для выявления Query Paths и Content Terminuses.

Noise Path (Шумовой путь)

Последовательность запросов, которая не является статистически значимой и игнорируется системой.

Query Logs (Логи запросов)

Данные, фиксирующие запросы, отправленные пользователями поисковой системе.

Query Path (Путь запросов)

Статистически значимая серия запросов (в определенном порядке или как набор), которую пользователи вводят во время поисковой сессии и которая завершается выбором Content Terminus.

Selection Distribution (Распределение выбора)

Вероятность выбора конкретного Content Item в контексте определенного Query Path. Используется для пропорционального масштабирования корректировки ранжирования.

Statistical Search Patterns (Статистические поисковые паттерны)

Обобщенный термин для выявленных закономерностей в логах, включающий Query Paths и Content Terminuses.

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

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

1. Выбор Query Paths (последовательность запросов из прошлых сессий).
2. Идентификация Content Terminuses (кликнутый контент в конце пути).
3. Идентификация Context текущей сессии.
4. Критическое условие: Определение связи между текущим Context и выбранным Query Path ТОЛЬКО если два или более запросов из Query Path похожи на два или более запросов текущей сессии.
5. Идентификация двух или более Content Items, связанных с Content Terminus.
6. Определение вероятности выбора (likelihood или Selection Distribution) для каждого Content Item.
7. Корректировка ранжирования каждого Content Item пропорционально этой вероятности.

Ядро изобретения — это использование исторических последовательностей запросов (требующих минимум два совпадения с текущей сессией) для предсказания желаемого результата и пропорциональная корректировка ранжирования на основе исторических данных о кликах.

Claim 5 (Независимый пункт): Альтернативное описание метода, фокусирующееся на Statistical Search Patterns.

1. Анализ Click Logs и Query Logs.
2. Выбор Statistical Search Patterns.
3. Сравнение запросов текущей сессии с паттернами.
4. Критическое условие: Определение связи текущей сессии с паттерном ТОЛЬКО если два или более запросов паттерна похожи на два или более запросов текущей сессии.
5. Идентификация двух или более Content Items, связанных с паттерном.
6. Определение вероятности выбора и пропорциональная корректировка ранжирования.

Claims 9-12 (Зависимые от 5): Вводят концепцию категоризации. Система может идентифицировать категории для Query Paths, текущей сессии и Content Terminuses, и использовать совпадение этих категорий как дополнительный фактор для корректировки ранжирования.

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

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

INDEXING / QUNDERSTANDING (Офлайн-обработка)
На этих этапах происходит предварительная обработка данных. Mining Engine анализирует Query Logs и Click Logs. Система выявляет Statistical Search Patterns, определяет Query Paths, идентифицирует Content Terminuses и рассчитывает Selection Distribution. Эти данные сохраняются для быстрого доступа.

QUNDERSTANDING (Онлайн-обработка)
Во время сессии пользователя система отслеживает последовательность запросов для определения текущего Context. Происходит сравнение этого контекста с предварительно рассчитанными Query Paths.

RANKING / RERANKING
Основное применение патента. После генерации начального набора результатов Adjusting Engine вмешивается. Если текущий Context совпадает с историческим Query Path (условие: 2+ общих запроса), система идентифицирует связанные Content Terminuses и корректирует их Ranking Scores. Корректировка масштабируется пропорционально Selection Distribution. Затем результаты пересортировываются.

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

• Офлайн: Исторические Query Logs и Click Logs.
• Онлайн: Текущая поисковая сессия (Context), текущий запрос, база данных Query Paths и Content Terminuses.

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

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

На что влияет

• Специфические запросы: Наибольшее влияние оказывается на информационные, исследовательские (exploratory) и уточняющие (refinement) запросы, где пользователи выполняют многошаговый поиск. Меньше влияет на навигационные запросы.
• Конкретные ниши: Тематики, требующие глубокого изучения или сравнения (например, путешествия, финансы, e-commerce, технологии), где пользователи часто переформулируют запросы в рамках одной сессии.

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

Алгоритм применяется при выполнении строгих условий, определенных в Claims:

• Условие сессии: Пользователь должен ввести несколько запросов в рамках текущей сессии, чтобы сформировался Context.
• Триггер активации (Порог совпадения): Система активируется ТОЛЬКО тогда, когда два или более запросов из текущей сессии похожи на два или более запросов из идентифицированного исторического Query Path. Система не активируется на основе одного запроса.
• Наличие данных: Должны существовать предварительно рассчитанные статистически значимые Query Paths. Если путь признан Noise Path, механизм не применяется.

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

Процесс А: Офлайн-анализ данных (Mining)

1. Сбор данных: Агрегация Query Logs и Click Logs из прошлых поисковых сессий.
2. Идентификация серий запросов: Выявление последовательностей запросов, которые завершились выбором определенного Content Item.
3. Оценка статистической значимости: Определение, является ли серия запросов статистически значимой.
   • Если НЕТ: Серия определяется как Noise Path (шум).
   • Если ДА: Серия определяется как Query Path.
4. Определение Content Terminus: Идентификация Content Item(s), связанных с Query Path.
5. Расчет распределения выбора: Если с Query Path связано несколько Content Items, рассчитывается Selection Distribution (например, URL 1 выбран в 60% случаев, URL 2 в 40%).
6. Сохранение: Query Paths, Content Terminuses и Selection Distribution сохраняются в базе данных.

Процесс Б: Онлайн-обработка запроса и корректировка ранжирования

1. Отслеживание сессии и определение контекста: Идентификация запросов текущей сессии пользователя (Context).
2. Сравнение с Query Paths: Сравнение текущего Context с базой исторических Query Paths.
3. Проверка триггера: Определение, связан ли Context с каким-либо Query Path. Условие: минимум два запроса из сессии должны совпадать с минимум двумя запросами из Query Path.
   • Если НЕТ: Использовать стандартное ранжирование.
   • Если ДА: Перейти к шагу 4.
4. Идентификация Content Terminuses: Получение Content Terminuses и их Selection Distribution, связанных с совпавшим Query Path.
5. Получение результатов: Идентификация Content Items, релевантных текущему запросу.
6. Корректировка ранжирования: Корректировка рангов идентифицированных Content Terminuses. Масштаб корректировки пропорционален их Selection Distribution. (Опционально: понижение ранга контента, который редко выбирается в этом контексте).
7. Выдача результатов: Предоставление пользователю переранжированного списка результатов.

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

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

Система полагается исключительно на поведенческие данные для работы этого механизма корректировки:

• Поведенческие факторы:
  • Query Logs: Последовательности запросов, введенных пользователями в рамках сессий. Это основной источник для определения Query Paths и текущего Context.
  • Click Logs: Данные о выборе контента пользователями. Это основной источник для определения Content Terminuses и расчета Selection Distribution.

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

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

• Статистическая значимость (Statistical Significance): Метрика для определения, является ли серия запросов действительным Query Path или шумом (Noise Path). Рассчитывается на основе частоты встречаемости серии в логах.
• Selection Distribution (Распределение выбора): Вероятность того, что конкретный Content Item будет выбран в контексте определенного Query Path. Рассчитывается на основе исторических данных о кликах для данного пути.
• Степень сходства (Degree of Similarity) / Связь контекста (Context Relation): Метрика для сравнения запросов текущей сессии с запросами в Query Path. Может использовать точное совпадение, семантическую близость или варианты объединения (Union, Exclusive Union).
• Порог совпадения контекста: Жестко заданное условие в Claims: минимум 2 совпадающих запроса между текущей сессией и историческим Query Path.
• Масштаб корректировки (Adjustment Scale): Величина, на которую изменяется ранг Content Item. Она прямо пропорциональна Selection Distribution.

1. Контекст сессии как фактор ранжирования: История запросов пользователя в рамках текущей сессии напрямую влияет на ранжирование результатов следующего запроса. Система пытается предсказать конечную цель пользователя, а не просто ответить на последний запрос.
2. Важность поведенческих паттернов: Система полностью основана на анализе исторических поведенческих данных (Query Logs и Click Logs). Статистически значимые пути пользователей (Query Paths) становятся основой для корректировки ранжирования.
3. Ориентация на User Journey и Task Completion: Механизм отдает предпочтение контенту, который исторически завершал поисковую задачу (Content Terminus). Это подчеркивает важность удовлетворенности пользователя и решения его проблемы.
4. Пропорциональное усиление (Proportional Boosting): Корректировка ранжирования не бинарна. Чем чаще URL выбирался в конце определенного пути в прошлом (выше Selection Distribution), тем сильнее он будет повышен в ранжировании при обнаружении этого пути в текущей сессии.
5. Порог активации в два запроса: Механизм не активируется на основе одного запроса. Для его запуска необходимо совпадение как минимум двух запросов между текущей сессией и историческим путем, что обеспечивает надежность контекста.
6. Возможность понижения: Хотя основной фокус на повышении Content Terminuses, патент также упоминает возможность понижения контента, который имеет высокий базовый ранг, но редко выбирается в определенном контексте.

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

• Оптимизация под User Journey и Task Completion: Фокусируйтесь на том, чтобы ваш контент был лучшим конечным ответом (Content Terminus). Анализируйте, какие серии запросов (Query Paths) используют пользователи в вашей нише, и убедитесь, что контент полностью удовлетворяет интент, стоящий за всем путем, а не только за последним запросом.
• Создание контента для сложных задач: Разрабатывайте подробный, авторитетный контент (например, Pillar Pages, Hubs), который может служить конечной точкой для многошаговых поисковых сессий. Это повышает вероятность того, что ваш сайт будет идентифицирован как статистически значимый Content Terminus.
• Анализ поведения и повышение удовлетворенности: Используйте аналитику для минимизации возврата в поиск (pogo-sticking). Высокая удовлетворенность контентом способствует тому, что ваш сайт будет чаще фиксироваться в Click Logs как успешное завершение сессии, увеличивая ваш Selection Distribution.
• Семантическое покрытие темы: Обеспечьте широкий охват темы, чтобы ваш контент был релевантен различным запросам в рамках одного Query Path. Это увеличивает вероятность того, что система повысит ваш контент на разных этапах поисковой сессии пользователя.

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

• Оптимизация только под изолированные ключевые слова: Игнорирование контекста сессии. Если ваш контент отвечает только на один узкий запрос, но не удовлетворяет более широкую потребность, он вряд ли станет Content Terminus и может быть вытеснен другими результатами, как только контекст будет определен.
• Использование кликбейта и неудовлетворение интента: Привлечение трафика, который быстро покидает сайт и возвращается к поиску для уточнения запроса. Это генерирует негативные поведенческие сигналы, уменьшая вероятность идентификации вашего сайта как Content Terminus.
• Создание поверхностного контента: Контент, который заставляет пользователя искать дополнительную информацию по той же теме в рамках той же сессии, проигрывает ресурсам, которые сразу дают исчерпывающий ответ и становятся конечной точкой сессии.

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

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

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

Сценарий: Планирование путешествия (Исследовательская сессия)

1. Исторический паттерн (Query Path): Google идентифицировал путь: Q1: "погода на Бали в октябре" -> Q2: "лучшие пляжи Бали" -> Q3: "отели на Бали Семиньяк". Content Terminus: Агрегатор отелей (URL_A) и сайт отзывов (URL_R). Selection Distribution: URL_A (60%), URL_R (40%).
2. Текущая сессия пользователя (Шаг 1): Пользователь вводит Q1: "Бали октябрь погода". Ранжирование стандартное.
3. Текущая сессия пользователя (Шаг 2): Пользователь вводит Q2: "популярные пляжи Бали".
4. Активация механизма: Система обнаруживает совпадение 2 запросов с историческим Query Path. Текущий Context совпадает с паттерном планирования поездки.
5. Корректировка ранжирования: Для текущего запроса Q2 система агрессивно повышает ранжирование URL_A и URL_R, даже если они не идеально оптимизированы под этот конкретный запрос. URL_A получает больший буст, чем URL_R, согласно Selection Distribution.
6. Результат: Пользователь видит в топе выдачи сайты, которые исторически помогали другим пользователям планировать поездку.