Как Google предлагает альтернативные варианты для слов в середине поискового запроса при его редактировании (Midstring Refinements)

Описание

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

Патент решает проблему неэффективности стандартных систем автодополнения (autocomplete) при редактировании уже введенного запроса. Традиционные системы предлагают завершение на основе префикса (prefix-completions), что бесполезно, если пользователь хочет заменить слово в середине запроса (midstring). Изобретение улучшает UX, предлагая контекстуально релевантные альтернативы (refinements) для термина, с которым взаимодействует пользователь, даже без его фактического изменения.

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

Запатентована система генерации предложений по уточнению запроса (query refinement candidates), которая активируется при взаимодействии пользователя (например, перемещении курсора) с существующим запросом. Система идентифицирует термин, на котором сфокусирован пользователь (Anchor Segment), и находит для него семантически отличные альтернативы (Sibling Segments) на основе исторического поведения пользователей. Затем она формирует новые запросы, заменяя анкорный сегмент на предложенные альтернативы.

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

Система работает следующим образом:

• Мониторинг действий: Клиент отслеживает действия пользователя с исходным запросом (включая не модифицирующие, такие как перемещение курсора или наведение).
• Идентификация анкоря: На основе позиции курсора система определяет Anchor Segment (термин для замены) и Remaining Segments (контекст).
• Поиск альтернатив: Система ищет Sibling Segments — термины, связанные с анкорем, но семантически отличные. Основной источник данных — Related Queries Database (анализ последовательных запросов в рамках одной сессии).
• Формирование и Валидация: Формируются кандидаты путем замены анкоря на альтернативу. Эти кандидаты валидируются по Historical Queries Database для подтверждения их популярности и логичности.
• Отображение: Ранжированные кандидаты передаются клиенту и отображаются пользователю.

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

Высокая. Описанный механизм (Midstring Query Refinements) является стандартной функцией современных поисковых интерфейсов, включая Google Suggest. Понимание того, как генерируются эти предложения, остается актуальным для анализа поведения пользователей и семантики.

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

Влияние на SEO среднее (5/10). Патент не описывает алгоритмы ранжирования и не влияет напрямую на позиции сайтов. Он описывает функцию UX на этапе Query Understanding. Однако он имеет высокое стратегическое значение для специалистов по исследованию ключевых слов (Keyword Research) и пониманию пути пользователя (User Journey), так как раскрывает, как Google интерпретирует взаимосвязи между концепциями на основе анализа поисковых сессий.

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

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

Anchor Segment (Анкорный сегмент)

Слово или фраза в исходном запросе, которую система определяет как объект внимания пользователя и которая, вероятно, будет заменена. Определяется на основе позиции курсора или других действий.

Sibling Segment (Сегмент-сиблинг)

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

Remaining Segments (Оставшиеся сегменты)

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

Query Refinement Candidate (Кандидат на уточнение запроса)

Предлагаемый новый запрос, сформированный путем замены Anchor Segment на Sibling Segment и включающий Remaining Segments.

Semantically Distinct (Семантически отличный)

Критерий для выбора сиблингов. Означает, что замена должна отличаться по смыслу, а не быть просто синонимом или словоформой. Для фильтрации может использоваться стемминг (например, porter stemming).

Related Queries Database (База данных связанных запросов)

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

Historical Queries Database (База данных исторических запросов)

Хранилище ранее отправленных пользователями полных запросов и частоты их использования. Используется для валидации и ранжирования кандидатов.

Template (Шаблон)

Структура, создаваемая на основе Remaining Segments с заполнителем (placeholder) вместо Anchor Segment. Используется для фильтрации кандидатов и динамически обновляется при редактировании.

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

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

1. Система получает оригинальный запрос от клиента.
2. Идентифицируются сегменты в запросе.
3. Определяется Anchor Segment на основе положения курсора и Remaining Segments.
4. Идентифицируются Sibling Segments, которые семантически отличны от анкоря.
5. Формируются Query Refinement Candidates путем замены анкоря на сиблинг.
6. Информация о кандидатах отправляется клиенту.

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

Claim 2 (Зависимый): Уточняет триггер. Анкорь может быть идентифицирован, когда курсор находится внутри или рядом с сегментом, *без изменения* оригинального запроса (немодифицирующее действие).

Claim 5 (Зависимый): Уточняет источник сиблингов. Они идентифицируются на основе уточнений (refinements) к анкорному сегменту, ранее отправленных сообществом пользователей (т.е. из Related Queries Database).

Claim 8 (Зависимый от 1): Детализирует процесс валидации для многословных запросов.

1. Формируются потенциальные кандидаты.
2. Исключаются кандидаты, которые отсутствуют в предопределенной базе данных исторических полных запросов (Historical Queries Database).

