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

Описание

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

Патент решает проблему объединения результатов поиска из разных источников, которые используют несопоставимые сигналы ранжирования. Конкретно, он описывает, как совместить в одной выдаче (1) нативные приложения, имеющие соответствующий веб-ресурс (corresponding web resource), и (2) нативные приложения, у которых такого ресурса нет (app-only). Поскольку сигналы для ранжирования веб-контента (например, ссылки, авторитетность домена) отличаются от сигналов для app-only контента (например, загрузки, отзывы, использование приложения), их исходные оценки релевантности нельзя напрямую сравнивать.

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

Запатентован метод для слияния различных наборов результатов ранжирования нативных приложений. Система генерирует два отдельных рейтинга: один для приложений с веб-аналогами (first ranking), другой для app-only приложений (second ranking). Ключевым элементом является расчет Universal Ranking Score для каждого элемента. Эта оценка базируется исключительно на позиции элемента в его собственном списке и общем количестве элементов в этом списке, что позволяет объединить списки без нормализации исходных оценок ранжирования.

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

Механизм работает следующим образом:

• Сегментация и Индексирование: Приложения делятся на две группы. Приложения с веб-версией могут индексироваться в Web Index, а app-only — в Application Index.
• Раздельное ранжирование: Web Ranker ранжирует первую группу, используя как веб-сигналы, так и сигналы приложений. Application Ranker ранжирует вторую группу, используя только сигналы приложений.
• Расчет универсальной оценки: Rank Combiner рассчитывает Universal Ranking Score для каждого результата. Эта оценка зависит от его позиции (k) и общего числа результатов в списке (n). В патенте предложены формулы, например, $(n-k+1)/n$.
• Объединение (Blending): Все элементы из обоих списков сортируются на основе их Universal Ranking Score для формирования финальной комбинированной выдачи.

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

Высокая. Интеграция контента из нативных приложений в результаты поиска (App Indexing, Deep Linking) остается критически важной задачей, особенно в мобильном поиске. Патент описывает фундаментальную архитектуру для смешивания разных типов результатов (Universal Search), решая проблему сравнения разнородных сигналов ранжирования.

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

Патент имеет высокое значение (7.5/10) для SEO и ASO (App Store Optimization) стратегий. Он раскрывает, что Google использует разные индексы и разные наборы сигналов в зависимости от наличия у приложения веб-версии. Это напрямую влияет на стратегию продвижения: app-only приложения должны фокусироваться исключительно на ASO-сигналах, в то время как приложения с веб-версией должны синхронизировать усилия по ASO и традиционному веб-SEO, чтобы максимизировать видимость.

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

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

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

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

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

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

Corresponding Web Resource (Соответствующий веб-ресурс)

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

App-Only (Только приложение)

Нативное приложение или его контент, у которого нет Corresponding Web Resource.

Deep Link (Глубинная ссылка)

Ссылка в результате поиска, которая ведет на конкретную Application Page внутри нативного приложения.

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

Индекс веб-ресурсов. В контексте патента, также включает нативные приложения, если у них есть Corresponding Web Resource.

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

Индекс нативных приложений, у которых нет Corresponding Web Resource.

Web Ranker (Веб-ранжировщик)

Компонент, который ранжирует элементы из Web Index (веб-страницы и приложения с веб-версией).

Application Ranker (Ранжировщик приложений)

Компонент, который ранжирует элементы из Application Index (app-only приложения).

Rank Combiner (Объединитель ранжирования)

Компонент, который объединяет списки от Web Ranker и Application Ranker в единый список.

Universal Ranking Score (Универсальная оценка ранжирования)

Нормализованная оценка, рассчитываемая Rank Combiner. Она основана на позиции элемента (k) и общем количестве элементов (n) в его исходном списке.

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

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

