Как Google проверяет соответствие контента в мобильных приложениях и на веб-страницах для показа App Deep Links в поиске

Описание

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

Патент решает проблему обеспечения надежности и точности при интеграции контента нативных приложений в веб-поиск (App Indexing/Deep Linking). Он устраняет риск того, что ссылка, ведущая из результатов поиска в нативное приложение (Native Application Search Result), приведет пользователя к контенту, который отличается от соответствующей проиндексированной веб-страницы. Это может произойти из-за ошибок в сопоставлении адресов (Address Pairs), устаревших данных в бэкенде приложения или намеренных манипуляций (например, клоакинга). Система гарантирует консистентность пользовательского опыта.

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

Запатентована система и метод для автоматической верификации согласованности контента (Consistent Content) между нативным приложением и соответствующим веб-ресурсом. Система сравнивает контент, полученный по адресу приложения и адресу веб-ресурса (Address Pair), используя различные методы анализа (NLP и структурный анализ). Только если контент признан согласованным, пара адресов валидируется, что позволяет поисковой системе использовать веб-ресурс как прокси для оценки и ранжирования контента приложения (scoring proxy).

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

Механизм работает в два этапа: Верификация и Применение.

• Верификация (Индексирование/Офлайн): Система получает Address Pair (адрес приложения и веб-URL). Она загружает контент из обоих источников и сравнивает их с помощью метрик: сходство n-грамм (n-gram similarity), совпадение сущностей (entity matching), совпадение фраз (phrase matching) и сходство векторов признаков (feature similarity). Если метрики превышают пороги, пара валидируется и сохраняется в индексе (index validation data).
• Применение (Поиск/Онлайн): При получении запроса система определяет релевантные веб-ресурсы и проверяет, какие приложения установлены у пользователя. Если релевантный веб-ресурс имеет валидированную пару адресов с установленным приложением, система генерирует Native Application Search Result (App Deep Link), который запускает приложение и направляет его к нужному контенту.

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

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

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

Патент имеет существенное значение (7.5/10) для SEO-стратегий компаний, имеющих как веб-сайт, так и нативное приложение. Он раскрывает строгие технические требования к паритету контента для работы App Indexing. Патент также подтверждает, что веб-ресурс используется как scoring proxy для приложения. Это означает, что ранжирование App Deep Link напрямую зависит от сигналов ранжирования соответствующей веб-страницы. Без верификации консистентности приложение не будет показано в SERP вместо веб-ссылки.

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

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

Address Pair (Пара адресов)

Связка первого адреса (для нативного приложения, например, deep link URI) и второго адреса (для веб-ресурса, например, URL), которые предположительно предоставляют одинаковый контент.

Boilerplate content (Шаблонный контент)

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

Consistent Content (Консистентный/Согласованный контент)

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

Entity Match Measure (Мера совпадения сущностей)

Метрика, оценивающая схожесть контента на основе количества общих идентифицированных сущностей (концепций или объектов, например, узлов в Knowledge Graph).

Feature Similarity Measure (Мера схожести признаков)

Метрика, оценивающая схожесть на основе векторов признаков (content feature vector), которые описывают форматирование и структуру контента (например, заголовки, подзаголовки).

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

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

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

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

N-gram Similarity Measure (Мера схожести n-грамм)

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

Phrase Match Measure (Мера совпадения фраз)

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

Scoring Proxy (Прокси для оценки)

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

Validation Data (Данные валидации)

Информация, хранящаяся в индексе (index validation data), которая подтверждает, что Address Pair была проверена и контент по этим адресам признан консистентным.

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

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

1. Система получает доступ к данным валидации индекса (index validation data) для нативного приложения, установленного на устройстве пользователя. Эти данные хранят Address Pairs и статус их валидации.
2. Статус валидации подтверждает, что контент из адреса приложения (первый контент) и веб-адреса (второй контент) был сравнен и признан консистентным (Consistent Content). Консистентность определяется на основе достижения пороговых значений (match thresholds) одной или несколькими мерами схожести (similarity match measures).
3. Система получает поисковый запрос от устройства пользователя.
4. Система идентифицирует веб-ресурсы, релевантные запросу.
5. Система определяет, что релевантный веб-ресурс адресуется вторым адресом (веб-адресом) из валидированной пары адресов для данного нативного приложения.
6. В ответ на это определение генерируется Native Application Search Result, который включает первый адрес (адрес приложения/deep link) из валидированной пары.
7. Веб-результаты и результат для нативного приложения предоставляются устройству пользователя.

