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

Описание

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

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

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

Запатентована система и метод для выборочной локализации поисковых запросов и динамического упорядочивания результатов. Система определяет местоположение пользователя (явно из запроса или неявно через GPS/профиль) и оценивает релевантность локации для данного запроса. Ключевым элементом является механизм принятия решений о приоритезации (promotion) или понижении локальных результатов, использующий Whitelists и Blacklists для повышения точности определения интента.

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

Система работает по следующей логике:

• Идентификация местоположения: Сначала проверяется наличие явной локации в запросе. Если ее нет, система ищет неявный location indicator (GPS, данные сети, профиль пользователя).
• Генерация результатов: Если локация найдена, система создает Modified Search Query (Запрос + Локация) и генерирует как локальные, так и общие (не локальные) результаты.
• Определение релевантности и Приоритезация: Система оценивает, насколько локальные результаты релевантны запросу. Если релевантность высока, система проверяет запрос по Blacklist (список запросов, часто ошибочно связываемых с локацией). Если запрос не в Blacklist, локальные результаты продвигаются (Promoted) выше общих. Если в Blacklist — локальные результаты понижаются.
• Обработка отсутствия локации: Если местоположение не найдено, но запрос имеет сильный локальный интент (например, находится в Whitelist), система может показать пользователю запрос на ввод местоположения (Prompt for location).

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

Критически высокая. Описанные механизмы являются фундаментом современного локального и мобильного поиска. Автоматическое определение локального интента и использование неявных сигналов местоположения устройства для формирования выдачи — это стандартная практика Google. Хотя методы определения интента эволюционировали (например, в сторону машинного обучения, также упомянутого в патенте), базовая логика остается ядром Local SEO.

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

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

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

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

Blacklist (Черный список)

Репозиторий запросов, которые были определены как вероятно ошибочно ассоциируемые с местоположением (likely to be incorrectly associated with location information). Используется для предотвращения нерелевантного повышения локальных результатов.

Location Indicator (Индикатор местоположения)

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

Location-related information (Информация, связанная с местоположением)

Явная информация о местоположении, включенная непосредственно в текст поискового запроса.

Modified Search Query (Модифицированный поисковый запрос)

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

Physical location identifier (Идентификатор физического местоположения)

Конкретные типы данных в запросе, используемые для определения локации: почтовый индекс, название муниципалитета, координаты GPS, код аэропорта и т.д.

Profile Database (База данных профилей)

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

Promotion (Продвижение / Приоритезация)

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

Results Sequencer (Секвенсор результатов)

Компонент, который определяет порядок отображения различных наборов результатов (локальных и не локальных). Использует логику релевантности и данные из Whitelist/Blacklist для принятия решения о Promotion или Demotion.

Whitelist (Белый список)

Репозиторий запросов, которые были определены как с высокой вероятностью связанные с информацией о местоположении. Используется для активации и приоритизации запроса на ввод локации (prompt), если местоположение устройства неизвестно.

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

Патент содержит как системные (Apparatus, Claim 1), так и процедурные (Method, Claim 3) пункты формулы изобретения, фокусирующиеся на механизме корректировки выдачи.

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

1. Request processor получает запрос и идентифицирует связанную локацию.
2. Search engine генерирует два набора результатов: локальный (используя запрос + локацию) и не локальный (используя только запрос).
3. Система содержит репозиторий (Blacklist) запросов, которые, вероятно, ошибочно ассоциируются с локацией.
4. Results sequencer определяет порядок отображения этих двух наборов. Логика секвенсора:
   1. Определить, заинтересован ли пользователь больше в локальных или не локальных результатах.
   2. Если интерес к локальным результатам выше, проверить, находится ли запрос в Blacklist.
   3. Если запрос в Blacklist: упорядочить так, чтобы не локальные результаты имели предпочтение (переопределение/понижение локальных).
   4. Если запрос не в Blacklist: упорядочить так, чтобы локальные результаты имели предпочтение (promotion).

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

