Как Google индексирует контент внутри мобильных приложений с помощью виртуальных машин и «невидимого текста» для Deep Linking

Описание

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

Патент решает фундаментальную проблему индексации нативных мобильных приложений. Традиционные поисковые краулеры не могут эффективно «просматривать» и индексировать контент внутри скомпилированных приложений так же, как они это делают с веб-страницами. До этого изобретения поисковые системы в основном полагались на метаданные, внешние по отношению к приложению (например, описание в App Store). Патент предлагает механизм для индексации фактического контента и конкретных состояний (environment instances) внутри приложения, что значительно повышает релевантность поиска по контенту приложений.

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

Запатентована система и метод для индексации environment instances (экранов или состояний) нативных приложений. Ключевым элементом является использование виртуальной машины (Virtual Machine) для запуска приложения и извлечения данных непосредственно из процесса рендеринга. Особый акцент сделан на извлечении textual data, которое разработчик пометил как «невидимое» (invisible textual data) — то есть данных, описывающих контент экрана, но не отображаемых пользователю. Это позволяет индексировать контент приложения для обеспечения поиска и Deep Linking.

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

Система работает в несколько этапов:

• Эмуляция: Нативное приложение запускается внутри Virtual Machine, которая эмулирует операционную систему целевого устройства (например, Android).
• Определение состояний: Система определяет набор environment instances для индексации. Это может происходить путем автоматического исследования приложения (клика по меню) или использования списка URI (Deep Links), предоставленного издателем.
• Извлечение данных (Extraction): Когда приложение рендерит конкретный экран, система перехватывает данные, передаваемые в процесс рендеринга. Она извлекает текстовые данные, помеченные как невидимые (например, через TextView objects), а также может захватывать изображения или видео.
• Индексация: Извлеченные данные, описывающие контент экрана, индексируются в Application Index и связываются с соответствующим URI (Deep Link).

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

Высокая. Описанные механизмы лежат в основе технологий Google App Indexing (в настоящее время часть Firebase App Indexing). Индексация контента приложений и обеспечение бесшовного перехода из поиска внутрь приложения (Deep Linking) остаются критически важными компонентами мобильного поиска и стратегий ASO (App Store Optimization) и мобильного SEO.

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

Патент имеет высокое значение (8/10) для мобильного SEO и ASO. Он описывает техническую реализацию того, как контент внутри приложения становится видимым для поисковой системы. Для компаний, у которых мобильное приложение является ключевым каналом, понимание этого механизма критично. Это позволяет оптимизировать контент приложения так, чтобы он ранжировался в мобильной выдаче наравне с веб-ресурсами, и обеспечивает прямой трафик на конкретные экраны приложения через Deep Linking.

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

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

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

Индекс, содержащий данные о контенте и environment instances нативных приложений. Используется поисковой системой наряду с веб-индексом.

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

Система, которая выполняет процесс извлечения и индексации данных из нативных приложений.

Deep Linking (Глубинные ссылки)

Использование Uniform Resource Identifier (URI) для ссылки на конкретный контент или состояние внутри мобильного приложения, а не просто на запуск приложения.

Environment Instance (Экземпляр среды)

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

Invisible Textual Data (Невидимые текстовые данные)

Текстовые данные, описывающие особенности environment instance. Эти данные передаются в процесс рендеринга приложения, но помечены как невидимые, поэтому не отображаются пользователю на экране. Они предназначены специально для индексации.

Native Application (Нативное приложение)

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

OpenGL Surface View / Text View Object

Технические компоненты (упомянутые как пример реализации, например, в Android), используемые для рендеринга графики и текста. Система может накладывать Text View Object (с невидимым текстом) поверх OpenGL Surface View для извлечения данных.

Uniform Resource Identifier (URI)

Идентификатор, который соответствует конкретному environment instance в приложении (Deep Link).

Virtual Machine (VM) (Виртуальная машина)

Программная среда, используемая Application Indexer для эмуляции операционной системы устройства. Позволяет запускать нативное приложение и извлекать из него данные в контролируемой среде.

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

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

1. Система генерирует набор environment instances нативного приложения, запуская его в Virtual Machine на сервере.
2. Для каждого сгенерированного environment instance:
   1. Извлекаются текстовые данные, предоставленные процессу рендеринга приложения.
   2. Ключевое условие: эти данные должны быть идентифицированы как invisible textual data, то есть рендерятся в невидимой форме и не видны на дисплее пользователя.
   3. Из ключевых слов в этих текстовых данных генерируются индексные данные, описывающие контент.
   4. Эти данные индексируются поисковой системой.

Ядро изобретения — это индексация контента приложения путем запуска приложения на сервере (в VM) и извлечения специально предоставленных разработчиком описательных данных, которые не видны конечному пользователю.

Claim 2 (Зависимый от 1): Уточняет способ определения environment instances.

Система может получать Uniform Resource Identifiers (URIs) от издателя приложения. Генерация набора environment instances включает генерацию экземпляра для каждого полученного URI.

