Как Google сканирует и индексирует контент внутри мобильных приложений с помощью эмуляции и извлечения данных

Описание

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

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

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

Запатентована система и метод для индексации страниц нативных приложений (Application Pages). Суть изобретения заключается в использовании виртуальной машины (Virtual Machine), которая эмулирует операционную систему мобильного устройства. Приложение запускается внутри этой эмулированной среды, система переходит по его страницам и извлекает контент (текст, изображения, ссылки) с помощью специализированных экстракторов (Extractors) непосредственно из процесса рендеринга.

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

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

• Эмуляция среды: Создается Virtual Machine, имитирующая ОС пользовательского устройства (например, Android).
• Запуск приложения: Нативное приложение инсталлируется и запускается внутри виртуальной машины.
• Навигация (Crawling): Система обращается к различным страницам приложения автоматически (исследуя меню и ссылки) или целенаправленно (по списку URI, предоставленному издателем).
• Извлечение контента (Extraction): Используются специализированные экстракторы (Text Extractor, Image Extractor, List Extractor). Они перехватывают данные (например, объекты TextView в Android), передаваемые процессу рендеринга (Rendering Process), до того как они будут отображены на экране.
• Индексирование: Извлеченный контент сохраняется в Application Index и связывается с URI конкретной страницы (Application Page Identifier).

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

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

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

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

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

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

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

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

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

Конкретная среда отображения контента внутри нативного приложения. Генерируется и отображается самим приложением, а не браузером.

Application Page Identifier (Идентификатор страницы приложения)

Уникальный идентификатор (часто в форме URI или Deep Link), который позволяет однозначно адресовать и открыть конкретную страницу внутри приложения.

Deep Linking (Глубокое связывание)

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

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

Компонент виртуальной машины, предназначенный для извлечения данных определенного типа. Патент упоминает Text Extractor, Image Extractor, List Extractor. Экстракторы получают доступ к данным, предоставляемым процессу рендеринга.

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

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

Receiving Cache (Кэш приема)

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

Rendering Process (Процесс рендеринга)

Процесс внутри приложения или ОС, который получает данные (объекты) и отображает их на экране устройства.

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

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

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

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

1. Система обрабатывает каждую страницу (Application Page) нативного приложения, которое работает независимо от браузера.
2. Производится извлечение контента со страницы.
3. Ключевое условие: контент включает данные разных типов (plurality of different content types).
4. Для каждого типа используется соответствующий специализированный экстрактор (extractor specific to that content type).
5. Генерируются данные, описывающие контент страницы, включая отображаемый текст.
6. Эти данные индексируются в поисковом индексе.

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

Claim 2 (Зависимый от 1): Уточняет механизм индексации.

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

Это техническая основа для реализации Deep Linking, позволяющая однозначно идентифицировать и адресовать конкретный экран внутри конкретного приложения.

Claim 3 (Зависимый от 1): Описывает способ управления сканированием.

1. Система получает от издателя приложения данные, указывающие, какие страницы следует индексировать.
2. Доступ осуществляется только к этим указанным страницам.

Это позволяет издателям контролировать, какой контент попадет в индекс, функционируя аналогично Sitemap или robots.txt для веб-сайтов.

Claim 4, 5 (Зависимые от 1): Уточняют типы экстракторов и данных.

Упоминаются Text Extractor для текста и Image Extractor для изображений. Также указывается, что извлекаемые данные могут включать данные изображения (image data), отображающие страницу приложения.

Claim 6 (Зависимый от 5): Описывает альтернативный метод извлечения текста.

Генерация текстовых данных может включать выполнение оптического распознавания символов (OCR) на извлеченных данных изображения.

Хотя основной метод (Claim 1) предполагает прямой перехват данных до рендеринга, патент также защищает использование OCR на отрендеренном экране как альтернативный или резервный способ получения текстового контента.

Claim 7, 8 (Зависимые от 1): Уточняют извлечение ссылок.

Извлекаемые данные также включают: (Claim 7) данные о ссылках внутри приложения, ведущих на другие страницы этого же приложения (внутренние ссылки); (Claim 8) данные о ссылках, ведущих на внешние веб-ресурсы (URL), при выборе которых запускается браузер.

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

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

CRAWLING – Сканирование и Сбор данных
Это основной этап применения. Вместо стандартного Googlebot, сканирующего HTML, используется специализированная инфраструктура на базе Virtual Machine. Эта система эмулирует ОС, запускает нативные приложения и осуществляет навигацию по ним (автоматически или по URI) для сбора сырых данных.

