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

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

Parent Query (Родительский запрос)

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

Child Query (Дочерний запрос)

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

Sibling Queries (Родственные запросы)

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

Session Data (Данные сессии)

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

Fan-out (Ветвление)

Метрика для родительского запроса, равная количеству уникальных дочерних запросов, связанных с ним. Высокий Fan-out может указывать на слишком общий родительский запрос, и такие запросы могут фильтроваться.

Fan-in (Схождение)

Метрика для дочернего запроса, равная количеству уникальных родительских запросов, связанных с ним. Высокий Fan-in может указывать на слабость связи с конкретным родителем, и такие запросы могут фильтроваться.

Strength of Relationship (Сила связи)

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

Intra-suggestion diversity / Intra-sibling diversity (Разнообразие внутри предложений)

Метрика, оценивающая разнообразие между топовыми документами, релевантными кандидату в родственные запросы, и документами, уже "увиденными" (seen documents) по исходному запросу и другим принятым предложениям.

Seen Documents (Увиденные документы)

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

User Preference Data (Данные о предпочтениях пользователя)

Данные о кликах (click data), включающие click-through-rate (CTR), взвешенные клики (weighted clicks), показы и другие метрики, используемые для оценки качества результатов и ранжирования родственных запросов.

Inverse Document Frequency (IDF, Обратная частота документа)

Метрика, используемая для фильтрации родительских запросов. Низкий IDF может указывать на слишком популярные концепции, которые не несут много информации для их дочерних запросов.

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

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

1. Ассоциация родительских запросов с группами дочерних запросов (на основе сессий).
2. Идентификация кандидатов в родственные запросы (candidate sibling queries) для конкретного дочернего запроса. Условия идентификации:
   • Родители обоих запросов (как исходного дочернего, так и кандидата) должны иметь показатель Fan-out, удовлетворяющий пороговому значению (т.е. не иметь слишком много детей).
   • Запросы должны иметь группу общих родителей (shared parent queries), размер которой удовлетворяет порогу общих запросов (common-query threshold).
3. Выбор финальных родственных запросов (final sibling queries) из кандидатов и их ассоциация в качестве уточнений.

Claim 3 (Зависимый от 1): Уточняет механизм выбора финальных запросов. Группа финальных родственных запросов выбирается на основе разнообразия (diversity) между документами, релевантными этим финальным запросам.

Claim 13 (Независимый пункт): Описывает процесс с акцентом на разнообразие и строгое определение дочернего запроса (без промежуточных запросов).

1. Ассоциация родительских и дочерних запросов, при условии, что дочерний запрос следовал за родительским без каких-либо промежуточных запросов в сессии.
2. Идентификация кандидатов в родственные запросы (с условием достаточности общих родителей).
3. Выбор финальных родственных запросов из кандидатов на основе разнообразия (diversity) между документами, релевантными этим финальным запросам.

Claim 19 (Зависимый от 13): Детализирует итеративный алгоритм выбора на основе разнообразия.

1. Кандидаты упорядочиваются (ранжируются).
2. Система обрабатывает кандидатов по порядку.
3. Для кандидата определяется, удовлетворяет ли его оценка разнообразия (intra-sibling diversity score) пороговому значению. Оценка измеряет разнообразие между топовыми документами кандидата и группой увиденных документов (seen documents).
4. Если ДА, кандидат добавляется в финальную группу.
5. Топовые документы принятого кандидата добавляются в группу seen documents.

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

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

QUNDERSTANDING – Понимание Запросов
Основная работа происходит на этом этапе в офлайн-режиме. Sibling Refinements Engine анализирует Session Data и User Preference Data для построения карты взаимосвязей между запросами (родитель-ребенок-родственник). Здесь генерируется база данных уточнений (Refinement Database).

INDEXING – Индексирование
Данные из индекса используются для расчета Inverse Document Frequency (IDF) для фильтрации родительских запросов, а также для определения топовых документов (top_docs), используемых при расчете разнообразия.

METASEARCH – Метапоиск и Смешивание / RERANKING – Переранжирование
На этапе формирования SERP система обращается к базе данных уточнений, чтобы получить предварительно рассчитанные родственные запросы. Процесс фильтрации разнообразия (описанный в FIG. 8 и Claim 19) может применяться здесь (или быть предварительно рассчитанным) для выбора финального набора предложений, гарантируя, что они разнообразны по отношению друг к другу и к основному запросу.

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

• Session Data (последовательности запросов).
• User Preference Data (данные о кликах, CTR, показы).
• Индекс документов (для расчета IDF и получения результатов).

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

• Ассоциации Дочерний Запрос — Финальные Родственные Запросы (Child-Final Sibling Associations), сохраненные в базе данных уточнений.

На что влияет

