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

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

Activity Indication (Индикация активности)

Данные, указывающие на предыдущие действия пользователя, такие как отправка поискового запроса, доступ к документу, отправка/получение сообщения, создание записи в календаре или задачи. Включает время действия (activity time) и связанные сущности.

Entity (Сущность)

Топик дискурса; человек, место, концепция или вещь, на которую можно сослаться текстовым фрагментом и которая отличима от других. Хранятся в Entity Database.

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

Хранилище сущностей, их свойств и взаимосвязей.

Familiarity Measure (Мера знакомства)

Метрика, указывающая на знакомство пользователя с одной или несколькими сущностями или локациями. Используется при расчете travel-related score.

General Travel Information Indication (Общая индикация информации о путешествии)

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

Likely Travel Time (Вероятное время поездки)

Предполагаемая дата или время, когда пользователь заинтересован в поездке в определенную локацию. Определяется на основе данных в activity indications (например, бронирования в почте или календаре).

Location Determination Engine (Механизм определения локации)

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

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

Компонент, вычисляющий travel-related score для определенной локации.

Travel Information Engine (Механизм информации о путешествиях)

Компонент, который определяет, ранжирует и предоставляет коллекцию travel-related information indications пользователю.

Travel-related Information Indication (Индикация информации, связанной с путешествием)

Конкретный элемент информации о локации (например, сниппет документа, ссылка, погода, список достопримечательностей, маршрут).

Travel-related Score (Оценка, связанная с путешествием)

Метрика, указывающая на вероятность того, что пользователь заинтересован в поездке в определенную локацию.

User Interface Activity Indication (Индикация активности пользовательского интерфейса)

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

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

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

1. Идентификация множества activity indications пользователя, каждое из которых связано с сущностями.
2. Идентификация набора (set) связанных действий на основе общих или связанных сущностей.
3. Определение локации (location) на основе сущностей из этого набора.
4. Расчет travel-related score для этой локации, указывающего на вероятность интереса к поездке.
5. Определение коллекции travel-related information indications. Этот шаг включает:
   • Идентификацию множества документов, связанных с поездкой в эту локацию.
   • Ранжирование (ranking) этих документов.
   • Выбор одного или нескольких документов на основе ранжирования.
   • Определение индикаций на основе выбранных документов.
6. Предоставление коллекции информации при условии, что travel-related score удовлетворяет порогу, и в ответ на user interface activity indication (т.е. проактивно, без запроса).

Claim 7 (Зависимый от 1): Уточняет расчет travel-related score.

Оценка включает определение времени действия (activity time) как минимум одного из действий в наборе и сравнение этого времени с текущим временем.

Claim 9 (Зависимый от 7): Уточняет влияние времени на оценку.

Чем больше разница между текущим временем и activity time, тем менее индикативен travel-related score (т.е. интерес пользователя угасает со временем, если нет новых действий).

Claim 11 (Зависимый от 1): Вводит концепцию likely travel time.

Расчет travel-related score включает определение вероятного времени поездки.

Claim 12, 13, 14 (Зависимые от 11): Описывают динамику изменения оценки в зависимости от likely travel time.

Оценка корректируется со временем. Она увеличивается по мере приближения к likely travel time (Claim 13) и уменьшается после того, как likely travel time прошло (Claim 14).

Claim 32 (Независимый пункт): Альтернативная формулировка основного метода, акцентирующая внимание на familiarity measure.

Процесс аналогичен Claim 1, но расчет travel-related score явно основывается на activity indications И на мере знакомства (familiarity measure) пользователя с сущностями из набора действий.

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

Изобретение охватывает инфраструктуру для сбора данных о пользователе и механизмы проактивного поиска (типа Google Discover).

INDEXING – Индексирование и извлечение признаков
На этом этапе происходит индексация не только веб-контента, но и личных данных пользователя (User Activities, User Attributes), если пользователь дал разрешение. Происходит извлечение сущностей из этих активностей (почта, календарь, история поиска) и их сохранение в Content Database и Entity Database.

QUNDERSTANDING – Понимание Запросов (и Намерений)
Система выходит за рамки понимания одного запроса и фокусируется на понимании долгосрочных намерений. Location Determination Engine постоянно анализирует activity indications, кластеризует их и выявляет потенциальные поездки. Это процесс интерпретации сессии или множества сессий.

RANKING – Ранжирование
Когда система решает сформировать коллекцию информации, она использует механизм ранжирования (как указано в Claim 1). Travel Information Engine идентифицирует кандидатов (документы, данные) и ранжирует их, чтобы выбрать наиболее полезную информацию для путеводителя. Ранжирование может учитывать как общую релевантность локации, так и специфические сущности из набора действий пользователя.

METASEARCH – Метапоиск и Смешивание
Travel Information Engine действует как система метапоиска, собирая информацию из разных источников (веб-документы, базы данных о погоде, карты, личные данные пользователя) и смешивая их в единый интерфейс (путеводитель).

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

