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

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

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

Ссылка (URI), ведущая на конкретную страницу контента (content page) внутри нативного приложения, а не на его главную страницу.

First Application (Первое приложение)

Приложение, в котором пользователь инициирует поиск и просматривает результаты. Обычно это веб-браузер или приложение Google Search.

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

Приложение, разработанное для конкретной ОС устройства (например, iOS, Android) и работающее независимо от браузера. Отличается от First Application.

Native Application Search Result

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

Synchronized Content (Синхронизированный контент)

Контент, который идентичен при доступе через нативное приложение (по URI 1) и через веб-ресурс (по URI 2).

URI 1 (Первый URI)

Идентификатор ресурса, предназначенный для обработки нативным приложением (App Deep Link). Например, android-app://com.example/page.

URI 2 (Второй URI)

Альтернативный идентификатор ресурса, который может быть обработан First Application (например, браузером). Обычно это веб-URL. Например, https://www.example.com/page.

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

Claim 1 (Независимый пункт): Описывает основной метод, выполняемый на устройстве пользователя (client-side).

1. Устройство получает результаты поиска в First Application. Набор включает Native Application Search Result с URI 1 (App Deep Link).
2. Устройство определяет, установлено ли нативное приложение, способное обработать URI 1.
3. Если приложение НЕ установлено, устройство обрабатывает URI 2 (Web URL).
4. Обработка URI 2 включает конкретные шаги (механизм получения URI 2 по требованию):
   • Отправку запроса с устройства поисковой системе для получения URI 2 на основе URI 1. Поисковая система хранит URI 2 как альтернативный источник (alternate source).
   • Получение URI 2 от поисковой системы.
   • Перезапись (rewriting) URI 1 на URI 2 в качестве базовой ссылки (underlying link). Внешний вид результата поиска не меняется.
5. При клике First Application открывает контент по URI 2.
6. Контент по URI 1 и URI 2 является synchronized content.

Claim 2 (Зависимый от 1): Уточняет время проверки.

Определение статуса установки приложения происходит в ответ на получение набора результатов поиска (т.е. во время рендеринга SERP).

Claim 3 (Зависимый от 1): Уточняет альтернативное время проверки.

Определение статуса установки приложения происходит в ответ на выбор (клик) пользователем Native Application Search Result.

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

Определение статуса установки выполняется путем запуска скрипта (executing a script), включенного в набор результатов поиска.

Claim 6 (Зависимый от 1): Уточняет типы.

First Application является веб-браузером, а URI 2 — это URL веб-страницы.

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

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

INDEXING – Индексирование и извлечение признаков
На этом этапе поисковая система должна проиндексировать как веб-контент (Web Index), так и контент приложений (Native Application Data). Критически важно установление и сохранение связи (mapping) между URI 1 (App Deep Link) и URI 2 (Web URL) для synchronized content. Это необходимо, чтобы система могла предоставить альтернативный URI по запросу.

RANKING / METASEARCH – Ранжирование и Формирование SERP
Система ранжирует контент и формирует выдачу, которая может включать Native Application Search Results. Вместе с результатами система предоставляет клиентский скрипт для выполнения логики.

Client-Side Execution (На устройстве пользователя)
Основное применение патента. Логика выполняется в First Application (браузере) после этапа RERANKING.

1. Инициализация: При загрузке SERP или при клике активируется скрипт.
2. Проверка: Скрипт взаимодействует с ОС устройства для проверки статуса установки приложения.
3. Принятие решения и действие: Если приложение не установлено, скрипт инициирует получение URI 2 (запрашивая его у поисковой системы, если он не был встроен в SERP) и выполняет URI Rewriting.

Входные данные (на устройстве):

• SERP с Native Application Search Result и URI 1.
• Клиентский скрипт.
• Данные о статусе установки приложений на устройстве.

Выходные данные (на устройстве):

• Модифицированный результат поиска с активированным URI 1 или URI 2.
• Действие при клике: запуск нативного приложения или загрузка веб-страницы.

На что влияет

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

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

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

• Триггер активации: Присутствие Native Application Search Result в поисковой выдаче.
• Временные рамки: Проверка и подмена происходят либо в момент рендеринга SERP на устройстве (Claim 2), либо в момент клика пользователя по результату (Claim 3).
• Условие переключения (Fallback): Отсутствие на устройстве нативного приложения, способного обработать URI 1.

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

Процесс выполняется на устройстве пользователя.

1. Получение результатов: Устройство получает SERP от поисковой системы в First Application (браузере). SERP содержит Native Application Search Result с URI 1 (App Deep Link) и клиентский скрипт.
2. Инициализация проверки: Запускается клиентский скрипт (при рендеринге или при клике).
3. Проверка установки приложения: Скрипт локально определяет, установлено ли нативное приложение, способное обработать URI 1.
4. Условное ветвление:
   • Сценарий А (Приложение установлено): URI 1 остается активным. При клике запускается нативное приложение.
   • Сценарий Б (Приложение НЕ установлено): Активируется механизм fallback (переход к шагу 5).
5. Получение альтернативного URI 2: Скрипт определяет URI 2.
   • Вариант 1 (Встроенный): URI 2 уже присутствует в коде SERP.
   • Вариант 2 (По требованию - описан в Claim 1): Устройство отправляет запрос поисковой системе для получения URI 2, соответствующего URI 1.
