Как Google индексирует действия и контент внутри приложений для универсального поиска на устройстве (Cross-App Search)

Описание

Какую задачу решает

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

Что запатентовано

Запатентована система для создания и использования Central on-device repository (центрального репозитория на устройстве). Эта система позволяет различным установленным приложениям «жертвовать» (donate) структурированные данные о поисковых запросах пользователя, его действиях и просмотренном контенте в этот локальный репозиторий. Затем система предоставляет Unified Interface (унифицированный интерфейс), позволяющий выполнять кросс-приложенческий поиск (Cross-App Search) по этому репозиторию.

Как это работает

Механизм работает следующим образом:

• Сбор данных (Donation): Когда пользователь выполняет поиск или действие в приложении (например, слушает песню в музыкальном приложении), это приложение генерирует и передает search-based content или activity-based content в Central on-device repository. Эти данные включают идентификатор контента, поисковый запрос и ссылку для запуска приложения в нужном состоянии.
• Локальное индексирование: Система обрабатывает полученные данные и создает запись (entry) в локальном репозитории.
• Поиск: Пользователь вводит запрос через Unified Interface (например, системную строку поиска) или через Automated Assistant.
• Результаты: Система ищет совпадения в локальном репозитории и отображает результаты из разных приложений.
• Выполнение (Fulfillment): При выборе результата система запускает соответствующее приложение в определенном состоянии (например, сразу открывает нужную песню или страницу книги).

Актуальность для SEO

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

Важность для SEO

Влияние на традиционное веб-SEO (продвижение сайтов в google.com) минимальное (1/10). Патент описывает исключительно инфраструктуру для локального поиска на устройстве (on-device search) и взаимодействия между приложениями. Он не содержит информации об алгоритмах ранжирования веб-страниц. Однако он имеет значение для специалистов, занимающихся App Store Optimization (ASO) и стратегиями индексации приложений (App Indexing), поскольку описывает, как контент из приложений становится доступным для системного поиска.

Детальный разбор

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

Activity-based content (Контент, основанный на активности)

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

Automated Assistant (Автоматизированный Ассистент)

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

Central on-device repository (Центральный репозиторий на устройстве)

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

Content Identifier / Entity Identifier (Идентификатор контента / Сущности)

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

Cross-app search query (Кросс-приложенческий поисковый запрос)

Запрос, сгенерированный на основе ввода пользователя в Unified Interface и используемый для поиска по Central on-device repository, охватывая данные из нескольких приложений.

Donated content (Переданный контент)

Search-based или activity-based content, который приложение добровольно предоставляет системе для включения в Central on-device repository.

Particular State (Определенное состояние приложения)

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

Personalized or Public Indication (Индикация персонализированного или публичного контента)

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

Search-based content (Контент, основанный на поиске)

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

Unified Interface (Унифицированный интерфейс)

Системный поисковый интерфейс (например, главная строка поиска на смартфоне), который не зависит от конкретных приложений и обеспечивает доступ к Central on-device repository.

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

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

1. Система получает search-based content от первого приложения, основанный на предыдущем поиске пользователя внутри этого приложения.
2. Система обрабатывает этот контент и создает первую запись (first entry) в Central on-device repository. (Репозиторий также содержит записи от других приложений).
3. Система получает поисковый запрос от пользователя через Unified Interface (независимый от приложений).
4. Система ищет в Central on-device repository записи, релевантные запросу.
5. При обнаружении, что первая запись релевантна, система генерирует интерфейсный элемент на ее основе и отображает его в Unified Interface для выбора пользователем.

Claim 2 и 3 (Зависимые): Детализируют процесс выполнения (fulfillment).

1. В ответ на выбор пользователем интерфейсного элемента, система запускает первое приложение в particular state.
2. Этот particular state включает отображение конкретного пользовательского интерфейса приложения, который показывает контент (in-app content), связанный с исходным поиском.

Claim 9 (Независимый пункт): Описывает интеграцию с голосовым ассистентом.

1. Процесс аналогичен Claim 1 (сбор и индексация контента от приложений).
2. Система получает голосовое высказывание (spoken utterance), содержащее поисковый запрос, через Automated Assistant.
3. В ответ на это система (i) ищет в Central on-device repository и (ii) вызывает отображение Unified Interface.
4. При обнаружении релевантной записи система отображает соответствующий интерфейсный элемент в Unified Interface.

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

1. При получении и индексации контента от приложения система сохраняет indication indicating whether in-app content […] is personalized or public (индикацию того, является ли контент персонализированным или публичным).
2. После выполнения поиска через Unified Interface и обнаружения нескольких релевантных записей (subset of entries).
3. Система ранжирует эти записи, основываясь, по крайней мере, на этой индикации (personalized or public).
4. Система генерирует и отображает интерфейсные элементы на основе отранжированного списка.

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

