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

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

Candidate Query (Запрос-кандидат, CQ)

Исходный или предшествующий запрос в поисковой сессии, который пользователь впоследствии уточняет. Часто имеет низкие Quality Score и Navigation Score.

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

Данные о действиях пользователей в ответ на результаты поиска (клики, длительность кликов – long/short clicks).

Navigation Score (NS, Оценка навигационности)

Метрика, определяющая, является ли запрос навигационным. Основана на Navigational Metrics.

Navigational Resource (Навигационный ресурс)

Ресурс, который является целью поиска для навигационного запроса. Идентифицируется по высоким показателям CTR или Traffic Proportion.

Navigation Store (Хранилище навигационных данных)

База данных, хранящая ассоциации между Candidate Queries и Navigational Resources.

P(RQ)

Базовая вероятность ввода Revised Query (частота RQ / общее число запросов).

P(RQ|CQ)

Условная вероятность того, что Revised Query будет введен в той же сессии, что и Candidate Query.

Quality Score (QS, Оценка качества запроса)

Метрика качества запроса. Основана на Resource Metrics и, опционально, Revision Metrics.

Query Sequence (Последовательность запросов)

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

Revised Query (Уточненный запрос, RQ)

Запрос, следующий за Candidate Query в сессии. В контексте патента – это запрос с высокими QS и NS.

Revision Metrics (Метрики уточнений)

Данные, характеризующие процесс изменения запроса: тип (revision type), время (revision time), частота (revision frequency).

Resource Metrics (Метрики ресурсов)

Данные, характеризующие ресурсы, найденные по запросу: авторитетность (Authority Scores, например, PageRank), характеристики URL, CTR.

Traffic Proportion (Доля трафика)

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

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

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

1. Выбор Candidate Query (CQ) в Query Sequence из лога запросов.
2. Выбор последующего Revised Query (RQ) в той же последовательности.
3. Определение Quality Score (QS) и Navigation Score (NS) для RQ.
4. Проверка условия: QS(RQ) > Порога Качества И NS(RQ) > Порога Навигационности.
5. Если условие выполнено: Идентификация Navigational Resource для RQ.
6. Ассоциация этого Navigational Resource с CQ для использования в поисковых операциях.

Claim 2 (Зависимый от 1): Уточняет критерии выбора CQ.

Candidate Query выбирается, если его собственный NS ниже порога И его собственный QS ниже порога. Это гарантирует, что система улучшает выдачу только для тех запросов, которые действительно в этом нуждаются (т.е. исходных "плохих" запросов).

Claim 7 (Зависимый): Вводит проверку вероятности для подтверждения связи между запросами (соответствует шагу 226 на FIG. 2A).

Запрос определяется как Candidate Query, только если вероятность уточнения от него к RQ выше, чем общая вероятность ввода RQ. Это механизм защиты от ложных ассоциаций между несвязанными запросами, которые случайно оказались в одной сессии. $P(RQ|CQ) > P(RQ)$.

Claim 25 (Независимый пункт): Описывает альтернативный вариант реализации (FIG. 2B), где QS рассчитывается относительно CQ.

Метод аналогичен Claim 1, но QS для RQ определяется *относительно* CQ. Это позволяет оценить, насколько улучшилась выдача именно в результате этого конкретного уточнения (учитывая время и тип изменения), что повышает точность ассоциаций и отсекает смену темы поиска.

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

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

INDEXING – Индексирование и извлечение признаков
На этом этапе рассчитываются статические метрики ресурсов, которые позже используются для расчета Quality Score и Navigation Score (например, Authority Scores/PageRank, характеристики URL).

QUNDERSTANDING – Понимание Запросов (Офлайн-анализ)
Основная работа происходит офлайн. Компонент Revision Navigation Analyzer обрабатывает Query Logs и Click Logs.

• Вычисление метрик: Расчет QS и NS для запросов на основе агрегированных данных.
• Анализ последовательностей: Идентификация Query Sequences и выявление связей между CQ и RQ.
• Генерация ассоциаций: Создание и сохранение ассоциаций в Navigation Store.

RANKING – Ранжирование / RERANKING – Переранжирование (Онлайн-применение)
Во время обработки запроса пользователя система использует предварительно рассчитанные данные из Navigation Store.

• Корректировка релевантности (Ranking): Если входящий запрос соответствует CQ, система увеличивает оценку релевантности (Relevance Score) соответствующего Navigational Resource.
• Корректировка выдачи (Reranking): Альтернативно, система может переупорядочить уже сформированный набор результатов, повышая позицию Navigational Resource.

Входные данные (Офлайн):