6. Перезапись ссылки (URI Rewriting): Система перезаписывает активную ссылку в результате поиска с URI 1 на URI 2. Визуально результат не меняется.
7. Обработка клика: При клике First Application (браузер) обрабатывает URI 2 и отображает synchronized content.

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

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

Патент фокусируется на механизме обработки ссылок на клиенте, а не на ранжировании.

• Структурные данные (Индексы/Mapping): Данные о соответствии между URI 1 (App) и URI 2 (Web) для synchronized content. Хранятся поисковой системой и предоставляются по запросу или встраиваются в SERP.
• Пользовательские факторы (Состояние устройства): Данные о том, какие нативные приложения установлены на устройстве. Эти данные проверяются локально на клиенте.
• Технические факторы (Идентификаторы): URI 1 и URI 2.

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

В патенте не упоминаются метрики ранжирования или оценки качества. Используются логические операции:

• Статус установки приложения: Булева проверка (Установлено/Не установлено). Выполняется на клиенте, возможно, через доступ скрипта к манифесту устройства.
• Поиск соответствия (Lookup): Поиск URI 2 для заданного URI 1. Выполняется на сервере поисковой системы (если URI запрашивается по требованию).

1. Децентрализация логики (Client-Side Processing): Ключевая особенность — проверка установки приложения и решение о перенаправлении принимаются на устройстве пользователя, а не на серверах Google. Это позволяет предоставлять App Deep Links всем, не требуя от Google знания о состоянии устройств пользователей.
2. Критичность синхронизированного контента (Content Parity): Весь механизм основан на предположении о существовании synchronized content. Наличие веб-эквивалента является обязательным условием для эффективной индексации контента приложений и работы fallback-механизма.
3. Приоритет доступа к контенту над установкой приложения: Google стремится доставить контент пользователю немедленно. Если приложение не установлено, система бесшовно перенаправит на веб-версию, а не будет принуждать к установке или показывать ошибку.
4. Гибкость реализации Fallback: Патент защищает механизм, при котором альтернативный URL (URI 2) может запрашиваться у поисковой системы на лету (on-demand), если он не был включен в исходный SERP. Также предусмотрена гибкость момента проверки (при рендеринге или клике).
5. Важность технической реализации App Indexing: Корректное внедрение App Indexing (связывание URI 1 и URI 2) является фундаментом для работы этой системы.

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

• Обеспечение полного паритета контента (Synchronized Content): Убедитесь, что весь важный контент в нативном приложении имеет идентичный эквивалент на мобильном веб-сайте. Контент по URI 1 должен полностью совпадать с контентом по URI 2. Это фундамент для работы описанного механизма.
• Корректная настройка App Indexing (Firebase): Необходимо явно указывать соответствие между App Deep Links (URI 1) и веб-URL (URI 2). Это делается через атрибут rel="alternate" на веб-странице, в XML Sitemap или через Firebase API. Это позволяет Google знать, какой URI 2 использовать в качестве альтернативы.
• Оптимизация мобильного сайта (Fallback Quality): Так как мобильный сайт служит резервным вариантом, его качество, скорость (Core Web Vitals) и UX критически важны. Плохой опыт на мобильном сайте приведет к отказам, даже если механизм перенаправления сработает.
• Тестирование Fallback-механизма: Проверяйте поведение результатов поиска на устройствах, где ваше приложение НЕ установлено. Убедитесь, что пользователи бесшовно перенаправляются на корректную веб-страницу, а не на страницу загрузки приложения или ошибку.

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

• Создание уникального контента только в приложении (App-Only Content): Размещение важного контента только в приложении без веб-эквивалента рискованно. Такой контент имеет ограниченный охват и недоступен пользователям без приложения, так как механизм подмены URI 2 не сработает.
• Некорректная ассоциация URI и URL: Ошибки в App Indexing, когда App URI ассоциируется с нерелевантным Web URL (например, с главной страницей сайта вместо конкретной статьи/товара). Это нарушает принцип synchronized content и ухудшает UX.
• Игнорирование связи App/Web: Запуск приложения без настройки связи между Deep Links и веб-URL не позволит Google эффективно использовать описанный в патенте механизм фолбэка.
• Агрессивное принуждение к установке: Использование URI 2 для перенаправления на страницу установки приложения вместо показа контента в браузере. Патент направлен на предотвращение такого поведения в пользу немедленной доставки контента.

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

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

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

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

1. Подготовка: Интернет-магазин настроил App Indexing. Товар "Кроссовки X" доступен по URI 1 (app://shop/product/X) и URI 2 (https://shop.com/product/X).
2. Поиск: Пользователь ищет "Кроссовки X" на смартфоне, где приложение магазина НЕ установлено.
3. Выдача: Google показывает Native Application Search Result с URI 1.
4. Клик и Обработка: Пользователь кликает на результат. Скрипт на устройстве определяет, что приложение не установлено.
5. Запрос и Подмена (по Claim 1): Скрипт запрашивает у Google альтернативу для URI 1. Google возвращает URI 2. Скрипт незаметно переписывает ссылку на https://shop.com/product/X.
6. Результат: Браузер пользователя открывает веб-страницу товара. Пользователь получает доступ к контенту без установки приложения.