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

Описание

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

Патент решает задачу эффективной интеграции результатов поиска по нативным приложениям (Native Applications) в результаты поиска по веб-ресурсам (Web Resources). Цель — определить, когда информационная потребность пользователя может быть лучше удовлетворена нативным приложением, и решить, когда активировать поиск по корпусу приложений (Triggering) и как позиционировать результаты приложений относительно веб-результатов (Ranking/Insertion).

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

Запатентована система, которая определяет, когда следует искать в корпусе нативных приложений и вставлять соответствующие результаты в набор общих результатов веб-поиска. Ключевым элементом является использование Search Probability Ratio (SPR) — метрики, которая оценивает вероятность того, что запрос предназначен для поиска приложений, а не веб-страниц. Эта метрика используется как для активации поиска по приложениям, так и для определения необходимости и способа вставки результатов.

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

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

• Первичный поиск: Выполняется стандартный поиск по веб-корпусу (первая поисковая операция).
• Расчет SPR: Для запроса определяется Search Probability Ratio (SPR) — вероятность того, что запрос направлен на поиск приложений.
• Триггер: Если SPR превышает пороговое значение (SPR Threshold), система активирует вторую поисковую операцию по корпусу приложений.
• Вторичный поиск: Выполняется поиск и оценка нативных приложений на основе их качества и релевантности.
• Принятие решения о вставке: Система определяет, следует ли вставлять результат приложения в веб-выдачу. Это решение базируется на SPR, оценке приложения и оценке веб-страницы, описывающей приложение (например, Product Page).
• Вставка и Ранжирование: Если решение положительное, результат приложения вставляется в веб-выдачу. Позиция вставки может определяться значением SPR (чем выше SPR, тем выше позиция) или результат приложения может заменить соответствующую Product Page.

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

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

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

Патент имеет высокое значение (8.5/10) для SEO и ASO стратегий, особенно для проектов, имеющих как веб-сайт, так и нативное приложение. Он описывает конкретные механизмы, определяющие, когда Google предпочтет результаты приложений веб-результатам. Понимание Search Probability Ratio и критической зависимости видимости приложения от ранжирования его Product Page необходимо для максимизации трафика в мобильном поиске.

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

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

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

Индекс страниц нативных приложений. Может быть отдельным индексом или частью комбинированного индекса.

Application Scorer (Оценщик приложений)

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

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

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

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

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

First Search Operation (Первая поисковая операция)

Основной поиск, обычно по корпусу веб-ресурсов (Web Index).

Inserter (Модуль вставки)

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

Insertion Score (IS) (Оценка вставки)

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

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

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

Product Page / Descriptive Resource (Страница продукта / Описывающий ресурс)

Веб-ресурс (Первый ресурс), который описывает нативное приложение (Второй ресурс). Например, страница в онлайн-магазине приложений (Google Play, App Store).

Second Search Operation (Вторая поисковая операция)

Дополнительный поиск, обычно по корпусу нативных приложений (Application Index), который активируется при определенных условиях.

Search Probability Ratio (SPR) (Коэффициент вероятности поиска)

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

SPR Threshold (Пороговое значение SPR)

Значение SPR, при превышении которого активируется вторая поисковая операция.

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

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

1. Система получает запрос для первой поисковой операции (веб-поиск) и идентифицирует первые ресурсы (веб-страницы).
2. Определяется Search Probability Ratio (SPR) для запроса. SPR основан на вероятности того, что запрос предназначен для второй поисковой операции (поиск приложений), отличной от первой.
3. Если SPR запроса соответствует пороговому значению (threshold search probability ratio):
   1. Инициируется вторая поисковая операция и идентифицируются вторые ресурсы (нативные приложения).
   2. Определяется, следует ли вставлять результат второго ресурса в набор результатов первых ресурсов. Это решение основано как минимум на SPR.
4. Если принято решение о вставке, результат второго ресурса вставляется в набор результатов первых ресурсов.

Claim 3 (Зависимый от 1): Уточняет условия для вставки результата. Это критически важное утверждение, связывающее SEO и ASO.