Это означает, что издатель может явно указать, какие экраны нужно проиндексировать, предоставив список Deep Links.

Claim 3 (Зависимый от 1): Описывает пример технической реализации извлечения данных (например, для Android).

1. Генерация environment instance включает создание OpenGL surface view (основной графический рендеринг).
2. Извлечение невидимых данных включает:
   1. Создание text view object, который содержит текстовые данные и накладывается поверх OpenGL surface view.
   2. Извлечение текста из этого text view object.

Это техническое описание того, как разработчик может предоставить невидимый текст системе индексации во время рендеринга.

Claim 5 и 6 (Зависимые): Описывают использование индекса в поиске (Deep Linking).

Система генерирует поисковый результат, включающий URI и изображение environment instance.

• (Claim 5): Если приложение установлено, выбор результата приводит к запуску приложения и переходу к указанному environment instance.
• (Claim 6): Если приложение не установлено, выбор результата приводит к предложению установить приложение.

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

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

CRAWLING – Сканирование и Сбор данных
На этом этапе система должна обнаружить environment instances для индексации. Это может происходить двумя путями: (1) получение списка URI от издателя или (2) автоматическое исследование (краулинг) приложения внутри Virtual Machine путем активации меню и ссылок.

INDEXING – Индексирование и извлечение признаков
Основное применение патента. Application Indexer запускает приложение в Virtual Machine. Происходит рендеринг каждого environment instance. Специальные экстракторы (Text Extractor, Image Extractor) перехватывают данные из процесса рендеринга, в частности invisible textual data. Извлеченные данные сохраняются в Application Index.

METASEARCH – Метапоиск и Смешивание
Поисковая система использует Application Index наряду с веб-индексом. Результаты из обоих индексов смешиваются для формирования универсальной выдачи, включающей как веб-ресурсы, так и ссылки на нативные приложения.

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

• Пакет нативного приложения (например, APK).
• Список URI (Deep Links), предоставленный издателем (опционально).

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

• Записи в Application Index, содержащие:
  • Идентификатор приложения.
  • URI для environment instance.
  • Текстовое описание контента (извлеченное из invisible textual data).
  • Изображения или видео, захваченные во время рендеринга.

На что влияет

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

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

• При каких условиях работает алгоритм: Алгоритм применяется в процессе индексации нативных приложений, которые поддерживаются целевой операционной системой (например, Android).
• Триггеры активации: Активируется при обнаружении нового приложения или обновлении существующего, либо при получении нового списка URI от издателя. Извлечение данных происходит только тогда, когда приложение успешно запускается и рендерит контент в Virtual Machine.

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

Процесс индексации нативного приложения:

1. Инициализация VM: Система создает экземпляр Virtual Machine, эмулирующий операционную систему целевого устройства.
2. Запуск приложения: Нативное приложение устанавливается и запускается внутри VM.
3. Определение Environment Instances: Система определяет набор экранов/состояний для индексации.
   1. Вариант A (Краулинг): Автоматический процесс исследует приложение, последовательно выбирая пункты меню и ссылки.
   2. Вариант B (По списку URI): Система использует предоставленный издателем список URI и запускает приложение с соответствующими параметрами для доступа к каждому URI.
4. Рендеринг и Перехват: Для каждого environment instance приложение выполняет процесс рендеринга. VM перехватывает данные, передаваемые в этот процесс.
5. Извлечение невидимого текста: Система идентифицирует текстовые данные, помеченные как invisible textual data (например, извлекает текст из TextView objects, наложенных поверх основного контента, но скрытых от пользователя).
6. Извлечение медиа: Система может захватывать скриншоты или записывать короткие видеоролики взаимодействия с environment instance.
7. Генерация индексных данных: Извлеченный текст (особенно ключевые слова из невидимого текста) используется для создания описания контента.
8. Индексация: Сгенерированные данные, URI, идентификатор приложения и медиа сохраняются в Application Index.

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

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

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

• Контентные факторы:
  • Invisible Textual Data: Критически важный элемент. Текст, предоставленный разработчиком специально для индексации, описывающий контент экрана, но невидимый для пользователя.
  • Видимый текст: Патент упоминает, что видимый текст, отображаемый в environment instance (например, меню), также может быть использован.
• Мультимедиа факторы:
  • Изображения и Видео: Данные, извлекаемые с помощью Image Extractor или Video Extractor из процесса рендеринга (например, из ImageView objects). Система может записывать видео взаимодействия с приложением.
• Технические факторы:
  • Uniform Resource Identifiers (URIs): Deep Links, используемые для идентификации и доступа к конкретным environment instances.
• Структурные факторы:
  • Навигационная структура приложения: Используется при автоматическом краулинге приложения внутри VM для обнаружения новых экранов. Также может быть представлена в виде карты приложения (native application map).

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

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

Система фокусируется на:

• Извлечение ключевых слов: Генерация индексных данных из ключевых слов, содержащихся в invisible textual data.
• Сопоставление контента и URI: Обеспечение точной связи между описанием контента и Deep Link, который ведет к этому контенту.

Выводы

1. Индексация контента внутри приложений (App Indexing): Патент подтверждает, что Google разработал сложные механизмы для индексации контента, находящегося внутри нативных мобильных приложений, преодолевая ограничения традиционного веб-краулинга.
2. Использование виртуальных машин для индексации: Ключевым методом является запуск приложения в эмулируемой среде (Virtual Machine) на серверах Google. Это позволяет системе «видеть» и взаимодействовать с приложением так же, как это делает пользователь.
3. Концепция «Невидимого текста» для SEO приложений: Изобретение явно описывает механизм, позволяющий разработчикам предоставлять описательные данные (invisible textual data) специально для поисковых систем во время рендеринга экрана. Это функциональный эквивалент мета-тегов для экранов приложений.
4. Критичность Deep Linking (URI): Успешная индексация требует наличия уникальных идентификаторов (URI) для каждого значимого экрана или состояния (environment instance). Без Deep Links невозможно связать поисковый результат с конкретным контентом внутри приложения.
5. Автоматизация и Участие издателя: Система может работать как автоматически (исследуя приложение в VM), так и на основе данных, предоставленных издателем (список URI, невидимый текст), что подчеркивает важность технической оптимизации приложения для индексации.

Практика

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

• Внедрение App Indexing: Необходимо активно внедрять технологии индексации приложений (например, Firebase App Indexing). Это позволяет контенту приложения ранжироваться в мобильном поиске.
• Поддержка Deep Linking (URI): Обеспечить, чтобы все ключевые экраны приложения (товары, статьи, функции) имели уникальные URI и чтобы приложение корректно обрабатывало переход по этим ссылкам извне.
• Предоставление описательных данных для экранов: Необходимо предоставлять четкие и релевантные текстовые описания для каждого индексируемого environment instance. Хотя патент фокусируется на механизме извлечения «невидимого текста» через рендеринг, на практике это часто реализуется через API App Indexing, где передаются заголовки и описания экранов. Суть остается той же — предоставление описания контента системе индексации.
• Связывание веб-контента и контента приложения: Если контент дублируется на сайте и в приложении, необходимо связать веб-URL с соответствующими URI приложения (например, через разметку на сайте или в Search Console). Это помогает Google понять структуру и консолидировать сигналы.
• Оптимизация структуры приложения: Структура приложения должна быть логичной, чтобы облегчить как пользователям, так и автоматизированным системам (если используется автоматический краулинг в VM) навигацию и обнаружение контента.

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

• Игнорирование мобильного приложения как источника трафика: Рассматривать приложение только как инструмент для существующих клиентов, игнорируя его потенциал для привлечения нового органического трафика через поиск.
• Отсутствие Deep Links: Создание контента в приложении, к которому невозможно получить доступ напрямую по ссылке. Это делает индексацию конкретного контента невозможной.
• Предоставление нерелевантных описаний (Клоакинг): Попытка манипулировать индексом путем предоставления invisible textual data или данных через API, которые не соответствуют фактическому контенту экрана. Патент указывает, что система может верифицировать данные, используя VM для захвата скриншотов и видимого текста.
• Блокировка рендеринга: Технические проблемы, которые могут помешать приложению корректно запуститься и отрендерить контент в эмулируемой среде Google.

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

Этот патент имеет фундаментальное значение для мобильной экосистемы. Он стирает грань между вебом и нативными приложениями с точки зрения доступности для поиска. Для SEO-стратегии это означает необходимость комплексного подхода, включающего оптимизацию не только веб-сайта, но и контента мобильного приложения (ASO/App SEO). Компании, инвестирующие в App Indexing, получают дополнительный канал органического трафика и улучшают пользовательский опыт за счет бесшовного перехода из поиска в приложение.

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

Сценарий: Индексация товара в E-commerce приложении

1. Задача: Обеспечить ранжирование конкретного товара (например, «Кроссовки Nike Air Max 2025») из мобильного приложения в поиске Google.
2. Действия разработчика/SEO:
   1. Обеспечить наличие Deep Link для экрана этого товара (например, app://com.example.shop/product/12345).
   2. При открытии этого экрана в приложении, предоставить системе индексации текстовые данные, описывающие товар (заголовок, описание, ключевые слова). Это может быть реализовано через Firebase App Indexing API или, как описано в патенте, через механизм invisible textual data во время рендеринга.
3. Действия Google (согласно патенту):
   1. Google запускает приложение в VM, используя Deep Link.
   2. Приложение рендерит экран товара.
   3. Google извлекает предоставленные текстовые данные и делает скриншот экрана.
   4. Данные индексируются в Application Index.
4. Ожидаемый результат: При поиске «Кроссовки Nike Air Max 2025» в мобильной выдаче появляется результат, ведущий прямо на экран товара в приложении (если оно установлено) или предлагающий его установить.

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