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

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

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

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

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

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

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

Уникальный идентификатор (Uniform Resource Identifier), который ссылается на конкретную страницу внутри приложения. Используется для индексации и Deep Linking.

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

Технология, позволяющая при клике на результат поиска запускать приложение и сразу открывать конкретную страницу (Application Page), релевантную запросу.

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

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

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

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

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

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

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

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

View Class Objects (Объекты классов View)

Элементы пользовательского интерфейса в ОС. В патенте упоминаются TextView (текст), ImageView (изображения) и ListView (списки) как примеры для Android. Экстракторы получают данные из этих объектов.

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

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

1. Создается виртуальная машина (VM), эмулирующая ОС устройства.
2. Внутри VM запускается нативное приложение.
3. Система получает доступ к внутренним страницам приложения (Application Pages) в VM.
4. Для каждой страницы генерируются данные, описывающие ее контент (включая отображаемый текст).
5. Эти данные индексируются. Ключевой момент: Индексация происходит по комбинации URI страницы приложения и уникального идентификатора самого приложения.

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

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

Claim 3 (Зависимый от 1): Уточняет метод извлечения контента. Генерация данных включает извлечение текстовых данных, которые передаются в процесс рендеринга приложения. Это означает перехват сырых данных до отображения, а не анализ готового изображения (OCR).

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

1. Система получает "первые результаты поиска" (веб-результаты из Web Index).
2. Система получает "вторые результаты поиска" (результаты приложений из Application Index).
3. Система предоставляет пользователю объединенные результаты.

Claim 9 (Зависимый от 8): Уточняет функциональность результата поиска для приложения (Deep Linking). Результат включает изображение страницы приложения и данные, которые при выборе пользователем вызывают запуск приложения и открытие конкретной релевантной страницы.

Claim 17 (Независимый пункт): Детализирует процесс извлечения данных с акцентом на перехвате данных рендеринга.

1. Нативное приложение запускается в среде ОС (например, VM).
2. Извлекаются данные, описывающие контент, причем эти данные — это именно то, что предоставляется процессу рендеринга для отображения.
3. Извлеченные данные ассоциируются с URI страницы и ID приложения и индексируются.

Claim 18, 19, 20 (Зависимые от 17): Уточняют природу извлекаемых данных. Данные представляют собой объекты класса View, такие как text view object (текст) и list view object (списки).

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

Изобретение охватывает весь жизненный цикл индексирования и поиска контента приложений.

CRAWLING – Сканирование и Сбор данных
Основное применение патента. Вместо Googlebot используется User Device OS Virtual Machine. Система эмулирует взаимодействие с приложением для обнаружения новых страниц (автоматическое исследование меню и ссылок) или сканирует страницы по предоставленному списку URI (Claim 2).

INDEXING – Индексирование и извлечение признаков
Система извлекает признаки (текст, изображения, структуру) не из HTML, а непосредственно из процесса рендеринга приложения, перехватывая объекты View (TextView, ListView). Извлеченные данные сохраняются в Application Index, структурированные по App ID и Application Page URI.

METASEARCH – Метапоиск и Смешивание
Ключевой этап применения (Claim 8). Система объединяет результаты из Web Index и Application Index. Происходит формирование универсальной выдачи, включающей как веб-ссылки, так и Deep Links в приложения.

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

• Нативное приложение (например, APK).
• Опционально: список URI страниц приложения, предоставленный издателем.
• Данные, запрашиваемые приложением из внешних источников во время работы (перехватываются через Receiving Cache).

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

• Структурированные данные о контенте приложения в Application Index.
• Скриншоты отрендеренных страниц.
• Смешанная страница результатов поиска (SERP).

На что влияет

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

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

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

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

Процесс А: Индексирование приложения (Офлайн/Периодический)

