Как Google использует историю посещений (чекины) пользователя и его друзей для персонализации локальной выдачи

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

Check-in (Чекин)

Действие пользователя в Location-based service, подтверждающее его физическое присутствие в определенном месте (Entity) в определенное время. Используется как источник Presence Data.

Contact (Контакт)

Другой пользователь, связанный с текущим пользователем через Social Graph.

Entity (Сущность / Место)

Объект, имеющий географическое местоположение, который может быть результатом поиска. Примеры: ресторан, магазин, парк, библиотека.

Location-based service (Сервис на основе местоположения)

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

Presence Data (Данные о присутствии)

Информация о текущем (current presence) или прошлом (past presence) физическом присутствии пользователя или его контактов в определенном Entity.

Relevancy Score (Оценка релевантности)

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

Relationship Score (Оценка отношений)

Метрика, определяющая силу связи между пользователем и контактом в Social Graph. Может основываться на частоте взаимодействия, продолжительности знакомства или степени родства.

Social Graph (Социальный граф)

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

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

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

1. Система получает поисковый запрос от пользователя.
2. Идентифицируется результат поиска, связанный с Entity, имеющей географическое местоположение, и имеющий Relevancy Score.
3. Идентифицируется контакт из Social Graph пользователя. Подтверждается, что этот контакт указал свое физическое присутствие (текущее или прошлое) в этой Entity с помощью Location-based service.
4. Relevancy Score результата модифицируется на основе типа физического присутствия контакта. Ключевой момент: применяется первый вес (first weight), если присутствие текущее, и второй вес (second weight), если присутствие прошлое, при этом первый вес больше второго (Текущее присутствие важнее прошлого).
5. Результаты ранжируются на основе модифицированных оценок и передаются пользователю.

Claim 2 (Зависимый): Дополняет Claim 1, указывая, что модификация Relevancy Score также основывается на текущем или прошлом физическом присутствии самого пользователя в данной Entity.

Claim 7 (Зависимый): Детализирует процесс модификации с учетом силы связи.

Генерируется Relationship Score, основанный на степени отношений между пользователем и контактом. Relevancy Score модифицируется с использованием этого Relationship Score. (Присутствие близкого друга влияет сильнее, чем присутствие случайного знакомого).

Claim 8 (Зависимый): Уточняет механизм временного затухания (Time Decay).

Модификация Relevancy Score включает уменьшение веса присутствия с течением времени. Более недавнему физическому присутствию контакта придается больший вес.

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

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

INDEXING – Индексирование и извлечение признаков
На этом этапе система собирает и индексирует Presence Data. Это включает обработку чекинов или данных истории местоположений от Location-based services, связывая пользователей с Entities и временными метками. Также рассчитываются и сохраняются Relationship Scores внутри Social Graph.

RERANKING – Переранжирование (Персонализация)
Основное применение патента. Алгоритм функционирует как персонализирующий Твидлер (Twiddler). После того как стандартный этап RANKING сформировал базовый набор результатов с Relevancy Scores, система активирует этот механизм.

1. Получение контекста: Извлекается Social Graph и Presence Data для текущего пользователя и его контактов.
2. Сопоставление: Данные о присутствии сопоставляются с Entities в результатах поиска.
3. Модификация и Переранжирование: Вычисляются модификаторы на основе типа, давности присутствия и Relationship Score. Relevancy Scores корректируются, и происходит финальная сортировка.

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

• Поисковый запрос и идентификатор пользователя.
• Стандартные результаты поиска (Entities) и их Relevancy Scores.
• Social Graph пользователя и Relationship Scores контактов.
• Presence Data (история посещений/чекинов) пользователя и контактов.

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

• Персонализированный список результатов поиска с модифицированными оценками ранжирования.

На что влияет

