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

Описание

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

Патент решает две ключевые проблемы для мобильного поиска:

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

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

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

Запатентована система и метод интеграции местоположения устройства в поисковые запросы. Ядром системы является Native Application (нативное приложение, например, Google Gears или современные API геолокации HTML5), которое выступает посредником между веб-браузером и аппаратными модулями определения местоположения (GPS, Cell-ID). Система использует иерархический подход к определению локации: приоритет отдается текущему местоположению, но при его отсутствии используются данные из истории поисков. Ключевой особенностью является механизм параллельного поиска по нескольким недавним локациям, если текущее местоположение неизвестно.

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

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

1. Доступ к локации: Когда пользователь загружает страницу поиска, веб-приложение в браузере запрашивает местоположение через API у Native Application.
2. Определение местоположения: Native Application получает данные от GPS или других источников (Cell-ID, WiFi) и возвращает их веб-приложению.
3. Иерархия локаций: При отправке запроса система определяет, какую локацию использовать: (1) Явно указанную в запросе (например, «пицца Москва»); (2) Текущее местоположение устройства; (3) Последнее использованное местоположение из истории.
4. Параллельный поиск (при неопределенности): Если текущее местоположение недоступно и в запросе нет явной локации, система может выбрать несколько недавних местоположений из истории и выполнить поиск по ним одновременно.
5. Триггер локального поиска: Сервер определяет, является ли запрос локальным (например, «ресторан» vs «рецепт»), используя базу данных локальных терминов (Local Terms Database), и применяет определенную локацию для генерации результатов.

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

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

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

Патент имеет критическое значение (9/10) для SEO, особенно в локальном и мобильном сегментах. Он описывает архитектуру, которая определяет, ДЛЯ КАКОГО МЕСТОПОЛОЖЕНИЯ будет выполняться поиск, когда пользователь вводит запрос с локальным интентом. Понимание того, как Google получает и приоритизирует данные о местоположении (текущее vs. история), необходимо для разработки эффективных стратегий локального продвижения и оптимизации под запросы типа «рядом со мной».

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

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

Native Application (Нативное приложение)

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

Browser-based Application / Web Page Code (Приложение на базе браузера)

Код (HTML, JavaScript), загружаемый с веб-страницы и выполняемый внутри веб-браузера.

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

Машиночитаемые данные о местоположении, например, координаты широты/долготы (Lat/Long) или Cell-ID.

Location Descriptor / Human-readable description (Дескриптор местоположения)

Человекочитаемое описание местоположения (например, название города, адрес), часто получаемое путем обратного геокодирования Location Identifier.

GPS Module (GPS-модуль)

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

Local Search (Локальный поиск)

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

Local Terms Database (База данных локальных терминов)

Хранилище терминов (whitelist/blacklist), которые указывают на локальный интент запроса (например, «пицца», «автосервис»).

API (Application Programming Interface)

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

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

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

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

1. Native Application получает поисковый запрос от веб-браузера.
2. Native Application определяет, что (i) в запросе нет термина, связанного с местоположением (location-based term), И (ii) браузеру недоступна явная информация о местоположении (explicit location information, например, данные GPS).
3. В ответ на это Native Application выбирает ДВА ИЛИ БОлее конкретных географических местоположения из ранее идентифицированных (истории).
4. Native Application отправляет поисковой системе ДВА запроса одновременно: (i) исходный запрос + данные первой локации и (ii) исходный запрос + данные второй локации.
5. Native Application получает результаты для обоих запросов.
6. Native Application передает (например, браузеру) результаты обоих запросов.

Claim 5 (Зависимый от 1): Уточняет, что параллельным запросам могут быть назначены разные веса.

Первому поисковому запросу (например, по самой последней локации) назначается первый вес (first weight), а второму запросу (например, по предпоследней локации) назначается второй вес (second weight), отличный от первого.

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

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

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

CRAWLING & INDEXING
На этапе индексирования система должна иметь доступ к геокодированным данным о бизнесе и контенте, чтобы впоследствии сопоставить их с местоположением пользователя.

QUNDERSTANDING – Понимание Запросов
Основное применение. Система должна:

• Определить интент запроса: является ли он локальным. Это делается путем сравнения терминов запроса с Local Terms Database.
• Определить источник местоположения: система использует иерархию (явное указание в запросе > текущая локация устройства > история локаций).
• Получить данные о местоположении устройства: взаимодействие браузера и Native Application для доступа к GPS/Cell-ID.
• Сформировать итоговый запрос (или несколько запросов), дополнив его данными о местоположении.

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

METASEARCH & RERANKING
Если был инициирован параллельный поиск по нескольким локациям (согласно Claim 1), на этом этапе может происходить взвешивание (согласно Claim 5) и смешивание результатов из разных локаций или подготовка их для быстрого отображения пользователю.

На что влияет

