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

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

Current/Original Search Query (Текущий/Исходный поисковый запрос)

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

Distinct Search Queries (Различные поисковые запросы)

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

Optional Term (Необязательный термин)

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

Previously Submitted Search Queries (Ранее отправленные поисковые запросы / История поиска)

Набор запросов, отправленных тем же пользователем, часто в пределах недавнего временного окна (recent time window) или сессии.

Query Revision Engine (Система пересмотра запросов)

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

Revised Search Query (Пересмотренный поисковый запрос)

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

Similarity (Схожесть запросов)

Метрика, определяющая связь между двумя запросами. Может основываться на совпадении терминов, пересечении поисковых результатов (overlap) или совместном выборе одних и тех же ресурсов пользователями (co-selection/co-click).

Threshold Number (Пороговое количество)

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

Weight (Вес термина)

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

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

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

1. Система получает текущий запрос (Current Search Query) от пользователя.
2. Определяется, что текущий запрос похож на первый ранее отправленный запрос из истории того же пользователя. Схожесть определяется как минимум по совпадению хотя бы одного термина.
3. Идентифицируется второй (контекстный) термин, который удовлетворяет условиям: (i) он появляется в первом ранее отправленном запросе, (ii) он отсутствует в текущем запросе, и (iii) (Ключевое условие) он появляется в пороговом количестве (threshold number) других различных (distinct) запросов в истории этого пользователя.
4. Генерируется пересмотренный запрос (Revised Search Query) путем добавления второго термина к текущему запросу.
5. Получаются результаты поиска для пересмотренного запроса и предоставляются пользователю в ответ на исходный запрос.

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

История поиска ограничивается запросами, отправленными пользователем в течение недавнего временного окна (recent time window). Это фокусирует механизм на контексте текущей сессии.

Claims 4 и 5 (Зависимые): Расширяют определение схожести запросов.

Помимо совпадения терминов (Claim 1), схожесть может определяться на основе того, что пользователи часто выбирали одни и те же ресурсы в ответ на оба запроса (Claim 4, co-selection/co-click), или на основе пересечения результатов поиска по обоим запросам (Claim 5, overlap).

Claims 6 и 7 (Зависимые): Описывают механизмы "смягчения" добавленного контекста.

Добавленный термин может быть идентифицирован как необязательный (optional term) с помощью оператора (Claim 6). Также ему может быть присвоен пониженный вес (weight), чтобы он имел меньшее значение при расчете оценки ранжирования, чем термины исходного запроса (Claim 7).

Claim 8 (Зависимый): Уточняет метод идентификации пользователя.

Определение того, что запросы принадлежат одному пользователю, основывается на совпадении идентификаторов cookie или login identifier.

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

Изобретение применяется на этапе интерпретации запроса, до основного процесса ранжирования.

QUNDERSTANDING – Понимание Запросов
Это основной этап применения патента. Query Revision Engine перехватывает входящий запрос и анализирует его в контексте данных о пользователе в реальном времени.

1. Контекстуализация: Система извлекает недавнюю историю поиска пользователя (Previously Submitted Search Queries).
2. Анализ и Переписывание: Система применяет алгоритм для определения схожести и идентификации устойчивых контекстных терминов. Если условия выполняются, генерируется Revised Search Query. Это процесс персонализации запроса на основе сессии.

RANKING – Ранжирование
На этом этапе используется уже пересмотренный запрос. Если к запросу были добавлены термины с пониженным весом или как необязательные, система ранжирования учитывает эти модификаторы при расчете Scores для ресурсов.

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

• Текущий поисковый запрос (Original Search Query).
• Идентификатор пользователя (Cookie ID, Login ID).
• История недавних поисковых запросов пользователя.
• (Опционально) Данные о кликах (co-selection data) и пересечении результатов (SERP overlap) для определения схожести запросов.

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

• Пересмотренный поисковый запрос (Revised Search Query), потенциально с модифицированными весами терминов, передаваемый в систему ранжирования.

