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

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

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

База данных, содержащая индексированный контент нативных приложений и связанные с ним deep links. Используется для поиска внутри корпуса приложений (Application Corpus).

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

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

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

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

Interface Element (Элемент интерфейса)

Ключевой элемент патента. Элемент управления в SERP (например, кнопка или ссылка), который при выборе инициирует показ множества результатов поиска (deep links) из конкретного нативного приложения. Согласно патенту, выбор этого элемента НЕ запускает само приложение немедленно.

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

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

Native application trigger system (Система активации поиска по нативным приложениям)

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

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

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

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

Числовая оценка, показывающая, насколько контент приложения соответствует поисковому запросу. Рассчитывается компонентом Native Application Content Scorer.

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

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

1. Система получает набор веб-результатов в ответ на запрос пользователя.
2. В этот набор включается interface element, который указывает на конкретное (particular) нативное приложение.
3. Этот элемент настроен так, что при его выборе пользователю будет предоставлено множество результатов (deep links) из этого конкретного приложения.
4. Критически важное уточнение: выбор этого interface element НЕ приводит к запуску (does not instantiate) указанного нативного приложения.
5. Система отправляет веб-результаты и interface element на устройство.
6. Система получает сигнал о выборе interface element.
7. В ответ система предоставляет множество результатов поиска из указанного нативного приложения.

Ядро изобретения — механизм "углубления" в контент приложения, оставаясь при этом в интерфейсе поисковой системы.

Claim 2 (Зависимый от 1): Детализирует первый вариант триггера для включения interface element (на основе релевантности контента).

1. Система определяет, что указанное приложение установлено на устройстве пользователя.
2. Система получает набор deep links из этого приложения, релевантных запросу.
3. Система определяет, что по крайней мере пороговое количество (threshold number) этих результатов имеют пороговую оценку релевантности (threshold relevance score) запросу.
4. Если все условия выполнены, interface element включается в выдачу.

Claim 3 (Зависимый от 1): Детализирует второй вариант триггера (на основе интента запроса).

1. Система определяет, что приложение установлено на устройстве пользователя.
2. Система определяет, что запрос имеет пороговый Search Probability Ratio (т.е. высока вероятность, что пользователь хочет искать в приложениях, а не в вебе).
3. Если условия выполнены, interface element включается в выдачу.

Claim 4 (Зависимый от 3): Уточняет вид interface element.

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

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

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

INDEXING – Индексирование и извлечение признаков
На этом этапе происходит сбор данных о нативных приложениях (через Application Data Extractor and Processor), индексация их контента и сохранение deep links в Application Index.

QUNDERSTANDING – Понимание Запросов
Система анализирует логи запросов для расчета Search Probability Ratio — метрики, определяющей, насколько вероятно, что запрос направлен на поиск в приложениях.

RANKING – Ранжирование
Resource Scorer оценивает веб-ресурсы. Параллельно Native Application Content Scorer рассчитывает Relevance Scores для контента приложений (deep links) относительно запроса.

METASEARCH – Метапоиск и Смешивание
Основной этап применения патента. Native application trigger system принимает решение о включении interface element.

1. Проверка установки: Система взаимодействует с пользовательскими данными (профилем), чтобы проверить, установлено ли приложение (обязательное условие согласно Claims 2 и 3).
2. Оценка триггеров: Система проверяет, достигнуты ли пороги по Relevance Scores ИЛИ по Search Probability Ratio.
3. Смешивание: Если пороги достигнуты, interface element вставляется в смешанную выдачу.
4. Вторичный поиск: При активации элемента система выполняет новый поиск, ограниченный приложением. В патенте упоминается, что для этого запрос может быть модифицирован (например, с оператором типа inapp:), чтобы ограничить результаты только этим приложением.

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

• Исходный запрос пользователя.
• Данные из Web Index и Application Index.
• Данные профиля пользователя (список установленных приложений).
• Search Probability Ratio для запроса.
• Relevance Scores для deep links.

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

• Первичная SERP, содержащая веб-результаты и interface element.
• Вторичная SERP (при клике на элемент), содержащая только deep links из указанного приложения.