1. Получение запроса и определение связанной локации.
2. Генерация первого (локального) и второго (не локального) набора результатов.
3. Первоначальное определение, что пользователь больше заинтересован в первом наборе.
4. Проверка, находится ли запрос в списке запросов, вероятно ошибочно ассоциируемых с локацией (Blacklist).
5. В ответ на нахождение запроса в списке: Определение, что первоначальное определение, вероятно, неверно. Генерация порядка выдачи, в котором второй (не локальный) набор отображается перед первым (локальным).

Ключевой защищенный механизм — это использование Blacklist для отмены (override) алгоритмического решения о продвижении локальных результатов.

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

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

QUNDERSTANDING – Понимание Запросов
Это ключевой этап. Request Processor анализирует запрос на наличие явной локации. Если ее нет, он определяет неявную локацию (Location Indicator) через данные устройства (GPS, сеть) или Profile Manager. Происходит классификация интента запроса — определение, является ли он локальным, используя Whitelists/Blacklists или машинное обучение (упомянутое в описании). При необходимости генерируется Modified Search Query.

RANKING – Ранжирование
Система выполняет множественные поиски. Если локация идентифицирована, Search Engine выполняет поиск по локальному индексу (Local Index) с использованием Modified Search Query и стандартный поиск по веб-индексу (Web Index) по исходному запросу.

METASEARCH – Метапоиск и Смешивание / RERANKING – Переранжирование
Results Sequencer вступает в работу после получения результатов из разных индексов. Он принимает решение о финальном порядке (Promotion или Demotion) локального блока относительно общих результатов, основываясь на оценке релевантности и данных Blacklist. Response Formatter готовит финальную выдачу, которая может также включать prompt for location.

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

• Исходный поисковый запрос.
• Метаданные устройства (ID пользователя/устройства, данные GPS, данные сети).
• Whitelist и Blacklist запросов.
• Profile Database (Default location, Recent locations).

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

• Отформатированная SERP с упорядоченными локальными и не локальными результатами.
• Возможно, запрос на ввод местоположения (prompt).

На что влияет

• Специфические запросы: Наибольшее влияние оказывается на запросы с неявным локальным интентом (например, «рестораны», «сантехник», «Starbucks»). Транзакционные и коммерческие запросы, связанные с физическими услугами или товарами.
• Конкретные ниши или тематики: Критическое влияние на все локальные бизнесы (ритейл, услуги, HoReCa).
• Типы устройств: Особенно сильно влияет на мобильные устройства, где ввод затруднен и вероятность использования неявных сигналов локации (GPS) выше.

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

Алгоритм применяется при обработке запроса в реальном времени, используя предварительно вычисленные данные (списки, профили).

Триггеры активации:

• Автоматическая локализация (Promotion/Demotion): Активируется, когда в запросе нет явной локации, но найдено связанное местоположение устройства И система определяет, что локальные результаты релевантны запросу. Решение о повышении зависит от Blacklist.
• Запрос локации (Prompt): Активируется, когда местоположение устройства неизвестно, НО запрос с высокой вероятностью имеет локальный интент (проверка по Whitelist).

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

Детальный процесс обработки запроса (на основе логики, описанной в патенте, FIG. 5):

1. Получение запроса: Система получает поисковый запрос от устройства.
2. Проверка явной локации: Содержит ли текст запроса location-related information?
   • Если ДА: Генерируются локальные и не локальные результаты. Локальные результаты обычно повышаются. Локация добавляется в историю. Процесс завершен.
   • Если НЕТ: Переход к шагу 3.
3. Проверка неявной локации: Связан ли с запросом Location Indicator (GPS, сеть, профиль)?
   • Если ДА (Локация найдена): Переход к шагу 4.
   • Если НЕТ (Локация не найдена): Переход к шагу 8.
