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

Описание

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

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

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

Запатентована система индексации нативных приложений и генерации структурированных результатов поиска. Система извлекает данные двумя способами: анализируя установочный пакет приложения (Application Package) для получения иконки и официального названия (Application Display Name), и выполняя приложение в виртуальной машине (User Device OS Virtual Machine) для извлечения внутреннего контента и заголовков страниц. Эти данные объединяются в Application Index, что позволяет формировать информативные результаты поиска (Native Application Search Result).

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

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

• Эмуляция и выполнение: Система запускает нативное приложение в Virtual Machine, эмулирующей операционную систему пользовательского устройства (например, Android).
• Сканирование: Система получает доступ к экранам приложения (Application Pages) либо путем автоматического исследования интерфейса, либо используя URI (Deep Links), предоставленные разработчиком.
• Извлечение контента: Используются специальные экстракторы (Text Extractor, Image Extractor, List Extractor), которые перехватывают данные непосредственно перед рендерингом на экран (например, извлекая текст из стандартных объектов ОС, таких как TextView).
• Анализ пакета: Отдельно анализируется установочный файл приложения для извлечения Application Icon и Application Display Name (текста, отображаемого под иконкой).
• Индексация: Все извлеченные данные сохраняются в Application Index.
• Генерация SERP: При совпадении запроса система генерирует результат поиска, комбинируя извлеченные элементы (например: Иконка + Название Приложения – Заголовок Страницы + Сниппет).

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

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

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

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

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

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

Application Display Name (Отображаемое имя приложения)

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

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

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

Application Package / Compressed collection of files (Пакет приложения)

Коллекция файлов (часто сжатая, например, APK или IPA), используемая для распространения и установки нативного приложения на устройство.

Application Page (Страница приложения / Экран)

Конкретная среда отображения (экран) внутри нативного приложения, на которой представлен контент. Специфична для конкретного приложения и ОС.

Deep Link (Глубинная ссылка)

Ссылка (URI), которая ведет не на главный экран приложения, а на конкретную страницу контента (Application Page) внутри него.

Extractors (Экстракторы)

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

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

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

Native Application Search Result (Результат поиска нативного приложения)

Специальный формат результата поиска, соответствующий контенту внутри нативного приложения, который при выборе запускает это приложение и открывает конкретный экран (Deep Link).

User Device OS Virtual Machine (Виртуальная машина ОС пользовательского устройства)

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

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

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

1. Система получает доступ к compressed collection of files (установочному пакету) для множества нативных приложений.
2. Для каждого приложения из пакета определяется application name. Процесс определения включает:
   1. Определение application icon из файлов пакета.
   2. Индексация этой иконки.
   3. Выбор text string defining the application display name (текста под иконкой) в качестве application name.
3. Система получает доступ к application pages (внутренним экранам) приложения.
4. Для каждой страницы генерируются application page data (описание контента) и application page name (заголовок страницы).
5. Система индексирует application page data и application name в индексе, доступном для поиска.

Ядром изобретения является метод определения канонического имени приложения путем анализа пакета и извлечения строки Application Display Name, связанной с иконкой, а также последующая индексация внутреннего контента.

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

1. Система получает данные о том, что страница приложения релевантна запросу.
2. В ответ система выполняет:
   1. Выбирает из индекса application name и включает его как первый текстовый дескриптор в результат поиска.
   2. Выбирает application icon и включает его как первый графический дескриптор (image descriptor).
   3. Выбирает URI страницы приложения и включает его в результат поиска.
   4. Выбирает application page name (заголовок страницы, на которую ведет URI) как второй текстовый дескриптор.
   5. Предоставляет сформированный результат поиска пользовательскому устройству.

Этот пункт защищает метод формирования комбинированного результата поиска, состоящего из Иконки, Имени Приложения, Заголовка Экрана и URI.

Claim 3 (Зависимый от 2): Уточняет выбор application name с учетом языка.

Если для приложения существует несколько названий на разных языках, система определяет язык запроса и выбирает то название приложения (application name), которое соответствует этому языку.

Claim 4 (Зависимый от 3): Уточняет процесс доступа к страницам приложения.

Система может получать от издателя (publisher) приложения данные, указывающие, какие страницы следует индексировать. В этом случае система ограничивает доступ только этими указанными страницами.

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

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

CRAWLING – Сканирование и Сбор данных
Применяется специализированная форма сканирования. Вместо стандартного веб-краулера используется User Device OS Virtual Machine. Эта виртуальная машина запускает приложение и действует как краулер для внутренней среды приложения, переходя по экранам (автоматически или по списку URI от издателя). Также используется Package Processor для анализа установочного файла.

INDEXING – Индексирование и извлечение признаков
Это основной этап применения патента. Происходит извлечение признаков из двух источников:

1. Внутри приложения (через VM): Extractors перехватывают данные (текст, изображения, списки) непосредственно из процесса рендеринга приложения. Это позволяет получить точное представление контента. Извлекаются application page name и application page data.
2. Из пакета приложения (через Package Processor): Анализируется установочный файл для извлечения Application Icon и Application Display Name.

Результат сохраняется в Application Index.

RANKING – Ранжирование
Поисковая система использует Application Index наряду с Web Index для поиска кандидатов, релевантных запросу.

METASEARCH – Метапоиск и Смешивание
Search Results Generator отвечает за формирование финального вида результата поиска для нативного приложения. Он комбинирует извлеченные компоненты (Иконка, Имя Приложения, Заголовок Экрана) в единый блок (Native Application Search Result) для показа в SERP.

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

• Установочные пакеты нативных приложений (Application Packages).
• (Опционально) Список URI (Deep Links) для индексации, предоставленный издателем.

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

• Структурированные данные в Application Index, включающие контент страниц, заголовки страниц, URI, иконку приложения и отображаемое имя приложения.

На что влияет

• Конкретные типы контента: Влияет на любой контент, представленный внутри нативных приложений, доступный через Deep Links — статьи, карточки товаров, профили, результаты поиска внутри приложения и т.д.
• Конкретные ниши или тематики: Наиболее актуально для приложений, где контент является ключевой ценностью (E-commerce, Медиа, Путешествия, Рецепты), в отличие от чисто функциональных утилит.
• Языковые и географические ограничения: Система учитывает локализацию, извлекая Application Display Name для разных языков из пакета и выбирая подходящее имя в зависимости от языка запроса пользователя (Claim 3).

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

• Триггеры активации (Индексация): Применяется при обработке нативных приложений для включения их в Application Index. Это может происходить при публикации приложения в магазине или при получении сигналов от издателя.
• Триггеры активации (Поиск): Применяется, когда поисковая система определяет, что Application Page релевантна запросу пользователя (особенно на мобильных устройствах).
• Исключения и особые случаи: Издатели могут ограничить индексацию только определенными страницами, предоставив список URI (Claim 4).

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

Процесс А: Индексация нативного приложения (Offline)

1. Инициализация среды: Запуск Virtual Machine, эмулирующей целевую ОС устройства.
2. Выполнение приложения: Установка и запуск нативного приложения внутри виртуальной машины.
3. Доступ к страницам (Crawling): Получение доступа к Application Pages. Это может быть сделано путем автоматического исследования меню и опций или путем перехода по списку URI, предоставленному издателем.
4. Извлечение контента (Внутри VM): Для каждой страницы активируются Extractors. Они перехватывают данные, передаваемые в процесс рендеринга (например, текст из TextView, изображения из ImageView), и определяют заголовок страницы (application page name).
5. Обработка пакета (Параллельный процесс): Package Processor анализирует установочный файл приложения (Application Package).
6. Извлечение метаданных (Из пакета): Идентификация Application Icon и соответствующего ему Application Display Name (текста под иконкой). При наличии нескольких языков сохраняются все варианты.
7. Индексация: Сохранение всех извлеченных данных (контент, заголовок страницы, иконка, имя приложения) в Application Index, связанных с URI конкретной страницы.

Процесс Б: Генерация результата поиска (Real-time)

1. Идентификация релевантности: Поисковая система определяет, что страница приложения релевантна запросу.
2. Извлечение данных из индекса: Система извлекает из Application Index сохраненные данные для соответствующего URI: иконку, имя приложения, заголовок страницы и контент.
3. Локализация имени: Выбирается Application Display Name, соответствующее языку запроса (если доступно).
4. Конструирование результата: Генерируется Native Application Search Result. Элементы комбинируются: Иконка (первый графический дескриптор), Имя Приложения (первый текстовый дескриптор), Заголовок Страницы (второй текстовый дескриптор) и сниппет из контента.
5. Предоставление результата: Сформированный результат отправляется на устройство пользователя для показа в SERP.

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

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

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

• Технические факторы:
  • Application Package (установочные файлы, например, APK).
  • URI (Deep Links), идентифицирующие конкретные Application Pages.
• Контентные факторы (извлекаются из VM):
  • Текст, отображаемый на странице. Извлекается с помощью Text Extractor из рендеринговых объектов (например, TextView objects).
  • Заголовки страниц (Application Page Name).
  • Данные списков и меню, извлекаемые с помощью List Extractor (например, ListView objects).
• Мультимедиа факторы:
  • Изображения, отображаемые на странице. Извлекаются с помощью Image Extractor (например, ImageView objects).
  • Application Icon. Извлекается из установочного пакета.
• Географические факторы:
  • Данные о локализации и языке, содержащиеся в установочном пакете, для определения Application Display Name на разных языках.

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

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