Этот патент описывает инфраструктуру операционной системы устройства (например, Android) и не вписывается напрямую в архитектуру Google Web Search (поиск в интернете). Он описывает параллельную систему локального поиска.

INDEXING (Локальное индексирование)
Процесс сбора donated content от приложений и создание Central on-device repository является формой локального индексирования активности пользователя и контента приложений.

QUNDERSTANDING (Локальное понимание запросов)
Обработка запроса, введенного пользователем через Unified Interface или произнесенного через Automated Assistant (включая ASR и NLU для голосовых запросов).

RANKING (Локальное ранжирование)
Сортировка результатов, найденных в Central on-device repository. Патент явно упоминает использование сигнала personalized or public для ранжирования (Claim 17).

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

• Search-based content и Activity-based content, переданные приложениями.
• Идентификаторы контента (Content Identifiers).
• Ссылки для запуска приложений (Fulfillment links/Shortcuts).
• Временные метки доступа к контенту.
• Индикация personalized or public.
• Запрос пользователя (текстовый или голосовой).

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

• Интерфейсные элементы (результаты поиска), отображаемые в Unified Interface.
• Команды для запуска приложений в particular state (Deep Linking).

На что влияет

• Типы контента: Влияет исключительно на контент и действия внутри установленных мобильных приложений (песни, плейлисты, книги, сообщения, задачи, элементы управления умным домом и т.д.). Не влияет на ранжирование веб-страниц, статей или товаров в интернете.
• Специфические запросы: Влияет на запросы, направленные на повторный доступ к ранее использованному контенту или возобновление действий (например, «продолжить читать [книга]» или поиск по названию песни, которая недавно проигрывалась).

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

• Триггеры для индексации: Алгоритм сбора данных активируется, когда пользователь взаимодействует с приложением. Приложение может передать данные: (i) сразу после получения поискового запроса от пользователя; (ii) после того, как пользователь выбрал результат поиска; или (iii) после того, как пользователь взаимодействовал с контентом в течение определенного времени (predetermined amount of time).
• Триггеры для поиска: Алгоритм поиска активируется каждый раз, когда пользователь использует Unified Interface или обращается к Automated Assistant с запросом, который может быть выполнен локально.

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

Процесс А: Сбор и индексация данных (Фоновый режим)

1. Активность пользователя: Пользователь выполняет поиск или действие внутри Приложения А (например, ищет «Wheels on the bus» в музыкальном приложении).
2. Генерация контента в приложении: Приложение А определяет релевантный контент и пользователь взаимодействует с ним (например, слушает песню).
3. Генерация данных для передачи: Приложение А генерирует пакет данных (search-based content), включающий исходный запрос, Content Identifier песни, ссылку для ее запуска и флаг (personalized или public).
4. Передача (Donation): Приложение А передает этот пакет в систему.
5. Обработка и хранение: Система обрабатывает пакет и создает запись (entry) в Central on-device repository, связывая ее с Приложением А.

Процесс Б: Поиск и выполнение (Реальное время)

1. Получение запроса: Система получает запрос от пользователя через Unified Interface или Automated Assistant (например, пользователь вводит «Wheels o»).
2. Поиск в репозитории: Система выполняет поиск записей в Central on-device repository, соответствующих запросу.
3. Определение релевантных записей: Система идентифицирует одну или несколько релевантных записей из разных приложений (например, из музыкального приложения и приложения для чтения книг).
4. Ранжирование (Если применимо, Claim 17): Система ранжирует найденные записи. Ранжирование может основываться на индикации personalized vs public (например, отдавая предпочтение персонализированному контенту) и/или других факторах (например, времени последнего доступа).
5. Генерация интерфейса: Система генерирует интерфейсные элементы для топовых результатов.
6. Отображение: Система отображает эти элементы в Unified Interface.
7. Выбор пользователя: Пользователь выбирает один из элементов.
8. Выполнение (Fulfillment): Система использует сохраненную ссылку (link/shortcut) для запуска соответствующего приложения в particular state (например, музыкальное приложение открывается сразу на экране воспроизведения песни).

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

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

Патент фокусируется на данных, передаваемых приложениями, а не на факторах веб-ранжирования.

• Контентные факторы (In-App): Текст поисковых запросов, выполненных пользователем в приложении (полных или частичных). Названия или описания контента/действий (например, название песни, имя автора).
• Технические факторы (In-App):
  • Content Identifier (Идентификатор сущности): Ключевой элемент для идентификации контента внутри приложения.
  • Application Identifier: Идентификатор приложения, передавшего данные.
  • Fulfillment Link/Shortcut: Ссылка или команда, которая позволяет запустить приложение в определенном состоянии (Deep Link).