На что влияет

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

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

Алгоритм применяется при выполнении строгого набора условий:

• Наличие истории: У пользователя есть достаточная недавняя история поиска в рамках recent time window.
• Триггер схожести: Текущий запрос похож на один из предыдущих запросов (по терминам, результатам или кликам).
• Идентификация контекста: В похожем предыдущем запросе есть термины, отсутствующие в текущем запросе.
• Пороговое значение (Threshold): Эти контекстные термины встречаются в пороговом количестве (Threshold Number) других различных (distinct) запросов в истории пользователя. Это подтверждает устойчивый интент.

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

Процесс обработки запроса в реальном времени:

1. Получение данных: Система получает текущий запрос, идентифицирует пользователя и извлекает его недавнюю историю поиска.
2. Определение схожести: Текущий запрос сравнивается с запросами в истории. Проверяется совпадение терминов и, опционально, данные co-click или SERP overlap.
3. Проверка наличия схожих запросов: Если схожих запросов нет, обработать исходный запрос стандартным способом. Если есть, перейти к следующему шагу.
4. Идентификация кандидатов: Для схожего запроса из истории определяются термины-кандидаты (те, которые отсутствуют в текущем запросе).
5. Проверка устойчивости интента (Threshold Check): Для каждого термина-кандидата подсчитывается, в скольких других различных запросах в истории он встречается.
6. Выбор контекстных терминов: Отбираются термины, которые превысили пороговое количество.
7. Генерация пересмотренного запроса: Отобранные контекстные термины добавляются к текущему запросу.
8. Корректировка весов (Опционально): Добавленным терминам присваивается пониженный вес или статус необязательного термина.
9. Выполнение поиска: Пересмотренный запрос отправляется в систему ранжирования, результаты возвращаются пользователю.

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

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

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

• Поведенческие факторы:
  • История поисковых запросов (Search History): Критически важные данные. Анализируется текст ранее отправленных запросов для выявления контекста и устойчивого интента.
  • Данные о кликах/выборах (Selection Data): Могут использоваться для определения схожести между запросами (co-selection/co-click).
• Пользовательские факторы:
  • Идентификаторы пользователя (Cookie ID, Login ID): Используются для связывания текущего запроса с историей поиска того же пользователя.
• Временные факторы:
  • Временное окно (Time Window): История поиска ограничивается недавним периодом (recent time window) для определения контекста текущей сессии.

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

• Threshold Number (Пороговое количество): Ключевая метрика патента. Заданное значение (в патенте приводятся примеры 2, 3 или 4), определяющее минимальное количество различных запросов в истории, в которых должен появиться термин. Определяет "устойчивость" контекста.
• Similarity (Схожесть запросов): Рассчитывается на основе одного или нескольких методов:
  • Совпадения терминов (Term matching) – требуется как минимум одно совпадение согласно Claim 1.
  • Пересечения результатов поиска (SERP Overlap).
  • Совместного выбора ресурсов (Co-selection).
• Term Weight (Вес термина): Метрика, используемая для снижения влияния добавленного контекстного термина на ранжирование по сравнению с исходными терминами запроса.

1. Персонализация на уровне сессии: Патент описывает механизм глубокой краткосрочной персонализации. Google активно использует контекст недавних действий пользователя (сессии), чтобы автоматически уточнить и специализировать его текущие запросы.
2. Идентификация "Устойчивого Интента" (Persistent Intent): Ключевым механизмом является не простое добавление слов из предыдущего запроса, а требование, чтобы контекстный термин повторялся в пороговом количестве (Threshold Number) различных запросов. Это позволяет выявить основную тему или задачу сессии (например, бренд, местоположение).
3. Схожесть запросов шире, чем совпадение слов: Хотя базовое требование (Claim 1) — это совпадение термина, система также может определять схожесть по поведению пользователей (co-click) и пересечению выдачи (SERP overlap), что указывает на семантическую связь.
4. Баланс между контекстом и интентом: Система предусматривает "мягкое" включение контекста. Добавленные термины могут быть помечены как необязательные (optional) или иметь пониженный вес (weight), чтобы не исказить основной интент текущего запроса.
5. Важность User Journey для SEO: Понимание полного пути пользователя и того, как различные запросы связаны в рамках одной сессии, становится критически важным. Оптимизация под изолированные ключевые слова становится менее эффективной.

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

