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

Описание

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

Патент решает проблему невозможности индексации контента, находящегося внутри нативных мобильных приложений (Native Applications), которые требуют обязательного предоставления учетных данных (account credential requirements) для доступа. Это ограничение мешает поисковым системам обнаруживать релевантный контент, скрытый за «стеной входа» (login wall), даже если этот контент является общедоступным (generic content), а не персонализированным.

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

Запатентована система и метод для индексирования контента в приложениях с ограниченным доступом. Система использует автоматизированный краулер, который получает или генерирует специальные robot account credentials (учетные данные робота), не принадлежащие реальным пользователям. Приложение запускается в эмулируемой среде (Virtual Machine), которая настроена так, будто робот-аккаунт уже вошел в систему. Это позволяет краулеру получить доступ к внутренним экранам приложения (environment instances), извлечь контент и проиндексировать его.

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

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

• Обнаружение ограничений: Система определяет, что нативное приложение требует входа для доступа к контенту.
• Получение учетных данных робота: Система проверяет наличие существующих robot account credentials для этого приложения или генерирует новые.
• Эмуляция и вход: Создается виртуальная машина, эмулирующая ОС мобильного устройства. Она настраивается так, чтобы ОС сообщала о том, что робот-аккаунт уже авторизован (signed in).
• Запуск и доступ: Приложение запускается внутри этой среды. Видя авторизованный статус в ОС, приложение предоставляет доступ к своему контенту.
• Извлечение данных: Краулер перемещается по экранам приложения (environment instances). Специальные экстракторы (Extractors) в виртуальной машине извлекают текст и медиа непосредственно из процесса рендеринга приложения. Данные, запрашиваемые приложением с внешних серверов, также могут перехватываться (например, через Receiving Cache).
• Индексирование: Извлеченные данные сохраняются в Application Index, доступном для поисковой системы.

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

Высокая. Хотя оригинальная заявка подана в 2015 году, текущая публикация является продолжением (continuation) от 2024 года, что указывает на сохраняющийся стратегический интерес Google к этой технологии. Индексация контента приложений (App Indexing) остается важной частью унификации поиска. Проблема контента, скрытого за login walls, по-прежнему актуальна для многих современных приложений (например, ритейл, социальные сети, сервисы).

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

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

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

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

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

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

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

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

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

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

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

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

Generic Content (Общедоступный контент)

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

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

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

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

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

Robot Account Credentials (Учетные данные робот-аккаунта)

Учетные данные (логин и пароль), созданные специально для автоматизированного краулера (automated crawler), а не для человека. Используются для обхода требований входа в систему при индексации.

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

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

Uniform Resource Identifier (URI)

Идентификатор (Deep Link), используемый для ссылки на конкретный Environment Instance внутри приложения.

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

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

1. Система получает (для автоматизированного краулера) набор robot account credentials. Ключевые характеристики этих данных: они предназначены для краулера, не связаны с реальным человеком и сгенерированы специально для краулера.
2. Система инстанцирует (запускает) нативное приложение (которое работает независимо от браузера) с использованием этих учетных данных.
3. Система получает доступ к environment instances (экранам) приложения.
4. Для каждого экземпляра:
   1. Генерируются данные, описывающие контент экземпляра (включая текст, отображаемый на экране).
   2. Важное условие: контент, доступ к которому получен с помощью robot account credentials, является контентом, не специфичным для какого-либо конкретного пользователя-человека (т.е. generic content).
   3. Данные индексируются в индексе, доступном для поиска.

Claim 4 и 5 (Зависимые): Детализируют процесс получения учетных данных.

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

Claim 7 и 8 (Зависимые): Детализируют процесс запуска приложения.

Приложение запускается внутри Virtual Machine, эмулирующей ОС устройства. Виртуальная машина инстанцируется так, что операционная система указывает на то, что аккаунт уже вошел в систему (signed in) с использованием предоставленных учетных данных. Это позволяет обойти экран входа.

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

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

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

Это основной этап применения патента. Application Indexer выступает в роли специализированного краулера для нативных приложений.

• Доступ к контенту: Вместо стандартного HTTP-запроса краулер использует Virtual Machine для запуска приложения.
• Обход ограничений: Система использует robot account credentials для обхода login walls, которые блокировали бы доступ стандартным краулерам.
• Сбор данных: Данные собираются не парсингом HTML, а путем извлечения информации из процесса рендеринга приложения с помощью Extractors. Данные, запрашиваемые приложением извне, также могут быть перехвачены (Receiving Cache).

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

Извлеченные данные (текст, медиа) обрабатываются и сохраняются в Application Index. На этом этапе также может происходить привязка контента к конкретным URI (Deep Links) и к характеристикам робот-аккаунта, использованного для доступа (например, региону).

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

