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

Описание

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

Патент решает проблему фрагментации информации на персональных устройствах (смартфонах, планшетах). Пользователи выполняют задачи (например, планирование поездки), используя множество разных нативных приложений (бронирование, карты, мессенджеры, заметки). Стандартный поиск затрудняет повторное нахождение всей информации, связанной с конкретной задачей, так как она разбросана по изолированным приложениям. Изобретение направлено на организацию, поиск и извлечение контента приложений путем объединения связанной активности в topics (темы) или tasks (задачи).

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

Запатентована локальная поисковая система, реализованная непосредственно на устройстве пользователя (on a user device). Эта система получает данные от нативных приложений (контент и контекст использования), индексирует их локально и использует векторные представления (cluster feature-vector representations) для идентификации связанных действий пользователя в разных приложениях. Эти действия кластеризуются в overarching topics или tasks, которые затем представляются пользователю в интерфейсе поиска.

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

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

• Сбор данных: Нативные приложения генерируют наборы данных, включающие контент (текст, сущности) и контекст (время использования, другие открытые приложения, поля данных, популярность приложения).
• Генерация векторов: Vector Generation Unit обрабатывает эти данные и создает cluster feature-vector — числовое представление контента и контекста.
• Локальное индексирование: Векторы сохраняются в локальном индексе (search engine index) на устройстве.
• Обработка запроса: При поиске (включая zero-input query) система генерирует query vector на основе запроса и текущего контекста пользователя (user context).
• Поиск сходства и кластеризация: Vector Similarity Unit находит похожие векторы в индексе и группирует их в задачи или темы, используя алгоритмы кластеризации.
• Отображение результатов: Система предлагает пользователю выявленные задачи в виде кликабельных элементов (selectable controls). При выборе задачи отображаются релевантные результаты из всех задействованных приложений, сгруппированные по приложению-источнику.

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

Высокая для мобильных экосистем и локального поиска. Технология напрямую связана с функциями поиска по устройству (например, Android Personal Search, Apple Spotlight), которые становятся все более важными для повторного вовлечения пользователей (re-engagement) и удобства использования ОС. Патент описывает сложный механизм использования контекста и векторного поиска для понимания кросс-приложенческой активности.

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

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

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

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

Cluster Feature-Vector Representation (Векторное представление кластерных признаков)

Числовое представление набора данных (контента и контекста) из нативного приложения. Оно квантифицирует отношение между извлеченными признаками и установленным словарем (cluster feature-vector vocabulary).

Context Information (Контекстная информация)

Данные, связанные с взаимодействием пользователя с приложением. Включают: поля контента (например, «Кому:», «Тема:»), активность пользователя, время создания/взаимодействия, количество взаимодействий, популярность приложения, а также данные о других приложениях, использовавшихся в той же сессии.

Global Language Model (Глобальная языковая модель)

Внешняя модель (доступная через Cloud Interface Unit), используемая для определения отношений между векторами, например, для идентификации синонимов или связанных концепций (например, что «Пьяцца Навона» связана с «Италия»).

Native Application Content (Контент нативного приложения)

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

Overarching Topic / Task (Всеобъемлющая тема / Задача)

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

Query Vector (Вектор запроса)

Числовое представление, сгенерированное на основе поискового запроса пользователя И текущего контекста пользователя (user context).

Vector Similarity Unit (Блок определения сходства векторов)

Компонент системы, который сравнивает Query Vector с индексированными векторами и использует алгоритмы кластеризации для группировки похожих векторов в задачи/темы.

Zero-Input Query (Запрос с нулевым вводом)

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

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

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

1. Поисковая система, реализованная на устройстве пользователя, получает данные от нескольких нативных приложений. Данные включают (i) контент и (ii) контекстную информацию.
2. Система индексирует эти данные локально для генерации index data (в описании патента это cluster feature-vector representations).
3. Система идентифицирует множество задач (tasks) из index data.
4. Ключевое определение: Каждая задача связана с всеобъемлющей темой (overarching topic) пользовательской активности, распределенной по двум или более приложениям, где действия в совокупности направлены на выполнение этой задачи.
5. Система предоставляет интерфейс с кликабельными элементами управления (selectable controls), идентифицирующими эти задачи.
6. При выборе элемента управления система генерирует страницу результатов поиска (search results page).
7. Результаты в SERP относятся к выбранной задаче и организованы в отдельные группы для соответствующих двух или более приложений, сгруппированные по тому, какое приложение сгенерировало результат.

Claims 2-5 (Зависимые): Детализируют состав index data (индексированных данных).

• Claim 2: Данные включают слова, извлеченные из текста контента.
• Claim 3: Данные включают информацию, указывающую на поля (fields), связанные с контентом (например, «Кому:», «Тема:»).
• Claim 4: Данные включают информацию о популярности (popularity) нативных приложений на устройстве.
• Claim 5: Данные включают информацию о приложениях, которые были доступны в течение той же сессии (same session), что и сгенерированный набор данных.

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

Этот патент описывает архитектуру локальной поисковой системы на устройстве (например, в рамках ОС Android), а не систему веб-поиска Google.com.

