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

Описание

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

Патент решает проблему неоднозначности запросов, которые могут относиться как к личным контактам пользователя (например, из адресной книги телефона или email), так и к публичной информации в интернете. Цель – определить истинное намерение пользователя и корректно ранжировать и смешивать (blending) эти разнородные типы результатов (Contact Entry и Additional Information Item) в персонализированной выдаче.

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

Запатентована система для ранжирования записей из личных контактов пользователя относительно других информационных элементов (например, веб-страниц). Система вычисляет вероятность того, что запрос направлен на поиск контактной информации (Contact Indication Measure), используя для этого контекстные сигналы, такие как интерфейс, через который подан запрос. Также запатентован метод ранжирования контактов между собой на основе временных данных (Temporal Data) и истории взаимодействий.

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

Система работает в несколько этапов:

• Анализ интента: Анализируется запрос и контекст его подачи (устройство, время, интерфейс) для определения Contact Indication Measure — вероятности того, что пользователь ищет контакт.
• Поиск и оценка контактов: Идентифицируются релевантные контакты в личных коллекциях пользователя. Они оцениваются с использованием сигналов персонализации, таких как частота, давность и время предыдущих взаимодействий (Temporal Data).
• Поиск и оценка веб-результатов: Идентифицируются и оцениваются релевантные публичные веб-документы или другие неконтактные данные.
• Ранжирование и смешивание: Система объединяет результаты, используя рассчитанные оценки и Contact Indication Measure, чтобы определить, следует ли показывать контакты, веб-результаты или и то, и другое, и с какой степенью заметности (prominence).

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

Высокая. Персонализация, использование контекстуальных сигналов (время, место, устройство, интерфейс) и смешивание данных из разных источников (Universal Search/Metasearch) являются фундаментальными аспектами современного поиска. Интеграция личных данных особенно активна в Google Assistant и поиске на мобильных устройствах.

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

Минимальное влияние (1/10). Этот патент описывает механизмы персонализации и смешивания приватных данных пользователя (контактов) с публичным веб-индексом. Он не описывает, как Google ранжирует публичные веб-страницы. Для оптимизации публичного веб-сайта (стандартного SEO) этот патент практически не дает применимых инсайтов.

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

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

Additional Information Item (Дополнительный информационный элемент)

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

Affinity Measure (Мера аффинности)

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

Commonality Measure (Мера общности)

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

Contact Entry (Запись контакта)

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

Contact Identification System (Система идентификации контактов)

Система, отвечающая за поиск и оценку релевантных записей в коллекциях контактов пользователя.

Contact Indication Measure (Показатель индикации контакта)

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

Contacts Collection (Коллекция контактов)

Любая коллекция записей контактов пользователя (например, адресная книга телефона, контакты email-сервиса, социальные сети).

Query Temporal Data (Временные данные запроса)

Дата и/или время, связанные с отправкой запроса.

Ranking Engine (Механизм ранжирования)

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

Scoring Engine (Механизм оценки)

Компонент внутри Contact Identification System, который рассчитывает оценки (scores) для записей контактов на основе различных сигналов ранжирования.

Temporal Data (Временные данные контакта)

Данные, связанные с записью контакта, указывающие время и/или даты, в течение которых пользователь взаимодействовал с этим контактом. Могут также включать тип взаимодействия (звонок, текст, email) и вес (propensity).

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

Патент содержит два ключевых независимых пункта, описывающих разные аспекты ранжирования.

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

1. Система получает запрос пользователя через устройство.
2. Идентифицируется Contact Indication Measure (вероятность поиска контакта). Критически важно: этот показатель определяется на основе того, какой из нескольких интерфейсов на устройстве был использован для отправки запроса.
3. Из личной коллекции контактов идентифицируется Contact Entry.
4. Определяется Contact Entry Score, основанный на релевантности и на Contact Indication Measure.
5. Из другого источника идентифицируется Additional Information Item (не являющийся записью контакта).
6. Определяется Additional Information Item Score (отличающийся от оценки контакта).
7. Оба элемента ранжируются на основе их оценок.
8. В ответ на запрос предоставляется информация о контакте и информация о дополнительном элементе, причем они отображаются отдельно.

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

1. Система получает запрос.
2. Идентифицируется Первый контакт и его Temporal Data (история временных характеристик прошлых взаимодействий с ним).
3. Идентифицируется Второй контакт и его Temporal Data.
4. Определяются Query Temporal Data (текущее время/дата запроса).
5. Первый контакт ранжируется относительно Второго на основе взаимосвязи между Query Temporal Data и Temporal Data обоих контактов. (Т.е. с кем пользователь вероятнее хочет связаться именно сейчас).
6. Предоставляется информация об обоих контактах, причем их заметность (prominence) основана на этом ранжировании.

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