• Оптимизация под поисковые сессии (User Journey Mapping): Анализируйте не только отдельные ключевые слова, но и последовательности запросов, которые пользователи используют при исследовании темы. Убедитесь, что ваш сайт предоставляет контент, удовлетворяющий смежные и последующие интенты в рамках одной сессии. Это увеличит вероятность релевантности вашего контента автоматически уточненным запросам.
• Построение тематического авторитета (Topical Authority): Создавайте кластеры контента, которые широко охватывают тему. Если пользователь исследует вашу нишу, его общие запросы будут автоматически уточняться Google. Авторитетный ресурс с широким охватом имеет больше шансов соответствовать этим специализированным (пересмотренным) запросам.
• Усиление и узнаваемость бренда (в E-commerce): Бренды часто выступают в роли устойчивого контекста. Если ваш бренд силен, пользователи будут чаще включать его в запросы. Система идентифицирует этот контекст и сможет автоматически добавлять название вашего бренда к общим запросам пользователя, направляя трафик к вам.
• Оптимизация под длиннохвостые запросы: Поскольку система автоматически добавляет контекстные термины, итоговый запрос часто становится более длинным и специфичным. Убедитесь, что ваш контент оптимизирован для соответствия таким специализированным интентам.

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

• Изолированная оптимизация под ВЧ запросы: Фокусировка исключительно на высокочастотных общих запросах без учета контекста. Если пользователь находится в определенной сессии, Google перепишет этот общий запрос, и ваш контент может оказаться нерелевантным новому контексту.
• Создание поверхностного контента: Контент, отвечающий только на один узкий вопрос и не покрывающий связанные аспекты темы, не сможет удовлетворить пересмотренные запросы, включающие дополнительный контекст из сессии пользователя.
• Игнорирование комплексного интента и пути пользователя: Непонимание того, как пользователи итеративно ищут информацию в вашей нише, приведет к созданию контента, который не соответствует реальным потребностям сессии.

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

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

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

Сценарий 1: Планирование путешествия

1. История пользователя:
   • Запрос 1: "flights to Rome"
   • Запрос 2: "best time to visit Rome"
   • Запрос 3: "Colosseum tickets Rome"
2. Текущий запрос: "weather forecast" (общий запрос)
3. Анализ системы:
   • Схожесть: Текущий запрос может быть признан похожим на Запрос 2 (интент планирования, возможно через co-click данные).
   • Контекстный термин: "Rome".
   • Проверка порога (допустим, порог=2): "Rome" появляется в Запросе 1 и Запросе 3. Порог достигнут.
4. Пересмотренный запрос: "weather forecast Rome".
5. Результат: Пользователь видит прогноз погоды для Рима, что соответствует его текущей задаче.

Сценарий 2: Покупка электроники (Строгое соответствие Claim 1)

1. История пользователя:
   • Запрос 1: "best mirrorless cameras for video"
   • Запрос 2: "Sony A7S III video specs"
   • Запрос 3: "Panasonic Lumix GH6 vs Sony A7S III"
2. Текущий запрос: "Sony A7S III price"
3. Анализ системы:
   • Схожесть: Текущий запрос похож на Запрос 2 и 3 (совпадение термина "Sony A7S III").
   • Контекстный термин: "video".
   • Проверка порога (допустим, порог=2): "video" появляется в Запросе 1 и Запросе 2. Порог достигнут.
4. Пересмотренный запрос: "Sony A7S III price video" (термин video может иметь пониженный вес).
5. Результат: В выдаче могут быть повышены результаты, которые не только указывают цену, но и упоминают комплектации или аксессуары, полезные для видеосъемки.