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

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

Action Query (Запрос на действие)

Запрос или команда на выполнение компьютерного действия (computer-based action). Не ограничивается поиском, может включать запуск приложений, резервирование, навигацию и т.д.

Action Term (Термин действия)

Часть Action Query, определяющая, какое действие необходимо выполнить (аналог глагола). Например, «Найти», «Забронировать», «Позвонить».

Entity Term (Термин сущности)

Часть Action Query, определяющая объект, параметр или входные данные для действия (аналог существительного). Например, «ресторан», «активность», «итальянская кухня».

Unresolved Entity Term (Неразрешенный термин сущности)

Entity Term, который не удалось определить или уточнить на основе текущего контента или ввода пользователя. Например, если определен род (genus), но не вид (species).

User Attribute Data (Данные атрибутов пользователя)

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

Location Data (Данные о местоположении)

Данные, используемые для уточнения запроса. Включают текущее местоположение устройства (GPS), данные о точках интереса (Point of Interest data) из базы данных POI или данные от маяков (beacon data) поблизости.

Identified Content (Идентифицированный контент)

Контент, отображаемый на устройстве непосредственно перед инициацией Action Query (например, скриншот приложения, текст в чате). Является основой для определения текущего контекста.

Vague Action Term (Неопределенный термин действия)

Action Term, который слишком общий для определения конкретного действия без дополнительного контекста (например, «Мне скучно»).

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

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

1. Система получает ввод для инициации Action Query (например, нажатие кнопки, голосовая команда).
2. Идентифицируется контент, отображавшийся на устройстве непосредственно перед получением ввода.
3. Идентифицируется Action Term, который связан с Entity Term и настроен на выполнение действия.
4. Определяется невозможность разрешить (уточнить) Entity Term на основе идентифицированного контента.
5. В ответ на это Entity Term разрешается с использованием User Attribute Data, хранящихся на устройстве.
6. Генерируется интерактивный контент (например, карточка с кнопкой) с использованием идентифицированного Action Term и разрешенного Entity Term.
7. Интерактивный контент предоставляется для отображения.
8. Компьютерное действие выполняется при выборе пользователем графического элемента в этом контенте.

Claim 6, 7, 8 (Зависимые): Уточняют условия, при которых определяется невозможность разрешения Entity Term.

• Claim 6: Когда Action Term является неопределенным (vague action term).
• Claim 7: Когда сущность в контенте допускает множественные интерпретации (например, слово "cats" может означать животных или мюзикл).
• Claim 8: Когда невозможно определить вид (species) для определенного рода (genus) (например, определено «ресторан», но не «тип кухни»).

Claim 9 (Зависимый): Уточняет, что для разрешения Entity Term могут дополнительно использоваться Location Data (текущее местоположение, данные POI или данные маяков).

Claim 10 (Зависимый): Описывает применение метода к поиску точек интереса (POI).

• Action Term — это поиск POI.
• Entity Term — это категория POI.
• Разрешение с помощью User Attribute Data заключается в определении конкретной категории POI (например, ресторан, магазин, развлечение).

Claim 12 (Зависимый от 10): Уточняет, что разрешение может включать определение подкатегории для разрешенной категории POI (например, определение типа кухни для категории «ресторан»).

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

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

QUNDERSTANDING – Понимание Запросов
Это основной этап применения патента. Система должна интерпретировать ввод пользователя и текущий контекст (Identified Content). Ключевая задача здесь — распознать намерение (Action Term) и определить, является ли контекст достаточным для его выполнения. Если Entity Term не разрешен, активируется механизм патента для обогащения запроса с помощью User Attribute Data.

RANKING / RETRIEVAL (Персонализированный отбор)
После того как запрос был уточнен с помощью User Attribute Data, система выполняет поиск или отбор кандидатов. Поскольку запрос теперь персонализирован (например, из «найти активность» превратился в «найти походы поблизости»), результаты поиска будут специфичны для интересов пользователя.

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

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