• Временные факторы: Content-accessing timestamp (временная метка доступа к контенту) – время, когда пользователь взаимодействовал с контентом.
• Поведенческие факторы (In-App): Данные о прогрессе (например, процент прочтения книги, момент остановки песни).

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

• Relevance Match (Соответствие релевантности): Определение того, соответствует ли запись в репозитории запросу пользователя в Unified Interface.
• Personalized/Public Indication (Индикация Персонализации): Метрика, определяемая самим приложением перед передачей данных. Патент предполагает, что приложение может определить это на основе частоты (frequency) запроса. Если частота превышает порог (frequency threshold), контент может быть помечен как public; если нет – как personalized.
• Ranking Score (Оценка ранжирования на устройстве): Вычисляется для результатов поиска в Unified Interface. Согласно Claim 17, эта оценка основывается как минимум на Personalized/Public Indication (предположительно, персонализированный контент ранжируется выше).

Выводы

1. Фокус на локальном поиске и интеграции приложений: Патент описывает систему, которая функционирует исключительно на устройстве пользователя (on-device) для улучшения поиска контента внутри установленных приложений. Это инфраструктура уровня операционной системы, а не веб-поиска.
2. Активное участие приложений (Donation): Система зависит от того, что разработчики приложений реализуют функционал для передачи (donation) структурированных данных (запросов, действий, идентификаторов контента) в центральный локальный репозиторий.
3. Deep Linking как основа выполнения: Ключевая ценность для пользователя заключается в возможности не просто найти контент, но и немедленно запустить приложение в нужном состоянии (particular state) с помощью сохраненных ссылок или ярлыков.
4. Интеграция с Ассистентом: Automated Assistant может инициировать поиск по этому локальному репозиторию в ответ на голосовые команды, выступая как альтернатива ручному вводу в Unified Interface.
5. Локальное ранжирование и персонализация: Система использует сигналы, предоставляемые приложениями, для ранжирования результатов. Явно указано использование флага personalized vs public, что позволяет системе отдавать приоритет контенту, который приложение считает важным для конкретного пользователя.
6. Отсутствие связи с Web SEO: Патент не содержит механизмов, влияющих на сканирование, индексирование или ранжирование веб-сайтов в поиске Google. Выводы для SEO-специалистов, работающих с веб-сайтами, отсутствуют.

Практика

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

Патент не дает практических рекомендаций для SEO веб-сайтов. Однако для специалистов, связанных с разработкой и продвижением мобильных приложений (ASO, App Indexing), можно сделать следующие выводы:

• Реализация API для индексации действий: Необходимо активно использовать соответствующие API платформы (например, Android Intents, Shortcuts) для передачи (donation) ключевых действий пользователя, поисковых запросов и контента в Central on-device repository. Это позволит приложению появляться в результатах системного поиска и Ассистента.
• Структурирование контента и Entity Identification: Обеспечить, чтобы ключевой контент внутри приложения имел четкие Content Identifiers (Entity ID). Это необходимо для точной идентификации контента системой поиска.
• Реализация надежного Deep Linking: Критически важно реализовать обработку входящих ссылок (Deep Links), чтобы приложение корректно запускалось в particular state при выборе пользователем результата поиска в Unified Interface.
• Определение персонализированного контента: Использовать логику внутри приложения для определения того, какой контент является personalized (важным и часто используемым пользователем), и передавать соответствующий флаг системе. Согласно патенту, это может повысить ранжирование этого контента в локальном поиске.

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

• Игнорирование индексации приложений: Отказ от реализации API для передачи данных в локальный индекс приведет к тому, что контент приложения будет невидим для системного поиска и Ассистента, ухудшая пользовательский опыт.
• Некорректная обработка Deep Links: Если приложение передает данные в индекс, но не обрабатывает входящие ссылки корректно, пользователь будет попадать на главный экран приложения вместо конкретного контента, что противоречит цели изобретения.
• Передача только публичного контента: Передача всего контента как public без учета персонализации может привести к потере позиций в локальном поиске, если система отдает приоритет personalized контенту.

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

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

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

Сценарий: Возобновление чтения книги через системный поиск

1. Действие: Пользователь читал электронную книгу «Wheels On» в приложении Book App и остановился на 125 странице.
2. Donation: Приложение Book App передает в Central on-device repository запись, содержащую: Название («Wheels On»), Content Identifier книги, прогресс (Page 125/268), и Deep Link для открытия книги на этой странице. Оно также помечает контент как personalized.
3. Поиск: Позже пользователь вводит «Wheels O» в системной строке поиска (Unified Interface).
4. Результат: Система находит запись от Book App и запись от Music App (где пользователь слушал песню). Так как запись от Book App помечена как personalized, она может быть показана выше.
5. Выполнение: Пользователь нажимает на результат от Book App. Система запускает Book App, используя Deep Link, и приложение открывается сразу на 125 странице.

Вопросы и ответы