INDEXING – Индексирование и извлечение признаков
На этом этапе происходит извлечение признаков (Feature Extraction). Extractors (Text, Image, List) анализируют данные, полученные от Rendering Process приложения. Извлеченный структурированный контент сохраняется в Application Index.

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

METASEARCH – Метапоиск и Смешивание
Имея Application Index, поисковая система может смешивать результаты поиска приложений (native application search results) с результатами веб-поиска (web resource search results) на странице выдачи (Universal Search).

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

• Бинарный файл нативного приложения (например, APK).
• Идентификатор приложения (Application Identifier).
• (Опционально) Список URI страниц приложения, предоставленный издателем.

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

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

На что влияет

• Типы контента: Влияет на любой контент внутри нативных приложений, отображаемый стандартными средствами: статьи, товары (eCommerce), рецепты, профили, списки (фильмы, музыка).
• Специфические запросы: Наибольшее влияние на информационные и транзакционные запросы на мобильных устройствах, где пользователи ищут информацию или хотят совершить действие, которое удобно выполнить через приложение.
• Конкретные ниши: eCommerce, Travel, Media, Финансы, Социальные сети — любые ниши, где активно используются нативные приложения.

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

• Условия работы: Алгоритм применяется в процессе планового сканивания и индексации нативных мобильных приложений поисковой системой.
• Триггеры активации: Обнаружение нового приложения, обновление существующего приложения или получение запроса на индексацию (списка URI) от издателя.
• Исключения: Система может испытывать трудности с приложениями, требующими сложной аутентификации, или использующими нестандартные методы рендеринга (например, игровые движки), которые не поддерживаются стандартными Extractors.

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

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

1. Инициализация Виртуальной Машины: Система (например, Extraction Controller) запускает виртуальную машину, эмулирующую целевую операционную систему (например, Android). VM модифицирована для включения компонентов Extractors.
2. Запуск Приложения: Нативное приложение инсталлируется и запускается внутри эмулированной среды.
3. Навигация и Доступ к Страницам: Система осуществляет доступ к страницам приложения:
   1. Управляемый доступ: Если издатель предоставил список URI, система последовательно загружает эти URI.
   2. Автоматическое исследование: Система автоматически исследует приложение, активируя меню и ссылки для обнаружения новых страниц.
4. Извлечение Контента (Extraction): Для каждой загруженной страницы активируются Extractors. Они перехватывают данные (например, объекты классов TextView, ImageView, ListView), которые передаются в Rendering Process приложения.
5. Преимущество метода: Этот метод позволяет извлекать «чистые» данные в бинарной форме и получать доступ к контенту, который может быть не виден в области просмотра (например, в прокручиваемом списке).
6. Кэширование Внешних Данных (Опционально): Если приложение запрашивает данные с внешних серверов (API, фиды), виртуальная машина перехватывает и кэширует эти данные (Receiving Cache) для индексации.
7. Обработка Изображений и OCR (Опционально): При необходимости система может сделать снимок отрендеренной страницы (Screen Extraction) и применить OCR для извлечения текста, который не удалось получить прямым перехватом.
8. Индексация: Извлеченные структурированные данные сохраняются в Application Index. Ключом для индексации служит комбинация уникального идентификатора приложения и URI данной страницы.

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

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

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

• Контентные факторы:
  • Текстовый контент. Извлекается с помощью Text Extractor путем перехвата текстовых данных из объектов рендеринга (например, TextView).
• Мультимедиа факторы:
  • Изображения. Извлекаются с помощью Image Extractor (например, ImageView). Также могут извлекаться снимки всей страницы для превью или OCR.
• Ссылочные факторы:
  • Внутренние ссылки (Application page link data). Ссылки на другие страницы внутри того же приложения.
  • Внешние ссылки (Web page link data). Ссылки (URL), ведущие на веб-ресурсы.
• Структурные факторы:
  • Списки и меню. Извлекаются с помощью List Extractor (например, ListView), что позволяет получить данные о структуре и элементах списков, включая те, что находятся за пределами видимой области экрана.
  • Иерархия объектов. Система анализирует структуру объектов (например, Widget -> ListView -> Group -> TextView) для понимания контекста и структуры контента.
• Технические факторы:
  • URI страницы приложения (Application Page Identifier).
  • Идентификатор приложения (Application Identifier).

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

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

Методы извлечения:

• Прямое извлечение данных (Direct Extraction): Основной метод. Перехват данных из объектов рендеринга. Обеспечивает высокую точность и полноту.
• Оптическое распознавание символов (OCR): Упоминается как возможный метод анализа изображений для генерации текста (резервный вариант).

Стратегии индексации динамического контента:

• Для страниц с динамическим контентом, где URI зависит от параметров (например, страница акции с тикером в URI), система может индексировать не все возможные варианты, а только N самых популярных значений параметров (например, Топ-100 самых запрашиваемых акций).

Выводы

1. Контент приложений приравнивается к веб-контенту: Google разработал инфраструктуру для преодоления барьера между вебом и нативными приложениями. Контент внутри приложений теперь является индексируемым и доступным для поиска ресурсом наравне с веб-страницами.
2. Механизм сканирования через эмуляцию: Для доступа к контенту используется сложный метод — запуск приложения в виртуальной машине (Virtual Machine). Это позволяет системе взаимодействовать с приложением в контролируемой среде.
3. Приоритет прямого извлечения контента (Direct Extraction): Ключевой технической особенностью является использование специализированных Extractors, которые перехватывают данные непосредственно перед рендерингом (например, из объектов TextView). Это более надежно и точно, чем анализ скриншотов (OCR), и позволяет извлекать контент, скрытый прокруткой.
4. Критичность URI и Deep Linking: Индексация основана на привязке контента к уникальному идентификатору приложения и URI конкретной страницы. Это подчеркивает критическую важность реализации корректной схемы URI (Deep Linking) внутри приложения для его успешной индексации.
5. Контроль со стороны издателя: Издатели могут влиять на процесс, предоставляя список URI для индексации (Claim 3), что делает процесс управляемым.
6. Индексация динамического и внешнего контента: Система способна индексировать контент, загружаемый из внешних источников (API) во время выполнения приложения, используя Receiving Cache, и может приоритизировать популярные варианты динамических страниц (Top-N).

Практика

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

Для SEO-специалистов и разработчиков, работающих с мобильными приложениями:

• Внедрение App Indexing и Deep Linking: Критически важно обеспечить техническую возможность индексации. Необходимо разработать и внедрить логичную схему URI для ключевых экранов приложения (например, используя Firebase App Indexing). Каждый важный экран должен иметь уникальный URI.
• Использование стандартных компонентов UI: Проектируйте интерфейсы с использованием стандартных объектов ОС (например, TextView, ListView, ImageView в Android). Extractors настроены на работу именно с ними. Это гарантирует корректное извлечение контента.
• Оптимизация контента внутри приложения (On-App SEO): Контент внутри приложения (тексты, заголовки) должен быть оптимизирован под ключевые запросы. Так как система использует Text Extractors для получения чистого текста, важность качества контента такая же, как и на веб-сайтах.
• Предоставление карты приложения (URI List): Активно предоставляйте Google список ключевых URI для индексации (как описано в Claim 3). Это гарантирует сканирование наиболее важных разделов.
• Обеспечение доступности API: Если контент загружается динамически через API, убедитесь, что эти ресурсы доступны для системы индексации Google, так как она может перехватывать эти данные через Receiving Cache.

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

• Игнорирование App Indexing и отсутствие Deep Links: Рассматривать приложение как изолированную среду без URI для доступа к конкретному контенту. Это делает индексацию контента невозможной или бессмысленной.
• Использование графики или кастомного рендеринга для текста: Размещение важного контента в виде изображений или использование нестандартных графических библиотек для отрисовки текста. Text Extractor не сможет его извлечь напрямую. Полагаться только на OCR рискованно.
• Использование нестандартных или обфусцированных UI элементов: Хранение контента в сильно кастомизированных компонентах может помешать стандартным Extractors извлечь данные.
• Блокировка доступа к контенту (Login Wall): Размещение всего ценного контента за обязательным экраном входа, который виртуальная машина Google не сможет обойти при сканировании.

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

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

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

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

1. Задача: Обеспечить появление товаров из нативного приложения интернет-магазина в результатах поиска Google.
2. Действия (Техническая реализация):
   • Разработчики реализуют схему Deep Linking, где каждый товар имеет URI (например, app://com.example.store/product/12345).
   • Контент на странице товара (название, описание, цена) размещается в стандартных текстовых полях (TextView).
   • Магазин предоставляет Google список URI товаров для индексации.
3. Процесс Google (по патенту):
   • Google запускает приложение магазина в Virtual Machine.
   • Система переходит по URI app://…/product/12345.
   • Text Extractor перехватывает название, описание и цену из TextView. Image Extractor извлекает фото товара.
   • Данные индексируются в Application Index.
4. Ожидаемый результат: Когда пользователь ищет товар 12345 в Google на мобильном устройстве, в выдаче появляется результат (Deep Link). Клик по нему открывает страницу этого товара в приложении (если оно установлено).

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