• Специфические запросы: Наибольшее влияние на информационные и широкие запросы, где пользователи часто занимаются исследованием темы и переходят от одного связанного концепта к другому (например, от [Jupiter] к [Mars] или [Jupiter Moons]).
• Типы контента: Влияет на все типы контента, так как механизм основан на анализе запросов и разнообразии результатов, независимо от формата контента.

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

• Временные рамки: Основной анализ (идентификация родителей/детей/родственников) происходит офлайн в рамках пакетной обработки логов сессий. Выбор финального набора с учетом разнообразия происходит при генерации SERP или также рассчитывается офлайн.
• Триггеры активации (для идентификации связи): Активируется, когда два запроса имеют достаточное количество общих родителей (common-query threshold), и эти родители удовлетворяют требованиям качества (например, пороги Fan-out и IDF).
• Триггеры активации (для выбора предложения): Активируется, когда кандидат в родственные запросы демонстрирует достаточный уровень разнообразия результатов (intra-sibling diversity score выше порога) по сравнению с уже увиденными результатами.

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

Процесс состоит из двух основных частей: идентификация кандидатов и фильтрация для обеспечения разнообразия.

Часть А: Идентификация кандидатов в родственные запросы (Офлайн)

1. Сбор и очистка данных сессий: Получение Session Data, удаление подозрительного трафика (боты, спам), анонимизация.
2. Ассоциация Родитель-Ребенок: Идентификация пар запросов, где один следует за другим в сессии (часто без промежуточных запросов). Применение базовых фильтров (например, время между запросами, наличие клика после дочернего запроса).
3. Фильтрация дочерних запросов (Child Filter): Удаление дочерних запросов, у которых показатель Fan-in (количество родителей) превышает порог.
4. Фильтрация родительских запросов (Parent Filter): Удаление родительских запросов, у которых показатель Fan-out (количество детей) превышает порог. Также могут удаляться родители с низким IDF или являющиеся суперстрокой (superstring) ребенка.
5. Идентификация родственных связей (Sibling Associator): Для каждого дочернего запроса поиск других запросов, имеющих общих родителей. Проверка, что количество общих родителей удовлетворяет порогу (common-query threshold).
6. Расчет силы связи: Вычисление Strength of Relationship между родственными запросами на основе частоты их совместного появления после общих родителей. Фильтрация слабых связей.
7. Ранжирование кандидатов (Sibling Ranking Engine): Ранжирование оставшихся кандидатов для каждого дочернего запроса с использованием User Preference Data (например, CTR, взвешенные клики) или количества общих родителей.

Часть Б: Фильтрация для обеспечения разнообразия (Sibling Filtering Engine)

Этот процесс выполняется для каждого дочернего запроса и его списка ранжированных кандидатов.

1. Инициализация: Создается пустой список финальных предложений (final_sibs). Инициализируется набор увиденных документов (seen_docs), который включает топовые документы исходного (дочернего) запроса.
2. Итерация по кандидатам: Система обрабатывает ранжированных кандидатов по одному.
3. Расчет разнообразия: Для текущего кандидата (additional_sib) вычисляется intra-suggestion diversity. Это оценка того, насколько топовые результаты кандидата отличаются от документов в seen_docs.
4. Проверка порога разнообразия: Сравнение оценки разнообразия с порогом.
   • Если НЕТ (результаты слишком похожи): Кандидат отклоняется, переход к следующему.
   • Если ДА (результаты разнообразны): Кандидат принимается и добавляется в final_sibs.
5. Обновление увиденных документов: Если кандидат принят, его топовые документы добавляются в seen_docs. Это гарантирует, что следующий кандидат будет сравниваться и с ним тоже.
6. Завершение: Процесс продолжается до тех пор, пока не будет достигнуто желаемое количество финальных предложений (desired_sibs) или пока не закончатся кандидаты.

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

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

• Поведенческие факторы: Являются основными данными для этого патента.
  • Session Data: Последовательность запросов пользователей в рамках одной сессии. Используется для определения связей родитель-ребенок.
  • User Preference Data (Click Data): Данные о кликах, взвешенных кликах (weighted clicks), CTR, показах (impressions). Используются для: (i) валидации связи родитель-ребенок (требование клика после ребенка); (ii) ранжирования кандидатов в родственные запросы; (iii) расчета оценки разнообразия (intra-sibling diversity score).
• Контентные/Системные факторы:
  • Индекс документов: Используется для получения топовых результатов по запросам (для расчета разнообразия) и для расчета IDF.

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

• Fan-out: Количество уникальных дочерних запросов для данного родителя. Используется для фильтрации слишком общих родителей.
• Fan-in: Количество уникальных родительских запросов для данного ребенка. Используется для фильтрации детей со слабыми связями.
• Common-query threshold: Минимальное количество общих родителей, необходимое для признания двух запросов родственными.
• Strength of Relationship: Агрегированное значение частот, с которыми родственные запросы следовали за общими родителями. Может взвешиваться обратно пропорционально Fan-in и Fan-out.
• Intra-sibling diversity score: Оценка разнообразия результатов. Рассчитывается на основе User Preference Data (например, суммы оценок качества или tuple score) для документов, которые присутствуют в топе кандидата, но отсутствуют в наборе seen_docs.
• Inverse Document Frequency (IDF): Стандартная метрика IR, используемая для оценки важности/специфичности родительского запроса.