Это критически важный шаг фильтрации, гарантирующий, что система предлагает только реальные и осмысленные запросы.

Claim 9 (Зависимый от 1): Описывает использование шаблонов. Если запрос содержит два или более сегмента, создается Template, включающий Remaining Segments и плейсхолдер. Выбираются только кандидаты, соответствующие этому шаблону.

Claim 10 и 11 (Зависимые): Описывают динамическое обновление шаблона. При вводе новых символов шаблон обновляется, чтобы включить их, а также, возможно, оставшуюся часть анкорного сегмента, если ввод примыкает к ней.

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

Изобретение применяется на этапе взаимодействия пользователя с поисковой строкой.

QUNDERSTANDING – Понимание Запросов
Это основной этап применения. Система работает в двух режимах:

• Офлайн-обработка: Анализ логов поисковых сессий для построения Related Queries Database и Historical Queries Database. На этом этапе система изучает пути уточнения запросов пользователями.
• Онлайн-обработка (Real-time): Когда пользователь взаимодействует с запросом, Prediction Server в реальном времени определяет Anchor Segment, извлекает Sibling Segments, формирует и валидирует кандидатов.

Взаимодействие с компонентами:

• Клиент (Search Assistant): Отслеживает действия пользователя (курсор, ввод) и отправляет данные на сервер.
• Prediction Server: Выполняет основную логику (сегментация, идентификация, формирование, фильтрация).
• Базы данных: Обращается к Related Queries Database и Historical Queries Database.

Входные данные: Оригинальный запрос, данные о действиях пользователя (позиция курсора, введенные/удаленные символы).

Выходные данные: Отсортированный список Query Refinement Candidates.

На что влияет

• Специфические запросы: Наибольшее влияние на многословные запросы (информационные, коммерческие), где пользователи часто меняют один компонент для исследования альтернатив (например, смена локации, бренда, характеристики).
• Конкретные ниши: Влияет на все ниши, особенно Ecommerce, Travel, где распространены сравнения и уточнения спецификаций.

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

• Триггеры активации: Алгоритм активируется, когда пользователь взаимодействует с уже введенным запросом. Конкретные триггеры включают:
  • Перемещение курсора в позицию внутри запроса (не в конец).
  • Наведение курсора (hovering) или выделение (highlighting) сегмента.
  • Начало редактирования (удаление или добавление символов) внутри запроса.

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

Процесс А: Обработка немодифицирующего действия (например, перемещение курсора)

1. Получение данных: Система получает оригинальный запрос и позицию курсора.
2. Сегментация запроса: Запрос разбивается на концептуальные сегменты.
3. Идентификация анкоря: Определяется Anchor Segment на основе позиции курсора и Remaining Segments.
4. Создание шаблона: Формируется Template на основе Remaining Segments (например, «* hiking trails»).
5. Идентификация сиблингов: Система ищет Sibling Segments для анкоря. Источники: Related Queries Database (основной) или алгоритмическая генерация (дополнительный).
6. Применение критериев: Проверка, что сиблинги семантически отличны (Semantically Distinct) от анкоря.
7. Формирование кандидатов: Создаются потенциальные Query Refinement Candidates путем объединения сиблингов с остаточными сегментами (соответствие шаблону).
8. Фильтрация и Ранжирование:
   • Валидация: Кандидаты проверяются на наличие в Historical Queries Database.
   • Ранжирование: Применяются критерии популярности и релевантности (например, Lift Ratio).
9. Отправка результатов: Отсортированный список отправляется клиенту.

Процесс Б: Обработка модифицирующего действия (ввод/удаление)

1. Детектирование изменения: Система обнаруживает удаление или добавление символов в анкорном сегменте.
2. Обновление шаблона (При добавлении): Если символы добавлены, Template обновляется, включая новые символы (например, «gr* hiking trails»).
3. Сохранение шаблона (При удалении): Если символы только удаляются из анкоря, Template (основанный на остаточных сегментах) и идентификация сиблингов не меняются.
4. Фильтрация по шаблону: Выбираются кандидаты, которые соответствуют текущему (возможно, обновленному) шаблону.
5. Отправка результатов: Обновленный список кандидатов отправляется клиенту.

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

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

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

• Поведенческие факторы:
  • Пути уточнения запросов (Query Sessions): Данные из Related Queries Database. Анализ того, какие запросы пользователи вводят последовательно в рамках одной сессии, чтобы определить потенциальные Sibling Segments.
  • Исторические логи запросов: Данные из Historical Queries Database. Используются для валидации популярности и реальности предлагаемого кандидата.
