Как Google использует клики по карте и запросы маршрутов для определения филиалов брендов в локальном поиске

Описание

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

Патент решает проблему появления нерелевантных результатов при поиске multi-site entities (брендов, сетей, государственных учреждений). Иногда стандартные сигналы релевантности, такие как совпадение названия, приводят к показу неподходящих листингов (например, показ «Donna’s Moving Van» по запросу «DMV»). Изобретение улучшает точность локального поиска, проверяя, действительно ли результат принадлежит к искомой сети или бренду.

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

Запатентована система валидации релевантности локальных результатов для мультисайтовых сущностей с использованием специфических поведенческих сигналов. Система анализирует, как пользователи взаимодействуют с результатами поиска на картах. Для подтверждения или опровержения принадлежности листинга к искомому бренду используются две ключевые метрики: частота вызова информационного окна (Information window invocation frequency) и частота запроса маршрутов (Direction request frequency).

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

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

• Идентификация запроса: Определяется, что пользователь ищет мультисайтовую сущность (например, «Starbucks» или «DMV»).
• Анализ исторических данных: Система анализирует анонимизированные логи сессий (Session Logs), чтобы понять, как пользователи ранее взаимодействовали с конкретным листингом, когда он показывался по этому запросу.
• Измерение поведения: Рассчитывается, как часто пользователи открывали детали листинга (например, кликали на пин на карте) и как часто запрашивали маршрут к нему.
• Валидация: Если активность высокая (выше пороговых значений), листинг подтверждается как релевантный и добавляется в индекс мультисайтовых сущностей (multi-site-entity index). Если активность низкая, листинг считается нерелевантным для этого запроса и может быть добавлен в черный список (blacklist).

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

Высокая. Точность данных о филиалах и управление локальной выдачей критически важны для Google Maps и Local Pack. Поведенческие сигналы активно используются Google для валидации данных в Google Business Profile (GBP) и борьбы со спамом в названиях. Описанные механизмы остаются фундаментом для обеспечения качества локального поиска.

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

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

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

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

Multi-site entity (Мультисайтовая сущность)

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

Multi-site-entity search query (Поисковый запрос мультисайтовой сущности)

Запрос, содержащий название мультисайтовой сущности (например, «Starbucks» или «DMV»).

Business listing (Бизнес-листинг)

Запись в базе данных, содержащая информацию о сущности (название, адрес, телефон). В контексте современного поиска это аналог профиля в Google Business Profile (GBP).

Information window invocation frequency (Частота вызова информационного окна)

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

Direction request frequency (Частота запроса маршрутов)

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

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

Список бизнес-листингов, которые система определила как нерелевантные для конкретного multi-site-entity search query и которые не должны показываться в ответ на него, даже если их название совпадает.

Multi-site-entity index (Индекс мультисайтовых сущностей)

База данных, содержащая подтвержденные группы листингов, принадлежащих к определенным мультисайтовым сущностям.

Session Logs (Логи сессий)

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

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

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

1. Система определяет запрос как multi-site-entity search query (поиск по общему имени сущностей в разных локациях).
2. Идентифицируются прошлые пользовательские сессии, где конкретный business listing показывался в ответ на этот запрос.
3. Из логов этих сессий определяется Information window invocation frequency для этого листинга.
4. Из логов этих сессий определяется Direction request frequency для этого листинга.
5. Определяется, что термины в поле названия листинга (business name field) совпадают с ключевым словом запроса.
6. На основе измеренных частот (шаги 3 и 4) принимается решение о модификации либо blacklist, либо multi-site-entity index, связанных с этим запросом.

Claim 2 (Зависимый от 1): Детализирует условия добавления в черный список.

Листинг добавляется в blacklist, если выполняется ХОТЯ БЫ ОДНО из условий: (i) Information window invocation frequency ниже первого порога ИЛИ (ii) Direction request frequency ниже второго порога. Это означает, что низкая активность даже по одному из двух ключевых сигналов может привести к пессимизации.

Claim 3 (Зависимый от 1): Детализирует условия добавления в индекс (подтверждение релевантности).

Листинг добавляется в multi-site-entity index, если выполняются ОБА условия: (i) Information window invocation frequency выше первого порога И (ii) Direction request frequency выше второго порога. Для подтверждения требуется высокая активность по обоим сигналам.

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

Система использует Information window invocation frequency и Direction request frequency для расчета оценки (score) для бизнес-листинга. Эта оценка сохраняется в multi-site-entity index и может использоваться для ранжирования.

Claim 5 (Зависимый от 1): Детализирует условия удаления из индекса.

Листинг удаляется из multi-site-entity index, если выполняется ХОТЯ БЫ ОДНО из условий: (i) Information window invocation frequency ниже первого порога ИЛИ (ii) Direction request frequency ниже второго порога.

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

Изобретение затрагивает несколько этапов поиска, преимущественно в контексте локального поиска (Local Search/Google Maps).