Claims 2, 3, 4 (Зависимые от 1): Детализируют методы сравнения контента, используемые для верификации (упомянутые в Claim 1).

• Claim 2: Сравнение основывается на мере схожести n-грамм (N-gram Similarity Measure).
• Claim 3: Сравнение основывается на мере совпадения сущностей (Entity Match Measure), которая измеряет совпадение между сущностями, описанными в контенте.
• Claim 4: Сравнение основывается на мере схожести признаков (Feature Similarity Measure). Эта мера использует векторы признаков, которые представляют особенности форматирования (formatting features) контента.

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

Изобретение затрагивает несколько этапов поиска, разделяя процесс на верификацию (во время индексирования) и генерацию результатов (во время поиска).

CRAWLING & INDEXING – Сканирование, Сбор данных и Индексирование
Основной этап для верификации. Компонент Native Application Content/Web Content Verifier выполняет проверку консистентности. Он получает Address Pairs, извлекает контент из веб-ресурса и из нативного приложения. Извлечение контента из приложения может потребовать его запуска (эмуляции) и мониторинга запросов данных или анализа его интерфейса (опрос text handlers, view handlers). После извлечения происходит сравнение контента. Результат сравнения (Validation Data) сохраняется в индексе.

RANKING – Ранжирование
Стандартные алгоритмы ранжирования определяют релевантные веб-ресурсы. Веб-ресурс используется как scoring proxy для контента приложения.

METASEARCH – Метапоиск и Смешивание / RERANKING – Переранжирование
На этом этапе происходит генерация результатов для приложений. Компонент Native Application Search Result Generator анализирует топовые результаты этапа RANKING. Он проверяет выполнение условий:

1. Имеет ли релевантный веб-ресурс валидированную пару адресов (проверка Validation Data в индексе)?
2. Установлено ли соответствующее нативное приложение на устройстве пользователя (используя данные, переданные в запросе или данные профиля пользователя/устройства)?

Если оба условия выполнены, система генерирует Native Application Search Result (App Deep Link) и смешивает его с веб-результатами.

На что влияет

• Конкретные типы контента: Влияет на любой контент, который дублируется в нативном приложении и на веб-сайте: карточки товаров, новостные статьи, рецепты, профили пользователей, списки объектов.
• Конкретные ниши или тематики: Наибольшее влияние в нишах с сильным присутствием нативных приложений: E-commerce, медиа и новости, тревел, банкинг, социальные сети.
• Платформы: Влияет исключительно на результаты поиска на мобильных устройствах, где возможно использование нативных приложений.

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

Процесс верификации (Индексирование):

• Применяется при обнаружении новых заявленных Address Pairs (deep links).
• Может применяться периодически для перепроверки ранее валидированных пар, чтобы убедиться в сохранении консистентности.

Процесс генерации результатов (Поиск):

• Применяется в реальном времени во время обработки поискового запроса.
• Триггеры активации: Активируется при одновременном выполнении трех условий:
  1. Веб-ресурс признан релевантным запросу.
  2. Для этого веб-ресурса существует валидированная пара адресов (Validation Data = True).
  3. Соответствующее нативное приложение установлено на устройстве пользователя.

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

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