• Activity indications (история поиска, просмотров страниц, email, календарь).
• Entities, связанные с этими действиями.
• User Attributes (предпочтения, история поездок, домашний/рабочий адрес).
• Entity Database (связи между сущностями).
• Текущее время и текущее местоположение пользователя.

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

• Travel-related score для потенциальных локаций.
• Likely travel time.
• Коллекция travel-related information indications (проактивный путеводитель) или General Travel Information Indication (уведомление).

На что влияет

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

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

Алгоритм применяется при выполнении нескольких условий:

• Триггеры активации (Определение интереса): Когда система идентифицирует достаточное количество связанных activity indications, указывающих на конкретную локацию, и рассчитывает travel-related score, превышающий заданный порог.
• Триггеры активации (Доставка контента): Доставка происходит проактивно в ответ на user interface activity indication (например, открытие новой вкладки браузера, разблокировка телефона, доступ к приложению Google).
• Временные рамки: Система учитывает угасание интереса со временем (если нет новых действий), а также увеличивает приоритет показа по мере приближения к likely travel time.

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

Процесс А: Мониторинг и Оценка (Постоянный процесс)

1. Сбор и ассоциация: Система непрерывно собирает activity indications пользователя и ассоциирует их с entities.
2. Идентификация наборов: Location Determination Engine ищет наборы действий, связанных общими или родственными сущностями. Учитывается время действий (действия должны быть в пределах временного окна).
3. Определение локации: Для каждого набора определяется потенциальная локация на основе доминирующих сущностей, имеющих свойство "location".
4. Расчет Travel-Related Score: Scoring Engine вычисляет оценку для локации. При расчете учитываются:
   • Количество и типы действий в наборе (календарь и почта могут иметь больший вес, чем поиск).
   • Сила связей между сущностями.
   • Наличие сущностей, связанных с путешествиями (отель, ресторан).
   • Атрибуты пользователя и familiarity measure (поездка в незнакомое место получает более высокую оценку).
   • Время действий (оценка снижается со временем).
5. Определение Likely Travel Time: Если возможно, система определяет вероятное время поездки из данных (например, даты бронирования).
6. Корректировка оценки по времени: Оценка динамически корректируется: повышается при приближении к likely travel time и понижается после.

Процесс Б: Генерация и Доставка (Триггерный процесс)

1. Проверка порога: Система проверяет, превышает ли travel-related score для какой-либо локации пороговое значение.
2. Идентификация контента: Если порог превышен, Travel Information Engine идентифицирует документы и данные, релевантные поездке в эту локацию.
3. Ранжирование контента: Система ранжирует идентифицированный контент. Ранжирование может учитывать атрибуты пользователя, likely travel time (например, поиск событий на конкретные даты) и специфические сущности из набора действий (например, если пользователь искал пиццу, рестораны пиццы ранжируются выше).
4. Формирование коллекции: Выбирается лучший контент и формируется коллекция travel-related information indications (путеводитель).
5. Ожидание триггера доставки: Система ожидает user interface activity indication.
6. Доставка: Коллекция предоставляется пользователю (либо напрямую, либо через General Travel Information Indication).

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

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

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

• Поведенческие факторы (Activity Indications):
  • Поисковые запросы (Search Query).
  • Просмотры веб-страниц (Webpage Access).
  • Электронные письма (Email) – например, подтверждения бронирований.
  • Записи в календаре.
  • Создание задач.
• Временные факторы (Activity Time): Время совершения каждого действия. Используется для определения актуальности интереса и расчета likely travel time.
• Пользовательские факторы (User Attributes):
  • Предпочтения пользователя.
  • История предыдущих путешествий.
  • Знакомые локации (familiar locations) – например, дом, работа.
• Географические факторы:
  • Текущее местоположение пользователя.
  • Расстояние между текущим/знакомым местоположением и предполагаемым местом назначения.
• Данные о сущностях: Свойства сущностей и сила связей между ними (из Entity Database).

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

• Travel-related Score: Основная метрика вероятности поездки. Рассчитывается на основе агрегации факторов: количества, типов и времени activity indications, атрибутов пользователя, familiarity measure, и расстояния до локации.
• Familiarity Measure: Оценка знакомства пользователя с локацией. Если локация определена как знакомая (например, дом), travel-related score может быть понижен.
• Likely Travel Time: Предполагаемое время поездки. Используется для динамической корректировки travel-related score (повышение при приближении даты, понижение после).
• Ranking (Ранжирование документов): Метрика для отбора контента в путеводитель. Рассчитывается на основе релевантности документа локации и специфическим интересам пользователя, выявленным из его действий.
• Веса ассоциаций (Weights): Сила связи между activity indication и entity, а также между разными entities. Используется для кластеризации действий и определения локации.