• Бинарный файл нативного приложения.
• База данных robot account credentials.
• (Опционально) Список URI (Deep Links), предоставленный издателем приложения.

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

• Проиндексированные данные об environment instances (текст, скриншоты, видео), сохраненные в Application Index.

На что влияет

• Конкретные типы контента: Влияет на любой общедоступный (generic) контент внутри приложений: страницы товаров в e-commerce приложениях, статьи в новостных приложениях, профили пользователей в социальных сетях, списки локаций в картографических приложениях. Не влияет на веб-сайты.
• Конкретные ниши или тематики: Наибольшее влияние оказывается на ниши, где доминируют приложения, требующие регистрации для просмотра контента (например, некоторые сервисы по недвижимости, закрытые клубы распродаж, специализированные социальные сети).
• Языковые и географические ограничения: Система способна индексировать локализованный контент. Если приложение показывает разный общедоступный контент в зависимости от региона пользователя, система может использовать разные робот-аккаунты, сконфигурированные под эти регионы (например, аккаунт для Англии и аккаунт для Испании), для индексации всех вариантов.

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

• Триггеры активации: Алгоритм активируется, когда система идентифицирует нативное приложение, которое ограничивает доступ к своему контенту с помощью требований к учетным данным (account credential requirements). Это может быть определено путем анализа логов службы аутентификации, по указанию издателя или при обнаружении экрана входа при попытке сканирования.
• Исключения и особые случаи: Система предназначена только для индексации generic content. Она не предназначена (согласно Claim 1) для индексации контента, специфичного для конкретного пользователя (персональные данные, личные сообщения).

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

Процесс А: Генерация и управление робот-аккаунтами (Офлайн или по требованию)

1. Проверка существования аккаунта: Система проверяет базу данных Accounts на наличие robot account credentials для целевого приложения.
2. Генерация аккаунта (если требуется): Если аккаунта нет, система генерирует новый: логин, пароль и (опционально) другие данные профиля (например, регион, язык) для имитации определенного типа пользователя.
3. Сохранение: Учетные данные сохраняются для использования при индексации.

Процесс Б: Индексация приложения (Онлайн)

1. Определение ограничений доступа: Application Indexer определяет, что целевое приложение требует входа в систему.
2. Получение учетных данных: Индексатор извлекает соответствующий набор robot account credentials из базы данных.
3. Инициализация виртуальной машины: Запускается User Device OS Virtual Machine. ОС конфигурируется так, чтобы указывать, что робот-аккаунт уже авторизован (signed in).
4. Запуск приложения: Нативное приложение запускается внутри виртуальной машины. Приложение проверяет статус входа в ОС и предоставляет доступ к контенту.
5. Сканирование (Crawling): Индексатор получает доступ к environment instances. Это может происходить путем автоматического исследования меню и ссылок или путем доступа к предопределенным URI.
6. Извлечение данных: Для каждого environment instance активируются Extractors (Text, Video). Они перехватывают данные (например, объекты TextView, ImageView), передаваемые в процесс рендеринга. Данные, запрашиваемые с внешних серверов, могут перехватываться через Receiving Cache.
7. Обработка и индексация: Извлеченные данные (контент, метаданные, скриншоты) передаются в Indexer, который сохраняет их в Application Index, связывая с приложением и соответствующим URI.

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

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

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

• Технические факторы: Бинарный код нативного приложения (для запуска в VM); Uniform Resource Identifiers (URI/Deep Links) для навигации внутри приложения.
• Системные данные: Robot account credentials (логин, пароль); конфигурация виртуальной машины (тип ОС, состояние авторизации).
• Контентные факторы (извлекаемые): Текст, извлеченный из процесса рендеринга (из объектов типа TextView); данные изображений и видео, извлеченные Video Extractor. Данные, полученные из сетевых запросов (через Receiving Cache).
• Пользовательские/Географические факторы (имитируемые): Информация профиля робот-аккаунта (например, регион, язык), используемая для доступа к локализованному общедоступному контенту.

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

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

• Идентификация типа контента: Система различает generic content (подлежит индексации) и контент, специфичный для пользователя (не индексируется согласно этому патенту).
• Методы извлечения данных: Для извлечения текста и графики используются специализированные обработчики для конкретной ОС (например, обработка объектов TextView, ImageView), которые перехватывают данные до их финального рендеринга на экране.
• Извлечение видео/анимации: Система может выполнять предопределенные действия или скрипты для записи видеопоследовательности (например, «тура» по приложению) или использовать «bot mode».
• Классификация (Пользовательский контекст): Система может использовать таксономию типов пользователей для создания соответствующих робот-аккаунтов и последующей маркировки проиндексированного контента как релевантного для этих типов (например, контент для пользователей из Англии).

Выводы