Решение о вставке результата второго ресурса (приложения) принимается, если: (i) приложение имеет оценку, соответствующую второму порогу (т.е. приложение достаточно качественно/релевантно), И (ii) первый ресурс (веб-страница), который описывает это приложение (Product Page), имеет оценку, соответствующую первому порогу (т.е. страница продукта достаточно высоко ранжируется в веб-поиске).

Claim 4 (Зависимый от 1): Описывает механизм ранжирования при вставке.

Определяется Insertion Score, основанный, в частности, на SPR. Этот Insertion Score определяет порядковую позицию вставки (ordinal insertion position) результата приложения в ранжированный список веб-результатов.

Claim 5 (Зависимый от 4): Детализирует определение позиции вставки на основе SPR.

Позиция вставки зависит от значения SPR:

• Если SPR соответствует первому порогу (first insertion threshold) → Первая порядковая позиция.
• Если SPR соответствует второму порогу, но не первому → Вторая порядковая позиция.
• Если SPR соответствует третьему порогу, но не второму → Третья порядковая позиция.

Это означает, что чем выше уверенность системы в том, что пользователь ищет приложение (выше SPR), тем агрессивнее (выше) будет вставлен результат.

Claim 8 (Зависимый от 1): Описывает механизм замены.

Вставка результата приложения включает замену результата, идентифицирующего первый ресурс (веб-страницу), который описывает это приложение. То есть, вместо ссылки на Product Page в выдаче может быть показана прямая ссылка на само приложение (установка/открытие).

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

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

QUNDERSTANDING – Понимание Запросов
На этом этапе (или офлайн) система рассчитывает Search Probability Ratio (SPR) для запросов. Это требует анализа исторических данных поиска по разным корпусам (веб, магазины приложений), чтобы понять вероятность «апп-интента» для запроса.

RANKING – Ранжирование
Система запускает первую поисковую операцию (веб-поиск) с помощью Resource Scorer. Если условие SPR выполняется, система запускает вторую поисковую операцию (поиск по приложениям) с помощью Application Scorer.

METASEARCH – Метапоиск и Смешивание
Основное применение патента. Модуль Inserter анализирует результаты из обоих источников (Web Index и Application Index). Он определяет, нужно ли вставлять результаты приложений и куда именно. Это включает:

• Сравнение оценок приложений и соответствующих им Product Pages.
• Расчет Insertion Score на основе SPR.
• Принятие решения о способе вставки: добавление результата приложения или замена им соответствующего веб-результата.

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

• Запрос пользователя.
• SPR запроса (на основе исторических логов).
• Результаты веб-поиска и их оценки.
• Результаты поиска приложений и их оценки (включая ASO-сигналы).
• Данные о связи между приложениями и их Product Pages.
• Данные об устройстве пользователя (совместимость, установленные приложения).

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

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

На что влияет

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

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

• Триггеры активации: Основной триггер для запуска поиска по приложениям — это соответствие SPR запроса пороговому значению (SPR Threshold).
• Условия для вставки: Даже если поиск активирован, вставка результата происходит только при выполнении дополнительных условий (Claim 3):
  • Высокая оценка самого приложения (Native Application Score).
  • Высокая оценка соответствующей веб-страницы приложения (Product Page).
  • Совместимость приложения с устройством пользователя.
• Исключения: Патент упоминает фильтры. Результаты приложений могут подавляться для информационных запросов с разнообразными ответами, или если распределение оценок приложений слишком равномерное (нет явных лидеров). Также упоминается фильтрация «длиннохвостых» (long tail) запросов с низкой частотностью, даже если у них высокий SPR.

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

Этап 1: Получение запроса и анализ интента

1. Получить запрос от пользователя.
2. Определить Search Probability Ratio (SPR) для запроса.

Этап 2: Первая поисковая операция (Веб-поиск)

1. Инициировать поиск по Web Index.
2. Получить и ранжировать набор первых ресурсов (веб-страниц).

Этап 3: Активация второй поисковой операции (Поиск приложений)

1. Проверить, соответствует ли SPR пороговому значению (SPR Threshold).
   • Если НЕТ: Перейти к Этапу 6.
   • Если ДА: Перейти к шагу 2.
