Как Google использует личные данные (Gmail, историю местоположений) для ответов на запросы о посещенных местах

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

Personal Search Result (Персональный результат поиска)

Результат поиска, сгенерированный на основе private content пользователя. Он идентифицирует физическое местоположение, с которым пользователь ранее взаимодействовал.

Private Content (Приватный контент)

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

Private Content Index (Индекс приватного контента)

Индекс, содержащий обработанный private content. Доступ к элементам индекса строго ограничен авторизацией пользователя.

Personal Locational Query (Персональный локационный запрос)

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

Locational Semantic Segments (Локационные семантические сегменты)

Категоризированные части запроса, извлеченные для понимания персонального локационного интента. Включают:

• Action Type Segment: Действие пользователя (например, "visited", "checked-in", "reviewed").
• Location Entity Category Segment: Тип места (например, "restaurant", "hotel").
• Geographic Area Segment: Географическая область (например, "NYC", "nearby").
• Temporal Segment: Время (например, "last week", "April").
• Business Location Alias Segment: Название конкретного бизнеса.

Entity Database (База данных сущностей)

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

Physical Location (Физическое местоположение)

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

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

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

1. Получение запроса через интерфейс, предназначенный для поиска как в приватном, так и в публичном контенте.
2. Определение, что запрос является personal locational query.
3. Определение параметров поиска.
4. Получение информации о пользователе и доступ к private content index на основе авторизации (user information matching access information).
5. Определение релевантного private content, который ранее был сохранен на основе одного из двух источников:
   • Данных о местоположении (location data), сгенерированных аппаратными компонентами устройства пользователя (например, GPS).
   • Полученного пользователем email (received email).
6. Определение физической локации и даты предыдущего взаимодействия на основе этого контента.
7. Генерация personal search result, включающего идентификацию локации и индикацию даты взаимодействия (полученной из приватного контента).
8. Получение публичных результатов поиска.
9. Предоставление персонального результата вместе с публичными результатами с визуальным разделением (visually distinguishing).

Ядро изобретения — это использование специфических источников приватных данных (данные сенсоров устройства ИЛИ email) для ответа на персональные локационные запросы и представление этих данных в смешанной выдаче.

Claim 2 (Зависимый от 1): Уточняет процесс обогащения (Enrichment).

Система определяет дополнительный контент (additional content) из внешних ресурсов (не из private content) и включает его в персональный результат. Это позволяет дополнить приватные данные (факт посещения) публичной информацией (адрес, телефон).

Claim 10 (Независимый пункт): Описывает альтернативный процесс с фокусом на семантическом разборе запроса и использовании временных фильтров.

1. Получение запроса и публичных результатов.
2. Определение первого семантического сегмента (Action Type).
3. Определение второго семантического сегмента (Geographic Area ИЛИ Location Entity Category).
4. Определение временного сегмента (temporal segment).
5. Определение параметров поиска на основе этих сегментов, включая даты из временного сегмента.
6. Поиск в private content (основанном на location data устройства ИЛИ received email), индексированном по всем этим параметрам.
7. Определение физической локации, с которой пользователь взаимодействовал в указанные даты.
8. Генерация personal search result для показа вместе с публичными результатами.

Этот пункт фокусируется на том, как система разбирает запрос на семантические компоненты (Действие, Место/Область, Время) и использует их как точные фильтры для поиска в приватном индексе.

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

Система объединяет процессы индексирования приватного контента с обработкой запросов в реальном времени и формированием персонализированной выдачи.

CRAWLING & INDEXING (Приватный контент)
Система собирает и индексирует private content пользователя.

• Сбор данных: Получение данных из авторизованных источников: email, данные сенсоров устройства (location data), чекины, календари, история поиска и взаимодействия с картами.
• Извлечение признаков: Идентификация взаимодействий с физическими локациями в этом контенте.
• Индексирование: Создание Private Content Index. Элементы индекса содержат информацию о локации, дате, типе действия (action type). Доступ строго ограничен авторизацией пользователя.

QUNDERSTANDING – Понимание Запросов
Ключевой этап для активации системы.

• Классификация интента: Определение, является ли запрос personal locational query путем поиска ключевых слов или анализа синтаксической структуры.
• Семантический разбор: Извлечение Locational Semantic Segments.
• Расширение запроса: Параметры поиска могут быть расширены (например, "visits" может включать "check-ins" и "reservations").

RANKING – Ранжирование (Персональный поиск)
Поиск выполняется в Private Content Index.

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

METASEARCH & RERANKING – Метапоиск, Смешивание и Переранжирование
Финальный этап формирования SERP.

