Как Google индексирует внутренний контент мобильных приложений с помощью виртуальных машин и скрытого текста (App Indexing)

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

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

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

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

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

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

Конкретное состояние пользовательского интерфейса внутри нативного приложения, характеризующееся уникальным набором функций. Это может быть определенный экран, меню, уровень в игре, 3D-тур или последовательность действий.

Extractor (Экстрактор)

Компонент виртуальной машины (например, Text Extractor, Image Extractor), предназначенный для извлечения определенных типов данных из процесса рендеринга приложения.

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

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

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

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

Uniform Resource Identifier (URI)

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

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

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

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

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

1. Система определяет набор environment instances для нативного приложения. Это делается путем получения набора URI от издателя приложения.
2. Для каждого environment instance система определяет описывающие его текстовые данные, которые не видны пользователю при рендеринге. Процесс определения этих данных включает:
   • Запуск виртуальной машины (VM), эмулирующей ОС устройства.
   • Запуск нативного приложения внутри VM.
   • Доступ к URI, соответствующему данному environment instance.
   • Генерация (рендеринг) environment instance в VM.
   • Извлечение текстовых данных, переданных процессу рендеринга, но идентифицированных как invisible textual data (т.е. не предназначенных для отображения).
3. На основе извлеченных текстовых данных генерируются данные, описывающие контент.
4. Эти данные индексируются в индексе, доступном для поиска поисковой системой.

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

Claim 2 (Зависимый от 1): Описывает альтернативный вариант, где издатель предоставляет URI и сами текстовые данные, описывающие environment instance. Это может позволить системе получить данные без необходимости их извлечения через VM.

Claim 3 (Зависимый от 1): Уточняет техническую реализацию извлечения скрытого текста в VM.

Генерация environment instance включает создание первого графического представления (OpenGL surface view). Извлечение текста включает создание текстового объекта (text view object), содержащего текстовые данные, который накладывается поверх графического представления, и последующее извлечение данных из этого текстового объекта. Это подтверждает механизм "наложения" скрытого текста на графический контент для целей индексации.

Claim 4, 5 и 6 (Зависимые): Описывают функциональность результата поиска (Deep Linking).

Система генерирует результат поиска на основе индексированных данных (Claim 4). Результат поиска включает URI и изображение environment instance. Выбор результата пользователем приводит к запуску приложения и навигации к соответствующему контенту (Claim 5), либо к предложению установить приложение, если оно не установлено (Claim 6).

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

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

CRAWLING – Сканирование и Сбор данных
Это основной этап применения патента. Application Indexer выполняет функцию краулера для нативных приложений. Вместо загрузки HTML используется Virtual Machine для запуска приложения и эмуляции взаимодействия с ним. Сбор данных происходит либо путем перехода по предоставленным издателем URI, либо путем автоматизированного исследования структуры приложения (automated process that explores various menus).

INDEXING – Индексирование и извлечение признаков
На этом этапе происходит извлечение ключевой информации из отрендеренных environment instances. Ключевым процессом является извлечение invisible textual data с помощью Extractors. Также могут извлекаться видимый текст, изображения, видео и ссылки. Данные сохраняются в специализированном Application Index.

METASEARCH – Метапоиск и Смешивание
Поисковая система одновременно обращается к Web Index и Application Index. Результаты из обоих индексов (веб-страницы и глубокие ссылки на environment instances) смешиваются и предоставляются на единой странице результатов поиска (SERP).

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

• Нативное приложение (установочный файл).
• Набор URI, предоставленный издателем (опционально).
• Текстовые данные (видимые и невидимые), встроенные в приложение разработчиком.

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

• Индексные данные (Index Data) для каждого environment instance, включающие извлеченный текст, URI (deep link), и, возможно, изображения или видео (скриншоты).
• Application Index.

На что влияет