2. Инициировать поиск по Application Index.
3. Получить и ранжировать набор вторых ресурсов (нативных приложений), используя специфические сигналы (установки, рейтинги, использование и т.д.).

Этап 4: Сопоставление результатов

1. Для топовых нативных приложений определить соответствующие им веб-ресурсы из первого набора, которые их описывают (Product Pages).

Этап 5: Принятие решения о вставке и ранжирование

1. Определить, следует ли вставлять результат приложения. Проверка условий (Claim 3):
   • Достаточно ли высока оценка приложения (порог M).
   • Достаточно ли высока оценка соответствующей веб-страницы (порог N).
2. Если НЕТ: Перейти к Этапу 6.
3. Если ДА: Определить позицию и способ вставки:
   • Вариант А (Замена): Заменить результат веб-страницы (Product Page) результатом нативного приложения.
   • Вариант Б (Агрессивная вставка): Определить позицию вставки на основе SPR (Claim 5). Чем выше SPR, тем выше позиция (например, Топ-1, Топ-3, Топ-5).
4. Вставить результат приложения в набор веб-результатов.

Этап 6: Предоставление результатов

1. Предоставить финальный смешанный набор результатов пользователю.

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

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

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

• Поведенческие факторы (для расчета SPR):
  • Журналы запросов (Query Logs) из общего веб-поиска (референсный корпус).
  • Журналы запросов из поиска по приложениям или из онлайн-магазинов приложений (целевой корпус).
• Факторы качества и использования приложений (для Application Scorer / ASO-сигналы):
  • Installation data: Количество установок или загрузок приложения.
  • Usage data: Общее использование приложения (время работы, вовлеченность, просмотры экранов).
  • Ratings data: Пользовательские рейтинги приложения (например, «звезды»).
  • Semantic signals: Данные о настроениях пользователей (sentiment), извлеченные из отзывов.
  • Recency: Давность выпуска приложения или его текущей версии.
  • Developer quality ratings: Рейтинги качества разработчиков (основанные на качестве и стабильности других их продуктов).
• Контентные факторы (для Application Scorer):
  • Keywords and text content: Ключевые слова и текстовый контент, используемые для оценки релевантности приложения запросу.
• Пользовательские и Технические факторы (User device specific signals):
  • Installation status: Установлено ли приложение на устройстве пользователя.
  • Instantiation status: Запущено ли приложение в данный момент.
  • Use frequency: Как часто пользователь использует приложение.
  • Application stability: Насколько стабильно приложение работает на данном устройстве (частота сбоев).
  • Совместимость устройства с приложением.

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