4. Генерация и оценка (Локация найдена): Система создает Modified Search Query. Выполняются поиски по исходному и модифицированному запросам. Система оценивает, релевантны ли локальные результаты.
   • Если НЕТ (не релевантны): Предоставляются только не локальные результаты. Процесс завершен.
   • Если ДА (релевантны): Переход к шагу 5.
5. Проверка Blacklist: Находится ли исходный запрос в Blacklist?
6. Приоритезация (Demotion): Если запрос в Blacklist, система упорядочивает выдачу: сначала не локальные результаты, затем локальные. Процесс завершен.
7. Приоритезация (Promotion): Если запрос не в Blacklist, система упорядочивает выдачу: сначала локальные результаты, затем не локальные. Процесс завершен.
8. Оценка локального интента (Локация не найдена): Является ли местоположение релевантным для данного запроса в принципе?
   • Если НЕТ: Предоставляются не локальные результаты. Процесс завершен.
   • Если ДА: Переход к шагу 9.
9. Проверка Whitelist и формирование выдачи с Prompt: Находится ли запрос в Whitelist?
   • Если ДА (в Whitelist): Система показывает запрос на ввод локации (Prompt) ПЕРЕД не локальными результатами.
   • Если НЕТ (не в Whitelist): Система показывает не локальные результаты ПЕРЕД запросом на ввод локации (Prompt). Процесс завершен.

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

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

Система использует несколько категорий данных для принятия решений о локализации и приоритезации.

• Контентные факторы (Запрос): Текст запроса используется для поиска явной локации (Physical location identifier) и для сравнения с Whitelist и Blacklist.
• Географические факторы:
  • Явные: Почтовые индексы, названия городов, координаты, указанные в запросе.
  • Неявные (Location Indicator): Данные GPS с устройства, данные триангуляции от беспроводной сети.
• Пользовательские факторы:
  • Default location: Сохраненное в Profile Database местоположение по умолчанию.
  • Recent locations: История местоположений из предыдущих запросов или сессий.

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

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

• Predicted relevance of location (Прогнозируемая релевантность местоположения): Оценка вероятности локального интента. Патент упоминает несколько методов ее вычисления:
  • Сравнение результатов: Анализ различий между результатами по исходному запросу и по Modified Query.
  • Машинное обучение: Использование обученных систем (supervised machine learning system) на логах прошлых поисков для генерации оценки (score) или правил определения локальной ассоциации запроса.
• Использование Blacklist: Бинарная проверка (Да/Нет). Если запрос присутствует в списке, это переопределяет (override) решение о высокой релевантности локальных результатов и приводит к их понижению.
• Использование Whitelist: Бинарная проверка (Да/Нет). Используется для определения приоритета отображения Prompt for location, если местоположение устройства неизвестно.

Выводы

1. Неявная локализация как стандарт: Google активно стремится локализовать результаты поиска, даже если пользователь не указал местоположение. Система использует данные устройства (GPS, сеть) и профиля (дом, история) как замену явному указанию локации.
2. Модификация запроса — ключевой механизм: Для генерации локальных результатов система не просто фильтрует выдачу, а создает внутренний Modified Search Query, добавляя неявное местоположение к исходному тексту запроса.
3. Локальный интент определяет приоритет: Решение о том, показывать ли локальные результаты первыми (Promotion), зависит от оценки вероятности локального интента запроса (Predicted relevance of location).
4. Механизмы защиты от ошибок (Blacklists/Whitelists): Google использует заранее определенные списки для корректировки алгоритмических решений. Blacklists предотвращают агрессивную локализацию там, где она нерелевантна, а Whitelists помогают форсировать запрос локации при сильном интенте.
5. Множественные поиски для одной выдачи: Для принятия решения система выполняет как минимум два внутренних поиска (по исходному и модифицированному запросам), а затем сравнивает и смешивает (Sequencing) результаты.

Практика

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

