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

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

Device Type Identifier (Идентификатор типа устройства)

Данные, передаваемые вместе с запросом, которые позволяют поисковой системе определить тип устройства, отправившего запрос (например, ОС, форм-фактор).

Resource Utility / Device Utility Score (Полезность ресурса / Оценка полезности для устройства)

Метрика, указывающая на степень полезности ресурса для определенного типа устройства. Может принимать значения: Positive utility, Negative utility или Neutral utility.

Positive Utility (Положительная полезность)

Ресурс считается особенно полезным для данного типа устройства по сравнению с другими ресурсами (например, приложение для Android на устройстве Android).

Negative Utility (Отрицательная полезность)

Ресурс считается менее полезным или бесполезным для данного типа устройства (например, приложение для iOS на устройстве Android или сайт на Flash на мобильном устройстве).

Navigational Query (Навигационный запрос)

Запрос, целью которого является поиск конкретного ресурса или веб-сайта. Характеризуется четким намерением пользователя и специфическими навигационными метриками.

Dominant Intent (Доминирующий интент)

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

Score Adjuster (Корректировщик оценок)

Компонент поисковой системы, отвечающий за изменение оценок ранжирования на основе показателей полезности.

Application Index (Индекс приложений)

База данных, содержащая информацию о нативных приложениях (native applications) и их контенте.

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

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

1. Система получает запрос и идентификатор типа устройства (например, Тип А).
2. Получается набор результатов поиска.
3. Идентифицируются ресурсы с положительной полезностью для Типа А (Первое подмножество) и ресурсы с отрицательной полезностью для Типа А (Второе подмножество).
4. Условие 1 (Правомочность): Определяется правомочность (eligibility) корректировки. Выдача признается неправомочной (ineligible), если Первое подмножество (ресурсы с положительной полезностью) отсутствует. Это определение не зависит от наличия Второго подмножества (ресурсов с отрицательной полезностью).
5. Условие 2 (Интент): Если выдача правомочна (есть положительные ресурсы): Проверяется, имеет ли запрос доминирующий интент (dominant intent), независимый от ресурсов Первого подмножества.
6. Действие: Если доминирующего интента нет: Результаты корректируются так, что ресурсы Первого подмножества повышаются (boosted) относительно ресурсов Второго подмножества.
7. Блокировка: Если доминирующий интент есть ИЛИ если выдача неправомочна (Условие 1 не выполнено): Корректировка не производится.

Claims 4 и 5 (Зависимые): Добавляют дополнительное условие блокировки.

Система проверяет, является ли запрос навигационным (navigational query). Если запрос навигационный, выдача признается неправомочной для корректировки на основе полезности устройства.

Claims 2 и 12 (Зависимые): Уточняют механизм определения полезности.

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

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

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

INDEXING – Индексирование и извлечение признаков
На этом этапе система предварительно рассчитывает и сохраняет Device Utility Scores для ресурсов. Это включает анализ технических данных (например, манифестов приложений для определения совместимости с ОС), анализ контента веб-страниц (наличие специфичных ключевых слов, например, "Android" или "iOS") и анализ исторических данных о поведении пользователей (History Logs) для выявления предпочтений пользователей разных устройств.

QUNDERSTANDING – Понимание Запросов
На этом этапе система анализирует запрос для определения его характеристик. Система должна классифицировать запрос как Navigational Query и определить наличие Dominant Intent.

RERANKING – Переранжирование
Основное применение патента. После получения первичного набора результатов (RANKING), компонент Score Adjuster выполняет логику условной корректировки:

1. Получает тип устройства пользователя.
2. Анализирует Device Utility Scores топовых результатов.
3. Проверяет условия активации и исключения (наличие Positive Utility, отсутствие блокирующего интента).
4. Применяет бустинг или демоушен к соответствующим результатам.

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

• Исходный запрос пользователя.
• Device Type Identifier.
• Набор результатов поиска с исходными Ranking Scores.
• Device Utility Scores для каждого ресурса.
• Классификация запроса (Navigational/Dominant Intent).

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

• Скорректированный (или исходный) набор результатов поиска с финальными Ranking Scores.

На что влияет

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

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

Алгоритм применяется при выполнении строгого набора условий. Это система условной корректировки.

Условия для активации корректировки (все должны быть выполнены):

1. В результатах поиска присутствуют ресурсы с положительной полезностью (Positive Utility) для типа устройства пользователя.
2. Запрос НЕ является навигационным (Navigational Query).
3. Запрос НЕ имеет доминирующего интента (Dominant Intent), который независим от ресурсов с положительной полезностью.

Триггеры блокировки корректировки (любой из них блокирует):

• Отсутствие ресурсов с Positive Utility в выдаче.
• Запрос классифицирован как Navigational Query.
• Запрос имеет конфликтующий Dominant Intent.

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

1. Получение данных: Система получает поисковый запрос, Device Type Identifier (определяя Тип Устройства) и первичный набор результатов поиска.
2. Проверка наличия Positive Utility: Система анализирует топовые результаты, чтобы определить, есть ли среди них ресурсы, имеющие положительную полезность для данного Типа Устройства.
   • Если НЕТ: Перейти к шагу 6 (Не корректировать). Это предотвращает понижение ресурсов с отрицательной полезностью, если нет лучших альтернатив.
   • Если ДА: Перейти к шагу 3.
3. Проверка навигационного интента: Система определяет, является ли запрос Navigational Query.
   • Если ДА: Перейти к шагу 6 (Не корректировать). Это защищает явное желание пользователя перейти на конкретный сайт.
   • Если НЕТ: Перейти к шагу 4.