• Конкретные типы контента и ниши: Наибольшее влияние оказывается на локальный поиск (Local SEO) и Entities с географическим местоположением: рестораны, магазины, услуги, достопримечательности (HoReCa, ритейл, развлечения).
• Специфические запросы: Запросы с локальным интентом (например, "ресторан рядом", "лучший кофе", "кинотеатр").

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

Алгоритм применяется при выполнении следующих условий:

• Идентификация пользователя: Пользователь должен быть идентифицирован системой (залогинен).
• Разрешения на доступ к данным: Пользователь должен разрешить использование своей информации (социальной сети, истории местоположений) для персонализации поиска.
• Наличие данных: В системе должны существовать данные Social Graph и Presence Data для пользователя и/или его контактов.
• Тип запроса: Запрос должен возвращать результаты, связанные с Entities, для которых существуют данные о присутствии.

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

1. Получение запроса и идентификация: Система получает поисковый запрос и идентифицирует пользователя.
2. Получение стандартных результатов: Поисковая система возвращает список релевантных Entities с базовыми Relevancy Scores.
3. Извлечение социального контекста: Получается список контактов пользователя из Social Graph, а также соответствующие Relationship Scores.
4. Извлечение данных о присутствии: Из базы данных Presence Data извлекается история посещений/чекинов пользователя и его контактов, относящаяся к найденным Entities.
5. Расчет модификаторов (Бустинг): Для каждой Entity рассчитывается модификатор на основе анализа присутствия. Этот расчет включает:
   • Определение типа присутствия: Присвоение базовых весов (Текущее присутствие получает больший вес, чем прошлое).
   • Учет давности (Time Decay): Применение фактора затухания к весу прошлого присутствия (чем старше визит, тем меньше вес).
   • Учет социальных связей: Корректировка веса присутствия контакта на основе Relationship Score (визит близкого друга весит больше).
   • Учет собственных посещений: Учитываются посещения самого пользователя.
6. Агрегация и применение модификаторов: Все сигналы присутствия для данной Entity суммируются. Базовые Relevancy Scores изменяются с помощью рассчитанных модификаторов (путем умножения или сложения). Патент предлагает пример формулы агрегации (Equation 1): $Modifier = \sum K_iF_i$.
7. Переранжирование и выдача: Результаты сортируются по новым оценкам и предоставляются пользователю.

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

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

Патент фокусируется на использовании данных о поведении и социальных связях для персонализации.