Основные методы, описанные в патенте:

• Методы анализа (Extraction): Использование специализированных обработчиков данных для конкретной ОС (например, объектов TextView, ImageView, ListView) для извлечения контента до его рендеринга. Это ключевой метод, обеспечивающий точность данных.
• Анализ пакета (Package Processing): Декомпрессия и интерпретация установочного файла для поиска иконок и связанных с ними текстовых строк (Application Display Name).

Выводы

1. Индексация через эмуляцию: Google использует сложный механизм для индексации нативных приложений, включающий запуск приложения в Virtual Machine. Это позволяет системе видеть контент так, как он представлен пользователю, но в контролируемой среде.
2. Извлечение данных до рендеринга (Не OCR): Ключевой особенностью является использование Extractors, которые перехватывают данные из стандартных объектов ОС (таких как TextView) до того, как они будут отрисованы на экране. Это обеспечивает высокую точность извлечения текста и изображений и не является анализом скриншотов (OCR).
3. Зависимость от стандартных компонентов UI: Способность системы извлекать контент напрямую зависит от того, используются ли в приложении стандартные элементы интерфейса. Контент, отображаемый нестандартными способами (например, в игровых движках), может быть пропущен этим методом.
4. Структурированное представление Deep Links: Патент решает проблему неинформативных сниппетов. Заголовок в SERP формируется путем принудительной конкатенации Application Display Name (из пакета) и Application Page Name (из контента).
5. Важность метаданных пакета: Application Display Name (имя под иконкой) извлекается из установочного пакета (а не из магазина приложений) и играет ключевую роль в представлении приложения в поиске.
6. Контроль над индексацией: Разработчики имеют возможность контролировать, какой контент будет проиндексирован, предоставляя список URI (Claim 4).

Практика

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

Рекомендации касаются оптимизации приложений (ASO) и технической реализации App Indexing.

• Внедрение Deep Linking и App Indexing: Необходимо реализовать поддержку App Indexing (например, через Firebase) и Deep Links (URI) для всех ключевых экранов приложения. Это необходимое условие для работы описанной системы.
• Использование стандартных компонентов UI: При разработке убедиться, что основной контент и заголовки отображаются с использованием стандартных нативных компонентов ОС (например, TextView в Android). Это гарантирует, что Extractors Google смогут корректно извлечь информацию.
• Оптимизация Application Display Name: Убедиться, что Application Display Name (текст под иконкой в установочном пакете) является точным, информативным и корректно локализованным для разных языков. Он используется в качестве первой части заголовка в результатах поиска.
• Оптимизация заголовков страниц приложения (Application Page Name): Заголовки внутренних экранов должны быть релевантными контенту и оптимизированными (аналогично тегу <title>), так как они используются в качестве второй части заголовка в SERP.
• Предоставление списка URI: Рекомендуется предоставлять Google список URI для индексации (например, через API или связь с сайтом). Согласно патенту (Claim 4), это позволяет контролировать процесс сканирования и гарантировать индексацию нужных страниц.

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

• Использование нестандартных методов рендеринга: Размещение текста в кастомных графических движках (например, Unity, Flutter без соответствующей настройки) или в виде изображений может сделать его невидимым для Extractors, которые настроены на стандартные объекты ОС.
• Игнорирование Deep Links: Разработка приложений без возможности адресации конкретных экранов через URI делает внутренний контент недоступным для индексации описанной системой.
• Слишком длинное или спамное Application Display Name: Использование нерелевантных ключевых слов в отображаемом имени приложения может негативно сказаться на представлении в SERP и пользовательском опыте.
• Неинформативные заголовки экранов: Использование общих или нерелевантных заголовков для разных экранов приложения ухудшит представление приложения в поиске и снизит CTR.

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

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

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

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

1. Подготовка (Разработчик): Разработчик кулинарного приложения внедряет Deep Link для рецепта «Яблочный пирог» (например: app://com.example.recipes/recipe/apple-pie). Приложение использует стандартный TextView для отображения заголовка «Яблочный пирог» и ингредиентов. В установочном пакете Application Display Name указано как «Лучшие Рецепты».
2. Индексация (Google): Google запускает приложение в Virtual Machine и переходит по URI. Text Extractor извлекает заголовок «Яблочный пирог» (Application Page Name) и текст рецепта. Package Processor извлекает иконку и имя «Лучшие Рецепты» (Application Display Name). Все это сохраняется в Application Index.
3. Поиск (Пользователь): Пользователь ищет «рецепт яблочного пирога».
4. Результат: В SERP появляется результат с иконкой приложения и заголовком, сформированным по шаблону [Application Display Name] – [Application Page Name]: «Лучшие Рецепты – Яблочный пирог». При клике у пользователя открывается приложение сразу на экране рецепта.

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