• Query Logs (запросы, идентификаторы сессий, временные метки).
• Click Logs (клики, длительность кликов).
• Данные индекса (авторитетность ресурсов, перекрестные ссылки).

Выходные данные (Офлайн):

• Navigation Store (ассоциации CQ → Navigational Resource).

Выходные данные (Онлайн):

• Скорректированный набор результатов поиска с повышенным ранжированием Navigational Resource.

На что влияет

• Специфические запросы: Наибольшее влияние оказывается на общие, неоднозначные или информационные запросы, которые пользователи часто уточняют до конкретного навигационного интента (например, запрос "discussions", уточняемый до "usenet groups").
• Типы контента: Влияет на продвижение авторитетных хабов, порталов, официальных сайтов или ключевых страниц по теме, которые часто являются конечной целью поиска.

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

• Условие применения (Онлайн): Когда входящий запрос пользователя соответствует Candidate Query, для которого в Navigation Store существует ассоциация.
• Триггеры активации (Офлайн): Механизм анализа активируется, когда в логах обнаруживается Query Sequence, удовлетворяющая условиям: последующий запрос (RQ) имеет высокие QS и NS, а предшествующий запрос (CQ) часто имеет низкие оценки, и между ними существует статистически значимая связь (P(RQ|CQ) > P(RQ)).

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

Процесс А: Офлайн-генерация навигационных ассоциаций

1. Идентификация последовательностей: Анализ Query Logs для группировки запросов в Query Sequences (сессии) на основе идентификаторов и временных меток (например, в пределах 5 минут).
2. Выбор уточненного запроса (RQ): В рамках последовательности выбирается запрос, у которого QS и NS превышают установленные пороги.
3. Выбор предшествующего запроса (CQ): Выбирается запрос, который предшествует RQ в этой последовательности.
4. Оценка предшествующего запроса: Проверяется, являются ли QS и NS этого запроса ниже пороговых значений.
5. Валидация связи: Проверяется статистическая значимость связи: вероятность уточнения P(RQ|CQ) должна быть выше вероятности ввода RQ независимо P(RQ). (Или используется относительный QS).
6. Идентификация ресурса: Если условия выполнены, идентифицируется Navigational Resource для RQ (например, ресурс с самым высоким Traffic Proportion).
7. Сохранение ассоциации: Navigational Resource ассоциируется с CQ и сохраняется в Navigation Store.
8. Итерация: Процесс повторяется для всех запросов в логах.

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

1. Получение запроса: Система получает входящий запрос.
2. Проверка Navigation Store: Проверяется, соответствует ли запрос какому-либо Candidate Query в хранилище.
3. Корректировка ранжирования: Если соответствие найдено, система повышает релевантность (Relevance Score) связанного Navigational Resource. Патент упоминает возможность ограничения повышения ранга (например, не выше 4-й позиции).
4. Предоставление результатов: Формируется итоговая выдача с учетом повышения ранга.

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

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

Система использует комбинацию поведенческих, контентных/технических и ссылочных факторов для расчета ключевых метрик.

• Поведенческие факторы (из Query/Click Logs):
  • Последовательности запросов (Query Sequences).
  • Временные метки (для расчета Revision Time).
  • Частота уточнений (Revision Frequency).
  • Click-through rate (CTR).
  • Длительность кликов (long/short clicks).
  • Доля трафика (Traffic Proportion).
• Контентные/Технические факторы:
  • Характеристики URL (длина, глубина директории).
  • Текст запросов (для определения Revision Type: синонимы, степень изменения терминов).
• Ссылочные факторы:
  • Авторитетность ресурсов (Authority Scores, например, PageRank).
  • Перекрестные ссылки (Cross linkage) между ресурсами в выдаче.

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

Ключевыми метриками являются Quality Score и Navigation Score.

Quality Score (QS)

Рассчитывается на основе Resource Metrics и Revision Metrics.

• Resource Metrics (Влияние на QS): Высокая авторитетность ресурсов, высокий CTR, короткие URL → Повышают QS.
• Revision Metrics (Влияние на QS): Низкая частота последующих уточнений (пользователь удовлетворен), малое время между запросами (тесная связь), тип уточнения (синонимы лучше, чем полная смена темы) → Повышают QS.

Формула (Пример из патента): $QS = f1(f2(\text{Resource Metrics}), f3(\text{Revision Metrics}))$, где f1, f2, f3 – функции (например, взвешенная сумма).

Navigation Score (NS)

Рассчитывается на основе Navigational Metrics.