• Search Probability Ratio (SPR): Рассчитывается как отношение вероятности появления запроса в целевом корпусе к вероятности его появления в референсном корпусе. Формула: SPR(q) = (#qT / #{Q}T) / (#qR / #{Q}R), где #qT/R — количество экземпляров запроса q в целевом/референсном корпусе, а #{Q}T/R — общее количество всех запросов в соответствующем корпусе.
• SPR Threshold: Пороговое значение для активации поиска по приложениям.
• Native Application Score (NA_S): Оценка приложения, агрегирующая ASO-сигналы, контентные и пользовательские сигналы.
• Insertion Score (IS): Метрика для определения необходимости и позиции вставки. Упоминается формула: IS = f(SPR, NA_S), где f — математическая функция. IS сравнивается с порогом IS_T.
• Insertion Thresholds (Пороги вставки): Различные уровни SPR, определяющие агрессивность позиционирования результата (Claim 5).

Выводы

1. Определение интента запроса (Web vs. App): Центральным элементом патента является Search Probability Ratio (SPR). Google активно анализирует исторические данные поиска из разных источников (веб, магазины приложений), чтобы определить вероятность того, что пользователь ищет именно приложение.
2. Условная активация поиска по приложениям: Поиск по Application Index не всегда активен. Он запускается (Triggering), только если SPR запроса превышает определенный порог.
3. Агрессивное ранжирование на основе интента: Если система уверена в интенте (высокий SPR), результаты приложений могут быть вставлены очень агрессивно. Позиция вставки (вплоть до Топ-1) напрямую зависит от уровня SPR (Claim 5).
4. Критическая взаимосвязь SEO и ASO (Claim 3): Для того чтобы результат приложения был показан, требуется, чтобы не только само приложение имело высокую оценку (ASO), но и соответствующая ему веб-страница (Product Page) хорошо ранжировалась в веб-поиске (SEO). Это ключевой вывод для стратегии продвижения.
5. Механизм замены (Substitution): Google может полностью заменить веб-результат (ссылку на Product Page) прямым результатом приложения (кнопка «Установить» или Deep Link), если приложение доступно для устройства пользователя.
6. Многообразие сигналов для ранжирования приложений: Ранжирование приложений использует широкий спектр сигналов: от традиционных (ключевые слова, рейтинги) до поведенческих (установки, использование, стабильность) и персонализированных (установлено ли приложение у пользователя, как часто используется).

Практика

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

• Оптимизация Product Pages (SEO для ASO): Убедитесь, что веб-страницы ваших приложений (в Google Play, App Store и на вашем сайте) хорошо оптимизированы и высоко ранжируются в веб-поиске. Согласно Claim 3, высокая позиция Product Page является обязательным условием для показа результата нативного приложения в смешанной выдаче.
• Стимулирование «Апп-Интента» (Увеличение SPR): Работайте над узнаваемостью бренда приложения. Чем чаще пользователи ищут ваше приложение по названию в магазинах приложений, тем выше будет Search Probability Ratio для этих запросов, что увеличивает шансы на агрессивное ранжирование в Топ-1 веб-поиска.
• Внедрение App Indexing и Deep Links: Предоставляйте Google доступ к контенту внутри приложения и соответствующим Deep Links. Это позволяет системе показывать не только установку приложения, но и конкретные Environment Instances в ответ на запрос.
• Фокус на качестве и стабильности приложения (ASO): Сигналы, такие как Ratings data, Usage data (вовлеченность и удержание), Semantic signals (отзывы) и Application stability, напрямую влияют на Native Application Score. Качественное приложение имеет больше шансов быть показанным в веб-поиске.
• Использование персонализированных сигналов: Поощряйте регулярное использование приложения. Сигналы Installation status и Use frequency повышают релевантность приложения для конкретного пользователя, увеличивая шансы на показ в его персональной выдаче.

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

• Игнорирование веб-присутствия приложения: Рассчитывать только на ASO внутри магазина приложений недостаточно. Отсутствие хорошо ранжируемой Product Page в веб-индексе может заблокировать показ приложения в смешанной выдаче Google (согласно Claim 3).
• Накрутка установок без вовлечения: Фокус только на количестве установок (Installation data) без реального использования (Usage data) не даст устойчивого результата, так как система учитывает комплекс сигналов.
• Выпуск нестабильных приложений: Низкая стабильность (Application stability) и негативные отзывы снизят Native Application Score и рейтинг разработчика (Developer quality ratings), что негативно скажется на ранжировании.

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

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

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

Сценарий 1: Агрессивное ранжирование по брендовому запросу

1. Ситуация: Пользователь ищет популярную игру «Best Chess».
2. Анализ Google: Система видит, что запрос [Best Chess] очень часто вводится в Google Play. Рассчитывается SPR, и он оказывается очень высоким (превышает первый порог вставки).
3. Действие: Google активирует поиск по приложениям. Приложение «Best Chess» имеет высокие рейтинги (высокий NA_S).
4. Результат: Система рассчитывает Insertion Score, соответствующий Позиции №1 (согласно Claim 5). В мобильной выдаче на первом месте показывается блок установки приложения «Best Chess», вытесняя все веб-результаты.

Сценарий 2: Замена Product Page на результат приложения

1. Ситуация: Пользователь ищет [обзор игры Best Chess].
2. Анализ Google: SPR для этого запроса ниже, чем для брендового, но превышает порог активации. В веб-поиске на 4-й позиции находится Product Page игры в Google Play.
3. Действие: Система проверяет оценки приложения и его Product Page. Обе оценки высоки (условие Claim 3 выполнено). Устройство пользователя совместимо.
4. Результат: Система принимает решение о вставке путем замены (согласно Claim 8). На 4-й позиции вместо ссылки на веб-страницу Google Play показывается прямой блок установки приложения «Best Chess».

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