Как Google разбирает локальные запросы на «Что» и «Где», тестируя разные варианты интерпретации

Описание

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

Патент решает проблему интерпретации локальных поисковых запросов, введенных пользователем в единое поле ввода, где намерение (интент) и географический контекст явно не разделены. Задача состоит в том, чтобы автоматически и точно определить, какие термины запроса относятся к объекту поиска («Что»/What), а какие — к местоположению («Где»/Where), особенно когда запрос неоднозначен (например, «pizza new york» или «jack in the box stanford ca»).

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

Запатентована система для генерации и оценки множественных интерпретаций локального поискового запроса. Система разделяет исходный запрос на различные наборы partitions (частей), где каждая часть может представлять «Что» или «Где». Эти части направляются в соответствующие репозитории (например, map data repository, local search data repository). Система выбирает наилучшую интерпретацию на основе confidence scores, полученных от этих репозиториев.

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

Система функционирует как механизм валидации гипотез:

• Генерация гипотез (Splitting): Полученный запрос разбирается на все или наиболее вероятные варианты разделения (splits). Например, «pizza new york» может быть разделен как [pizza | new york], [pizza new | york] и т.д. Для этого используется древовидная структура (search plan).
• Параллельная проверка: Каждая часть (partition) отправляется в соответствующий индекс. Например, предполагаемая локация отправляется в индекс Карт, а предполагаемый объект — в индекс Локального поиска.
• Оценка уверенности (Confidence Scoring): Репозитории возвращают результаты и оценки их релевантности. Система агрегирует эти оценки в общий confidence score для каждой интерпретации. Высокий балл означает, что интерпретация согласована (т.е. объект найден в указанной локации).
• Выбор лучшей интерпретации: Выбирается вариант разделения запроса с наивысшим confidence score, и его результаты возвращаются пользователю.

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

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

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

Патент имеет высокое значение (8/10) для локального SEO. Он раскрывает механизм, посредством которого Google определяет релевантность бизнеса или объекта для конкретной локации, указанной в запросе. Понимание этого механизма помогает оптимизировать названия бизнесов, категории и контент так, чтобы они корректно интерпретировались системой как релевантная комбинация «Что» и «Где». Также подчеркивается важность контекстных сигналов пользователя.

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

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

Confidence Score (Оценка уверенности)

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

Interpretation / Split (Интерпретация / Разделение)

Одна из гипотез о том, как следует разделить термины исходного запроса на функциональные части (например, «Что» и «Где»).

Local Search Data Repository (Репозиторий данных локального поиска)

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

Map Data Repository (Репозиторий картографических данных)

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

Partition (Часть запроса)

Набор из одного или нескольких терминов исходного запроса, который в рамках одной интерпретации рассматривается как единое целое (например, как «Что» или как «Где»).

Search Plan (План поиска)

Древовидная структура (tree structure), используемая для организации и оценки различных интерпретаций запроса. Корневой узел — исходный запрос, дочерние узлы — варианты разделения (splits), листовые узлы (leaf nodes) — конкретные части (partitions).

User Context Information (Контекстная информация пользователя)

Дополнительные данные о пользователе, используемые для уточнения интерпретации запроса. Включают IP-адрес, историю поиска, профиль пользователя, язык, а также текущую область просмотра карты (map area being currently viewed).

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

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

1. Система получает поисковый запрос, включающий несколько терминов.
2. Определяется множество разделений (plurality of splits) запроса. Каждое разделение делит запрос на свой набор частей (partitions).
3. Одна из частей (первая часть) ассоциируется с географической областью («Где»).
4. Для каждого разделения выполняется поиск в нескольких репозиториях с использованием соответствующих частей.
5. Map data repository используется для поиска локации, соответствующей первой части («Где»).
6. Для каждого разделения определяется confidence score на основе оценок документов (результатов), найденных для всех его частей.
7. Выбирается одно разделение на основе сравнения confidence scores.
8. Результаты, соответствующие выбранному разделению, передаются пользователю.

Claim 4 (Зависимый): Уточняет механизм определения разделений.

Определение разделений основано на древовидной структуре (tree structure). Каждая часть (partition) запроса ассоциируется с листовым узлом (leaf node) дерева и с одним из репозиториев.