1. Получение данных: Система получает доступ к Address Pair (первый адрес для приложения, второй адрес для веб-ресурса).
2. Извлечение первого контента (Приложение): Система получает контент для первого адреса. Это может включать запуск нативного приложения, мониторинг данных, получаемых в ответ на его запросы, или анализ обработчиков текста и представлений приложения.
3. Извлечение второго контента (Веб): Система получает контент для второго адреса (веб-ресурса).
4. Предварительная обработка (Опционально): Игнорирование или дисконтирование шаблонного контента (boilerplate content).
5. Анализ и расчет мер схожести: Система обрабатывает оба набора контента для расчета различных метрик:
   • Извлечение n-грамм и расчет N-gram Similarity Measure. Учитывается взвешивание по расположению (заголовки) или частоте (редкие n-граммы важнее).
   • Идентификация сущностей и расчет Entity Match Measure.
   • Определение фраз и расчет Phrase Match Measure (например, на основе edit distance).
   • Определение векторов признаков форматирования и расчет Feature Similarity Measure.
6. Определение консистентности: Система сравнивает полученные меры схожести с предустановленными пороговыми значениями. Контент признается консистентным, если одна, несколько или комбинация мер превышают порог.
7. Валидация и сохранение: Если контент консистентен, Address Pair валидируется, и Validation Data сохраняется в индексе ресурсов. Если нет – пара не валидируется.

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

1. Получение запроса: Система получает поисковый запрос и данные для идентификации приложений, установленных на устройстве пользователя (идентификаторы приложений или идентификатор устройства/аккаунта).
2. Получение веб-результатов: Система получает данные о веб-ресурсах, релевантных запросу.
3. Определение установленных приложений: Система определяет, какие нативные приложения установлены у пользователя.
4. Проверка условий: Система определяет, является ли релевантный веб-ресурс частью валидированной пары адресов (на основе Validation Data) для установленного нативного приложения.
5. Генерация результата приложения: Если условие выполнено, система генерирует Native Application Search Result. Этот результат включает данные (например, deep link или параметры командной строки), которые заставят приложение запросить консистентный контент при запуске.
6. Предоставление SERP: Система предоставляет веб-результаты и результаты для нативных приложений пользователю.

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

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

• Контентные факторы: Текст, извлеченный из интерфейса нативного приложения и с веб-страницы. Включает заголовки, подзаголовки, основной текст.
• Структурные факторы (Formatting Features): Форматирование, расположение и заметность элементов контента. Используются для взвешивания n-грамм (например, n-граммы в заголовках важнее) и для расчета векторов признаков (content feature vectors).
• Технические факторы: Адреса (URI/URL), используемые для извлечения контента (Address Pairs).
• Пользовательские факторы (На этапе поиска): Данные об установленных нативных приложениях на устройстве пользователя.

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

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

• N-gram Similarity Measure: Рассчитывается на основе извлеченных n-грамм (например, биграмм и триграмм). Может использоваться косинусное сходство разреженных векторов. Упоминается взвешивание n-грамм:
  • По расположению/форматированию (заголовки важнее основного текста).
  • По частотности (редкие n-граммы важнее частых, таких как стоп-слова — inverse proportion to their respective frequencies).
• Entity Match Measure: Измеряет совпадение между идентифицированными сущностями (узлами в Knowledge Graph). Метрика пропорциональна количеству совпавших сущностей.
• Phrase Match Measure: Измеряет совпадение между фразами. Совпадения могут определяться точным соответствием или на основе расстояния редактирования (edit distance threshold).
• Feature Similarity Measure: Измеряет схожесть между векторами признаков (feature vectors), представляющими особенности форматирования контента (заголовки, списки и т.д.).
• Пороговые значения (Thresholds): Используются для бинарного решения о консистентности на основе рассчитанных мер схожести.

Выводы

1. Паритет контента обязателен для App Indexing: Google не полагается на заявленные издателями связи (deep links). Система автоматически и строго проверяет, действительно ли контент в приложении соответствует контенту на связанной веб-странице. Отсутствие верификации блокирует показ App Deep Links.
2. Веб-ресурс как «Scoring Proxy» для приложения: Патент подтверждает, что веб-ресурс используется как scoring proxy для нативного приложения. Это означает, что ранжирование результата приложения основывается на сигналах ранжирования соответствующей веб-страницы.
3. Комплексный подход к сравнению: Для верификации используется не простое сравнение текста, а комбинация методов: N-gram Similarity, Entity Matching, Phrase Matching и Feature Similarity (структура). Это позволяет подтверждать консистентность, даже если верстка отличается.
4. Учет структуры и значимости контента: Система учитывает форматирование (заголовки) при расчете схожести признаков и при взвешивании n-грамм. Также учитывается частотность n-грамм (редкие термины важнее).
5. Обработка Boilerplate: Система способна игнорировать или снижать вес шаблонного контента (boilerplate content) при сравнении, фокусируясь на основном содержании.
6. Условия показа App Deep Links: Показ требует выполнения трех условий: релевантность веб-страницы, наличие валидированной связи (консистентность контента) и факт установки приложения у пользователя.

