Как Google объединяет локальные, веб- и ASO-результаты в унифицированном поиске на устройствах (Android/ChromeOS)

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

Actionable User Interface Element (Активный элемент пользовательского интерфейса)

Элемент UI, связанный с результатом поиска, который позволяет выполнить действие напрямую из выдачи (например, кнопка "Video Call" для контакта, "Install application" для приложения из магазина).

Application Launcher (Лаунчер приложений)

Интерфейс операционной системы (например, в Android или ChromeOS), который предоставляет доступ к приложениям и включает унифицированное поле поиска.

Data Store (Хранилище данных)

Источник данных для поисковой системы. Может быть локальным (файловая система, контакты) или онлайновым (веб-индекс, база данных App Store).

First Portion / Second Portion (Первая часть / Вторая часть сортировки)

Логическое разделение результатов в запатентованном методе сортировки. First Portion содержит лучшие результаты от каждого источника для обеспечения разнообразия. Second Portion содержит остальные результаты, отсортированные по общему рейтингу.

Local Search Engine (Локальная поисковая система)

Поисковый движок, который ищет данные, хранящиеся непосредственно на устройстве пользователя (Local Data Store).

Online Search Engine (Онлайн поисковая система)

Поисковый движок, который ищет данные во внешних хранилищах (Online Data Store).

Predetermined amount of time (Предопределенное количество времени)

Таймаут. Максимальное время, в течение которого система ожидает результатов от поисковых движков.

Ranking Score (Оценка ранжирования)

Числовая оценка релевантности результата, предоставляемая конкретной поисковой системой.

Threshold Number (Пороговое количество)

Заранее определенное количество результатов (например, 1 или 2), которое гарантированно включается в First Portion выдачи от каждого источника.

Zero Query (Нулевой запрос)

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

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

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

1. Система получает запрос в интерфейсе.
2. Запрос отправляется нескольким поисковым системам. Явно указаны как минимум: поиск локальных файлов, поиск локальных приложений, поиск приложений в магазине (App Store).
3. Система получает результаты.
4. Сортировка (Ядро изобретения): Результаты сортируются так, что финальная выдача состоит из двух частей:
   • Первая часть (First portion): Включает как минимум пороговое количество (threshold number) результатов от каждого поискового движка, предоставившего результаты.
   • Вторая часть (Second portion): Включает оставшиеся результаты от всех движков, агрегированные и отсортированные согласно их ranking score.
5. Представление: Отображение первой и второй части. Если результат является запускаемым приложением, он ассоциируется с активным элементом UI (actionable user interface element) для его запуска (или установки).

Этот алгоритм смешивания гарантирует разнообразие (diversity) выдачи. Он не позволяет одному источнику (например, веб-поиску) полностью доминировать в топе, даже если его результаты имеют более высокие Ranking Scores, за счет принудительного включения лучших результатов из других источников.

Claim 8 (Независимый пункт): Описывает схожий процесс, фокусируясь на временных ограничениях.

1. Получение взаимодействия с полем поиска.
2. Отправка запроса нескольким поисковым системам.
3. Получение результатов в течение предопределенного времени (predetermined amount of time). Это подчеркивает требование низкой задержки (low latency) и наличие таймаута.
4. Сортировка по двухэтапному механизму (как в Claim 1).

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

Патент описывает архитектуру поиска на уровне клиентского устройства (ОС или браузера), а не работу основного веб-поиска Google.

METASEARCH – Метапоиск и Смешивание (Universal Search & Blending)
Это основная область применения. Система на устройстве действует как метапоисковый движок (федеративный поиск). Она оркестрирует запросы к различным вертикалям (локальным индексам и внешним API) и реализует логику смешивания (Blending) для создания унифицированной выдачи.

RERANKING – Переранжирование (Reranking & Twiddlers)
После получения результатов применяется запатентованный алгоритм сортировки. Это переранжирование (Twiddler), цель которого — обеспечить разнообразие источников (Diversity) в финальной выдаче лаунчера.

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