1. Отслеживание долгосрочных намерений: Google активно анализирует действия пользователей вне рамок одной поисковой сессии для выявления сложных намерений, таких как планирование поездки. Система связывает поисковые запросы, просмотры сайтов и личные данные (почта, календарь).
2. Сущности как клей для данных: Entities используются для объединения разрозненных действий. Понимание того, как контент связан с сущностями (особенно локациями и туристическими объектами), критически важно для его идентификации системой.
3. Проактивный поиск (Discover) основан на ранжировании: Система не просто показывает случайный контент. Claim 1 прямо указывает, что для формирования проактивной выдачи используется процесс идентификации и ранжирования документов. Это означает, что контент конкурирует за видимость в этих блоках.
4. Персонализация и контекст критичны: Travel-related score и выбор контента сильно зависят от контекста пользователя: его атрибутов, времени (likely travel time), местоположения и истории (familiarity measure). Интерес к поездке динамичен — он угасает со временем, но возрастает по мере приближения к дате поездки.
5. Незнакомые локации в приоритете: Система склонна предоставлять больше информации о локациях, которые пользователь плохо знает (низкий familiarity measure), по сравнению с привычными местами (дом, работа).

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

• Оптимизация под Google Discover и проактивный поиск: Поскольку система ранжирует документы для проактивного показа (Claim 1), необходимо применять лучшие практики оптимизации под Discover: создавать высококачественный контент по актуальным темам (в данном случае, путешествия), использовать привлекательные изображения и заголовки.
• Усиление связи контента с сущностями (Entity Association): Контент должен быть четко связан с конкретными локациями и туристическими объектами (достопримечательности, рестораны, отели). Используйте структурированные данные (Schema.org для LocalBusiness, Events, TouristAttraction) и убедитесь, что текст ясно указывает на релевантные сущности, чтобы Travel Information Engine мог идентифицировать и высоко ранжировать ваш контент.
• Создание контента для разных этапов путешествия: Создавайте контент, который может быть полезен как на этапе планирования, так и во время самой поездки (например, "Лучшие пиццерии в Lincoln Park", а не только "Отели в Чикаго"). Это увеличивает шансы на то, что ваш контент будет выбран для путеводителя, так как система ищет разнообразную информацию.
• Актуализация событийного контента: Если ваш бизнес зависит от событий, убедитесь, что информация о датах четко указана. Система ищет контент, релевантный likely travel time пользователя.

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

• Игнорирование оптимизации под сущности: Создание контента без четкой привязки к конкретным локациям или объектам (например, "Советы путешественникам") снижает вероятность его выбора этой системой, которая ищет информацию для конкретного места назначения.
• Фокус только на традиционном поиске: Ограничение стратегии только ранжированием по ключевым словам в стандартной выдаче игнорирует растущий канал трафика из проактивных систем (Discover), который работает по описанным в патенте принципам.
• Создание поверхностного контента: Поскольку система проводит ранжирование документов, низкокачественный или кликбейтный контент с меньшей вероятностью будет выбран для включения в проактивный путеводитель.

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

Этот патент подчеркивает стратегическую важность перехода от реактивного поиска (ответ на запрос) к проактивному (предоставление информации до запроса). Для SEO это означает, что видимость сайта все больше зависит от того, насколько хорошо Google понимает его контент в контексте сущностей и намерений пользователя. Стратегия должна включать оптимизацию под весь путь пользователя (Customer Journey Map) и обеспечение видимости в нетрадиционных точках контакта, таких как Discover и Assistant.

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

Сценарий: Оптимизация сайта ресторана в туристической зоне

1. Ситуация: Пользователь ищет "отели в Чикаго" и получает email с подтверждением брони на следующие выходные. Google определяет локацию "Чикаго" и likely travel time (следующие выходные). Travel-related score высок.
2. Цель SEO: Добиться того, чтобы местный ресторан появился в проактивном путеводителе пользователя.
3. Действия:
   • Усиление сущностей: Убедиться, что на сайте ресторана четко указано его местоположение (район Lincoln Park, Чикаго), тип кухни (пицца) и он зарегистрирован в Google Business Profile. Использовать разметку LocalBusiness.
   • Создание релевантного контента: Опубликовать статью в блоге ресторана, например, "5 вещей, которые нужно сделать в Lincoln Park на выходных" (включая посещение ресторана). Это связывает ресторан с более широким туристическим интересом.
   • Оптимизация под Discover: Использовать высококачественные фотографии блюд и интерьера.
4. Ожидаемый результат: Когда система генерирует путеводитель по Чикаго, Travel Information Engine ранжирует доступный контент. Благодаря четкой связи с сущностями ("Чикаго", "Lincoln Park", "пицца") и качественному контенту, ресторан или статья из его блога включаются в раздел "Рестораны рядом" в путеводителе пользователя.