• Специфические запросы: Наибольшее влияние оказывается на запросы с локальным интентом (коммерческие, информационные запросы о местах, услугах, товарах поблизости).
• Конкретные типы контента: Локальные страницы (Local Listings, страницы филиалов), агрегаторы услуг, интернет-магазины с физическими точками выдачи.
• Конкретные ниши или тематики: Критически важно для тематик с высокой локальной привязкой: рестораны, ритейл, услуги (автосервисы, салоны красоты), недвижимость, медицина (YMYL).
• Географические ограничения: Механизм разработан для повышения точности поиска в пределах географических зон (город, район).

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

Алгоритм определения местоположения применяется при каждой обработке запроса. Конкретные механизмы активируются при следующих условиях:

• Триггер доступа к GPS: Активируется, когда веб-приложение запрашивает текущее местоположение через Native Application (и пользователь разрешил доступ).
• Триггер локального интента: Активируется, когда сервер определяет, что запрос содержит термины из Local Terms Database.
• Триггер использования истории: Активируется, если текущее местоположение недоступно (нет GPS сигнала, доступ запрещен) и в запросе нет явного указания локации.
• Триггер параллельного поиска (Claim 1): Активируется строго при условии, что нет ни текущей локации, ни локационного термина в запросе. Система использует несколько предыдущих локаций.

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

Процесс А: Получение текущего местоположения устройства (Взаимодействие Клиента)

1. Инициализация: Пользователь запускает браузер и загружает веб-страницу (например, страницу поиска).
2. Запрос локации: Код веб-страницы (JavaScript) инициирует вызов API (например, getCurrentPosition()) к Native Application для получения местоположения.
3. Доступ к оборудованию: Native Application обращается к GPS-модулю или другим источникам (WiFi, Cell-ID).
4. Получение идентификатора: Native Application получает Location Identifier (например, Lat/Long).
5. Геокодирование (Опционально): Native Application или веб-приложение отправляет Location Identifier на удаленный сервер для получения человекочитаемого Location Descriptor (например, названия города).
6. Предоставление данных: Информация о местоположении возвращается веб-приложению в браузере.

Процесс Б: Обработка поискового запроса и выбор локации (Взаимодействие Клиент-Сервер)

1. Получение запроса: Пользователь вводит и отправляет поисковый запрос.
2. Анализ запроса на явную локацию: Система проверяет, содержит ли запрос явные указания местоположения (название города, адрес).
   • Если ДА: Используется эта локация. История локаций обновляется. Переход к шагу 5.
   • Если НЕТ: Переход к шагу 3.
3. Проверка доступности текущей локации: Система проверяет, удалось ли Процессу А определить текущее местоположение устройства.
   • Если ДА: Используется текущая локация. История локаций обновляется. Переход к шагу 5.
   • Если НЕТ: Переход к шагу 4.
4. Использование истории локаций (Fallback): Система обращается к хранилищу недавних местоположений (локальному или на сервере).
   1. Выбор кандидатов: Выбирается одно или несколько недавних местоположений (например, топ-N).
   2. Параллельный поиск: Формируются и отправляются несколько поисковых запросов одновременно (Запрос + Локация 1, Запрос + Локация 2…). Им могут быть назначены разные веса в зависимости от новизны.
5. Определение локального интента: Сервер анализирует запрос на наличие терминов из Local Terms Database.
   • Если ДА: Инициируется локальный поиск с использованием определенной(ых) локации(й).
   • Если НЕТ: Инициируется общий поиск (локация игнорируется).
6. Возврат результатов: Сервер возвращает локализованные результаты. Если использовался параллельный поиск, возвращаются результаты для всех локаций.

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

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

• Географические факторы (Ключевые):
  • GPS Data: Координаты широты и долготы (Lat/Long), высота, точность.
  • Cell-ID / WiFi Data: Данные о сотовых вышках или точках доступа WiFi для триангуляции местоположения.
  • IP Address: Может использоваться для грубого определения региона, если другие методы недоступны.
• Контентные факторы:
  • Query Text: Текст запроса анализируется на наличие явных указаний местоположения (названия городов, адреса) и локальных терминов.
• Поведенческие/Пользовательские факторы:
  • Stored Recent Locations: История предыдущих местоположений, связанных с поисками пользователя. Хранится локально (Cookies, Database) или на сервере (привязка к Session ID).
  • User Preferences: Настройки пользователя, разрешающие или запрещающие определение местоположения.
• Системные данные:
  • Local Terms Database: Белые/черные списки терминов для определения локального интента.

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

Патент не детализирует формулы, но описывает следующие ключевые метрики и методы:

• Иерархия источников местоположения: Система использует строгую приоритизацию источников данных: Явное указание в запросе > Текущее местоположение (GPS/Cell-ID) > История местоположений.
• Определение локального интента: Основано на сравнении терминов запроса с Local Terms Database.
• Выбор локаций из истории: При отсутствии текущей локации система выбирает недавние местоположения. Патент предполагает выбор наиболее свежих записей (most recent location).
• Параллельное выполнение (Parallel Execution): При использовании истории система может выполнять поиск по нескольким локациям одновременно (Claim 1).
• Взвешивание (Weighting): Результатам параллельных поисков могут присваиваться разные веса (Claim 5). Логично предположить, что более свежие локации получают больший вес.
• Обратное геокодирование (Reverse Geocoding): Преобразование Location Identifier (Lat/Long) в Location Descriptor (Город, Адрес).