На что влияет

• Типы устройств: Влияет исключительно на поиск на мобильных устройствах (смартфоны, планшеты), так как зависит от наличия установленных нативных приложений.
• Специфические запросы: Наибольшее влияние на запросы, для которых характерен высокий Search Probability Ratio (например, поиск товаров, рецептов, медиаконтента, бронирований).
• Конкретные ниши или тематики: E-commerce, путешествия, развлечения, кулинария — ниши, где пользователи часто имеют установленные специализированные приложения с богатым каталогом контента.

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

Алгоритм применяется при выполнении строгого набора условий (комбинация обязательного условия и одного из двух триггеров):

• Обязательное условие (Персонализация): Конкретное нативное приложение должно быть установлено на устройстве пользователя (явно указано в Claims 2 и 3).
• Триггер 1 (Качество контента): Пороговое количество контента (deep links) внутри приложения должно иметь Relevance Score выше порогового значения (Claim 2).
• Триггер 2 (Интент запроса): Search Probability Ratio для данного запроса должен превышать пороговое значение (Claim 3).

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

Этап 1: Первичная обработка запроса и оценка триггеров

1. Получение запроса и веб-результатов: Система получает запрос и генерирует стандартный набор веб-результатов.
2. Идентификация кандидатов: Native application trigger system идентифицирует нативные приложения, релевантные запросу.
3. Проверка установки: Система проверяет профиль пользователя, чтобы определить, установлены ли приложения-кандидаты на устройстве.
4. Оценка триггеров для установленных приложений: Для каждого установленного приложения проверяются условия:
   1. Проверка по релевантности: Извлекаются deep links из Application Index. Проверяется, достигнуто ли пороговое количество результатов с пороговым Relevance Score.
   2. Проверка по интенту: Проверяется, превышает ли Search Probability Ratio запроса пороговое значение.
5. Принятие решения: Если хотя бы один из триггеров сработал для конкретного приложения, принимается решение о включении interface element.

Этап 2: Формирование смешанной выдачи

1. Включение элемента: Interface element включается в набор веб-результатов. Он может быть оформлен как отдельный блок или как дополнение к уже существующему deep link ("More results from...").
2. Предоставление SERP: Смешанная выдача отправляется пользователю.

Этап 3: Обработка взаимодействия с элементом

1. Получение выбора: Пользователь выбирает interface element. Приложение НЕ запускается (Claim 1).
2. Модификация запроса (Опционально): Система может модифицировать исходный запрос, чтобы ограничить поиск только указанным приложением (например, добавив оператор типа "inapp:").
3. Выполнение специализированного поиска: Система выполняет поиск по Application Index, фильтруя результаты только для данного приложения.
4. Предоставление специализированной SERP: Пользователю предоставляется новая страница результатов (в интерфейсе поиска), содержащая множество deep links из этого приложения.

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

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

• Пользовательские факторы: Критически важные данные. Система использует профиль пользователя (profile of installed native applications) для определения списка установленных приложений на устройстве. Это обязательное условие для работы механизма.
• Контентные факторы (Приложений): Индексированный контент нативных приложений, включая тексты, метаданные и структуру, доступные через deep links. Эти данные хранятся в Application Index.
• Поведенческие факторы (Агрегированные): Логи запросов (Query logs) к различным корпусам (веб, магазины приложений). Используются для расчета Search Probability Ratio.

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

• Relevance Score (Оценка релевантности контента приложения): Метрика, рассчитываемая Native Application Content Scorer. Используется для оценки соответствия контента внутри приложения запросу.
• Search Probability Ratio (Коэффициент вероятности поиска): Метрика интента. Рассчитывается как мера вероятности того, что запрос подан для корпуса приложений по сравнению с веб-корпусом. Основывается на соотношении количества запросов к разным корпусам.
• Пороговые значения (Thresholds):
  • Threshold relevance score: Минимальная оценка релевантности.
  • Threshold number: Минимальное количество высокорелевантных результатов в приложении (для активации Триггера 1).
  • Threshold search probability ratio: Минимальная вероятность интента поиска в приложении (для активации Триггера 2).

