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

Описание

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

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

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

Запатентована система для присвоения оценки качества (Quality Score) контенту внутри нативных приложений, доступному через диплинки (deeplinks). Эта оценка вычисляется путем переноса оценок релевантности (Relevance Scores) от похожих веб-ресурсов. Система измеряет сходство (Similarity Score) между контентом приложения и веб-ресурсами и использует его как вес для переноса релевантности, позволяя ранжировать контент приложений без веб-эквивалента.

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

Механизм работает в два этапа:

• Офлайн (Подготовка): Система заранее вычисляет Similarity Scores между индексированным контентом приложений (Application Index) и веб-ресурсами (Web Index).
• Рантайм (Обработка запроса):
  • При получении запроса система определяет Relevance Scores для релевантных веб-ресурсов.
  • Для контента приложения вычисляется Quality Score. Это сумма произведений (Relevance Score похожего веб-ресурса) * (Similarity Score между контентом приложения и этим веб-ресурсом) для всех похожих веб-ресурсов.
  • Quality Score нормализуется, и диплинк приложения ранжируется вместе с веб-результатами в общей выдаче.

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

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

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

Влияние от среднего до высокого (6.5/10). Патент имеет первостепенное значение для App Store Optimization (ASO) и стратегий App Indexing. Он раскрывает конкретный механизм, как авторитетность и релевантность веб-страниц (даже чужих) могут напрямую влиять на видимость контента внутри приложений в поиске Google. Для веб-SEO он дает понимание того, как Google смешивает результаты на этапе Метапоиска.

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

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

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

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

Deeplink (Диплинк/Глубинная ссылка)

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

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

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

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

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

Quality Score (Оценка качества контента приложения)

Рассчитанная оценка для контента нативного приложения. Она выводится из Relevance Scores похожих веб-ресурсов и их Similarity Scores. В контексте патента этот термин фактически означает предполагаемую оценку релевантности.

Relevance Score (Оценка релевантности)

Оценка, указывающая на релевантность веб-ресурса поисковому запросу. Может быть основана на позиции в ранжировании.

Similarity Score (Оценка схожести)

Оценка, представляющая степень схожести между веб-ресурсом и контентом нативного приложения. Может рассчитываться с использованием n-gram Jaccard similarity, minimum hash или locality-sensitive hashing.

Web Index (Веб-индекс)

Индекс веб-ресурсов.

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

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

1. Система получает Relevance Scores для набора веб-ресурсов, релевантных запросу.
2. Для каждого веб-ресурса система получает Similarity Scores, представляющие схожесть между этим веб-ресурсом и контентом нативных приложений (на которые ссылаются диплинки).
3. Для каждого диплинка генерируется Quality Score на основе полученных оценок релевантности и схожести.
4. Отбираются диплинки, чей Quality Score удовлетворяет пороговому значению.
5. Отобранные диплинки предоставляются пользователю вместе с результатами веб-поиска.

Claim 4 (Зависимый от 1): Определяет формулу расчета Quality Score.

• Для каждого веб-ресурса вычисляется произведение его Relevance Score и Similarity Score между ним и контентом приложения.
• Quality Score является суммой этих произведений для всех веб-ресурсов.

Это математически представляет собой вычисление скалярного произведения (dot product) между вектором оценок релевантности веб-ресурсов и вектором оценок их сходства с контентом приложения. Это механизм переноса веса: чем релевантнее веб-страница и чем больше она похожа на контент приложения, тем больший вклад она вносит в оценку приложения.

Claim 8 (Зависимый от 1): Описывает процесс смешивания (blending) результатов.

1. Quality Score приложения нормализуется для соответствия шкале веб-оценок Relevance Scores, генерируя normalized relevance score.
2. Веб-результаты и диплинки ранжируются на основе их соответствующих (нормализованных) оценок для создания единого списка.
3. Единый ранжированный список предоставляется пользователю.

Claim 9 (Зависимый от 1): Уточняет, что контент, на который ссылается диплинк, не является веб-ресурсом. Это подчеркивает, что система предназначена для оценки контента, существующего только внутри приложений.

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

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

INDEXING – Индексирование и извлечение признаков
На этом этапе происходит сбор данных и ключевые офлайн-вычисления. Веб-ресурсы индексируются в Web Index, а контент приложений — в Application Index. Критически важным является расчет Similarity Scores между элементами этих двух индексов. В патенте указано, что это выполняется как часть бэкенд-процесса.

RANKING – Ранжирование
На этом этапе для исходного запроса генерируются стандартные веб-результаты и вычисляются их Relevance Scores (с помощью Resource Scorer).