1. Инициализация среды: Система запускает виртуальную машину (User Device OS Virtual Machine), эмулирующую целевую мобильную ОС.
2. Инсталляция и запуск: Нативное приложение устанавливается и запускается внутри VM.
3. Сканирование страниц: Система получает доступ к страницам приложения (Application Pages) путем автоматического исследования интерфейса или путем доступа по списку URI, предоставленному разработчиком (Claim 2).
4. Перехват данных рендеринга: Когда приложение готовит страницу к отображению, активируются Экстракторы (Text Extractor, List Extractor и т.д.). Они перехватывают данные (например, объекты TextView, ListView), передаваемые в Rendering Process.
5. Извлечение контента: Система извлекает текст, данные списков и другую информацию из перехваченных объектов. Также может быть сделан скриншот страницы (Screen Extractor).
6. Обработка внешних данных: Данные, которые приложение запрашивает из внешних источников, могут быть перехвачены и сохранены в Receiving Cache для индексации.
7. Сохранение и индексация: Извлеченный контент передается Индексатору. Данные сохраняются в Application Index и ассоциируются с ID приложения и URI данной страницы.

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

1. Получение запроса: Поисковая система получает запрос от пользователя.
2. Параллельный поиск: Система ищет релевантные результаты одновременно в Web Index и Application Index.
3. Формирование результатов приложений: Для результатов из приложений система формирует сниппет, используя извлеченный текст и релевантный скриншот. Формируются данные для Deep Linking (URI).
4. Смешивание и ранжирование: Результаты из обоих источников объединяются и ранжируются для формирования финальной SERP.
5. Взаимодействие (Deep Linking): При выборе результата приложения система отправляет команду на устройство пользователя для запуска приложения и открытия конкретного URI.

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

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

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

• Структурные факторы (Внутри приложения): Система анализирует иерархию объектов пользовательского интерфейса (View class objects). Извлекаются данные из стандартных компонентов:
  • TextView objects (или аналоги): для получения текста.
  • ListView objects (или аналоги): для получения данных из списков и меню.
  • ImageView objects (или аналоги): для получения изображений.
• Контентные факторы: Текст, отображаемый на странице приложения, извлеченный из объектов TextView.
• Технические факторы (Идентификаторы и Ссылки):
  • Native Application Identifier: Уникальный идентификатор приложения.
  • Application Page Identifier (URI): Идентификатор конкретной страницы внутри приложения.
  • Внутренние ссылки на другие страницы приложения (application page link data).
  • Внешние ссылки на веб-ресурсы (web page link data).
• Мультимедиа факторы: Изображения страниц (скриншоты), сгенерированные в процессе рендеринга.

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

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

• Метод извлечения текста: Перехват данных, передаваемых в Rendering Process (Claim 3, 17). Это обеспечивает доступ к точному тексту в бинарном виде и позволяет получить полный текст, даже если он скрыт за прокруткой (scrollable elements). В качестве альтернативы упоминается OCR (Optical Character Recognition) по изображению страницы (Claim 5), но основной акцент сделан на перехвате объектов.
• Индексация по идентификаторам: Ключевой метрикой для поиска является соответствие запроса контенту, проиндексированному по комбинации URI страницы и ID приложения (Claim 1, 17).
• Обработка параметризованных URI: Для страниц, контент которых зависит от параметров в URI (например, разные товары или акции), система может индексировать только N наиболее популярных значений параметров для контроля размера индекса.
• Использование структуры данных: Извлечение данных из иерархических объектов (ListView, Groups) позволяет системе понимать структуру контента на странице (например, связь между именем и телефоном в списке контактов).