1. Система определяет первый рейтинг (First Ranking) для набора первых приложений, у которых есть соответствующий веб-ресурс. Критично: Ранжирование основано на комбинации контента приложения И контента соответствующего веб-ресурса.
2. Для каждого приложения в первом рейтинге рассчитывается First Universal Ranking Score. Эта оценка основана на позиции (k) и общем количестве (n) приложений в этом рейтинге.
3. Система определяет второй рейтинг (Second Ranking) для набора вторых приложений, у которых НЕТ соответствующего веб-ресурса. Ранжирование основано на контенте самого приложения.
4. Для каждого приложения во втором рейтинге рассчитывается Second Universal Ranking Score на основе его позиции (k) и общего количества (n) приложений в этом рейтинге.
5. Определяется комбинированный рейтинг (Combined Ranking) на основе Universal Ranking Scores.
6. Предоставляются результаты поиска, включающие Deep Links, которые запускают приложение и открывают контент в конкретном месте.

Claim 2 (Зависимый от 1): Детализирует первый метод расчета Universal Ranking Score (Формула 1).

Расчет включает определение соотношения между суммой (разницы между общим количеством приложений (n) и позицией (k) плюс константа (m)) к общему количеству приложений (n). Это соответствует формуле $(n-k+m)/n$. (Claim 4 уточняет, что m может быть равно 1).

Claim 6 и 8 (Зависимые от 1 и 6): Детализируют второй метод расчета Universal Ranking Score (Формула 2).

Расчет основан на инверсии числа Фибоначчи (Inverse of the Fibonacci number), соответствующего позиции приложения. Оценка нормализуется путем деления на сумму инверсий чисел Фибоначчи для всех приложений в рейтинге. Это соответствует формуле $Inv(Fib(k)) / Σ Inv(Fib(i))$.

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

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

CRAWLING – Сканирование и Сбор данных
Application Data Extractor and Processor получает и интерпретирует установочные файлы (application package files) нативных приложений.

INDEXING – Индексирование и извлечение признаков
Indexer сканирует контент приложений. Ключевой шаг: система определяет, есть ли у приложения или его страницы Corresponding Web Resource.

• Если ДА: Приложение/страница может быть проиндексирована в Web Index.
• Если НЕТ: Приложение/страница индексируется в Application Index.

RANKING – Ранжирование
Процесс разделен на два параллельных потока:

• Web Ranker обрабатывает Web Index, генерируя первый список (веб-страницы и приложения с веб-версией), используя веб-сигналы и сигналы приложений.
• Application Ranker обрабатывает Application Index, генерируя второй список (app-only приложения), используя только сигналы приложений.

METASEARCH – Метапоиск и Смешивание
Это основной этап применения патента. Rank Combiner получает два списка. Он игнорирует исходные оценки ранжирования и рассчитывает Universal Ranking Score для каждого элемента на основе его позиции (k) и размера списка (n). Затем он объединяет и сортирует элементы по этой универсальной оценке.

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

• Первый список ранжированных результатов от Web Ranker (с позициями).
• Второй список ранжированных результатов от Application Ranker (с позициями).
• Общее количество релевантных результатов (n) в каждом списке.

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

• Единый комбинированный список результатов (Combined Ranking), отсортированный по Universal Ranking Score.

На что влияет

• Типы контента: Влияет на отображение нативных мобильных приложений и их страниц (Deep Links) в результатах поиска наряду с традиционными веб-страницами.
• Специфические запросы: Наибольшее влияние на мобильный поиск, где пользователи ищут как информацию, так и приложения для выполнения задач (например, «бронирование отелей», «новости», «фитнес трекер»).

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

Алгоритм смешивания применяется, когда в ответ на запрос система идентифицирует релевантные результаты как в Web Index, так и в Application Index, и необходимо создать универсальную выдачу.

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