• Ввод пользователя для инициации действия (кнопка, голос, жест).
• Identified Content (контент на экране, текст диалога).
• User Attribute Data (профиль интересов пользователя).
• Location Data (текущее местоположение, данные POI).

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

• Разрешенный Action Query (с уточненными Entity Terms).
• Интерактивный контент (рекомендации, карточки действий), предоставленный пользователю.

На что влияет

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

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

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

• Триггер активации: Пользователь явно или неявно запрашивает помощь или действие.
• Условие контекста: Текущий контент и ввод пользователя недостаточны для разрешения всех необходимых Entity Terms для выполнения действия. Это происходит, когда:
  • Запрос неопределенный (vague).
  • Контекст допускает множественные интерпретации.
  • Определена общая категория, но не конкретный элемент (genus vs species).
• Наличие данных: В системе доступны релевантные User Attribute Data и/или Location Data, которые могут помочь разрешить неоднозначность.

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

Процесс обработки запроса на действие:

1. Получение ввода: Система получает ввод от пользователя для инициации Action Query.
2. Идентификация контента: Определяется текущий контент, отображаемый на устройстве (контекст).
3. Идентификация терминов: На основе контента и ввода система пытается определить Action Terms и Entity Terms для компьютерного действия.
4. Проверка разрешения сущностей: Система определяет, есть ли неразрешенные (unresolved) Entity Terms.
   • Если НЕТ: Перейти к шагу 6.
   • Если ДА: (например, обнаружено неопределенное действие типа «Мне скучно», сформирован запрос «Поиск Активности», но термин «Активность» не разрешен). Перейти к шагу 5.
5. Разрешение сущностей с помощью атрибутов: Система использует User Attribute Data (например, пользователь любит походы) и/или Location Data (например, пользователь находится в парке) для разрешения Entity Term (например, «Активность» разрешается как «Походы на природе»).
6. Выполнение действия: Система выполняет компьютерное действие с использованием разрешенного Action Query. Это может включать:
   • Проверку доступности сети.
   • Выполнение запроса к удаленной системе (если онлайн).
   • Выполнение запроса к локальной базе данных, например, базе POI (если офлайн или для быстрого ответа).
7. Генерация и предоставление результата: Генерируется интерактивный контент (например, список ближайших маршрутов для похода) и отображается пользователю.

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

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

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

• Контентные факторы (Контекст): Текст, метаданные, стенограммы диалогов, URL-адреса, изображения и теги изображений из контента, который пользователь просматривал в последнее время (Identified Content).
• Пользовательские факторы (Персонализация): User Attribute Data — история пользователя, интересы, предпочтения, любимые сущности (команды, авторы, исполнители и т.д.). Эти данные хранятся локально или удаленно.
• Географические факторы: Location Data — текущее местоположение устройства (GPS), данные из базы данных точек интереса (POI), данные от ближайших маяков (beacon data).
• Временные факторы: Текущее время и дата могут использоваться в сочетании с атрибутами пользователя для разрешения сущностей (хотя явно не выделены как основной фактор, они упоминаются как возможные дополнительные данные).

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

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

• Определение невозможности разрешения (Inability to Resolve): Логическое условие, которое срабатывает, если Entity Term не может быть уточнен из контекста. Основано на анализе семантики контента и определении наличия неопределенных терминов, множественных интерпретаций или неполной спецификации (genus/species).
• Выбор категории/подкатегории POI: Система использует User Attribute Data для выбора между категориями (ресторан, шоппинг, активность, услуги, развлечения) и подкатегориями (например, тип кухни или вид спорта). Механизм выбора основан на сопоставлении доступных категорий с профилем интересов пользователя.
• Комбинирование данных: Система может комбинировать User Attribute Data и Location Data. Например, если пользователь любит походы (атрибут) и находится в парке (локация), это усиливает выбор в пользу предложения активностей на природе.

