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

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

Contextual Information (Контекстуальная информация)

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

Device Type (Тип устройства)

Классификация устройства, с которого исходит запрос (например, wearable, non-wearable mobile). Является ключевым фактором для определения намерения пользователя.

Intention Module (Модуль определения намерения)

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

Non-wearable Mobile Device (Неносимое мобильное устройство)

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

Presentation Module (Модуль представления)

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

Query Module (Модуль обработки запросов)

Компонент, который получает исходный запрос и может модифицировать его на основе информации от Intention Module перед выполнением поиска.

Renderable Content (Контент для рендеринга)

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

User Intention (Намерение пользователя)

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

Wearable Device (Носимое устройство)

Тип устройства, предназначенный для ношения на теле (умные часы, очки).

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

Патент описывает два основных варианта реализации системы.

Вариант 1: Модификация запроса (Claim 1, Независимый пункт)

Описывает метод, при котором модифицируется сам запрос перед его выполнением:

1. Система получает поисковый запрос от устройства.
2. Система ассоциирует Device Type с этим устройством.
3. На основе Device Type система выводит User Intention.
4. На основе User Intention система модифицирует поисковый запрос (например, добавляя параметры для фокусировки поиска - Claim 5).
5. Система выполняет поиск по модифицированному запросу.
6. Система отправляет Renderable Content на устройство.

Claims 2, 3, 4 (Зависимые): Уточняют механизм вывода интента. Для одного и того же запроса выводятся разные интенты в зависимости от типа устройства. Конкретно:

• Если устройство — Wearable Device: интент связан со временем, расстоянием или ценой.
• Если устройство — Non-wearable Mobile Device: интент связан с контактной информацией, отзывами или другой общей информацией.

Вариант 2: Модификация результатов (Claim 16, Независимый пункт)

Описывает альтернативный метод, при котором запрос выполняется как есть, но результаты модифицируются:

1. Система получает запрос, ассоциирует Device Type и выводит User Intention.
2. Система выполняет поиск по исходному запросу.
3. На основе User Intention система модифицирует информацию, возвращенную поиском.
4. Система отправляет Renderable Content на основе модифицированной информации.

Claims 17, 18 (Зависимые от 16): Детализируют модификацию результатов через ранжирование и форматирование. Система ранжирует результаты на основе Device Type и извлекает данные из топового результата для форматирования. Правила ранжирования для локальных запросов отличаются:

• Для Non-wearable Mobile Device: ранжирование по наименьшему расстоянию или кратчайшему времени прибытия.
• Для Wearable Device: ранжирование производится так, чтобы результат с наивысшим рейтингом с наибольшей вероятностью помогал пользователю достичь фитнес-цели (fitness goal).

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

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

QUNDERSTANDING – Понимание Запросов
Основной этап применения. Система анализирует не только текст запроса, но и метаданные: Device Type и Contextual Information. На основе этих данных Intention Module определяет User Intention. Если используется Вариант 1, Query Module переписывает (модифицирует) запрос перед передачей его на этап ранжирования.

RANKING – Ранжирование
Система выполняет поиск (потенциально по модифицированному запросу). Стандартные алгоритмы ранжирования генерируют начальный набор результатов.

RERANKING – Переранжирование
На этом этапе может применяться Вариант 2. Результаты могут быть переранжированы на основе User Intention и Device Type (как описано в Claims 17, 18). Например, применение правил ранжирования, основанных на фитнес-целях.

METASEARCH – Метапоиск и Смешивание
Presentation Module работает на этом этапе, формируя финальный Renderable Content. Он извлекает нужную информацию (например, часы работы) и форматирует ее специфическим образом для устройства (например, в виде циферблата для часов).

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

• Исходный поисковый запрос.
• Идентификатор устройства (для определения Device Type).
• Contextual Information (местоположение, время, скорость движения).
• Пользовательские данные (например, фитнес-цели, если доступны).

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

• Модифицированный поисковый запрос (внутренний).
• Скорректированный рейтинг результатов.
• Renderable Content, адаптированный под формат устройства и намерение пользователя.