1. Идентификация ресурсов: В ответ на запрос система ищет релевантные нативные приложения и веб-ресурсы в Web Index и Application Index.
2. Определение первого ранжирования (Web Ranking): Web Ranker ранжирует набор результатов, состоящий из веб-ресурсов и приложений, у которых есть Corresponding Web Resource. Используются веб-сигналы и/или сигналы приложений.
3. Определение второго ранжирования (Application Ranking): Application Ranker ранжирует набор результатов, состоящий из app-only приложений. Используются только сигналы приложений.
4. Расчет универсальных оценок для первого списка: Rank Combiner определяет общее количество элементов (n) в первом списке. Для каждого элемента на позиции (k) рассчитывается Universal Ranking Score с использованием одной из формул (например, $(n-k+1)/n$).
5. Расчет универсальных оценок для второго списка: Аналогичный расчет производится для второго списка с использованием его собственного значения (n).
6. Применение весов (Опционально): Система может применить весовые коэффициенты (weighting) к Universal Ranking Scores в зависимости от источника (например, повысить результаты из Web Ranking).
7. Определение комбинированного ранжирования: Элементы из обоих списков объединяются и сортируются на основе их итоговых Universal Ranking Scores.
8. Разрешение конфликтов (Опционально): При одинаковых оценках применяются правила разрешения конфликтов (tie breaking rules), например, предпочтение приложению с веб-версией или более популярному приложению.
9. Предоставление результатов: Система генерирует SERP, включающий веб-ссылки и Deep Links на приложения.

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

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

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

1. Приложения с Corresponding Web Resource (Обрабатываются Web Ranker):

• Контентные факторы: Релевантность контента приложения И контента соответствующего веб-ресурса запросу.
• Ссылочные факторы (Веб-сигналы): Количество и качество ссылок на соответствующий веб-ресурс, качество домена веб-ресурса.
• Поведенческие/ASO факторы (Сигналы приложений): Количество загрузок/установок, данные об использовании приложения (application usage information), рейтинги, отзывы пользователей, свежесть (recency data).

2. App-Only Приложения (Обрабатываются Application Ranker):

• Контентные факторы: Релевантность контента самого приложения запросу.
• Поведенческие/ASO факторы (Сигналы приложений): Количество загрузок/установок, данные об использовании, рейтинги, отзывы, свежесть. (Веб-сигналы не используются).

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

Ключевой метрикой является Universal Ranking Score. Патент предлагает несколько методов расчета:

Метод 1: Линейное распределение (Equation 1)

Формула: $Universal Ranking Score = (n — k + m) / n$

• n = общее количество элементов в списке.
• k = позиция элемента в списке.
• m = константа (например, 1).

Интерпретация: Этот метод присваивает оценки на основе относительной позиции. Чем меньше ‘n’ (т.е. чем меньше качественных результатов в индексе), тем быстрее снижается оценка при движении вниз по списку.

Метод 2: Распределение по Фибоначчи (Equation 2)

Формула: $Universal Score = Inv(Fib(k)) / Σ Inv(Fib(i))$

• Fib(k) = Число Фибоначчи, соответствующее позиции k.
• Inv(Fib(k)) = Обратное значение (1/Fib(k)).

Интерпретация: Этот метод создает нелинейное распределение, давая значительно больший вес топовым позициям.

Метод 3: Поведенческие метрики

В патенте также упоминается возможность использования производительности результатов поиска (например, click-through rate) в качестве Universal Ranking Score.

Выводы

1. Раздельная архитектура для разных типов приложений: Google четко разделяет обработку приложений, у которых есть веб-аналог (Corresponding Web Resource), и App-Only приложений. Они индексируются (Web Index vs Application Index) и ранжируются разными системами (Web Ranker vs Application Ranker).
2. Преимущество веб-поддержки в ранжировании: Приложения с веб-версией имеют доступ к большему количеству сигналов. Они могут использовать как сигналы приложения (установки, отзывы), так и сигналы соответствующего веб-ресурса (ссылки, авторитетность). App-only приложения ограничены только сигналами приложений.
3. Механизм смешивания через нормализацию позиций: Для объединения результатов из разных индексов Google не сравнивает исходные оценки ранжирования. Вместо этого используется Universal Ranking Score, основанный только на позиции результата в его собственном индексе.
4. Важность ранжирования в своем кластере: Чтобы занять высокую позицию в комбинированной выдаче, приложение должно сначала занять высокую позицию в своем собственном индексе. Universal Ranking Score сохраняет относительный порядок внутри каждого списка.
5. Влияние размера пула (n): Общее количество релевантных результатов (n) в каждом индексе влияет на расчет Universal Ranking Score. Если в индексе мало качественных результатов (маленький n), оценки будут снижаться быстрее, чем в индексе с большим n.
6. Deep Linking как стандарт: Патент подчеркивает важность предоставления Deep Links, ведущих непосредственно к контенту (Application Pages) внутри приложения.