Claim 5 и 6 (Зависимые): Описывают использование контекста пользователя.

Запрос дополняется (supplementing) терминами на основе context information, связанной с пользователем. Эта информация может включать IP-адрес, профиль пользователя, историю поиска, язык запроса или хостнейм.

Claim 7 (Зависимый): Расширяет типы используемых репозиториев.

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

Claim 8 (Зависимый): Описывает оптимизацию генерации разделений.

Определение разделений может основываться на статистической модели (statistical model) для предсказания наиболее вероятных частей запроса. Это позволяет не перебирать все возможные варианты.

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

Контекстная информация может включать картографические данные, отображаемые на устройстве клиента (map data displayed on the client device), т.е. текущую область просмотра карты.

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

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

QUNDERSTANDING – Понимание Запросов

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

1. Парсинг и Генерация гипотез: Система анализирует входящий запрос и генерирует Search Plan (древовидную структуру гипотез о том, как разделить запрос на «Что» и «Где»).
2. Контекстуализация: Система может дополнять запрос или его части, используя User Context Information (например, если пользователь ищет «Hilton», просматривая карту Нью-Йорка, система может добавить «New York City» к части «Где»).
3. Валидация гипотез (Triggering specialized search): Система запускает параллельные поисковые процессы в специализированных репозиториях (Maps Data, Local Search Data) для проверки каждой гипотезы.

RANKING – Ранжирование (Косвенно)

Хотя патент не описывает алгоритмы ранжирования, он использует результаты ранжирования из репозиториев для вычисления Confidence Scores. Качество ранжирования внутри специализированных индексов напрямую влияет на выбор интерпретации.

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

• Исходный поисковый запрос (в виде единой фразы).
• User Context Information (IP, история, текущая область просмотра карты и т.д.).

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

• Выбранная оптимальная интерпретация запроса (определенные части «Что» и «Где»).
• Набор результатов поиска, соответствующий этой интерпретации.
• Географические координаты и/или карта, соответствующие части «Где».

На что влияет

• Специфические запросы: Наибольшее влияние оказывается на локальные информационные и транзакционные запросы, где пользователь ищет бизнес, объект или услугу в определенном месте (например, «рестораны у аэропорта», «bronx zoo», «лучшая пицца в бруклине»).
• Конкретные типы контента: Влияет на ранжирование бизнес-листингов (Google Business Profile), локальных веб-страниц и картографических результатов.
• Обработка неоднозначности: Влияет на запросы, где термины могут быть как названием бизнеса, так и названием места (например, «Newark airport»).

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

• Триггеры активации: Алгоритм активируется, когда система обнаруживает запрос с потенциальным локальным интентом, введенный в одно поле ввода.
• Обработка неоднозначных локаций: Если часть «Где» неоднозначна (например, «Springfield»), система может расширить ее до нескольких недвусмысленных локаций («Springfield, IL», «Springfield, MA») и проверить их параллельно.
• Использование контекста: Применяется, когда доступна контекстная информация пользователя (например, пользователь использует Google Maps и вводит запрос в поле поиска на карте).

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

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

1. Получение запроса: Система получает запрос от пользователя.
2. Контекстуальное обогащение (Опционально): Запрос может быть дополнен на основе User Context Information.
3. Генерация Плана Поиска (Search Plan): Создается древовидная структура, представляющая различные интерпретации (splits) запроса.
   • Корневой узел содержит исходный запрос.
   • Дочерние узлы представляют варианты разделения на «Что» и «Где» (включая возможность перекрытия терминов).
4. Оптимизация Плана (Опционально): Если запрос длинный, может использоваться статистическая модель для выбора только наиболее перспективных интерпретаций или ограничения их количества.
5. Выполнение Плана Поиска (Параллельное исполнение):
   1. Система обходит дерево до листовых узлов (leaf nodes), которые представляют конкретные части (partitions) запроса.
   2. Каждый листовой узел оценивается путем отправки запроса в соответствующий репозиторий (например, «Где» в Maps Data Repository, «Что» в Local Search Data Repository).
   3. Результаты поиска и их оценки релевантности сохраняются и ассоциируются с листовым узлом как его Confidence Score.