4. Проверка доминирующего интента: Система определяет, имеет ли запрос Dominant Intent, который не связан с найденными ресурсами с положительной полезностью.
   • Если ДА: Перейти к шагу 6 (Не корректировать). Это защищает четкий интент пользователя от замещения нерелевантными интенту ресурсами.
   • Если НЕТ: Перейти к шагу 5.
5. Корректировка результатов: Система применяет корректировку. Ресурсы с Positive Utility повышаются (boosted), а ресурсы с Negative Utility могут быть понижены (demoted) относительно друг друга.
6. Вывод результатов: Система предоставляет пользователю итоговый набор результатов.

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

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

Патент явно упоминает использование следующих данных для определения полезности и интента:

• Пользовательские факторы: Device Type Identifier — критически важные данные, определяющие контекст для корректировки.
• Поведенческие факторы: History Logs (журналы истории). Используются для определения полезности ресурсов (например, высокий selection rate или CTR для ресурса на определенном типе устройства указывает на положительную полезность) и для определения навигационных запросов (Navigation Metrics).
• Контентные факторы: Анализ контента ресурса на наличие специфичных ключевых слов (например, "droid", "Android OS Help").
• Технические факторы: Манифесты нативных приложений (которые явно указывают совместимость с ОС). Категоризация сайтов (например, сайты, хостящие приложения только для одной платформы). Использование технологий типа Flash (отрицательная полезность на мобильных).
• Структурные факторы (Entity Mapping): Связь ресурса с сущностями, специфичными для устройства.

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

• Device Utility Score: Основная метрика. Может быть абсолютной (например, +1, -1, 0) или масштабированной. Рассчитывается офлайн на основе факторов, перечисленных выше.
• Метрики навигации (Navigation Metrics): Используются для определения Navigational Query. Включают CTR, пропорцию трафика на конкретные ресурсы (proportion of search result selection traffic), перекрестные ссылки (cross linkage) между ресурсами в выдаче.
• Метрики доминирующего интента: Основаны на анализе терминов запроса, указывающих на конкретный субъект недвусмысленным образом. Также проверяется соответствие топовых ресурсов (например, в Топ-K) этому интенту.

1. Контекст устройства как сильный, но условный фактор ранжирования: Google активно использует тип устройства для модификации выдачи, но применение этого фактора зависит от выполнения строгих условий.
2. Приоритет интента над полезностью устройства: Намерение пользователя имеет высший приоритет. Если запрос является навигационным (Navigational Query) или имеет четкий доминирующий интент (Dominant Intent), система блокирует корректировку на основе полезности для устройства, чтобы не нарушить выполнение основной задачи пользователя.
3. Защитный механизм от необоснованных понижений: Требование обязательного наличия ресурсов с положительной полезностью (Positive Utility) для активации корректировки является ключевым защитным механизмом. Это предотвращает понижение ресурсов с отрицательной полезностью, если в выдаче нет лучших альтернатив для данного устройства.
4. Многофакторная оценка полезности: Device Utility Score определяется не только технической совместимостью, но и анализом контента и агрегированными данными о поведении пользователей с разных типов устройств.
5. Зависимость от предварительной классификации: Эффективность системы зависит от качества офлайн-процессов классификации ресурсов по их полезности и классификации запросов по интентам.

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

• Четкое сигнализирование о совместимости платформ: Если контент или ПО предназначено для конкретных устройств или ОС (например, Android или iOS), необходимо явно указывать это в контенте, заголовках и метаданных. Это поможет Google корректно определить Device Utility Score.
• Оптимизация пользовательского опыта (UX/UI) для целевых устройств: Обеспечение высокого качества UX на мобильных устройствах критически важно. Ресурсы, которые хорошо работают на конкретном типе устройства, с большей вероятностью получат Positive Utility, в том числе на основе поведенческих сигналов.
• Разделение платформо-специфичного контента: При наличии контента для разных платформ рекомендуется разделять его на разные URL или четко структурировать внутри страницы, чтобы облегчить системе категоризацию полезности.
• Для продвижения приложений (ASO/App SEO): Убедитесь, что манифесты приложений корректны. Используйте App Indexing и предоставляйте корректные глубинные ссылки (Deep Links). Оптимизируйте страницы в сторах.

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

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

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

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

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

Сценарий 1: Поиск приложения (Корректировка активирована)

1. Запрос: "лучшее приложение для заметок" с устройства Android.
2. Анализ: В выдаче есть приложения для Android (Positive Utility) и приложения только для iOS (Negative Utility). Запрос общий (не навигационный, нет доминирующего интента).
3. Действие системы: Условия выполнены. Система активирует корректировку.
4. Результат: Приложения для Android получают бустинг, приложения только для iOS понижаются в выдаче на этом устройстве.

Сценарий 2: Навигационный запрос (Корректировка заблокирована)

1. Запрос: "iTunes" с устройства Android.
2. Анализ: Сайт iTunes имеет отрицательную полезность (Negative Utility) для Android. Однако запрос классифицирован как Navigational Query.
3. Действие системы: Условие навигационности блокирует корректировку.
4. Результат: Официальный сайт iTunes ранжируется высоко, несмотря на его низкую полезность для Android, так как интент пользователя был приоритетнее.

Сценарий 3: Отсутствие положительных альтернатив (Корректировка заблокирована)

1. Запрос: Поиск узкоспециализированного ПО с устройства Linux.
2. Анализ: В выдаче есть только ПО для Windows (Negative Utility для Linux). Ресурсов для Linux (Positive Utility) не найдено.
3. Действие системы: Отсутствие Positive Utility блокирует корректировку.
4. Результат: ПО для Windows не понижается, так как система предполагает, что эта информация может быть полезна пользователю при отсутствии лучших альтернатив для его устройства.