Практика

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

• Синхронизация Веб и Приложения (если применимо): Если у приложения есть веб-версия, необходимо обеспечить, чтобы веб-сайт был максимально качественным и авторитетным (SEO). Сигналы с сайта (например, ссылочный профиль) напрямую влияют на ранжирование приложения, так как оно обрабатывается Web Ranker. Необходимо также обеспечить техническую связь между сайтом и приложением.
• Реализация App Indexing и Deep Linking: Критически важно для всех приложений. Необходимо настроить Deep Links для всех важных страниц приложения (Application Pages), чтобы система могла индексировать контент и направлять пользователей напрямую к нему из поиска.
• Максимизация сигналов ASO для App-Only приложений: Если у приложения нет веб-версии, оно ранжируется Application Ranker. Стратегия должна быть полностью сосредоточена на ASO: оптимизация метаданных, увеличение количества и качества установок, работа с отзывами, рейтингами, а также улучшение показателей использования приложения (application usage information) и его свежести.
• Стратегическое создание веб-аналогов: Для ключевого контента в приложении может быть целесообразно создать Corresponding Web Resource. Это позволит контенту перейти из Application Index в Web Index и получить доступ к веб-сигналам ранжирования, если сайт авторитетен.

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

• Игнорирование веб-сайта при наличии приложения: Ошибка считать, что для приложения с веб-версией важны только сигналы ASO. Патент ясно указывает, что такие приложения ранжируются на основе комбинации сигналов. Слабый сайт снизит видимость приложения в поиске.
• Отсутствие Deep Linking: Не предоставлять поисковой системе доступ к контенту внутри приложения. Это лишает приложение возможности ранжироваться по конкретным информационным запросам и ограничивает его видимость.
• Создание низкокачественного веб-сайта для App-Only: Создание сайта-заглушки низкого качества для app-only приложения с целью попасть в Web Index не принесет пользы, так как Web Ranker оценивает качество веб-ресурса.

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

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

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

Сценарий: Сравнение двух приложений по доставке еды

Запрос: «Заказать пиццу» (на мобильном устройстве).

Приложение А (С веб-версией): Крупный агрегатор с мощным сайтом и сильным SEO. Приложение популярно.

Приложение Б (App-Only): Стартап без функционального веб-сайта. Приложение имеет высокие оценки и хорошую вовлеченность.

Процесс ранжирования:

1. Приложение А обрабатывается Web Ranker. Получает высокую оценку благодаря сильным веб-сигналам и сигналам приложения. Занимает позицию 1 в Web Ranking (Предположим, n=50).
2. Приложение Б обрабатывается Application Ranker. Получает высокую оценку благодаря отличным сигналам приложения. Занимает позицию 1 в Application Ranking (Предположим, n=10).
3. Расчет Universal Score (по Формуле 1, m=1):
   • Приложение А: (50 — 1 + 1) / 50 = 1.0
   • Приложение Б: (10 — 1 + 1) / 10 = 1.0
4. Объединение: Оба приложения занимают верхние позиции. При равенстве оценок используются правила разрешения конфликтов.

Сценарий 2: Если Приложение А заняло позицию 3.

1. Приложение А занимает позицию 3 в Web Ranking (n=50).
2. Приложение Б занимает позицию 1 в Application Ranking (n=10).
3. Расчет Universal Score:
   • Приложение А: (50 — 3 + 1) / 50 = 0.96
   • Приложение Б: (10 — 1 + 1) / 10 = 1.0
4. Объединение: Приложение Б будет ранжироваться выше Приложения А в комбинированной выдаче.

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