• Пользовательские факторы (Интерфейс):
  • Положение курсора: Критически важно для определения Anchor Segment.
  • Введенные/Удаленные символы: Используются для обновления Template.

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

• Semantic Distinctiveness (Семантическая отличительность): Метрика для фильтрации сиблингов. В патенте упоминается использование алгоритмов стемминга (например, Porter stemming) для фильтрации слишком похожих вариантов.
• Frequency/Popularity (Частотность/Популярность): Используется для ранжирования кандидатов. Данные берутся из Historical Queries Database и Related Queries Database.
• Пороги частотности: Используются при валидации. Кандидаты с частотой ниже порога исключаются (это также помогает избежать утечки PII через редкие запросы).
• Lift Ratio (Коэффициент Лифта): Упоминается как метод фильтрации популярных, но нерелевантных последующих запросов. Сравнивается вероятность ввода кандидата после исходного запроса с его общей вероятностью. Если соотношение выше порога, кандидат считается релевантным.
• Template Matching (Соответствие шаблону): Бинарная метрика соответствия кандидата текущему состоянию редактирования.

Выводы

1. Данные сессий как основа семантических связей: Патент подчеркивает, что Google активно использует анализ последовательных запросов в рамках одной сессии (Related Queries Database) для понимания того, какие концепции пользователи считают взаимозаменяемыми. Это поведение определяет семантику для системы.
2. Контекст определяет альтернативы: Релевантность предлагаемых Sibling Segments строго зависит от контекста, заданного Remaining Segments. Система ищет альтернативы, которые имеют смысл в рамках всего запроса, а не изолированно.
3. Требование семантической уникальности: Ключевым аспектом является фильтрация Semantically Distinct. Цель системы — предложить реальное изменение направления поиска, а не переформулировку того же интента с использованием грамматических вариаций или близких синонимов.
4. Валидация популярностью и реальностью: Механизм агрессивно фильтрует предложения, проверяя их по Historical Queries Database. Это гарантирует, что пользователю предлагаются только реальные, популярные и логичные запросы (пример с фильтрацией «banana stock price» для запроса «Apple stock price»).
5. Критичность сегментации запросов: Способность системы разбивать запрос на концептуальные блоки (segments) является основой этого механизма.

Практика

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

Хотя патент описывает функцию интерфейса, он дает стратегические инсайты для SEO и Keyword Research.

• Использование Midstring Suggest для Keyword Research: Активно используйте описанный механизм как инструмент исследования. Вводите базовый запрос и перемещайте курсор на разные сегменты, чтобы увидеть, какие альтернативы (Sibling Segments) предлагает Google. Это позволяет выявить связанные концепции, альтернативные бренды или локации, которые пользователи считают взаимозаменяемыми.
• Анализ путей уточнения запросов (User Journey): Изучайте предложения для понимания следующих шагов пользователя. Поскольку предложения основаны на данных сессий, они показывают, как пользователи уточняют свой интент. Оптимизируйте контент так, чтобы отвечать не только на исходный запрос, но и на эти логические уточнения.
• Построение Topical Authority через связанные концепции: Убедитесь, что ваш контент покрывает не только основные запросы, но и тесно связанные Sibling Segments. Это укрепляет авторитетность в теме, охватывая весь спектр связанных концепций, которые пользователи исследуют.

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

• Игнорирование данных Google Suggest как источника инсайтов: Рассматривать Suggest только как функцию UX, упуская его ценность как источника данных о поведении пользователей и семантических связях.
• Фокус только на прямых синонимах и вариациях: При сборе семантического ядра ограничиваться только синонимами и грамматическими вариациями. Патент явно указывает на поиск Semantically Distinct вариантов, что требует фокуса на концептуальном разнообразии.
• Изолированная оптимизация: Рассмотрение ключевых слов в изоляции без учета того, как Google понимает взаимосвязи через пути уточнения запросов пользователями.

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

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

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

Сценарий: Исследование альтернативных брендов с помощью Midstring Suggest

1. Цель: Понять, какие бренды Google считает прямыми конкурентами или альтернативами для iPhone на основе поведения пользователей.
2. Действие: Ввести запрос в поисковую строку Google: «обзор iphone 15».
3. Применение механизма: Переместить курсор (кликнуть) на слово «iphone».
4. Анализ результата: Google активирует механизм Midstring Refinement. «iphone» становится Anchor Segment. Система предлагает Query Refinement Candidates, заменяя «iphone» на Sibling Segments.
5. Ожидаемый результат (Пример): В выпадающем списке появятся предложения: «обзор samsung s25», «обзор google pixel 9». Это те бренды, на которые пользователи чаще всего меняли запрос в рамках одной сессии, что подтверждает их концептуальную связь.

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