INDEXING – Индексирование и извлечение признаков (Локальное)
Основной этап применения. Система работает локально на устройстве.

1. Сбор данных: Получение контента и контекста от нативных приложений.
2. Извлечение признаков (Feature Extraction): Vector Generation Unit извлекает признаки из текста, сущностей, полей контента, а также контекстные сигналы (использование приложений, время, сессии).
3. Генерация векторов: Создание Cluster Feature-Vector Representations.
4. Индексирование: Сохранение векторов в локальном Search Engine Index.

QUNDERSTANDING – Понимание Запросов (Локальное)
Система интерпретирует локальный поисковый запрос (или zero-input query) и текущий контекст пользователя для генерации Query Vector.

RANKING – Ранжирование (Локальное)

1. Отбор кандидатов: Vector Similarity Unit сравнивает Query Vector с векторами в индексе, используя метрики расстояния (например, cosine distance function).
2. Кластеризация: Система группирует похожие векторы в tasks или topics. Этот процесс может происходить в реальном времени или асинхронно в фоновом режиме. Система может использовать внешние данные (Global Language Model, App Content Graph) через Cloud Interface Unit для улучшения кластеризации.
3. Ранжирование задач: Выявленные задачи ранжируются на основе таких факторов, как свежесть контента, объем контента в кластере и частота доступа.

METASEARCH – Метапоиск и Смешивание (Локальное)
User Interface Generation Unit формирует локальную SERP. Результаты из разных приложений смешиваются, но при этом четко группируются по приложению-источнику (согласно Claim 1).

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

• Контент нативных приложений (текст, сущности).
• Контекстная информация (поля, время, популярность приложений, история и сессии использования).
• Локальный поисковый запрос пользователя (или его отсутствие).
• Текущий контекст пользователя.

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

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

На что влияет

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

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

• Триггеры активации: Активируется при использовании функции поиска по устройству.
• Фоновые процессы: Индексирование и генерация векторов могут происходить непрерывно в реальном времени или в пакетном режиме (batch processing) для экономии ресурсов (например, когда устройство заряжается). Кластеризация также может выполняться асинхронно.
• Условия применения: Применяется, когда пользовательская активность распределена по двум или более приложениям и может быть объединена общей темой или задачей (Claim 1).

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

Процесс А: Индексирование (Фоновый режим или реальное время)

1. Получение данных: Система получает набор данных от нативного приложения, содержащий контент и контекстную информацию.
2. Извлечение признаков: Извлекаются признаки из контента (слова, сущности, поля) и контекста (популярность приложения, время взаимодействия, совместно используемые приложения).
3. Генерация вектора: Создается Cluster Feature-Vector Representation на основе извлеченных признаков и словаря признаков (feature-vector vocabulary).
4. Сохранение: Вектор сохраняется в локальном индексе поисковой системы.

Процесс Б: Обработка запроса (Реальное время)

1. Получение ввода: Система получает поисковый запрос (или zero-input query) и текущий контекст пользователя.
2. Генерация Query Vector: Создается вектор запроса на основе ввода и контекста.
3. Поиск сходства: Vector Similarity Unit сравнивает Query Vector с векторами в индексе и определяет набор похожих векторов.
4. Идентификация задач (Кластеризация): Набор похожих векторов анализируется для выявления групп (кластеров), представляющих задачи или темы, охватывающие несколько приложений. Может использоваться помощь Global Language Model.
5. Ранжирование задач: Выявленные задачи ранжируются (например, по свежести или объему контента).
6. Генерация UI: Создаются кликабельные элементы управления (selectable controls) для топовых задач и отображаются пользователю.
7. Обработка выбора задачи: Пользователь выбирает задачу.
8. Формирование SERP: Система извлекает контент, соответствующий векторам в выбранном кластере, и отображает его, группируя результаты по нативным приложениям-источникам.

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

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

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

Контентные факторы (Native Application Content):

• Текст контента (сообщения, заметки, статьи).
• Сущности (Entity names): имена контактов, названия мест, городов, стран, компаний, упомянутые в контенте.

Структурные факторы (Fields):

• Поля, связанные с контентом (Claim 3) (Fields Associated with App Content): поле «Кому:», «Тема:» сообщения, поле «Назначение:» бронирования, «Название:» статьи.

Поведенческие и Контекстные факторы (Context Information / User Context):

• Идентификатор приложения: Какое приложение сгенерировало контент.
• Популярность приложения (Claim 4): Метрики использования приложения на устройстве (например, общее количество взаимодействий).
• Совместное использование (Claim 5): Данные о других приложениях, использовавшихся в той же сессии (same session); паттерны переключения между приложениями.
• Недавняя активность: Наиболее часто используемые приложения (Most Recently Used Native Apps); приложения, открытые в данный момент на устройстве (Native Apps Open on User Device) (FIG. 2).

Временные факторы (Context Information):

• Время создания контента (content creation time).
• Время взаимодействия с контентом (content interaction time).

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