• Пользовательские факторы:
  • Social Graph: Список контактов пользователя, полученный из социальной сети или других источников.
  • История местоположений пользователя (User's Presence Data).
• Поведенческие факторы:
  • Presence Data (контактов и пользователя): Данные о реальном физическом присутствии, зафиксированные цифровым способом (check-ins или пассивное отслеживание местоположения).
• Географические факторы:
  • Географическое положение сущностей (Entities) в результатах поиска.
• Временные факторы:
  • Дата и время каждого случая присутствия (presence).

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

• Relationship Score (Оценка отношений): Метрика силы связи. Рассчитывается на основе частоты общения между пользователем и контактом, продолжительности нахождения контакта в социальном графе, степени родства или типа социального графа.
• Weighting by Presence Type (Взвешивание по типу присутствия): Присвоение разных весов. Current presence (текущее присутствие) имеет больший вес, чем past presence (прошлое присутствие) (Claim 1).
• Time Decay (Временное затухание): Вес присутствия уменьшается с течением времени. Давние посещения имеют минимальный вес, тогда как недавние – значительный (Claim 8).
• Модификатор оценки: Итоговый бустинг для Relevancy Score. Может быть рассчитан как мультипликатор или аддитивный бонус. Рассчитывается по формуле $\sum K_iF_i$. Где i — тип присутствия, K_i — настраиваемый весовой параметр, а F_i — фактор присутствия. Факторы F_i могут также модифицироваться нелинейными функциями (например, логарифмом или ограничением максимального значения).

1. Персонализация через реальное поведение: Патент описывает механизм, который напрямую связывает физическую активность пользователя и его социального круга с ранжированием в поиске. Места, которые пользователь посещал ранее, получат приоритет.
2. Социальные сигналы как фактор ранжирования для локальных сущностей: Присутствие друзей или контактов в определенном месте является сигналом релевантности или популярности этого места для пользователя (социальное доказательство).
3. Важность силы социальных связей: Система не просто учитывает факт присутствия контакта, но и взвешивает его значимость с помощью Relationship Score. Посещения близких друзей влияют на ранжирование сильнее, чем посещения случайных контактов.
4. Приоритет свежести и текущего момента (Recency): Патент явно указывает на приоритет текущего присутствия над прошлым и использование временного затухания (Time Decay). Это делает выдачу динамичной и чувствительной к недавней активности.
5. Зависимость от сбора данных: Эффективность системы напрямую зависит от объема и качества данных, собираемых через Location-based services (чекины, история местоположений) и доступности Social Graph.

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

Рекомендации применимы в первую очередь для локального бизнеса (Local SEO).

• Стимулирование реальных посещений и удержания клиентов: Поскольку история посещений самого пользователя (past presence of the user) является фактором повышения ранжирования, критически важно фокусироваться на качестве офлайн-услуг и программах лояльности. Повторные визиты усиливают сигнал и повышают видимость бизнеса для этого пользователя.
• Поощрение цифрового взаимодействия с локацией: Стимулируйте клиентов отмечать свое посещение (check-in) в Google Maps или подтверждать визит другими способами (отзывы, фото с геотегом). Эти действия подтверждают факт посещения и усиливают связь между пользователем и Entity.
• Повышение "социальной" привлекательности бизнеса: Создавайте условия, при которых клиенты захотят приходить с друзьями и делиться своим опытом. Визиты контактов пользователя (особенно с высоким Relationship Score) повышают видимость вашего бизнеса для него.
• Актуализация профиля в Google Business Profile (GBP): Убедитесь, что ваша Entity точно идентифицируется и имеет корректные географические данные, чтобы система могла сопоставить Presence Data с вашим бизнесом.

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

• Накрутка фейковых чекинов или истории посещений: Попытки манипулировать Presence Data с помощью ботов или неаутентичных аккаунтов являются высокорискованными. Использование Relationship Score также направлено на борьбу с такими манипуляциями, придавая вес только значимым социальным связям.
• Игнорирование офлайн-опыта: Концентрация только на традиционных факторах Local SEO без заботы о реальном клиентском опыте приведет к отсутствию сигналов Presence Data, что снизит видимость для потенциально лояльной аудитории.

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

Патент подтверждает стратегическое направление Google на конвергенцию онлайн-видимости и офлайн-активности в локальном поиске. Физическая активность пользователей и их социальный контекст являются ключевыми элементами персонализации. Это означает, что выдача по одному и тому же локальному запросу может кардинально отличаться для двух разных людей. Для локальных бизнесов это означает, что репутация и популярность "на земле" напрямую конвертируются в видимость в поиске, особенно в рамках социальных кругов их клиентов.

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

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

1. Пользователь (User) ищет: "итальянский ресторан".
2. Стандартная выдача: Включает рестораны A, B и C, ранжированные по стандартным факторам (релевантность, расстояние, рейтинг). Порядок: A, B, C.
3. Анализ Presence Data:
   • Ресторан A: Пользователь никогда не был. Друг 1 (слабая связь) был 2 года назад.
   • Ресторан B: Пользователь был 1 месяц назад (Past Presence).
   • Ресторан C: Пользователь никогда не был. Друг 2 (сильная связь, высокий Relationship Score) находится там прямо сейчас (Current Presence).
4. Модификация оценок:
   • Ресторан A получает минимальный бустинг (старый визит, слабая связь).
   • Ресторан B получает значительный бустинг (недавний визит самого пользователя).
   • Ресторан C получает максимальный бустинг (текущее присутствие близкого друга).
5. Результат: Персонализированная выдача для пользователя может выглядеть как C, B, A.