Изобретение затрагивает этапы понимания запроса, ранжирования и финального смешивания результатов.

INDEXING – Индексирование и извлечение признаков
Система должна проиндексировать личные данные пользователя (Contacts Collections), включая извлечение Temporal Data (истории взаимодействий) и расчет Affinity Measure для источников.

QUNDERSTANDING – Понимание Запросов
Query Processing Engine анализирует запрос и контекст его подачи (включая интерфейс) для вычисления Contact Indication Measure. Это определяет, насколько вероятно, что пользователь ищет личный контакт.

RANKING – Ранжирование
Происходит параллельный поиск. Основной Ranking Engine оценивает публичные веб-документы. Параллельно Contact Identification System и его Scoring Engine действуют как специализированный вертикальный поиск, оценивая личные контакты пользователя, используя персонализированные сигналы (например, Temporal Data).

METASEARCH – Метапоиск и Смешивание
Основное применение патента. Ranking Engine выполняет смешивание (blending), ранжируя разнородные результаты (контакты и веб-страницы) на основе их оценок и Contact Indication Measure.

RERANKING – Переранжирование
Применяется для ранжирования нескольких релевантных контактов относительно друг друга с использованием Temporal Data (Механизм из Claim 13).

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

• Запрос пользователя.
• Контекст пользователя (тип устройства, используемый интерфейс, время, местоположение).
• Личные коллекции контактов пользователя (Contacts Collections) и история взаимодействий.
• Публичный веб-индекс и другие источники персональных данных (файлы, история браузера).

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

• Смешанная поисковая выдача (SERP), отображающая личные контакты и/или веб-результаты в порядке, определенном механизмом ранжирования.

На что влияет

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

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

• Триггеры активации: Алгоритм активируется, когда запрос имеет соответствия в личных коллекциях контактов пользователя или когда Contact Indication Measure превышает порог.
• Условия применения: Логика смешивания зависит от рассчитанного Contact Indication Measure. Если он высок, контакты получают приоритет. Если он низок, приоритет отдается веб-результатам. Применяется только при наличии доступа к личным данным пользователя.

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

Процесс А: Смешивание контактов и веб-результатов (Claim 1)

1. Получение запроса и контекста: Система получает запрос и метаданные, включая используемый интерфейс.
2. Расчет интента: Вычисление Contact Indication Measure на основе контекста и интерфейса.
3. Идентификация контактов: Поиск релевантных Contact Entries.
4. Оценка контактов: Расчет Contact Entry Score. Оценка повышается, если Contact Indication Measure высок, и учитывает сигналы персонализации (история взаимодействий, время).
5. Идентификация других элементов: Поиск релевантных Additional Information Items (например, веб-страницы). Этот шаг может быть пропущен, если Contact Entry Score очень высок (Claim 3).
6. Оценка других элементов: Расчет Additional Information Item Score. Оценка может понижаться, если Contact Indication Measure высок.
7. Ранжирование и смешивание: Ранжирование контактов и других элементов на основе их оценок.
8. Формирование выдачи: Генерация SERP с заметностью результатов, соответствующей их рейтингу.

Процесс Б: Ранжирование контактов на основе времени (Claim 13)

1. Получение запроса и времени: Система определяет текущее время (Query Temporal Data).
2. Идентификация кандидатов: Идентифицируются несколько релевантных контактов (например, два человека с одинаковым именем).
3. Анализ истории взаимодействий: Система извлекает Temporal Data (историю прошлых взаимодействий с указанием времени/даты и типа связи) для каждого контакта.
4. Сравнение времени: Система сравнивает Query Temporal Data с Temporal Data каждого контакта.
5. Корректировка оценки: Оценка контакта повышается, если текущее время соответствует времени и типу связи, когда пользователь обычно взаимодействует с этим контактом.
6. Ранжирование: Контакты ранжируются на основе скорректированных оценок.

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

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

Патент фокусируется на использовании персональных и контекстных данных для ранжирования контактов. Стандартные SEO-факторы (ссылки, контент сайта) не упоминаются.

• Пользовательские и Поведенческие факторы: Критически важны.
  • История взаимодействия с контактами: частота (Frequency), давность (Recency), тип взаимодействия (звонок, текст, email).
  • Текущий контекст пользователя (в отпуске, на встрече, за рулем).
  • Социальные связи и общие атрибуты (для Commonality Measure).
• Временные факторы: Текущее время и дата запроса (Query Temporal Data). Исторические данные о времени и дате взаимодействий с контактом (Temporal Data).
• Географические факторы: Местоположение пользователя и местоположение контакта (для оценки близости).
• Технические/Контекстные факторы:
  • Тип устройства (мобильный vs. десктоп).
  • Тип ввода (голосовой vs. печатный).
  • Интерфейс, используемый для подачи запроса (критично для Claim 1).