• Обогащение результатов: Система дополняет найденные персональные данные информацией из Entity Database или публичного индекса (адреса, фото, рейтинги).
• Смешивание (Blending) и Форматирование: Personal search results объединяются с публичными, но форматируются так, чтобы визуально отличаться, и часто размещаются на заметной позиции (prominent positional location).

На что влияет

• Специфические запросы: Влияет на информационные и транзакционные запросы, связанные с воспоминаниями, повторным поиском посещенных мест или управлением бронированиями (например, «мой отель в Риме», «когда я был в Старбаксе на Мейн стрит»).
• Конкретные ниши или тематики: Наибольшее влияние в сферах Travel, HoReCa, ритейла и любых других нишах, где фиксируются физические взаимодействия пользователя (через бронирования, покупки или историю местоположений).

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

• Триггер активации: Когда Query Processing Engine классифицирует запрос как personal locational query. Это происходит, если запрос содержит определенные термины (например, «я», «мой», «посетил») и/или определенную синтаксическую структуру.
• Условия работы: Пользователь должен быть авторизован в системе, и у него должен быть проиндексирован релевантный Private Content (т.е. включена история местоположений или есть соответствующие письма в Gmail).

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

Процесс А: Индексирование приватного контента (Офлайн/Фоновый режим)

1. Получение приватного контента: Система получает данные из источников пользователя (Email, Location Data, Calendar и т.д.).
2. Анализ взаимодействия: Идентифицируются элементы контента, указывающие на взаимодействие с физическим местоположением (например, email-подтверждение или GPS-данные о пребывании в локации).
3. Извлечение признаков: Из контента извлекаются ключевые данные: идентификатор сущности, дата/время взаимодействия, тип взаимодействия (Action Type).
4. Генерация индексного элемента: Создается запись в Private Content Index.
5. Установка контроля доступа: Доступ к индексному элементу и исходному контенту ограничивается только авторизованным пользователем.

Процесс Б: Обработка запроса (Реальное время)

1. Получение запроса и информации о пользователе: Система получает запрос и данные авторизации пользователя.
2. Классификация запроса: Определяется, является ли запрос personal locational query.
3. Семантическая сегментация: Если запрос персональный, он разбивается на Locational Semantic Segments.
4. Расширение параметров поиска: Сегменты могут быть расширены (например, «посещения» расширяются до check-ins, location data, reviews).
5. Параллельный поиск: Запускается поиск в Public Content Index и в Private Content Index (с использованием расширенных параметров и контролем доступа).
6. Идентификация приватных результатов: Определяется релевантный приватный контент.
7. Обогащение (Enrichment): Система запрашивает Entity Database для получения дополнительной публичной информации о физическом местоположении.
8. Генерация персонального результата: Создается результат, объединяющий приватные данные (дата посещения) и публичные данные (адрес, телефон).
9. Смешивание и отображение: Персональные и публичные результаты объединяются на SERP с визуальным разделением.

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

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

Система использует уникальную комбинацию приватных и публичных данных.

Приватные данные (Private Content):

• Контентные факторы (Email/Calendar): Содержимое электронных писем (подтверждения бронирований, билеты, чеки) и записей календаря.
• Географические факторы (Location Data): Данные о местоположении пользователя (GPS, Wi-Fi, триангуляция сотовых вышек), указывающие на присутствие пользователя в физической локации.
• Поведенческие факторы (Interactions): Явные взаимодействия пользователя: check-ins в социальных сетях, отзывы, рейтинги, поисковые запросы маршрутов (directional queries) в картографических приложениях, сохраненные места на картах.
• Временные факторы: Даты и время, связанные с любым из вышеперечисленных взаимодействий.

Публичные данные (Entity Database / Public Content):

• Данные о сущностях: Используются для обогащения. Включают названия, адреса, телефоны, веб-сайты, категории (Location Entity Category), фотографии, публичные рейтинги и отзывы.

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

Патент не детализирует формулы ранжирования, но упоминает использование Ranking Signals для оценки приватных результатов. Упомянутые метрики и сигналы:

• Идентификация Personal Locational Query:
  • Анализ семантических сегментов: Определение наличия и комбинации Locational Semantic Segments.
  • Сопоставление с терминами и синтаксический анализ.
• Расширение запроса (Query Expansion/Interpretation):
  • Расширение Action Type: Если тип действия является классом (например, "visits"), система определяет членов класса (например, check-in, review) и включает их в параметры поиска.
  • Расширение Geographic Area: Определение вложенных или близлежащих географических областей.
• Ранжирование (Ranking Signals) приватных результатов:
  • Релевантность запросу.
  • Свежесть взаимодействия (Recency).
  • Личный рейтинг пользователя для этой локации.