• Типы контента: В первую очередь влияет на контент, доступный только через нативные приложения. Особенно актуально для графически насыщенных приложений, где мало видимого текста: игры (уровни, предметы), 3D-туры (локации), мультимедийные каталоги (товары, видео).
• Специфические запросы: Позволяет приложениям ранжироваться по информационным и транзакционным запросам, на которые ранее могли отвечать только веб-страницы (например, запрос о товаре может вести сразу на карточку товара в приложении магазина).
• Ниши: E-commerce, Travel, Gaming, Media – любые ниши, где нативные приложения являются основным каналом взаимодействия с пользователем.

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

Алгоритм индексации применяется при обнаружении нового приложения или обновлении существующего.

• Условия работы: Приложение должно быть доступно для запуска в эмулируемой среде. Для индексации конкретных environment instances они должны быть достижимы либо через автоматическое исследование, либо через предоставленные URI.
• Триггеры активации: Разработчик должен внедрить механизм предоставления данных для индексации – либо через встраивание invisible textual data, либо через предоставление списка URI с соответствующими описаниями.

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

Процесс индексации нативного приложения (на примере использования VM):

1. Инициализация VM: Application Indexer запускает виртуальную машину, эмулирующую целевую операционную систему устройства.
2. Установка и запуск приложения: Нативное приложение устанавливается и запускается внутри виртуальной машины.
3. Определение Environment Instances: Система определяет набор состояний для индексации.
   • Вариант А (Publisher-provided URIs): Система получает список URI от издателя и последовательно обращается к ним (основа Claim 1).
   • Вариант Б (Automated Exploration): Система автоматически исследует приложение, переходя по меню и ссылкам.
4. Рендеринг Environment Instance: Виртуальная машина генерирует (рендерит) целевой environment instance.
5. Извлечение данных (Extraction): Активируются экстракторы для сбора данных из процесса рендеринга:
   • Извлечение скрытого текста: Система перехватывает текстовые данные (например, из TextView объектов), которые были помечены как невидимые для пользователя.
   • Извлечение видимых данных: Система также может извлекать видимый текст, изображения или записывать короткие видеофрагменты взаимодействия.
6. Генерация индексных данных: Извлеченные данные обрабатываются для формирования описания environment instance.
7. Индексация: Сформированные данные, связанные с соответствующим URI (deep link) и идентификатором приложения, сохраняются в Application Index.

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

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

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

• Контентные факторы (Скрытые): Invisible textual data. Это ключевой элемент патента. Текст, предоставляемый разработчиком для описания графического или интерактивного контента, который не отображается пользователю (например, ключевые слова, сниппеты).
• Контентные факторы (Видимые): Упоминается возможность использования и видимого текста (rendered textual data), который отображается в интерфейсе.
• Мультимедиа факторы: Image data и Video data. Система может извлекать изображения (скриншоты) или видеофрагменты environment instance для использования в результатах поиска.
• Технические факторы: Uniform Resource Identifiers (URIs). Глубокие ссылки, используемые для доступа к конкретным environment instances.
• Структурные факторы: В контексте автоматического исследования система анализирует структуру навигации приложения. Упоминается возможность создания карты приложения (native application map).

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

Патент не описывает метрики ранжирования, а фокусируется на процессе индексации. Он описывает, какие данные собираются, но не как они взвешиваются поисковой системой.

Ключевые механизмы обработки данных:

• Эмуляция и Рендеринг: Использование виртуальной машины для выполнения кода приложения.
• Извлечение данных из объектов рендеринга: Технический метод доступа к данным внутри объектов интерфейса (например, TextView, ImageView) во время работы приложения в VM.
• Обработка скрытого текста: Механизм отделения текста, предназначенного для индексации, от текста, предназначенного для отображения пользователю, на основе атрибутов видимости.