1. «Стена входа» (Login Wall) не защищает от индексации: Основной вывод заключается в том, что Google разработал механизм для систематического обхода требований входа в систему в нативных приложениях с целью индексации общедоступного контента (generic content). Разработчики не должны предполагать, что контент не будет проиндексирован только потому, что он находится за экраном логина.
2. Использование робот-аккаунтов: Google использует автоматически сгенерированные robot account credentials, не связанные с реальными людьми, для доступа к контенту. Это стандартизированный процесс сканирования.
3. Индексация через эмуляцию и рендеринг: Индексация происходит путем запуска приложения в Virtual Machine и извлечения контента непосредственно из процесса рендеринга (например, перехват TextView) и сетевых запросов. Это означает, что индексируется то, что видит пользователь.
4. Фокус на общедоступном контенте: Патент явно подчеркивает, что индексируется только generic content, а не персональные данные пользователя.
5. Поддержка локализации и контекста: Система может создавать робот-аккаунты, имитирующие пользователей из разных регионов. Это позволяет индексировать различные версии общедоступного контента (например, локализованные предложения) и использовать их для повышения релевантности выдачи для соответствующих пользователей.
6. Важность технических аспектов App Indexing: Для успешной индексации контент должен быть доступен через навигацию внутри приложения или через URI (Deep Links), и представлен в форматах, которые могут быть обработаны экстракторами (стандартные текстовые и графические объекты ОС).

Практика

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

Рекомендации касаются стратегии App Indexing (Firebase App Indexing) для улучшения видимости контента приложения в поиске Google.

• Внедрение Deep Linking (URI): Необходимо убедиться, что все важные экраны (environment instances) с общедоступным контентом имеют уникальные URI. Хотя система может автоматически сканировать приложение, предоставление списка URI (например, через API или Sitemap для приложений) облегчает обнаружение контента.
• Обеспечение доступности контента для робот-аккаунтов: Если вы хотите, чтобы контент за login wall индексировался, убедитесь, что стандартный процесс регистрации позволяет создавать аккаунты без сложной верификации, которую не сможет пройти робот (например, сложная CAPTCHA или обязательная 2FA для доступа к общему контенту). Контент должен быть доступен сразу после стандартного входа.
• Использование стандартных элементов UI для рендеринга: Поскольку система извлекает контент из стандартных объектов рендеринга ОС (например, TextView в Android), следует избегать нестандартных способов отображения текста (например, текст как часть изображения или через кастомные графические движки), если вы хотите, чтобы он был проиндексирован.
• Оптимизация локализованного контента: Учитывая способность системы индексировать контент с помощью робот-аккаунтов, настроенных на разные регионы, необходимо обеспечить корректную локализацию контента в приложении. Убедитесь, что при смене региона в настройках аккаунта приложение действительно отображает соответствующий локализованный контент.

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

• Полагаться на Login Wall как на защиту от индексации: Ошибочно считать, что требование обязательной регистрации предотвратит индексацию общедоступных страниц товаров, профилей или статей в вашем приложении.
• Блокировка робот-аккаунтов или эмуляторов: Попытки идентифицировать и заблокировать аккаунты, используемые Google для индексации, или блокировать запуск приложения в эмулируемой среде, приведут к исключению контента приложения из поиска.
• Использование нестандартного рендеринга текста: Отображение важного для SEO текста способами, которые не могут быть перехвачены стандартными Extractors (например, рендеринг текста напрямую через OpenGL без использования TextView), помешает индексации.
• Смешивание персонального и общедоступного контента: Нечеткое разделение между generic content и персональными данными может усложнить работу индексатора и снизить релевантность индексируемых данных.

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

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

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

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

1. Ситуация: Приложение ритейлера требует создать аккаунт перед просмотром каталога товаров. Товары являются generic content.
2. Действия Google (согласно патенту):
   1. Google определяет необходимость входа.
   2. Система генерирует robot account credentials (например, user: robot_retailer_us, region: US).
   3. Запускается виртуальная машина, эмулирующая вход этого аккаунта на уровне ОС.
   4. Приложение запускается, видит авторизацию и открывает каталог.
   5. Краулер переходит по страницам товаров (environment instances).
   6. Text Extractor извлекает названия, описания и цены из TextView. Video Extractor сохраняет изображения товаров.
3. Действия SEO/Разработчика:
   1. Убедиться, что каждая страница товара имеет уникальный URI (Deep Link).
   2. Убедиться, что весь важный текст отображается через стандартные текстовые элементы UI.
   3. Не блокировать автоматическую регистрацию, используемую индексатором.
4. Ожидаемый результат: Товары из приложения появляются в поиске Google. При клике на результат пользователь перенаправляется (Deep Link) прямо на страницу товара в приложении (если оно установлено).

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