• Navigational Metrics (Влияние на NS): Высокая перекрестная связанность (Cross linkage), неравномерное распределение авторитетности (несколько явных лидеров), высокий CTR на конкретные ресурсы, высокая доля трафика (Traffic Proportion) на конкретные ресурсы → Повышают NS.

Патент указывает, что и QS, и NS могут быть результатом работы моделей машинного обучения (machine-learned model), обученных на данных с человеческими оценками.

1. Поведение пользователей формирует релевантность: Google активно использует агрегированные данные об уточнениях запросов для понимания истинного намерения. Если пользователи массово считают, что запрос А на самом деле означает запрос Б, Google научится показывать результаты для Б в ответ на А.
2. Авторитетность и клики как основа оценок: Quality Score и Navigation Score запросов напрямую зависят от авторитетности (Authority Scores) и кликабельности (CTR, Traffic Proportion) ресурсов в выдаче.
3. Защита от случайных ассоциаций: Система использует проверку вероятности (P(RQ|CQ) > P(RQ)) или относительный расчет QS, чтобы гарантировать, что ассоциация между запросами является статистически значимой, а не случайным совпадением в рамках одной сессии.
4. Механизм для обработки широких запросов: Этот механизм позволяет Google давать конкретные, авторитетные ответы на очень широкие или неточные запросы, если история поиска показывает, что пользователи ищут именно этот конкретный ресурс.
5. Важность быть конечной точкой поиска: Для SEO критически важно, чтобы сайт был Navigational Resource — ресурсом, на котором пользователи останавливают поиск (высокий CTR, низкая частота последующих уточнений).

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

• Станьте Navigational Resource в нише: Необходимо стремиться к тому, чтобы сайт стал основным пунктом назначения для конкретных, четко сформулированных запросов (Revised Queries). Это достигается через комплексное развитие E-E-A-T, построение бренда и обеспечение максимальной полезности контента.
• Оптимизация под финальный интент: Сосредоточьтесь на полном удовлетворении интента пользователя по уточненным запросам, чтобы минимизировать дальнейшие уточнения (низкий Revision Frequency). Это повысит Quality Score запроса, по которому вас находят.
• Анализ путей пользователей и упущенной семантики: Изучайте, как пользователи уточняют запросы в вашей нише. Если ваш сайт является лучшим ответом на уточненный запрос, Google может использовать его для ответа на более широкий спектр связанных, но менее точных запросов.
• Повышение CTR и Traffic Proportion: Работайте над сниппетами для увеличения CTR. Если ваш сайт является ответом на запрос, он должен получать подавляющую долю трафика по нему. Это увеличивает Navigation Score запроса.
• Улучшение технических характеристик URL: Патент явно упоминает, что короткие URL верхнего уровня положительно влияют на оценку качества. Поддерживайте чистую и логичную структуру URL.

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

• Фокус только на высокочастотных общих запросах: Попытка ранжироваться только по общим запросам (Candidate Queries) без создания сильной ассоциации с конкретными уточненными интентами (Revised Queries) неэффективна. Система предпочтет ресурс, который является целью навигации после уточнения.
• Создание контента, провоцирующего дальнейший поиск (Pogo-sticking): Контент, который не решает задачу пользователя полностью и вынуждает его возвращаться к выдаче и вводить уточняющие запросы, вредит сайту, снижая Quality Score связанных запросов.
• Игнорирование низкочастотных уточненных запросов: Пренебрежение оптимизацией под длинный хвост конкретных запросов лишает сайт возможности быть идентифицированным как Navigational Resource.

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

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

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

Сценарий: Оптимизация сайта хостинга под общий запрос

1. Исходный запрос (Candidate Query): "как создать сайт" (Низкий Navigation Score, смешанный интент).
2. Цепочка уточнений: Пользователи часто вводят -> "лучший хостинг для сайта" -> "хостинг wordpress с поддержкой php 8".
3. Уточненный запрос (Revised Query): "хостинг wordpress с поддержкой php 8" (Высокий Quality Score, высокий Navigation Score).
4. Действие SEO-специалиста: Обеспечить, чтобы сайт хостинг-провайдера был доминирующим Navigational Resource для Revised Query (Топ-1, высокий CTR, низкий показатель дальнейших уточнений).
5. Результат работы алгоритма: Google анализирует логи и видит, что значительная часть пользователей, начавших с "как создать сайт", в итоге приходит к сайту провайдера через уточненный запрос. Система проверяет статистическую значимость и создает ассоциацию.
6. Итог: Сайт хостинг-провайдера получает бустинг в выдаче по общему запросу "как создать сайт", даже если он напрямую под него не оптимизирован.