6. Агрегация оценок: Confidence Scores распространяются вверх по дереву. Оценка дочернего узла (интерпретации) рассчитывается на основе оценок его листовых узлов (например, путем суммирования).
7. Выбор оптимальной интерпретации: Система сравнивает Confidence Scores всех интерпретаций (дочерних узлов корневого узла) и выбирает ту, у которой наивысшая оценка.
8. Формирование выдачи: Результаты поиска, соответствующие оптимальной интерпретации (включая локальные листинги и карту), возвращаются пользователю.

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

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

Патент фокусируется на обработке запроса и контекста, а не на факторах ранжирования контента.

• Контентные факторы (внутри репозиториев): Система полагается на то, что данные в Local Search Data Repository (названия бизнесов, адреса, описания) и Maps Data Repository (названия улиц, городов, объектов) проиндексированы и могут быть сопоставлены с терминами запроса.
• Географические факторы: Критически важны. Используются данные из Maps Data Repository для геокодирования части «Где».
• Пользовательские факторы (User Context Information):
  • IP-адрес: Для определения приблизительного местоположения пользователя.
  • История пользователя (Search history, Viewing history): Для понимания интересов и предыдущих локаций.
  • Профиль пользователя: Зарегистрированная информация о локации.
  • Язык запроса и Хостнейм: Для определения региональных предпочтений.
  • Текущая активность: Map area being currently viewed (область карты, которую просматривает пользователь).

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

• Relevance Scores (Оценки релевантности): Числовые значения, возвращаемые каждым репозиторием, указывающие, насколько хорошо результат соответствует отправленной части запроса (partition). Патент не детализирует их расчет.
• Confidence Score (Оценка уверенности): Агрегированная метрика для оценки качества всей интерпретации.
  • Расчет для листового узла: Основан на Relevance Scores результатов. Может быть максимальной оценкой, суммой или средним значением оценок Топ-N результатов.
  • Расчет для родительского узла (Интерпретации): Функция от Confidence Scores дочерних узлов. В одном из примеров это сумма оценок дочерних узлов (например, Score(Что) + Score(Где)).
• Статистические модели: Могут использоваться для оценки вероятности (probability estimate) того, что данная интерпретация является правильной, чтобы оптимизировать план поиска и выполнять наиболее перспективные запросы в первую очередь.

Выводы

1. Интерпретация локального запроса — это процесс валидации гипотез. Google не просто ищет ключевые слова, а активно тестирует различные способы разделения запроса на «Что» и «Где», чтобы найти наиболее согласованную интерпретацию.
2. Качество результатов определяет интерпретацию. Выбор правильной интерпретации зависит от Confidence Score, который, в свою очередь, зависит от качества и релевантности результатов, найденных в специализированных индексах (Карты и Локальный поиск). Если система находит хороший бизнес в хорошо определенной локации, эта интерпретация побеждает.
3. Контекст пользователя критически важен. Патент явно указывает на использование User Context Information (IP, история, текущая область просмотра карты) для дополнения или уточнения запроса. Локальный поиск сильно персонализирован и зависит от текущего состояния пользователя.
4. Возможность перекрытия «Что» и «Где». Система может обрабатывать случаи, когда один и тот же термин является частью и объекта, и локации (например, «bronx zoo»: Что=»bronx zoo», Где=»bronx»). Это подчеркивает важность распознавания сущностей (Entities) в локальном контексте.
5. Обработка неоднозначности. Система имеет механизмы для работы с неоднозначными локациями (например, города с одинаковыми названиями), тестируя несколько вариантов параллельно.
6. Гибкость системы репозиториев. Механизм позволяет подключать дополнительные индексы (трафик, события, маршруты), что позволяет интерпретировать запрос не только как поиск места, но и как запрос маршрута или информации о событии.

Практика

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