INDEXING – Индексирование и извлечение признаков (Офлайн-обработка)
Основная работа алгоритма происходит офлайн. Система анализирует Session Logs для агрегации данных о поведении пользователей. На этом этапе вычисляются метрики Information window invocation frequency и Direction request frequency для пар [Запрос, Листинг]. По результатам анализа обновляются Multi-site-entity index и Blacklists.

QUNDERSTANDING – Понимание Запросов
Система должна классифицировать входящий запрос. Если запрос распознан как Multi-site-entity search query (например, путем сравнения с базой известных запросов мультисайтовых сущностей), это активирует логику, описанную в патенте.

RANKING / RERANKING – Ранжирование и Переранжирование (Локальный поиск)
При обработке локального запроса в реальном времени система использует предварительно рассчитанные данные:

• Использует Multi-site-entity index для поиска подтвержденных релевантных филиалов.
• Использует Blacklists для фильтрации и исключения нерелевантных результатов, даже если их названия совпадают.
• Использует рассчитанные оценки (score) на основе поведенческих сигналов (согласно Claim 4) как фактор ранжирования среди релевантных листингов.

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

• Session Logs (исторические данные о поведении).
• Business Data (база бизнес-листингов).
• Multi-site-entity search queries (база известных брендов/сетей).

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

• Обновленный Multi-site-entity index.
• Обновленные Blacklists для конкретных запросов.
• Оценки (scores) для листингов, основанные на поведении.

На что влияет

• Конкретные типы контента: В первую очередь влияет на результаты локального поиска (Local Pack в SERP, результаты в Google Maps).
• Специфические запросы: Брендовые запросы (например, «McDonalds»), а также категорийные запросы, которые функционируют как поиск сетей (например, «почтовое отделение», «DMV»).
• Конкретные ниши или тематики: Любые тематики, где существуют сети, франшизы или множественные отделения: ритейл, общественное питание, услуги, банковский сектор, государственные учреждения.

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

• Триггеры активации: Когда система идентифицирует входящий запрос как Multi-site-entity search query.
• Условия применения: Алгоритм применяется для валидации тех листингов, чье название (business name field) совпадает с названием искомой мультисайтовой сущности.
• Пороговые значения: Используются предопределенные пороги для Information window invocation frequency и Direction request frequency. Пересечение этих порогов определяет, будет ли листинг валидирован, пессимизирован или заблокирован для данного запроса.

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

Процесс офлайн-валидации листингов:

1. Идентификация релевантных сессий: Система выбирает из Session Logs все прошлые сессии, в которых конкретный бизнес-листинг был показан пользователю в ответ на конкретный multi-site-entity search query.
2. Проверка совпадения названия: Подтверждается, что название в бизнес-листинге совпадает с ключевым словом в multi-site-entity search query.
3. Расчет частоты вызова информационного окна: На основе данных выбранных сессий рассчитывается Information window invocation frequency. Это может быть отношение числа сессий, где окно было вызвано, к общему числу сессий (показов).
4. Расчет частоты запроса маршрутов: Рассчитывается Direction request frequency. Это может быть отношение числа сессий, где был запрошен маршрут к адресу листинга, к общему числу сессий.
5. Сравнение с пороговыми значениями: Полученные частоты сравниваются с предопределенными порогами (Threshold 1 для окон, Threshold 2 для маршрутов).
6. Принятие решения (Пессимизация): Если Information window invocation frequency ниже Threshold 1 ИЛИ Direction request frequency ниже Threshold 2:
   • Листинг добавляется в blacklist для данного запроса.
   • И/Или листинг удаляется из multi-site-entity index.
7. Принятие решения (Подтверждение): Если Information window invocation frequency выше Threshold 1 И Direction request frequency выше Threshold 2:
   • Листинг добавляется или подтверждается в multi-site-entity index.
8. Расчет и сохранение оценки (Опционально): На основе полученных частот рассчитывается score, который сохраняется в индексе для использования при ранжировании.

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

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

• Контентные факторы: Ключевым фактором является название сущности в листинге (business name field). Оно используется для первичного сопоставления листинга с запросом.
• Географические факторы: Адрес листинга. Используется как пункт назначения при анализе запросов маршрутов.
• Поведенческие факторы (Ключевые данные патента):
  • Взаимодействие с интерфейсом поиска (клики, наведение курсора на пин на карте), которое приводит к вызову Information window.
  • Явные запросы на построение маршрута (Direction requests) к адресу листинга.
• Системные данные: Агрегированные и анонимизированные логи пользовательских сессий (Session Logs).

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

• Information window invocation frequency: Метрика вовлеченности. Рассчитывается как абсолютное число вызовов или как отношение (количество вызовов окна / общее количество показов листинга по данному запросу).
• Direction request frequency: Метрика намерения посетить. Рассчитывается как абсолютное число запросов маршрута или как отношение (количество запросов маршрута / общее количество показов листинга по данному запросу).
• Threshold values (Пороговые значения): Предопределенные константы для обеих метрик. Они используются в логике принятия решений (Claims 2, 3, 5).
• Score: Оценка, вычисляемая на основе двух ключевых метрик. Используется для ранжирования подтвержденных листингов (Claim 4).