1. Единый интерфейс для публичного и приватного поиска: Google стремится быть единой точкой доступа ко всей информации пользователя, включая его личную историю взаимодействий с физическим миром. Система специально обрабатывает запросы, направленные на поиск этой личной информации.
2. Критичность приватных данных как источника: Патент подчеркивает важность private content, особенно email и истории местоположений (location data), как ключевого источника данных о поведении пользователя офлайн. Эти данные активно индексируются и используются в поиске.
3. Семантическое понимание персональных запросов: Система использует сложный механизм для распознавания personal locational queries, основанный на разборе запроса на семантические компоненты (Locational Semantic Segments: Кто, Что сделал, Где, Когда), а не только на ключевых словах.
4. Обогащение персональных данных публичными: Персональные результаты не изолированы. Google связывает приватные данные (факт посещения) с публичными данными о сущности (Entity Database), чтобы предоставить полный контекст (адрес, телефон, публичный рейтинг).
5. Персонализация как приоритет на SERP: Персональные результаты обрабатываются отдельно и визуально выделяются в SERP, часто занимая наиболее заметные позиции. Это может смещать публичные результаты вниз и изменять видимость в топе для конкретного пользователя.

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

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

• Оптимизация транзакционных Email (Email Markup): Убедитесь, что email-подтверждения (бронирования, покупки билетов), отправляемые пользователям, содержат полную информацию о физической локации. Использование микроразметки (Schema.org для Email) критически важно, чтобы помочь Google корректно извлечь эти данные в Private Content Index пользователя.
• Усиление Локального SEO и Entity Optimization: Обеспечьте полное и точное присутствие бизнеса в Google Business Profile и других источниках данных о сущностях. Это критически важно для этапа Обогащения (Enrichment). Если Google не сможет связать приватное взаимодействие с вашей публичной сущностью, персональный результат будет неполным или некорректным.
• Стимулирование генерации User-Generated Private Content: Поощряйте действия, которые фиксируются в приватном индексе Google: онлайн-бронирования, сохранение мест на Google Maps, отзывы. Чем чаще пользователь взаимодействует с брендом, тем выше вероятность появления бренда в его персональных результатах по релевантным запросам.
• Учет персонализации при анализе SERP: При анализе выдачи необходимо понимать, что авторизованные пользователи могут видеть совершенно другую картину за счет блока персональных результатов. Необходимо учитывать этот слой видимости при оценке позиций и трафика.

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

• Отправка неинформативных Email: Отправка подтверждений в виде изображений или без четкого указания деталей транзакции и локации (и без разметки Schema.org) затрудняет индексацию этих взаимодействий Google.
• Неконсистентные данные о компании (NAP): Расхождения в названии, адресе и телефоне между вашим сайтом, Google Business Profile и транзакционными письмами затрудняют процесс связывания приватного взаимодействия с вашей сущностью.
• Игнорирование данных в Google Business Profile: Неактуальные данные в GBP приведут к тому, что даже если пользователь увидит персональный результат о посещении вашего бизнеса, он получит устаревшую информацию, так как она подтягивается из публичных источников для обогащения.

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

Патент подтверждает стратегию Google на глубокую персонализацию и интеграцию всех доступных данных о пользователе (Gmail, Maps, Calendar). Для SEO это означает, что оптимизация должна выходить за рамки сайта и охватывать все точки цифрового взаимодействия с клиентом, включая пост-транзакционные коммуникации (Email). Успех все больше зависит от того, насколько хорошо ваша бизнес-сущность представлена в Knowledge Graph, поскольку именно она служит связующим звеном между приватными данными пользователя и публичной информацией о вашей компании.

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

Сценарий: Оптимизация Email для сети отелей

1. Задача: Увеличить вероятность того, что прошлые гости увидят отель в персональных результатах по запросам типа "отель, где я останавливался в Берлине".
2. Действие: Внедрение Schema.org разметки (LodgingReservation) в email-подтверждения бронирования.
3. Реализация: В код письма добавляется блок LD+JSON, содержащий структурированные данные о бронировании, включая точное название, адрес и даты проживания.

   <script type="application/ld+json"> { "@context": "http://schema.org", "@type": "LodgingReservation", ... "reservationFor": { "@type": "LodgingBusiness", "name": "Hotel Berlin Mitte", "address": { ... } }, "checkinDate": "2025-11-01T15:00:00+01:00" } </script>

4. Результат: Google корректно парсит email (который является private content), идентифицирует взаимодействие с физической локацией (Hotel Berlin Mitte) и добавляет структурированную запись в Private Content Index пользователя. При соответствующем запросе система легко найдет эту запись и сгенерирует personal search result.