• Запрос пользователя (текстовая строка или Zero Query).
• Результаты от Local Search Engines с их Ranking Scores.
• Результаты от Online Search Engines с их Ranking Scores.

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

• Единый отсортированный список разнородных результатов (файлы, контакты, приложения, веб-страницы), структурированный (First Portion + Second Portion).
• Actionable User Interface Elements, ассоциированные с результатами.

На что влияет

• Конкретные типы контента: Влияет на относительную видимость всех типов контента в поиске устройства:
  • Локальные данные (файлы, контакты, настройки).
  • Установленные приложения и контент внутри них (App Content).
  • Приложения в App Store (критично для ASO).
  • Веб-страницы (SEO).
• Специфические запросы: Влияет на все запросы в унифицированном интерфейсе. Особенно заметно при запросах с неоднозначным интентом (например, запрос "Калькулятор" может выдать установленное приложение, приложение в магазине и статью в Википедии).

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

• Условия работы: Алгоритм активируется при каждом взаимодействии пользователя с унифицированным полем поиска (Application Launcher или Omnibox).
• Триггеры активации: Ввод символов в поле поиска или фокус на поле поиска (активация Zero Query).
• Временные рамки: Применяется в реальном времени. Существует жесткое ограничение по времени (predetermined amount of time или таймаут), в течение которого поисковые системы должны вернуть результаты.

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

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

1. Получение запроса: Система регистрирует взаимодействие пользователя с полем поиска.
2. Параллельная отправка: Запрос отправляется одновременно нескольким поисковым системам (локальным и онлайн). Это может происходить через Launcher Search API.
3. Установка таймаута: Задается предопределенное время ожидания ответов (predetermined amount of time).
4. Сбор результатов: Система собирает результаты от различных поисковых систем. Каждый результат имеет Ranking Score от источника. Движки, не ответившие до таймаута, игнорируются.
5. Сортировка (Фаза 1 - Гарантированное разнообразие): Система формирует First Portion выдачи. От каждого ответившего источника отбирается пороговое количество (Threshold Number) лучших результатов (например, Топ-2).
6. Сортировка (Фаза 2 - Глобальная релевантность): Все оставшиеся результаты от всех источников объединяются в общий пул. Они сортируются на основе их Ranking Score (возможно, после нормализации). Это формирует Second Portion выдачи.
7. Формирование выдачи: First Portion и Second Portion объединяются.
8. Добавление активных элементов: Система определяет тип результата и добавляет соответствующие Actionable User Interface Elements (например, кнопки установки/открытия).
9. Отображение: Унифицированная выдача отображается пользователю в интерфейсе лаунчера.

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

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

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

• Контентные факторы:
  • Для локального поиска: Названия файлов, метаданные контактов, названия установленных приложений.
  • Для ASO: Названия приложений, описания, метаданные из магазина приложений.
  • Для Веб-поиска (SEO): Данные, обработанные основным веб-поиском (заголовки, сниппеты).
• Пользовательские факторы: История взаимодействий пользователя. Упоминается использование сохраненной информации об устройстве (stored information related to the computing device) для генерации результатов при Zero Query.

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

• Ranking Score: Оценка релевантности, предоставляемая каждым отдельным поисковым движком. Патент не уточняет, как эти оценки рассчитываются, но они используются для сортировки на Этапе 2.
• Threshold Number: Статическая конфигурационная метрика. Определяет, сколько результатов от каждого источника гарантированно попадает в первую часть выдачи (например, порог = 2).
• Predetermined amount of time: Таймаут (например, 500 мс, 1 секунда). Определяет максимальное время ожидания ответа от поисковых систем.