Выводы

1. Фундамент локального поиска: Патент описывает базовую архитектуру, которая позволяет Google автоматически определять местоположение пользователя для локализации выдачи. Это основа для всех запросов с локальным интентом на мобильных устройствах.
2. Иерархия определения местоположения критически важна: Google всегда будет пытаться определить наилучший доступный источник локации. Приоритет отдается точности (GPS) и явному интенту (запрос), но система имеет надежный механизм отката к истории поведения пользователя.
3. История местоположений влияет на текущие результаты: Если GPS недоступен, результаты поиска будут зависеть от того, где пользователь искал ранее. Это означает, что поведение пользователя в прошлом формирует его текущую выдачу в условиях геолокационной неопределенности.
4. Потенциал параллельного поиска по локациям: Ключевое утверждение (Claim 1) описывает агрессивный механизм параллельного поиска по нескольким недавним локациям. Если это реализовано, Google стремится минимизировать задержки, предугадывая возможные локации интереса пользователя (например, дом и работа).
5. Разделение интента (Local vs General): Система активно классифицирует запросы на локальные и общие, используя Local Terms Database. Локация применяется только к запросам с подтвержденным локальным интентом.
6. Приоритет пользователя: Пользователь всегда может переопределить автоматическое определение местоположения, явно указав локацию в своем запросе.

Практика

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

• Оптимизация под «Near Me» запросы: Поскольку система автоматически добавляет текущее местоположение к запросам с локальным интентом, необходимо оптимизировать контент и локальные сигналы (например, Google Business Profile) для ранжирования по неявным локальным запросам (которые пользователи видят как «рядом со мной»).
• Точность и полнота NAP (Name, Address, Phone): Критически важно поддерживать консистентность данных о физическом местоположении бизнеса во всех источниках (сайт, GBP, каталоги). Это гарантирует, что когда Google применяет местоположение пользователя, ваш бизнес будет корректно идентифицирован в этой зоне.
• Стимулирование локального контента и отзывов: Усиление локальных сигналов (отзывы с упоминанием района, локальный ссылочный профиль) помогает лучше ранжироваться, когда система применяет соответствующую геолокацию к запросу.
• Учет мобильного контекста и микромоментов: Понимание того, что пользователь может находиться в движении. Стратегия должна охватывать различные сценарии использования (поиск по текущей локации и поиск по недавним локациям).
• Техническая готовность к мобильному поиску: Обеспечение быстрой загрузки и адаптивности сайта (Mobile-First), так как описанные механизмы в первую очередь ориентированы на мобильные устройства.

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

• Игнорирование локальных сигналов: Фокусироваться только на общих факторах ранжирования, игнорируя геолокационную привязку бизнеса. Без сильных локальных сигналов бизнес не появится в выдаче, когда пользователь ищет поблизости.
• Неконсистентные данные о местоположении: Публикация разных адресов или телефонов в разных источниках снижает доверие поисковой системы и ухудшает локальное ранжирование.
• Манипуляции с виртуальными адресами (с осторожностью): Использование виртуальных офисов для создания видимости присутствия в регионе может быть неэффективным или рискованным, так как система полагается на реальное местоположение пользователя для определения релевантности.

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

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

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

Сценарий 1: Использование текущего местоположения (GPS)

1. Контекст: Пользователь находится в центре города (доступен GPS) и ищет, где поесть.
2. Действие: Пользователь вводит запрос «ресторан» на мобильном устройстве.
3. Работа системы: Браузер через Native Application получает GPS-координаты. Система определяет запрос «ресторан» как локальный (из Local Terms Database). Запрос модифицируется: «ресторан + [текущие координаты]».
4. Результат: Пользователь видит список ресторанов, отсортированный по близости к его текущему местоположению и рейтингу.

Сценарий 2: Откат к истории местоположений (Fallback)

1. Контекст: Пользователь находится в метро (GPS и Cell-ID недоступны). Ранее он искал информацию около дома и около работы.
2. Действие: Пользователь вводит запрос «аптека».
3. Работа системы: Текущее местоположение недоступно. В запросе нет явной локации. Система выбирает два последних местоположения: [Координаты Дома] и [Координаты Работы].
4. Параллельный поиск (Claim 1): Система одновременно выполняет два поиска: «аптека + [Дом]» и «аптека + [Работа]».
5. Результат: Пользователь получает результаты. Система может либо показать смешанную выдачу (с большим весом для более свежей локации), либо предоставить интерфейс для быстрого переключения между результатами для Дома и Работы.

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