• Обеспечение четкости и согласованности NAP (Name, Address, Phone). Критически важно, чтобы Google мог однозначно идентифицировать название вашего бизнеса («Что») и его местоположение («Где»). Несогласованность данных в Google Business Profile, на сайте и в других источниках может снизить Confidence Score при интерпретации запросов, связанных с вашим бизнесом.
• Оптимизация под локальный контекст пользователя. Понимая, что Google использует текущее местоположение пользователя или область просмотра карты (User Context Information), необходимо оптимизировать контент под запросы типа «рядом со мной» или запросы без явного указания города, если пользователь находится в вашем регионе.
• Использование точных географических идентификаторов. При создании локальных страниц (Landing Pages) убедитесь, что вы используете названия районов, городов и ориентиров так, как они распознаются в Map Data Repository. Это повышает вероятность того, что система корректно интерпретирует локацию в запросе.
• Оптимизация сущностей с географическим компонентом. Если ваш бизнес или объект имеет название, включающее локацию (например, «Bronx Zoo»), убедитесь, что ваша оптимизация учитывает оба аспекта: как объект поиска и как указание на местоположение. Это соответствует способности системы обрабатывать перекрывающиеся partitions.

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

• Использование неоднозначных названий бизнеса. Названия, которые легко спутать с локациями или общими категориями, могут привести к неправильной интерпретации запроса. Система может решить, что название вашего бизнеса — это часть локации или наоборот, что снизит Confidence Score.
• Гео-спамминг в названии (Если это не часть бренда). Добавление слишком большого количества ключевых слов и локаций в название бизнеса может усложнить парсинг запроса. Система может сгенерировать слишком много splits с низким Confidence Score, пытаясь определить, что из этого является реальным названием, а что — локацией.
• Игнорирование мобильного контекста. Не учитывать, что большинство локальных поисков происходит с мобильных устройств, где User Context Information (текущее местоположение) играет ключевую роль в интерпретации запроса.

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

Патент подтверждает, что успешный локальный поиск начинается с точного понимания запроса. Стратегия локального SEO должна строиться на создании сильных, четких и согласованных сигналов о том, ЧТО представляет собой бизнес и ГДЕ он находится. Система предпочитает однозначность. Чем легче Google сопоставить ваш бизнес с запросом и локацией, тем выше Confidence Score и вероятность показа в выдаче. Также это подчеркивает стратегический переход к поиску на основе сущностей и контекста, а не только ключевых слов.

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

Сценарий: Оптимизация для бизнеса в неоднозначной локации

Бизнес: Кофейня в Спрингфилде (Springfield).

1. Проблема: Существует много городов с названием Спрингфилд. Пользователь ищет «кофе спрингфилд».
2. Как работает система (согласно патенту): Система генерирует интерпретацию: Что=»кофе», Где=»спрингфилд». При проверке «спрингфилд» в Map Data Repository обнаруживается неоднозначность. Система расширяет интерпретацию до нескольких вариантов: [Что=»кофе», Где=»Springfield, IL»], [Что=»кофе», Где=»Springfield, MA»] и т.д.
3. Действия SEO-специалиста: Необходимо максимизировать Confidence Score для нужного варианта. Убедиться, что на сайте кофейни и в GBP четко указан полный адрес, включая штат (например, IL). Использовать микроразметку LocalBusiness с полным адресом. Получать локальные ссылки и отзывы, упоминающие полный контекст (например, «лучший кофе в Спрингфилде, Иллинойс»).
4. Ожидаемый результат: Система присвоит более высокий Confidence Score интерпретации, соответствующей вашему бизнесу, благодаря сильным сигналам связи между бизнесом и точной локацией.

Сценарий: Использование контекста карты

1. Ситуация: Пользователь открывает Google Maps, приближает карту к району Сохо в Нью-Йорке и вводит запрос «обувь».
2. Как работает система (согласно патенту): Система использует map area being currently viewed (Сохо) как User Context Information. Она дополняет запрос и генерирует основную интерпретацию: Что=»обувь», Где=»Сохо, Нью-Йорк».
3. Действия SEO-специалиста: Если вы продвигаете обувной магазин в Сохо, убедитесь, что название района (Сохо) явно упоминается на вашем сайте и в GBP (в описании, отзывах). Это усиливает связь вашего бизнеса с контекстом, который Google использует для интерпретации запроса.
4. Ожидаемый результат: Ваш магазин будет показан в результатах поиска по карте, даже если пользователь явно не вводил «Сохо» в запрос.

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