METASEARCH – Метапоиск и Смешивание / RERANKING – Переранжирование
Основное применение патента. Система (Native Application Content Scorer) использует Relevance Scores веб-результатов (из этапа RANKING) и предварительно вычисленные Similarity Scores (из этапа INDEXING) для расчета Quality Score для контента приложений. Затем происходит нормализация оценок, смешивание (blending) веб- и app-результатов и финальное переранжирование.

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

• Поисковый запрос.
• Relevance Scores веб-ресурсов, релевантных запросу.
• Предварительно рассчитанные Similarity Scores между веб-ресурсами и контентом приложений (deeplinks).

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

• Унифицированный ранжированный список, содержащий как результаты веб-поиска, так и диплинки нативных приложений.

На что влияет

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

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

Алгоритм применяется при следующих условиях:

• Триггеры активации: Когда выполняется поиск (особенно на мобильных устройствах) и система определяет, что результаты из нативных приложений должны быть включены в выдачу.
• Условия:
  • Для контента приложения должны существовать рассчитанные Similarity Scores с существующими веб-ресурсами.
  • Рассчитанный Quality Score для контента приложения должен удовлетворять определенному порогу (threshold quality score).
• Ограничения: Может быть установлено максимальное количество (maximum number) отбираемых диплинков.

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

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

Фаза А: Офлайн подготовка (Индексирование и расчет схожести)

1. Сбор веб-ресурсов: Наполнение Web Index.
2. Получение контента приложений: Наполнение Application Index (используя Application Data Extractor and Processor).
3. Генерация оценок схожести: Расчет Similarity Scores между релевантными парами веб-ресурсов и контента приложений. Используются методы сравнения контента: n-gram Jaccard similarity, minimum hash (minhash) или locality-sensitive hashing (LSH).
4. Хранение соответствий: Сохранение карты схожести (например, в формате: Веб-документ_i -> (КонтентПриложения_j, Оценка_ij)).

Фаза Б: Рантайм (Обработка запроса)

1. Получение запроса.
2. Генерация веб-результатов: Определение релевантных веб-ресурсов и расчет их Relevance Scores.
3. Получение данных о схожести: Извлечение предварительно рассчитанных Similarity Scores для этих релевантных веб-ресурсов.
4. Расчет оценок качества приложений: Для каждого фрагмента контента приложения (диплинка), похожего на релевантные веб-ресурсы, рассчитывается Quality Score. Расчет производится путем суммирования произведений (Web Relevance Score * Similarity Score) для всех связанных веб-ресурсов.
5. Отбор диплинков: Выбор диплинков, у которых Quality Score превышает установленный порог.
6. Нормализация: Нормализация Quality Scores отобранных диплинков для соответствия шкале Relevance Scores веб-ресурсов (генерация normalized relevance score).
7. Смешивание и Ранжирование: Объединение и сортировка веб-результатов и отобранных диплинков на основе их соответствующих (нормализованных) оценок.
8. Предоставление результатов: Отображение унифицированного списка пользователю.

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

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

• Контентные факторы (Веб и Приложения): Содержимое веб-ресурсов и содержимое страниц нативных приложений (текст, структура). Эти данные необходимы для расчета Similarity Score на этапе индексации.
• Системные данные: Relevance Scores для веб-ресурсов, рассчитанные стандартными алгоритмами веб-ранжирования. Deeplinks (URI), необходимые для доступа к контенту приложения.

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

• Similarity Score: Рассчитывается офлайн с использованием методов сравнения контента: n-gram Jaccard similarity, minimum hash (minhash) или locality-sensitive hashing (LSH).
• Relevance Score (Веб): Стандартная оценка ранжирования. Патент предлагает один из возможных вариантов расчета на основе позиции в ранжировании: (s-r)/s, где s – общее количество результатов, r – ранг ресурса.
• Quality Score (Приложение): Ключевая метрика изобретения. Рассчитывается онлайн по формуле:
  Quality Score(x) = Σ [relevance(resource_k) * similarity(resource_k, x)].
  Это скалярное произведение (dot product) вектора релевантности веб-ресурсов и вектора схожести контента приложения с этими ресурсами.
• Threshold Quality Score: Пороговое значение, используемое для фильтрации релевантных диплинков.
• Нормализация: Используется масштабирующий коэффициент (scaling coefficient) для приведения Quality Score к шкале Relevance Score, создавая normalized relevance score.

Выводы