• Оптимизация под локальный интент без географических ключевых слов: Критически важно оптимизировать контент под запросы, которые не содержат названий городов, но имеют сильный локальный интент (например, «кофейня», «замена масла»). Патент подтверждает, что Google будет активно локализовать такие запросы, используя местоположение устройства.
• Усиление локальных сигналов (Google Business Profile и Citations): Поскольку система полагается на способность находить релевантные локальные результаты для Modified Search Query, необходимо обеспечить максимальное присутствие и качество информации в локальном индексе Google (через GBP, локальные цитирования, отзывы).
• Мобильная оптимизация как приоритет: Механизмы патента в первую очередь нацелены на мобильные устройства. Обеспечение корректной работы сайта на мобильных устройствах и быстрая загрузка критичны для успеха в локализованной выдаче.
• Использование локальной микроразметки (Schema.org): Разметка LocalBusiness, адресов, часов работы помогает поисковой системе точнее ассоциировать ваш контент с конкретным физическим местоположением, улучшая видимость при автоматической локализации запросов.

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

• Игнорирование локальных сигналов для национальных брендов: Даже если бренд работает по всей стране, игнорирование локальной оптимизации филиалов является ошибкой. По запросам типа «[Бренд]» Google, скорее всего, применит логику локализации и покажет ближайшие филиалы (Promotion), а не только главный сайт.
• Фокус только на десктопной выдаче: Анализ позиций только на десктопе не дает полной картины, так как мобильная выдача будет значительно сильнее локализована благодаря механизмам этого патента и доступности GPS.
• Попытки национального ранжирования по локальным запросам: Если запрос имеет сильный локальный интент (попадает в Whitelist), попытки ранжироваться по нему на национальном уровне без физической привязки к локации пользователя будут неэффективны из-за применения Modified Query.

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

Патент подтверждает стратегию Google «Mobile First» и критическую важность гео-контекста пользователя. Местоположение является одним из самых сильных факторов контекстуализации поиска. Для SEO-специалистов это означает, что понимание локального интента часто важнее, чем точное совпадение ключевых слов. Стратегия должна учитывать, что один и тот же запрос генерирует радикально разную выдачу в зависимости от местоположения пользователя. Это усложняет мониторинг позиций и требует использования инструментов, эмулирующих поиск из разных географических точек.

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

Сценарий 1: Продвижение локальных результатов (Promotion)

1. Ситуация: Пользователь вводит запрос «Starbucks» на смартфоне в Бруклине. GPS включен.
2. Действие системы: Система не находит явной локации. Она использует GPS-данные (Location Indicator) как неявную локацию. Запрос «Starbucks» имеет высокий локальный интент и не в Blacklist.
3. Результат: Система генерирует Modified Query («Starbucks Brooklyn NY»). Локальные результаты (карты, адреса кофеен в Бруклине) повышаются (Promoted) и отображаются перед стандартными веб-результатами (например, сайтом starbucks.com).

Сценарий 2: Понижение локальных результатов (Blacklist Override)

1. Ситуация: Пользователь ищет «address of Steven Spielberg».
2. Действие системы: Система может изначально посчитать интент локальным из-за слова «address». Однако, этот запрос может находиться в Blacklist как запрос, для которого локальные результаты обычно нерелевантны.
3. Результат: Blacklist отменяет повышение локальных результатов. Пользователь видит информационные результаты (биографии, новости), а не карту с адресами однофамильцев.

Сценарий 3: Запрос локации (Whitelist Prompt)

1. Ситуация: Пользователь ищет «Pizza» с устройства, где GPS отключен и профиль не настроен (локация неизвестна).
2. Действие системы: Система не может определить локацию. Однако запрос «Pizza» находится в Whitelist (сильный локальный интент).
3. Результат: Система отображает ЗАПРОС на ввод города или индекса ПЕРЕД любыми результатами, так как уверена, что пользователю нужна локальная информация.

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