На что влияет

• Конкретные типы контента и ниши: Наибольшее влияние оказывается на Local SEO, поиск заведений, товаров и услуг, где намерение сильно зависит от контекста (время, местоположение).
• Специфические запросы: Влияет на запросы с неоднозначным интентом, где тип устройства служит сильным сигналом для уточнения (например, запрос названия бренда или заведения).
• Определенные форматы контента: Система предпочитает контент, из которого можно легко извлечь конкретные факты (часы работы, адреса, цены) для переформатирования в device-specific форматы (например, "glanceable experiences" для часов).

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

• Условия работы алгоритма: Алгоритм применяется в реальном времени при обработке поискового запроса.
• Триггеры активации: Активируется, когда система может с высокой степенью уверенности определить тип устройства и связать его с конкретным намерением для данного запроса. Особенно активен при запросах с мобильных и носимых устройств.

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

Система может работать по двум основным путям.

Путь А: Модификация запроса (Claim 1)

1. Получение запроса и Идентификация контекста: Система получает запрос, определяет Device Type и собирает Contextual Information.
2. Вывод интента: Intention Module использует Device Type как основной сигнал для определения User Intention (например, запрос кафе с часов -> интент «время работы»).
3. Модификация запроса: Query Module добавляет дополнительные параметры к запросу (например, «кафе + часы работы»).
4. Выполнение поиска: Поиск выполняется по модифицированному запросу.
5. Форматирование и вывод: Presentation Module получает результаты, форматирует их в адаптированный Renderable Content и отправляет пользователю.

Путь Б: Модификация результатов (Claim 16)

1. Получение запроса, Идентификация контекста и Вывод интента: Аналогично Пути А.
2. Выполнение поиска: Поиск выполняется по исходному запросу.
3. Модификация результатов (Ранжирование): Система применяет логику ранжирования, зависящую от Device Type и User Intention. (Например, ранжировать по соответствию фитнес-целям пользователя для часов).
4. Модификация результатов (Форматирование): Presentation Module извлекает ключевую информацию из топовых результатов и генерирует специфический Renderable Content (например, создать интерактивный циферблат для часов).
5. Вывод: Адаптированный Renderable Content отправляется пользователю.

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

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

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

• Технические факторы: Идентификаторы устройства (User Agent, IP address и т.д.), используемые для определения Device Type.
• Географические факторы: Текущее местоположение устройства. Используется для определения контекста, модификации запросов и ранжирования результатов по расстоянию или времени.
• Пользовательские факторы:
  • Тип устройства (Device Type) — ключевой фактор.
  • Данные о движении (скорость, направление), полученные с сенсоров устройства.
  • Персонализированные данные: Патент явно упоминает использование индивидуальных фитнес-целей (fitness goals) пользователя (например, цель по количеству шагов в день) для влияния на ранжирование.
• Временные факторы: Текущее время используется как часть контекста для определения намерения.

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

• User Intention (Намерение пользователя): Определяется с помощью правил (rules based algorithm) или системы машинного обучения (machine learning system), которая анализирует корреляции между типами устройств, запросами и поведением пользователей. Логика основана на предполагаемом использовании устройства (например, часы для "glanceable experiences").
• Параметры модификации запроса: Конкретные термины (например, "operating hours", "nearest"), которые добавляются к запросу на основе определенного намерения.
• Метрики ранжирования (Специфичные для патента):
  • Ранжирование по расстоянию/времени (Distance/Time to arrive): Используется преимущественно для неносимых мобильных устройств (Claim 18).
  • Ранжирование по соответствию фитнес-целям (Fitness Goal Achievement): Используется для носимых устройств. Система может предпочесть результат, который находится дальше, если это поможет пользователю достичь цели по количеству шагов (Claim 18).