1. Поведение пользователей определяет связь запросов: Патент демонстрирует, что Google использует реальные последовательности запросов пользователей (Session Data) для определения того, какие темы связаны между собой. Это поведенческое определение связи может отличаться от связей, установленных только на основе семантического анализа текста запросов или контента страниц.
2. Разнообразие является приоритетом для уточнений: Ключевая часть изобретения — механизм intra-suggestion diversity. Google активно избегает предложений ("Связанные запросы"), которые ведут к тем же результатам, что и исходный запрос или другие предложения в блоке. Цель — помочь пользователю исследовать новые направления.
3. Фильтрация шума через Fan-in/Fan-out: Использование метрик Fan-in и Fan-out позволяет системе игнорировать связи, основанные на слишком общих запросах (высокий Fan-out) или случайных переходах (высокий Fan-in), фокусируясь на значимых паттернах поведения.
4. Качество и Сила связи: Система не просто находит связи, но и количественно оценивает их через Strength of Relationship и ранжирует кандидатов, используя данные о кликах (User Preference Data), чтобы предложить наиболее полезные уточнения.

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

• Построение тематического авторитета через покрытие смежных интентов: Создавайте контент, который охватывает не только основной запрос, но и родственные запросы (sibling queries), которые пользователи естественным образом исследуют в рамках одной сессии. Это укрепляет релевантность сайта теме в целом.
• Анализ блока "Связанные запросы" (Related Searches): Регулярно анализируйте, какие запросы Google показывает в этом блоке для ваших ключевых слов. Это прямой индикатор того, какие sibling queries система идентифицировала на основе поведения пользователей. Эти запросы должны быть интегрированы в вашу контент-стратегию.
• Создание отдельных страниц для различных интентов: Поскольку система активно ищет разнообразие результатов (diversity), важно, чтобы разные родственные запросы вели на разные страницы вашего сайта (или на страницы с существенно разным контентом). Если несколько связанных запросов ведут к очень похожим результатам, Google не посчитает их достаточно разнообразными для показа в качестве уточнений.
• Оптимизация под путь пользователя (User Journey): Проектируйте структуру сайта и перелинковку так, чтобы она соответствовала естественному пути исследования темы, который описан в патенте (от родителя к различным детям/родственникам).

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

• Создание почти дублирующихся страниц (Keyword Cannibalization): Попытка ранжироваться по множеству очень похожих ключевых слов с помощью отдельных страниц с минимальными отличиями неэффективна в контексте этого патента. Система ищет разнообразие результатов, и такие страницы не будут считаться разнообразными (diverse).
• Игнорирование пути пользователя: Фокусировка только на отдельных высокочастотных запросах без учета того, как пользователи переходят от них к связанным темам в рамках сессии.
• Попытки манипулировать данными сессий: Использование ботов для генерации искусственных последовательностей запросов. Патент упоминает очистку Session Data от подозрительного трафика (suspect traffic).

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

Этот патент подтверждает стратегическую важность понимания не отдельных запросов, а всего процесса исследования темы пользователем. SEO-стратегия должна быть направлена на отображение контента на разнообразные пути (diverse paths), которые пользователи выбирают в рамках одной темы. Понимание того, какие запросы Google считает "родственными" (на основе поведения) и "разнообразными" (на основе результатов), критично для построения эффективной архитектуры сайта и достижения полного тематического охвата.

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

Сценарий: Оптимизация сайта о планетах (на основе примера из FIG. 1)

1. Анализ поведения: Пользователь ищет [Jupiter]. Google знает из Session Data, что многие пользователи, искавшие [Solar System] (Parent Query), затем искали [Jupiter] (Child 1), а также [Mars] и [Venus] (Child 2, 3).
2. Идентификация родственников: [Mars] и [Venus] идентифицируются как sibling queries для [Jupiter], так как имеют общего родителя [Solar System].
3. Проверка разнообразия: Google проверяет результаты для [Jupiter], [Mars] и [Venus]. Поскольку результаты для [Mars] сильно отличаются от результатов для [Jupiter] (разные документы в топе), оценка intra-suggestion diversity высока. [Mars] принимается как уточнение.
4. SEO-действие: Владелец сайта о космосе должен убедиться, что у него есть высококачественная, уникальная страница для "Jupiter" и отдельные, столь же качественные страницы для "Mars" и "Venus".
5. Ожидаемый результат: Сайт хорошо ранжируется по всем трем запросам и соответствует паттернам поведения пользователей, которые исследуют эту тему последовательно. Структура сайта помогает пользователям легко переходить между этими связанными темами.