• Контентные факторы (для контактов): Данные в узлах записи контакта (имя, псевдоним, организация, телефон, email).

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

• Contact Indication Measure: Вероятностная оценка того, что запрос ищет контакт. Рассчитывается на основе терминов запроса, контекста подачи (в частности, интерфейса) и статистики поведения пользователей.
• Temporal Data Matching: Оценка совпадения текущего времени запроса с историческими паттернами времени взаимодействия пользователя с конкретным контактом. Включает весовые коэффициенты (propensity) для разных типов связи.
• Contact Entry Score: Оценка для личного контакта. Агрегирует множество сигналов: степень совпадения запроса с узлами контакта, Contact Indication Measure, местоположение, Temporal Data Matching, частоту и давность взаимодействий, Commonality Measure и Affinity Measure коллекции.
• Additional Information Item Score: Оценка для веб-результата или другого элемента. Использует стандартные сигналы ранжирования (релевантность, качество, популярность). Может быть понижена, если Contact Indication Measure высок.
• Affinity Measure: Оценка важности конкретной коллекции контактов (например, телефонная книга важнее контактов соцсети).

Выводы

1. Инфраструктура персонализации и смешивания (Metasearch): Патент описывает архитектуру Универсального поиска, позволяющую Google интегрировать приватные данные пользователя (контакты) в общую поисковую выдачу, рассматривая их как специализированную вертикаль.
2. Явный расчет интента поиска контакта: Google активно вычисляет вероятность того, что пользователь ищет именно контакт (Contact Indication Measure). Этот показатель влияет на баланс между личными и публичными результатами.
3. Важность контекста подачи запроса: Контекст, в котором подается запрос, играет ключевую роль. Согласно Claim 1, даже конкретный используемый интерфейс на устройстве (например, поиск из приложения «Телефон» vs. поиск из браузера) является сильным сигналом для определения интента.
4. Глубокая персонализация на основе истории взаимодействий и времени: Ранжирование контактов сильно зависит от личной истории пользователя, в частности от того, в какое время суток или дни недели пользователь обычно взаимодействует с контактом (Temporal Data).
5. Отсутствие значимости для стандартного SEO: Патент полностью сосредоточен на обработке и ранжировании личных данных пользователя. Он не содержит информации о факторах ранжирования публичных веб-сайтов и не предлагает практических выводов для стандартных SEO-стратегий.

Практика

ВАЖНО: Патент является инфраструктурным и описывает обработку персональных данных пользователя. Он не дает практических выводов для SEO публичных сайтов.

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

Прямых рекомендаций для SEO, следующих из механизмов этого патента, нет.

Косвенный вывод:

• Учет персонализации при анализе SERP: Необходимо понимать, что при неоднозначных запросах (имена людей, названия организаций) органическая видимость публичного сайта может быть подавлена в пользу личных контактов пользователя, если Google определит высокий Contact Indication Measure. Это особенно актуально на мобильных устройствах.

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

Информация о неэффективных или опасных SEO-тактиках в тексте патента отсутствует, так как он не касается ранжирования публичных веб-ресурсов.

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

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

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

Практических примеров для SEO нет. Ниже приведен пример работы описанного механизма персонализации, основанный на данных, представленных в патенте (FIG. 2A, 2B, 9A-9C).

Сценарий: Ранжирование контактов на основе времени (Temporal Data)

1. Данные пользователя: У пользователя есть два контакта: «Боб Герман» (друг) и «Боб Джонс» (коллега).
   • История с Бобом Германом: В основном звонки по выходным (Wknd Call, вес 0.8).
   • История с Бобом Джонсом: В основном тексты по будням (Wkday Text, вес 0.8) и тексты по выходным (Wknd Text, вес 0.6).
2. Запрос 1 (Суббота, 13:00): Пользователь вводит «Боб». Система анализирует Temporal Data. Боб Герман соответствует паттерну выходного дня (0.8). Результат: Боб Герман ранжируется выше Боба Джонса.
3. Запрос 2 (Вторник, 13:00): Пользователь вводит «Боб». Система определяет, что время (будний день) соответствует паттерну Боба Джонса (0.8). Результат: Боб Джонс ранжируется выше Боба Германа.
4. Запрос 3 (Суббота, 13:00): Пользователь вводит «Написать Бобу» (Text Bob). Система учитывает и время (выходной), и интент (Текст). Боб Джонс имеет сильную историю текстовых сообщений по выходным (0.6), в то время как у Боба Германа нет истории текстовых сообщений. Результат: Боб Джонс ранжируется выше, так как его score с учетом типа связи оказался выше.

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