• Cluster Feature-Vector: Многомерный вектор, где каждое измерение соответствует признаку из словаря (слова, сущности, поля, контекстные сигналы). Значения могут быть бинарными или скалярными (FIG. 2).
• Сходство векторов (Vector Similarity): Метрика для сравнения Query Vector и индексированных векторов. В патенте упоминается использование функции косинусного расстояния (cosine distance function).
• Кластеризация: Используются алгоритмы кластеризации (упомянуты k-means, иерархическая кластеризация, кластеризация на основе распределения, потоковая кластеризация) для группировки векторов в задачи.
• Ранжирование задач: Метрики для упорядочивания выявленных задач. Включают: свежесть (how recently контент был доступен), объем контента (amount of native application content items), частота доступа.

Выводы

1. Фокус на локальный поиск и нативные приложения: Патент описывает исключительно систему поиска по устройству (On-Device Search) для контента нативных приложений. Он не имеет прямого отношения к алгоритмам ранжирования веб-поиска Google.com.
2. Контекст использования как ключевой сигнал: Система активно использует контекстную информацию для формирования векторных представлений. Популярность приложения, время использования и то, какие приложения используются вместе (в одной сессии), являются явными сигналами для индексации (Claims 4, 5).
3. Векторный поиск для понимания контента: Для индексации и поиска используется технология векторных представлений (Cluster Feature-Vectors), которая учитывает не только ключевые слова, но и сущности, структуру данных (поля) и контекст.
4. Идентификация кросс-приложенческих задач: Ядром изобретения является способность системы идентифицировать задачи (Tasks), которые охватывают активность пользователя в двух или более разных приложениях (Claim 1). Это позволяет системе объединять фрагментированную информацию.
5. Важность структурированных данных в приложениях: Использование полей контента (например, «Кому:», «Назначение:») в качестве признаков (Claim 3) подчеркивает важность четкой информационной архитектуры и структурированных данных внутри приложений для их индексации локальным поиском.
6. Группировка по источнику: В интерфейсе поиска результаты из разных приложений четко разделяются и группируются по приложению-источнику (Claim 1), что является важной особенностью пользовательского интерфейса.

Практика

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

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

• Обеспечение индексируемости контента приложений: Разработчики и маркетологи должны гарантировать, что важный контент внутри приложения доступен для индексации локальной поисковой системой (например, через Android App Indexing API). Это увеличивает шансы появления контента в поиске по устройству.
• Использование структурированных данных в приложении: Поскольку система использует поля данных (fields associated with native application content) как признаки (Claim 3), необходимо внедрять четкую структуру для ключевого контента (например, корректно размечать бронирования, события, контакты, товары).
• Насыщение контента сущностями: Система использует распознавание сущностей для генерации векторов и кластеризации. Контент приложения должен быть богат сущностями (имена, локации, даты, организации), чтобы помочь системе корректно классифицировать его и связать с задачами пользователя.
• Стимулирование вовлеченности (Engagement): Популярность приложения и частота его использования являются контекстными сигналами (Claim 4). Высокие показатели DAU/MAU и удержания (Retention) напрямую повышают вероятность того, что контент приложения будет высоко ранжироваться в локальном поиске.
• Проектирование с учетом кросс-приложенческих сценариев: Понимая, что система ищет Tasks, охватывающие несколько приложений (Claim 1), следует анализировать, в каких задачах участвует ваше приложение вместе с другими (например, приложение для бронирования отелей вместе с авиабилетами и картами). Оптимизация под эти сценарии улучшит видимость.

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

• Изоляция данных в приложении: Хранение контента в форматах, недоступных для системного индексатора, или блокировка индексации приведет к тому, что приложение будет полностью невидимо в поиске по устройству.
• Игнорирование контекста использования: Создание приложений без учета того, как и когда они используются в связке с другими приложениями, упускает возможность воспользоваться преимуществами кластеризации задач.
• Отсутствие четкой структуры и сущностей: Публикация неструктурированного контента без явных сущностей и метаданных затрудняет для системы его интерпретацию и включение в Cluster Feature-Vectors.

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

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

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

Сценарий: Повышение видимости контента туристического приложения

1. Задача пользователя: Планирование поездки в Рим. Пользователь ищет авиабилеты в App A, смотрит достопримечательности в App B (Trip Mentor App) и обсуждает планы в Мессенджере C.
2. Действия (Best Practice): Ваше приложение (App D, бронирование отелей) внедрило App Indexing API. Все бронирования имеют четкую структуру (Назначение: Рим, Даты:…). Контент насыщен сущностями (названия отелей, районы Рима). У приложения хорошие показатели вовлеченности.
3. Работа системы: Локальная поисковая система индексирует активность во всех четырех приложениях. Vector Similarity Unit кластеризует векторы из App A, B, C и D в задачу «Поездка в Рим», так как они содержат схожие сущности (Рим, Италия) и используются в схожем контексте.
4. Ожидаемый результат: Когда пользователь использует поиск по устройству (даже без запроса, zero-input), система предлагает кликабельный элемент «Поездка в Рим». При нажатии пользователь видит свои авиабилеты (из App A), статьи (из App B), сообщения (из C) и свои бронирования или просмотренные отели (из вашего App D), сгруппированные по приложениям. Это повышает re-engagement для App D.

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