1. Клиентский Универсальный Поиск: Патент описывает не алгоритмы веб-поиска Google, а механизм Универсального Поиска (Universal Search/Blending), реализованный на стороне клиента (в ОС Android/ChromeOS или браузере).
2. Гарантированное Разнообразие (Diversity by Design): Ключевое изобретение — это двухэтапный алгоритм смешивания. Он принудительно обеспечивает разнообразие источников, показывая Топ-N результатов от каждого источника (First Portion), прежде чем сортировать остальные по глобальной релевантности (Second Portion).
3. Прямая Конкуренция SEO, ASO и локального контента: В этом интерфейсе веб-результаты (SEO) и результаты из магазинов приложений (ASO) напрямую конкурируют за видимость как друг с другом, так и с локальными данными устройства.
4. Критическая важность ASO: Механизм обеспечивает видимость приложений в основном поиске устройства. Это подчеркивает критическую важность оптимизации приложений (ASO) и индексации их контента (App Indexing).
5. Требование к скорости: Существует жесткий таймаут (predetermined amount of time) для получения результатов. Медленные источники могут быть проигнорированы.

ВАЖНО: Патент имеет минимальное практическое применение для традиционного веб-SEO. Он ориентирован на пользовательский интерфейс устройства и критически важен для ASO (App Store Optimization) и разработчиков приложений.

Best practices (Фокус на ASO и Экосистему)

• (ASO) Оптимизация метаданных приложений: Названия и описания приложений должны быть оптимизированы под релевантные запросы. Цель — попасть в Threshold Number лучших результатов от магазина приложений, чтобы гарантированно отобразиться в First Portion унифицированного поиска устройства.
• (ASO/Разработка) Реализация индексации контента (App Indexing): Необходимо обеспечивать индексацию контента внутри приложения. Патент упоминает поиск по контенту приложений. Это позволяет пользователям находить конкретную информацию внутри приложения прямо из лаунчера.
• (Общая стратегия) Экосистемный подход: Развивайте присутствие бренда как в вебе (SEO), так и в виде приложений (нативные, PWA). Это увеличивает количество источников, в которых ваш контент может быть найден, и повышает шансы на видимость благодаря механизму гарантированного разнообразия.
• (SEO) Фокус на Топ-позиции в Веб-поиске: Чтобы веб-результат попал в унифицированную выдачу устройства, он должен занимать лидирующие позиции в основном веб-поиске. Только лучшие веб-результаты имеют шанс быть включенными в Threshold Number от веб-источника.

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

• Игнорирование ASO: Фокусировка исключительно на веб-SEO и игнорирование оптимизации приложений приводит к потере видимости в унифицированном поиске на мобильных устройствах, где пользователи часто ищут через лаунчер.
• (Для веб-SEO) Искать инсайты по ранжированию сайтов: Пытаться применить описанные механизмы сортировки к ранжированию веб-сайтов в google.com. Патент описывает другую среду и другие задачи.

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

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

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

Сценарий: Поиск на устройстве Android по запросу "Такси"

Предположим, Threshold Number = 1.

1. Запрос: Пользователь вводит "Такси" в лаунчере Android.
2. Параллельный поиск: Запрос отправляется: Локальному поиску, Google Play Store (ASO), Google Web Search (SEO).
3. Сбор результатов (Топ-1 от каждого):
   • Локальный поиск: Приложение "Uber" (установлено).
   • Google Play: Приложение "Bolt" (доступно для установки).
   • Web Search: Веб-сайт "Яндекс Такси".
4. Сортировка (Фаза 1): В первую часть выдачи (First Portion) попадают все три результата, так как каждый является лучшим в своем источнике.
5. Сортировка (Фаза 2): Оставшиеся результаты (например, другие приложения такси из Google Play и другие веб-сайты) сортируются ниже (Second Portion).
6. Финальная выдача (Пример):
   1. Uber [Открыть приложение]
   2. Bolt [Установить приложение]
   3. Яндекс Такси [Веб-страница]
   4. [Другие результаты, отсортированные по релевантности]

Вывод: Если бы компания "Bolt" не оптимизировала свое приложение (ASO) или сайт "Яндекс Такси" не был в топе веб-поиска (SEO), они бы не появились в гарантированной первой части выдачи.