Выводы

1. Поведенческие сигналы как валидатор локальных данных: Патент демонстрирует, как Google использует реальное взаимодействие пользователей для подтверждения точности и релевантности данных о локальных сущностях, особенно для брендов и сетей. Это механизм самоочистки данных на основе коллективного поведения.
2. Совпадение названия не гарантирует релевантность: Даже если название листинга идеально совпадает с запросом бренда, он может быть исключен из выдачи (добавлен в blacklist), если пользователи его игнорируют (низкие Information window invocation frequency и Direction request frequency).
3. Два ключевых сигнала локального интента: Система выделяет два типа взаимодействия как сильные индикаторы релевантности: интерес к деталям (вызов информационного окна) и намерение совершить визит (запрос маршрута).
4. Асимметричные правила валидации: Логика принятия решений строгая. Согласно Claims 2, 3 и 5, для подтверждения релевантности (добавления в индекс) требуется высокая активность по ОБОИМ сигналам (логическое AND). Однако для пессимизации (добавления в blacklist или удаления из индекса) достаточно низкой активности ХОТЯ БЫ ПО ОДНОМУ из сигналов (логическое OR).
5. Защита от спама в названиях: Этот механизм напрямую противодействует попыткам манипулировать локальной выдачей путем добавления чужих брендовых имен или популярных ключевых слов (например, «DMV») в название нерелевантного бизнеса.

Практика

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

• Стимулирование взаимодействия с Google Business Profile (GBP): Ключевая задача — мотивировать пользователей взаимодействовать с листингами филиалов. Необходимо не просто быть видимым в Local Pack, но и конвертировать показы в клики (Information window invocation) и построение маршрутов (Direction request).
• Повышение привлекательности листинга: Качественные и актуальные фотографии (особенно главное фото), высокий средний рейтинг и большое количество отзывов повышают вероятность того, что пользователь кликнет на листинг для изучения деталей, тем самым увеличивая Information window invocation frequency.
• Абсолютная точность геоданных: Убедитесь, что адрес и расположение пина на карте абсолютно точны. Ошибки в координатах могут приводить к затруднениям при построении маршрута и снижению Direction request frequency.
• Оптимизация под конверсию в визит: Наличие актуальных часов работы, информации о парковке и других важных деталей в листинге увеличивает вероятность того, что пользователь примет решение о визите и запросит маршрут.
• Повышение узнаваемости бренда (Brand Awareness): Чем чаще пользователи ищут именно ваш бренд и выбирают ваши филиалы среди других результатов, тем сильнее становятся агрегированные поведенческие сигналы, подтверждающие ваши позиции в multi-site-entity index.

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

• Манипуляции с названиями (Keyword Stuffing в GBP): Добавление чужих брендовых названий или нерелевантных ключевых слов в название своего бизнеса с целью показа по этим запросам. Этот механизм обнаружит отсутствие релевантного пользовательского поведения и добавит листинг в blacklist для этих запросов.
• Игнорирование качества листинга: Неполные, непривлекательные листинги с устаревшей информацией будут получать низкий уровень взаимодействия. Это может привести к снижению видимости, даже если листинг технически релевантен запросу.
• Накрутка одного типа поведения: Имитация кликов без последующего построения маршрутов может быть недостаточной для подтверждения релевантности, так как система требует высоких показателей по обоим сигналам (Claim 3).

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

Патент подтверждает стратегическую важность реального пользовательского спроса и вовлеченности в локальном поиске. Для долгосрочной SEO-стратегии это означает смещение фокуса с чисто технических факторов ранжирования на оптимизацию пользовательского опыта и конверсии в действия (клик, звонок, маршрут) в рамках GBP. Также этот механизм служит защитой для устоявшихся брендов, фильтруя нерелевантных конкурентов, которые пытаются мимикрировать под них или использовать их трафик.

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

Сценарий: Фильтрация спама в локальной выдаче

1. Запрос: Пользователь ищет «DMV» (Department of Motor Vehicles).
2. Кандидаты в выдаче:
   (A) Официальное отделение DMV.
   (B) Компания «DMV — Donna’s Moving Van» (пример из патента).
3. Анализ поведения: Система анализирует исторические данные. Пользователи, ищущие «DMV», массово кликают на листинг (A) и строят к нему маршруты. Листинг (B) получает показы из-за совпадения букв «DMV», но пользователи его игнорируют, так как ищут государственную услугу, а не переезд.
4. Расчет метрик: Для листинга (A) метрики Information window invocation frequency и Direction request frequency высокие. Для листинга (B) обе метрики близки к нулю.
5. Действие системы: Метрики листинга (B) оказываются ниже пороговых значений.
6. Результат: Листинг (B) добавляется в blacklist для запроса «DMV» и перестает показываться по нему, улучшая качество локальной выдачи. Листинг (A) подтверждается в multi-site-entity index.

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