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

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

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. Результат: Пользователь получает результаты. Система может либо показать смешанную выдачу (с большим весом для более свежей локации), либо предоставить интерфейс для быстрого переключения между результатами для Дома и Работы.