1. Перенос релевантности из веба в приложения: Google может ранжировать контент нативных приложений, даже если у него нет веб-эквивалента, путем переноса оценок релевантности с похожих веб-страниц (независимо от их владельца).
2. Веб-индекс как эталон (Ground Truth): Патент подчеркивает важность Web Index как основного источника данных о релевантности и качестве, которые затем распространяются на другие индексы (Application Index).
3. Критичность измерения схожести: Механизм сильно зависит от точности измерения схожести (Similarity Score). Чем больше контент приложения похож на авторитетный и релевантный веб-ресурс, тем выше будет его Quality Score.
4. Механизм расчета оценки: Формула (взвешенная сумма) показывает, что для высокого ранжирования контент приложения должен быть похож на веб-страницы, которые УЖЕ хорошо ранжируются по данному запросу.
5. Основа для универсального поиска: Это ключевой технический метод для Universal Search (Metasearch), позволяющий сравнивать и смешивать различные типы контента из разных индексов (cross-corpus ranking) через нормализацию оценок.

Практика

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

Рекомендации в первую очередь касаются App Store Optimization (ASO) и App Indexing.

• (ASO/App) Внедряйте App Indexing и Deeplinking: Обеспечьте комплексное внедрение индексации приложений (например, через Firebase). Контент внутри приложения должен быть доступен для сканирования через deeplinks, чтобы система могла рассчитать Similarity Scores.
• (ASO/App) Максимизируйте схожесть контента с высокоранжируемыми веб-страницами: Структура, ключевые слова и семантика контента в приложении должны соответствовать высококачественным веб-ресурсам в той же нише (даже если это сайты конкурентов). Это увеличивает Similarity Score и, как следствие, перенос высокого Relevance Score. Например, если приложение предлагает рецепты, убедитесь, что они структурно и семантически похожи на рецепты авторитетных кулинарных сайтов.
• (Web SEO/ASO) Поддерживайте сильное веб-присутствие (если применимо): Если у вас есть и сайт, и приложение, патент демонстрирует, что релевантность и качество ваших веб-страниц могут быть напрямую перенесены на похожий контент в приложении. Сильный сайт поддерживает видимость приложения.
• (ASO/App) Создавайте насыщенный текстовый контент: Контент внутри приложения должен быть текстово насыщенным и описательным. Это облегчает расчет Similarity Score с веб-ресурсами.

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

• (ASO/App) Создание полностью изолированного контента: Создание контента, который совершенно не похож ни на один высококачественный веб-контент (по структуре и семантике). В контексте данного механизма это помешает системе рассчитать Quality Score, так как не будет источника для переноса релевантности.
• (ASO/App) Использование «тонкого» контента или только изображений: Если контент представлен без текстового сопровождения, система не сможет эффективно рассчитать схожесть с веб-ресурсами.
• (ASO/App) Блокировка индексации контента приложений: Если контент не проиндексирован в Application Index, он не может участвовать в этом механизме ранжирования.
• (Web SEO/ASO) Игнорирование связи между Web SEO и ASO: Рассмотрение веб-поиска и поиска по приложениям как изолированных областей является ошибкой. Патент показывает прямую техническую связь, где веб-релевантность влияет на ранжирование приложений.

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

Патент подтверждает стратегию Google по унификации поиска на разных платформах и в разных корпусах контента. Он демонстрирует техническое решение проблемы сравнения разнородных данных: использование веба как эталона и измерение схожести для переноса оценок. Это подчеркивает важность наличия структурированного и семантически богатого контента как в вебе, так и в приложениях для максимальной видимости в поиске.

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

Сценарий: Ранжирование рецепта в нативном приложении без веб-сайта

1. Контент приложения (X): Рецепт «Курица Тикка Масала» в приложении «MyRecipes». У приложения нет веб-сайта. Контент использует стандартные списки ингредиентов и инструкции.
2. Поисковый запрос: «Курица Тикка Масала рецепт».
3. Веб-результаты и Релевантность:
   • Сайт A (BBC Good Food): Relevance Score = 0.95.
   • Сайт B (Allrecipes): Relevance Score = 0.90.
4. Расчет сходства (Офлайн): Google заранее рассчитал:
   • Сходство X и A (Similarity Score) = 0.8.
   • Сходство X и B (Similarity Score) = 0.7.
5. Расчет Quality Score (Рантайм): Quality Score(X) = (0.95 * 0.8) + (0.90 * 0.7) + [другие сайты] = 0.76 + 0.63 + … = 1.39+.
6. Результат: За счет переноса релевантности с высокоранжируемых, похожих веб-страниц, диплинк приложения получает высокий Quality Score. После нормализации он появляется в поисковой выдаче наряду с веб-результатами.

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