1. Контент приложений индексируется как веб-контент: Google разработал инфраструктуру для сканирования и индексирования контента внутри нативных приложений, рассматривая их как источник информации наряду с веб-сайтами. Страницы приложений (Application Pages) являются аналогом веб-страниц в этом процессе.
2. Технология сканирования через эмуляцию: Для доступа к контенту используется эмуляция мобильных ОС в виртуальных машинах, что позволяет Google запускать приложения и анализировать их работу в контролируемой среде.
3. Высокоточное извлечение контента (Interception vs OCR): Ключевая особенность — извлечение данных путем перехвата объектов рендеринга (например, TextView). Это дает Google доступ к чистым, структурированным данным и позволяет индексировать контент, скрытый за прокруткой.
4. Критичность URI (Deep Links) для страниц приложений: Для успешной индексации и реализации Deep Linking каждая важная страница внутри приложения должна иметь уникальный идентификатор (URI). Без этого система не сможет проиндексировать страницу отдельно.
5. Смешивание выдачи (Blending): Патент явно закрепляет механизм объединения веб-результатов и результатов из приложений в единой выдаче. Контент из приложений напрямую конкурирует за видимость в SERP.
6. Контроль со стороны издателя: Патент предусматривает возможность для издателей указывать, какие именно URI следует индексировать (Claim 2).

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

• Реализовать Deep Linking и App Indexing (Firebase): Необходимо технически обеспечить возможность индексации. Это включает определение схемы URI для ключевых экранов приложения (Application Page Identifier). Это фундамент для работы описанной системы.
• Использовать стандартные UI-компоненты: Убедитесь, что контент отображается с использованием стандартных компонентов ОС (TextView, ListView). Система полагается на перехват данных из этих объектов. Использование кастомных компонентов может помешать индексации.
• Оптимизировать контент внутри приложения (App SEO): Текст на индексируемых экранах приложения (тот, что попадает в TextView) должен быть оптимизирован под ключевые запросы, аналогично оптимизации веб-страниц. Google извлекает этот текст для ранжирования.
• Связать сайт и приложение: Подтвердите связь между сайтом и приложением (например, через Google Play Console и Search Console) и обеспечьте соответствие контента (Content Parity). Указывайте канонические ссылки на эквивалентные веб-страницы для консолидации сигналов.
• Предоставить карту приложения (Sitemap для URI): Хотя возможно автоматическое сканирование, предоставление списка ключевых URI (как описано в патенте как опция, Claim 2) гарантирует, что система проиндексирует наиболее важные страницы.

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

• Игнорировать Deep Linking: Разработка приложения без структурированных URI для доступа к контенту делает его невидимым для этой системы индексации.
• Использовать нестандартные способы отрисовки текста: Если текст "нарисован" в кастомном компоненте, через Canvas/OpenGL или представлен только в виде изображения, система не сможет извлечь его через стандартные экстракторы (TextView).
• Блокировать доступ к публичному контенту: Скрывать индексируемый публичный контент за обязательной формой логина. Контент должен быть доступен виртуальной машине для индексации.
• Полагаться только на ASO: Ограничивать мобильное продвижение только оптимизацией в сторах (ASO), игнорируя потенциал привлечения трафика из органического поиска Google напрямую в приложение.

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

Патент подчеркивает стратегию Google по созданию единого поискового опыта, стирающего границы между вебом и нативными приложениями. Для SEO это означает, что оптимизация больше не ограничивается только веб-сайтом. Нативное приложение становится активом, который должен участвовать в органическом поиске. Стратегия должна быть комплексной (Web + App), обеспечивая техническую возможность индексации и оптимизацию контента в обеих средах.

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

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

1. Задача: Обеспечить показ карточки товара из нативного приложения в поиске Google.
2. Реализация (Разработка): Разработчики реализуют схему URI для карточек товаров, например: android-app://com.example.shop/product/{product_id}. Они убеждаются, что название товара, описание и цена отображаются с использованием стандартных компонентов (TextView).
3. Реализация (SEO/Маркетинг): Активируется Firebase App Indexing. Связь между сайтом и приложением подтверждается. Веб-страница товара содержит ссылку на эквивалентный URI приложения.
4. Как работает Google (по патенту): Виртуальная машина Google запускает приложение, переходит по URI товара. Text Extractors перехватывают текст (название, цена, описание) из TextView. Этот контент индексируется в Application Index.
5. Результат: Пользователь ищет товар в Google. В результатах поиска появляется сниппет из приложения. Если приложение установлено, клик по результату (Deep Link) сразу открывает карточку товара в приложении.