1. Приоритет установленным приложениям (Персонализация): Описанный механизм работает только для приложений, которые уже установлены на устройстве пользователя (Claims 2 и 3). Это подчеркивает важность наращивания базы установок (ASO) для активации этой функции.
2. Механизм "углубления" (Pivoting): Патент вводит interface element как точку входа для перехода от общего поиска к специализированному поиску внутри конкретного приложения. Это позволяет приложению потенциально занять всю страницу выдачи.
3. Ключевое ограничение UI/UX: Принципиально важно, что клик по interface element НЕ открывает приложение (Claim 1). Вместо этого он перезагружает SERP в том же интерфейсе (например, браузере), показывая больше deep links. Это снижает барьер для пользователя и удерживает его в поиске.
4. Два пути активации (Релевантность vs. Интент): Система может активировать функцию либо на основе анализа контента (много релевантных результатов в приложении — Relevance Score), либо на основе анализа интента запроса (запрос характерен для поиска в приложениях — Search Probability Ratio).
5. Критичность App Indexing: Для работы механизма необходимо, чтобы контент приложения был проиндексирован и доступен в Application Index через deep links. Без этого система не сможет оценить релевантность и предоставить результаты.

ВАЖНО: Патент имеет минимальное отношение к традиционному веб-SEO. Он критически важен для App SEO (индексации контента приложений) и стратегий взаимодействия App/Web.

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

• Реализация глубокой индексации (App Indexing): Обеспечить максимальный охват контента приложения через deep links (используя Firebase App Indexing или аналогичные технологии). Это необходимое условие для того, чтобы система могла оценить Relevance Score.
• Оптимизация контента внутри приложений: Контент и метаданные на экранах, на которые ведут deep links, должны быть оптимизированы под релевантные запросы. Это повышает шансы достижения threshold relevance score (Триггер 1).
• Наращивание базы установок (ASO): Поскольку механизм активируется только для установленных приложений, стратегические усилия по ASO и продвижению установок приложения напрямую влияют на частоту показа interface element в поиске Google.
• Оптимизация под "App-Intents": Анализировать запросы с высоким Search Probability Ratio (например, конкретные товары, бронирования) и обеспечивать наличие соответствующего контента в приложении для активации Триггера 2.

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

• Игнорирование App Indexing: Если контент приложения не индексируется, оно не сможет участвовать в этом механизме и будет терять потенциальный трафик из органического поиска Google.
• Создание приложений без глубокого контента: Приложения, которые не имеют структурированного контента, доступного через deep links, не получат преимуществ, так как система не сможет найти "множество" релевантных результатов.
• "Битые" или поверхностные Deeplinks: Предоставление deep links, которые ведут на ошибки или только на главный экран приложения. Это негативно скажется на Relevance Score и пользовательском опыте.

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

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

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

Сценарий: Поиск товара в E-commerce

1. Ситуация: У пользователя установлено приложение крупного маркетплейса (например, Amazon). Контент проиндексирован через Firebase.
2. Запрос: Пользователь ищет в Google "лучшие сумки для подгузников".
3. Анализ Google: Система видит, что приложение Amazon установлено. Она проверяет Application Index и определяет, что в приложении есть сотни релевантных товаров (Relevance Score выше порога, количество результатов выше порога). Триггер 1 активирован.
4. Смешанная выдача (SERP 1): Google показывает веб-результаты, один deep link на категорию в приложении и под ним interface element: "Еще результаты из приложения Amazon".
5. Действие пользователя: Пользователь кликает на "Еще результаты из приложения Amazon".
6. Специализированная выдача (SERP 2): Интерфейс поиска перезагружается (приложение НЕ открывается). Google модифицирует запрос (например, внутренне используя "лучшие сумки для подгузников inapp:com.amazon"). Показывается новая выдача, состоящая только из deep links на конкретные товары внутри приложения Amazon.
7. Результат: Пользователь получает доступ к широкому ассортименту приложения прямо из поиска, а маркетплейс занимает всю страницу выдачи.