Практика

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

• Обеспечение полного паритета основного контента: Критически важно, чтобы экран приложения и связанная веб-страница содержали идентичный основной контент. Тексты, заголовки, цены, характеристики и ключевые сущности должны совпадать.
• Использование единого источника данных (Unified Backend/API): Лучшая стратегия — использовать единый бэкенд и API для предоставления контента как на веб-сайт, так и в нативное приложение. Это технически гарантирует синхронизацию данных и минимизирует риск расхождений.
• Поддержание схожей информационной структуры: Так как используется Feature Similarity Measure (анализ форматирования и структуры), иерархия заголовков и организация основного контента должны быть максимально близки в приложении и на веб-странице.
• Использование идентичной терминологии и сущностей: Обеспечьте использование одних и тех же названий продуктов, имен, терминов и идентификаторов (SKU) на обеих платформах для улучшения Entity Match Measure и N-gram Similarity Measure.
• Фокус на SEO веб-ресурса: Поскольку веб-страница является scoring proxy, необходимо продолжать инвестировать в оптимизацию и продвижение веб-сайта. Сильные позиции сайта позволят соответствующим App Deep Links также высоко ранжироваться.

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

• Различия в основном контенте (App Cloaking): Предоставление разной информации на сайте и в приложении по одному и тому же deep link (например, разные описания или цены). Это будет расценено как неконсистентный контент и заблокирует App Indexing.
• Усеченный контент в приложении: Попытка связать веб-страницу с экраном приложения, который содержит только краткую выжимку информации, доступной на сайте. Система посчитает это недостаточным для признания консистентности.
• Задержки в обновлении контента приложения: Если контент в приложении устаревает по сравнению с веб-версией, система может отменить валидацию Address Pair при повторной проверке.
• Игнорирование паритета с мобильной версией сайта: Патент указывает, что если у издателя есть несколько сайтов (например, десктопный и мобильный), контент приложения должен быть консистентен с любым из них.

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

Патент подтверждает стратегию «Web First» для индексации контента приложений. Google полагается на свой веб-индекс как на основной источник информации и использует его для валидации и ранжирования контента приложений. Для бизнеса это означает, что веб-присутствие остается фундаментом для поиска. Нативные приложения должны рассматриваться как дополнительный канал доступа к контенту, а успех App Indexing напрямую зависит от качества веб-сайта и строгого поддержания паритета контента.

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

Сценарий: Обеспечение App Indexing для карточки товара E-commerce

1. Задача: Гарантировать, что при поиске товара на мобильном устройстве у пользователя с установленным приложением появится App Deep Link.
2. Анализ требований патента: Система Google должна верифицировать, что контент на веб-странице (example.com/product/123) и на экране приложения (app://example/product?id=123) является консистентным.
3. Действия SEO и разработки:
   • Настроить API так, чтобы оно отдавало идентичные данные для обеих платформ: название, цена, описание, характеристики (SKU).
   • Провести аудит соответствия структуры: убедиться, что заголовки и основные блоки информации схожи.
   • Корректно внедрить App Indexing, связав URL и URI.
4. Процесс Google: Система сравнивает сущности (товар, бренд), n-граммы (описание) и структуру. Она игнорирует различия в навигации (boilerplate).
5. Ожидаемый результат: Content Verifier признает контент консистентным и валидирует Address Pair. Это позволит генерировать Native Application Search Result в мобильной выдаче, используя сигналы ранжирования веб-страницы.

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