1. Персонализация как ключ к пониманию запроса: Патент демонстрирует, как Google использует данные профиля пользователя (User Attribute Data) не только для переранжирования результатов, но и на фундаментальном уровне понимания запроса (Query Understanding). При недостатке контекста личные интересы определяют, как именно будет интерпретирован запрос.
2. Разрешение неопределенных интентов: Система специально разработана для обработки неопределенных (vague) запросов, где пользователь выражает потребность, но не указывает специфику (например, «Я голоден»). Это критически важно для диалоговых интерфейсов и ассистентов.
3. Важность структурированных данных о сущностях: Способность системы разрешать Entity Terms зависит от того, насколько хорошо контент и бизнесы категоризированы. Система должна уметь переходить от общего к частному (genus к species), например, от «ресторан» к «итальянская кухня», основываясь на интересах пользователя.
4. Контекст шире, чем просто запрос: Контекст включает в себя то, что находится на экране пользователя (Identified Content), его местоположение (Location Data) и его долгосрочные интересы (User Attribute Data).
5. Локальный и офлайн доступ: Патент подчеркивает возможность выполнения действий локально на устройстве, используя локальные базы данных (например, POI), что важно для скорости и доступности в условиях ограниченного подключения.

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

• Оптимизация сущностей и точная категоризация (Entity Optimization): Критически важно обеспечить, чтобы ваш бизнес, контент или продукт были правильно ассоциированы с конкретными категориями и подкатегориями (например, не просто «ресторан», а «веганский ресторан тайской кухни»). Это позволяет системе точно сопоставить вашу сущность с интересами пользователя (User Attribute Data), когда она разрешает неопределенный запрос.
• Усиление сигналов Local SEO: Поскольку Location Data и базы данных POI играют ключевую роль в разрешении запросов, необходимо поддерживать актуальность и полноту информации в Google Business Profile. Это гарантирует, что ваш бизнес будет рассмотрен при выполнении локально-ориентированных действий.
• Создание контента под персонализированные интенты: Понимайте, какие интересы есть у вашей аудитории. Создавайте контент, который явно отвечает этим интересам. Это увеличивает вероятность того, что Google свяжет ваш контент с профилем пользователя и предложит его в ответ на неопределенные запросы в вашей тематике.
• Использование микроразметки (Schema.org): Используйте детальную разметку для описания ваших предложений (событий, продуктов, меню). Это помогает поисковой системе лучше понять ваши сущности и их атрибуты, облегчая процесс сопоставления с User Attribute Data.

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

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

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

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

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

Сценарий 1: Local SEO для ресторана

1. Ситуация: Пользователь открывает мессенджер, где друг спрашивает: «Куда пойдем ужинать?». Пользователь отвечает: «Не знаю, я просто голоден».
2. Активация: Пользователь запускает Ассистента (например, долгим нажатием кнопки).
3. Анализ (Патент): Система анализирует экран. Определяет Action Term: «Предложить место для ужина». Определяет Entity Term: «Тип заведения/кухня». Контекст («Я голоден») не позволяет разрешить Entity Term.
4. Применение (Патент): Система обращается к User Attribute Data и видит, что пользователь часто посещает и высоко оценивает суши-бары.
5. Действие SEO: Владелец суши-бара тщательно заполнил GBP, указав категорию «Суши-бар», добавил меню с разметкой и имеет высокие отзывы.
6. Результат: Система разрешает Entity Term как «Суши» и предлагает этот суши-бар в качестве рекомендации, даже если поблизости есть другие типы ресторанов.

Сценарий 2: Оптимизация контента для хобби

1. Ситуация: Пользователь говорит Ассистенту: «Мне скучно».
2. Анализ (Патент): Action Term: «Предложить активность». Entity Term: «Тип активности» (не разрешен).
3. Применение (Патент): Система проверяет User Attribute Data и видит, что пользователь часто читает статьи о горном велосипеде.
4. Действие SEO: SEO-специалист сайта о горных велосипедах создал контент о лучших местных маршрутах и разметил его как TouristAttraction или Event (если это заезд).
5. Результат: Система разрешает «Тип активности» как «Горный велосипед» и предлагает пользователю статьи о маршрутах или информацию о ближайших трассах.