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

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

Application Crawling And Indexing System (Система сканирования и индексации приложений)

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

Application Manifest (Манифест приложения)

Файл (например, AndroidManifest.xml), содержащий метаданные о приложении, включая поддерживаемые шаблоны URI (схему, хост, путь).

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

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

Deep Links (Глубокие ссылки)

Ссылки на конкретные страницы контента (Application Pages) внутри приложения, в отличие от ссылок на главную страницу приложения.

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

Компоненты в виртуальной машине, которые извлекают данные контента (текст, изображения, списки) для индексации. Они перехватывают данные, предоставляемые процессу рендеринга приложения (например, объекты TextView в Android).

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

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

Publisher Affiliation Data (Данные об аффилиации издателя)

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

Synchronized Content (Синхронизированный контент)

Контент, который доступен для представления как на веб-ресурсах, так и на соответствующих страницах нативного приложения.

URI Pattern (Шаблон URI)

Структура, определяющая формат адресов контента в приложении. Может соответствовать веб-URL (http://example.com/path) или быть кастомным (app://content/id).

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

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

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

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

1. Система получает Publisher Affiliation Data, связывающие приложения с издателями.
2. Для каждого приложения система определяет, аффилировано ли оно с издателем, который предоставляет контент по URL, также используемым как URI приложения. Это определение включает:
   1. Определение URI Pattern для приложения.
   2. Проверку, совпадает ли издатель, определенный в URI Pattern (например, по имени хоста/домену), с издателем, указанным в Publisher Affiliation Data. Совпадение имени хоста URI с доменом издателя приводит к положительному результату.
3. Только для приложений, которые определены как аффилированные:
   1. Система выбирает URI (которые являются URL хоста издателя) на основе URI Pattern приложения. Выбираются URL, которые начинаются с этого шаблона.
   2. Система индексирует контент, доступный по этим URI для нативного приложения, в поисковом индексе.

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

Claim 6 (Зависимый от 1, но описывает альтернативный метод выбора URI): Детализирует итеративный процесс обнаружения ссылок (который может применяться, если URI не выбираются из существующего веб-индекса, как описано в Claim 4 и 5).

1. Приложение запускается, и выбирается первый URI на основе URI Pattern для генерации первой страницы приложения.
2. Запускается итеративный процесс:
   1. Определяются исходящие URI (outbound URIs) с текущей страницы приложения.
   2. Один или несколько исходящих URI выбираются для генерации последующих страниц приложения.

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

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

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

CRAWLING – Сканирование и Сбор данных

Это основной этап применения патента. Application Crawling And Indexing System выполняет несколько функций:

• Сбор данных об аффилиации: Получение Publisher Affiliation Data.
• Анализ пакетов приложений: Сканирование манифестов приложений (Application Manifest) для извлечения шаблонов URI.
• Выбор URI (Метод 1): Для аффилированных приложений система выбирает подходящие URL из существующего веб-индекса.
• Обнаружение URI (Метод 2): Для приложений с кастомными URI система запускает итеративный процесс краулинга внутри приложения.
• Рендеринг и Извлечение: Система запускает приложение в Virtual Machine и использует Extractors для сбора контента (текста, изображений) со страниц приложения.

INDEXING – Индексирование и извлечение признаков

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

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

• Publisher Affiliation Data (связь домен-приложение).
• Пакеты нативных приложений и их манифесты (Application Manifest).
• Существующий Web Index (для Метода 1).

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

• Индексированные данные страниц приложений (Application Page data) в Application Index.
• Связи между веб-URL и соответствующими им глубокими ссылками приложения.

На что влияет

• Типы контента: Влияет на любой контент внутри мобильных приложений, который может быть проиндексирован (текст, изображения, списки). Особенно актуально для приложений с богатым контентом: новости, рецепты, базы данных (фильмы, музыка), e-commerce (товары).
• Синхронизированный контент: Механизм напрямую нацелен на индексацию Synchronized Content, который дублируется на сайте и в приложении.
• Форматы контента: Влияет на контент, который может быть извлечен с помощью Extractors (например, стандартные элементы интерфейса, такие как TextView, ImageView в Android).

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

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

Условия активации (Метод 1 - Web-affiliated):

• Издатель предоставил Publisher Affiliation Data.
• Манифест приложения содержит URI Pattern (схему, хост).
• URI Pattern приложения совпадает с данными аффилиации издателя (доменом).

Если аффилиация не подтверждена, URI издателя не обрабатываются для данного приложения.

Условия активации (Метод 2 - Итеративное обнаружение):

• Приложение поддерживает глубокие ссылки (кастомные URI или веб-URL).
• Система может успешно запустить приложение в Virtual Machine.
• На страницах приложения присутствуют исходящие ссылки (outbound URIs), которые могут быть обнаружены системой.

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

Процесс А: Индексация аффилированных приложений (Web-affiliated)

1. Получение данных аффилиации: Система получает Publisher Affiliation Data, определяющие связь между издателями (доменами) и приложениями.
2. Анализ манифеста: Для нативного приложения извлекается URI Pattern (схема, хост, путь) из его манифеста.
3. Проверка аффилиации: Система сравнивает хост из URI Pattern приложения с доменом издателя из Publisher Affiliation Data.
4. Принятие решения:
   • Если НЕ аффилировано: Не обрабатывать URI издателя для этого приложения. Процесс останавливается.
   • Если Аффилировано: Перейти к шагу 5.
5. Выбор URI: Система ищет в Веб-индексе URL, которые соответствуют URI Pattern (например, начинаются с http://example.com/path/).
6. Сканирование контента приложения: Для выбранных URI система запускает приложение в виртуальной машине и передает URI приложению для генерации страницы.
7. Извлечение контента: Используя Extractors, система извлекает контент (текст, изображения) со сгенерированной страницы приложения.
8. Индексация: Извлеченный контент индексируется в Application Index и связывается с соответствующим URI.

Процесс Б: Итеративное обнаружение ссылок (Custom URIs или альтернатива Процессу А)

1. Определение шаблона URI: Система определяет базовый URI Pattern для приложения (например, из манифеста).
2. Инициализация: Система запускает нативное приложение в виртуальной машине и выбирает первый URI (например, главную страницу) для генерации первой страницы приложения.
3. Начало итерации.
4. Обнаружение исходящих ссылок: Система анализирует текущую страницу приложения для определения outbound URIs. Это может включать анализ извлеченного текста на соответствие URI Pattern или использование API индексации.
5. Выбор следующих URI: Система выбирает один или несколько обнаруженных исходящих URI для следующего шага сканирования.
6. Генерация и Индексация: Для выбранных URI генерируются следующие страницы приложения. Контент извлекается с помощью Extractors и индексируется.
7. Проверка завершения: Система проверяет, остались ли необработанные URI или достигнуто ли условие остановки.
   • Если НЕТ (процесс продолжается): Вернуться к шагу 4 для новых страниц.
   • Если ДА: Завершить индексацию для данного приложения.

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

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

Патент фокусируется на инфраструктуре индексации и использует следующие типы данных:

• Технические факторы:
  • URL/URI структура: Критически важные данные. Используются URI Patterns, извлеченные из манифеста (схема, хост, префикс пути).
  • Application Manifest Data: Используется для определения поддерживаемых приложением URI и проверки аффилиации.
• Контентные факторы: (Извлекаются во время индексации)
  • Текст: Извлекается с помощью текстовых Extractors (например, TextView) из страниц приложения.
  • Изображения: Извлекаются с помощью графических Extractors (например, ImageView).
  • Списки: Данные из прокручиваемых списков извлекаются с помощью соответствующих Extractors (например, ListView).
• Структурные факторы:
  • Внутренние ссылки приложения: Outbound URIs, обнаруженные на страницах приложения, используются для итеративного краулинга.
• Внешние данные:
  • Publisher Affiliation Data: Данные верификации от издателя, связывающие домен и приложение.
  • Web Index: Существующий индекс веб-страниц используется для поиска кандидатов URL для сканирования аффилированных приложений.
• Поведенческие факторы (Упоминаются опционально):
  • Патент упоминает возможность использования API для отслеживания того, какие ссылки реально просматриваются пользователями внутри приложений. Эти данные могут использоваться как дополнительный источник ссылок и для определения популярности ссылок (link popularity) с целью приоритизации краулинга.

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

Конкретные метрики ранжирования в патенте не описаны, но описаны метрики и процессы для индексации:

• Проверка аффилиации (Affiliation Check): Бинарная проверка (Да/Нет). Основана на точном совпадении хоста из URI Pattern приложения и домена издателя из Publisher Affiliation Data.
• Соответствие шаблону URI (URI Pattern Matching): Проверка, начинается ли веб-URL с шаблона URI, поддерживаемого приложением.
• Link Popularity (Популярность ссылок) (Опционально): Метрика, основанная на данных о реальном использовании ссылок пользователями внутри приложения. Используется для приоритизации краулинга.

1. App Indexing требует технической реализации: Индексация контента приложений не происходит автоматически без соответствующей технической подготовки. Приложение должно поддерживать глубокие ссылки (либо через веб-URL, либо через кастомные URI), и эта поддержка должна быть корректно описана в манифесте приложения.
2. Верификация аффилиации критична для веб-контента: Google строго проверяет связь между доменом и приложением. Индексация контента сайта через приложение возможна только в том случае, если URI Pattern в манифесте приложения совпадает с верифицированным доменом издателя. Это защищает контент от индексации через сторонние приложения.
3. Два пути индексации: Система может либо использовать уже известные веб-URL для доступа к контенту приложения (если приложение аффилировано с сайтом), либо активно сканировать приложение изнутри, итеративно переходя по внутренним ссылкам (особенно актуально для приложений без сайтов или с уникальным контентом).
4. Метод извлечения контента (Эмуляция и Экстракторы): Google не просто анализирует скриншоты. Система запускает приложение в виртуальной машине и использует Extractors для перехвата данных (текст, изображения), передаваемых на рендеринг. Это означает, что индексируется именно то, что видит пользователь в стандартных элементах интерфейса.
5. Поведенческие данные для приоритизации: Патент предусматривает возможность использования данных о реальном поведении пользователей в приложении (популярность ссылок) для определения приоритетов сканирования. Это подчеркивает важность интеграции API индексации (например, Firebase App Indexing API) для передачи этих сигналов.

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

• Реализация Deep Linking: Убедитесь, что приложение поддерживает глубокие ссылки для всего важного контента. Для Android это означает настройку intent filters в AndroidManifest.xml для обработки HTTP URL (App Links) или кастомных схем URI.
• Синхронизация контента сайта и приложения: Если приложение дублирует контент сайта, используйте те же самые HTTP URL для доступа к контенту в приложении. Это упрощает индексацию, так как Google может использовать уже известные веб-URL (Процесс А в патенте).
• Верификация связи сайта и приложения: Обязательно подтвердите аффилиацию между сайтом и приложением. Для Android App Links это включает размещение файла Digital Asset Links (assetlinks.json) на веб-сайте. Это соответствует требованию патента о проверке Publisher Affiliation Data.
• Использование стандартных элементов UI: Поскольку система использует Extractors, ориентированные на стандартные элементы интерфейса (например, TextView, ImageView), старайтесь использовать их для отображения основного контента. Это повышает вероятность корректного извлечения данных.
• Интеграция App Indexing API (например, Firebase): Для приложений с кастомными URI или для улучшения обнаружения ссылок интегрируйте API индексации. Это позволяет явно указывать исходящие ссылки и передавать сигналы о действиях пользователей, что может улучшить приоритизацию сканирования (link popularity).

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

• Блокировка доступа к контенту: Размещение всего важного контента за экраном обязательной авторизации (login wall) может помешать системе индексации получить доступ к страницам приложения.
• Использование нестандартных или сложных интерфейсов: Использование кастомных движков рендеринга (например, в играх) или сложных интерактивных элементов (Flash, Canvas без текстового представления) для отображения основного контента может помешать работе Extractors.
• Игнорирование Deep Linking: Разработка приложения как монолитной структуры без возможности адресации к конкретным экранам через URI делает индексацию контента невозможной.
• Несоответствие URI на сайте и в приложении: Если приложение и сайт предоставляют одинаковый контент, но используют разные структуры URI, это усложняет для Google понимание связи между ними и может потребовать более ресурсоемкого итеративного сканирования вместо использования готовых веб-URL.

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

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

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

Сценарий 1: Индексация приложения интернет-магазина (Аффилированного с сайтом)

1. Задача: Обеспечить показ товаров из приложения в результатах поиска Google.
2. Действия (по Патенту):
   • Разработчики настраивают манифест приложения так, чтобы он поддерживал URI Pattern, соответствующий сайту (например, http://www.example.com/product/).
   • Маркетологи верифицируют связь между доменом example.com и приложением (Publisher Affiliation Data).
3. Процесс Google:
   • Google проверяет аффилиацию. Она подтверждена.
   • Google берет уже известные URL товаров из Веб-индекса (например, http://www.example.com/product/123).
   • Google запускает приложение в виртуальной машине, передает ему этот URL.
   • Приложение открывает страницу товара 123.
   • Extractors извлекают название, описание, цену и изображение товара.
4. Результат: Контент товара индексируется. Когда пользователь ищет товар 123 на мобильном устройстве, в выдаче появляется глубокая ссылка, ведущая прямо в приложение.

Сценарий 2: Индексация контентного приложения без веб-сайта (Кастомные URI)

1. Задача: Проиндексировать статьи в приложении, у которого нет веб-версии.
2. Действия (по Патенту):
   • Разработчики реализуют поддержку кастомных URI (например, myapp://article/456) и интегрируют App Indexing API для помощи в обнаружении ссылок.
3. Процесс Google:
   • Google запускает приложение в виртуальной машине, начиная с главной страницы.
   • Система обнаруживает исходящие ссылки на статьи (outbound URIs) на главной странице (с помощью API или анализа текста).
   • Google переходит по ссылке myapp://article/456.
   • Extractors извлекают текст статьи.
   • Система итеративно ищет ссылки на другие статьи внутри текущей статьи.
4. Результат: Статьи индексируются, несмотря на отсутствие веб-сайта, благодаря итеративному процессу обнаружения.