1. Тип устройства как ключевой сигнал интента: Патент подтверждает, что Google использует тип устройства как важный контекстуальный сигнал для определения намерения пользователя. Это не просто адаптация верстки, а глубокая адаптация логики поиска.
2. Динамическая интерпретация и модификация запросов: Система активно переписывает запросы пользователя в реальном времени, основываясь на контексте. Пользователь на часах и пользователь на телефоне, вводящие один и тот же термин, де-факто выполняют разные поисковые запросы с точки зрения системы.
3. Контекстуализация и Персонализация Ранжирования: Ранжирование может радикально меняться в зависимости от устройства и личных целей пользователя. В патенте приводится конкретный пример, когда система предпочитает более удаленный объект ближайшему, чтобы помочь пользователю достичь фитнес-цели.
4. Приоритет удобства и формата представления: Система не просто находит релевантную информацию, но и активно переформатирует ее для удобства использования на конкретном устройстве (например, превращая текстовые часы работы в циферблат или расстояние в интерактивный шагомер).
5. Важность извлекаемых данных: Для реализации таких функций Google должен иметь возможность легко извлекать конкретные факты (часы работы, адреса, цены) из контента веб-страниц. Это подчеркивает важность структурированных данных.

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

• Обеспечение доступности и точности ключевой информации: Критически важная информация (часы работы, адреса, цены, контактные данные) должна быть точной, актуальной и легко извлекаемой из HTML-кода. Эта информация может быть приоритетной для пользователей мобильных и носимых устройств.
• Использование структурированных данных (Schema.org): Активно внедряйте микроразметку для Local Business, Product, Events и т.д. Это облегчает Google извлечение фактов для формирования адаптированных результатов (Renderable Content) на разных устройствах.
• Оптимизация под различные интенты: При разработке контент-стратегии учитывайте, что пользователи могут искать разную информацию в зависимости от контекста. Убедитесь, что сайт дает ответы на разные типы намерений (общая информация/отзывы для смартфонов; быстрая информация/расстояние для "glanceable" устройств).
• Фокус на Local SEO и Мобильной оптимизации: Патент имеет прямое отношение к локальному поиску. Управление данными в Google Business Profile и обеспечение высокой скорости загрузки на мобильных устройствах критичны для удовлетворения контекстных интентов.

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

• Скрытие ключевой информации в неиндексируемых форматах: Размещение часов работы, адресов или цен внутри изображений, видео или сложных скриптов затрудняет их извлечение Presentation Module для адаптации выдачи.
• Игнорирование контекста пользователя: Разработка стратегии, основанной на предположении, что все пользователи имеют одинаковый интент и используют одинаковые устройства.
• Пренебрежение точностью данных о бизнесе: Неверные часы работы или адреса приведут к негативному опыту, особенно на мобильных устройствах, где пользователи ищут информацию "здесь и сейчас".

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

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

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

Сценарий: Оптимизация карточки локального бизнеса для разных устройств

Задача: Улучшить видимость кофейни по запросу "кофейня рядом".

1. Анализ интентов:
   • Смартфон (Non-wearable): Пользователь может хотеть сравнить отзывы, посмотреть меню, найти список ближайших кофеен.
   • Умные часы (Wearable): Пользователь, скорее всего, хочет узнать часы работы ближайшей кофейни или расстояние до нее (возможно, с учетом фитнес-целей).
2. Действия SEO-специалиста:
   • Точность данных: Убедиться, что в Google Business Profile и на сайте указаны точные часы работы и адрес.
   • Структурированные данные: Внедрить разметку LocalBusiness на сайте, уделив особое внимание полям openingHoursSpecification и geo.
   • Контент: Убедиться, что часы работы и адрес представлены в чистом HTML-тексте на главной странице и странице контактов.
3. Ожидаемый результат (согласно патенту):
   • На смартфоне: Google покажет стандартную локальную выдачу (Local Pack), ранжированную по близости и релевантности/авторитетности.
   • На часах: Google определит Device Type, предположит интент "время/расстояние", модифицирует запрос, извлечет часы работы (благодаря структурированным данным) и может показать результат в адаптированном формате (например, в виде циферблата, показывающего время открытия/закрытия, или шагомера до цели).