1. Индексация контента приложений – это реальность: Патент подтверждает, что Google разработал сложную инфраструктуру (виртуальные машины, специализированные экстракторы) для сканирования и индексации контента непосредственно внутри нативных приложений, аналогично тому, как индексируется веб.
2. Критичность "Скрытого текста" для App SEO: Ключевой вывод – Google полагается на invisible textual data для понимания контента, особенно в графических приложениях. В отличие от веб-SEO, где скрытый текст часто считается манипуляцией, в контексте этого патента это основной легитимный механизм предоставления информации поисковой системе.
3. Deep Linking (URI) как основа: Uniform Resource Identifiers являются основой для индексации конкретных состояний приложения. Наличие проработанной структуры URI внутри приложения необходимо для того, чтобы контент был проиндексирован и доступен из поиска.
4. Техническая реализация имеет значение: Способ реализации интерфейса влияет на индексацию. Патент явно упоминает извлечение данных из стандартных объектов (TextView) и рендеринг на графических поверхностях (OpenGL surface view). Использование стандартных компонентов облегчает работу экстракторов.
5. Интеграция App и Web в поиске: Система предназначена для смешивания результатов из Web Index и Application Index, что позволяет пользователям бесшовно переходить из поиска непосредственно в релевантный контент приложения. Это стирает границы между вебом и приложениями в контексте поиска информации.

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

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

• Внедрение App Indexing (Firebase): Необходимо реализовать поддержку индексации контента приложения. Это стратегический приоритет для обеспечения видимости в органическом поиске.
• Оптимизация "Скрытого контента" для индексации: Для ключевых экранов (environment instances), особенно тех, где мало видимого текста, необходимо предоставлять системе индексации релевантные описательные данные. Согласно патенту, это реализуется через invisible textual data (на практике – через API индексации или атрибуты видимости для текстовых полей).
• Разработка структуры глубоких ссылок (URI): Спроектировать логичную и масштабируемую схему URI для всех важных environment instances. Каждый уникальный фрагмент контента должен иметь свой URI.
• Предоставление качественных метаданных: Убедиться, что данные, передаваемые для индексации (включая скрытый текст), точно описывают контент, содержат релевантные ключевые слова и привлекательные сниппеты. Патент упоминает, что издатель может предопределить сниппет для использования в поиске.
• Использование стандартных компонентов интерфейса: Поощрять разработчиков использовать стандартные объекты (такие как TextView и ImageView), так как система индексации оптимизирована для извлечения данных из них.
• Обеспечение стабильности приложения: Поскольку индексация включает запуск приложения в Virtual Machine, приложение должно работать стабильно. Ошибки и сбои могут помешать эффективной индексации контента.

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

• Игнорирование App Indexing: Рассматривать приложение как изолированную среду, недоступную для поиска. Это приводит к потере значительного объема органического трафика.
• Манипуляция скрытым текстом (Клоакинг): Предоставление в invisible textual data информации, которая не соответствует реальному контенту environment instance, с целью манипуляции ранжированием. Хотя патент описывает этот механизм как легитимный, злоупотребление им может привести к санкциям (система может верифицировать данные).
• Отсутствие глубоких ссылок: Разработка приложения без структуры URI, что делает невозможным индексацию и навигацию к конкретному контенту.
• Использование нестандартных графических движков без поддержки индексации: Полностью полагаться на кастомные графические решения, которые не предоставляют текстовые данные стандартным экстракторам ОС, и не компенсировать это предоставлением данных для индексации.

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

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

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

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

1. Задача: Обеспечить ранжирование карточки товара "Кроссовки Nike Air Max 2025" из мобильного приложения в поиске Google.
2. Действия (Разработка и SEO):
   • Создается URI для товара: android-app://com.example.store/products/nike-air-max-2025.
   • На экране карточки товара (environment instance) разработчик размещает видимый текст (цена, название).
   • Для улучшения индексации, согласно патенту, добавляются invisible textual data (или данные передаются через API индексации). Эти данные содержат:
     • Keywords: Nike Air Max 2025, мужские кроссовки для бега, купить Air Max.
     • Snippet: Обзор новейших кроссовок Nike Air Max 2025. Доступные цвета и размеры. Бесплатная доставка в приложении Example Store.
3. Процесс индексации: Application Indexer Google запускает приложение в VM, переходит по URI, рендерит карточку товара и извлекает видимые и невидимые текстовые данные.
4. Ожидаемый результат: При поиске "купить Nike Air Max 2025" пользователь видит в SERP результат поиска с глубокой ссылкой. При клике открывается приложение Example Store сразу на карточке этого товара (или предлагается установка).