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

Описание

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

Патент решает проблему совместимости глубоких ссылок (deep links) с разными версиями нативных приложений (native applications). Глубокие ссылки, созданные для новых версий приложений, могут не работать корректно (вызывать ошибки, сбои или не открывать нужный контент) на устройствах пользователей, которые не обновили приложение до последней версии (проблема обратной несовместимости). Это приводит к негативному пользовательскому опыту при переходе из поиска в приложение.

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

Запатентована система верификации и контролируемой выдачи глубоких ссылок для нативных приложений. Система проверяет работоспособность deep link для конкретной версии приложения (version level) и индексирует эту информацию (verification data). При формировании поисковой выдачи система проверяет версию приложения, установленную на устройстве пользователя, и разрешает показ глубокой ссылки только в том случае, если версия приложения пользователя равна или новее (same as or subsequent to) версии, для которой ссылка была верифицирована.

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

Система функционирует в двух основных режимах: индексирование и выдача.

• Индексирование и Верификация: Система получает набор глубоких ссылок. Используя эмулируемую среду, например, виртуальную машину (User Device OS Virtual Machine), система запускает определенную версию приложения и проверяет каждую ссылку. Если ссылка корректно открывает нужный экземпляр среды (environment instance), она помечается как верифицированная для этой версии.
• Выдача (Serving) и Фильтрация: Когда глубокая ссылка выбирается для показа в результатах поиска, система определяет версию приложения, установленную на целевом устройстве пользователя. Система сравнивает ее с минимальной верифицированной версией из индекса. Если установленная версия старше (ниже), глубокая ссылка не показывается.

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

Высокая. С учетом фрагментации версий операционных систем и того факта, что пользователи не всегда своевременно обновляют приложения, обеспечение корректной работы глубоких ссылок остается критически важной задачей для Google. Механизмы App Indexing (например, Firebase App Indexing) активно используются, и этот патент описывает ключевой инфраструктурный компонент для поддержания качества этого трафика.

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

Патент имеет существенное значение (7/10) для стратегий App SEO и App Indexing. Он описывает механизм, который напрямую влияет на видимость контента приложения в поиске Google. Если пользователи не обновляют приложение, они перестанут видеть глубокие ссылки на новый контент, что снизит трафик из поиска в приложение. Это подчеркивает важность не только технической реализации deep links, но и стратегий по стимулированию пользователей к обновлению приложений для максимизации охвата в поиске.

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

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

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

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

Deep Link Verifier (Верификатор глубоких ссылок)

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

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

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

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

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

Verification Data (Данные верификации)

Данные, генерируемые системой после успешного тестирования глубокой ссылки. Они указывают минимальную версию приложения (version level), для которой ссылка гарантированно работает.

Version Level (Уровень версии)

Идентификатор конкретной сборки или релиза нативного приложения.

User Device OS Virtual Machine (Виртуальная машина ОС пользовательского устройства)

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

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

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

1. Система работает с нативными приложениями (независимыми от браузера) и их глубокими ссылками.
2. Для каждой глубокой ссылки система получает verification data, подтверждающие, что ссылка корректно работает в приложении first version level (первого уровня версии).
3. Эти данные и ссылки сохраняются в индексе (index of deep links).
4. Система получает запрос на показ глубокой ссылки на устройстве пользователя, где установлено это приложение.
5. Система определяет уровень версии приложения, установленного на устройстве пользователя.
6. Ключевое действие: Глубокая ссылка показывается (serving the deep link) ТОЛЬКО если установленная версия приложения является такой же или более поздней (same as or subsequent to), чем верифицированная версия (first version level).

Claim 2 (Зависимый): Расширяет Claim 1, описывая процесс для второго набора ссылок, верифицированных для более новой версии (second version level).

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

Claim 4 (Зависимый от 2): Уточняет сценарий, когда ссылка из первого набора (верифицирована для V1) НЕ входит во второй набор (не верифицирована или не работает в V2).

В этом случае ссылка показывается, только если у пользователя установлена именно первая версия (first version level). Это описывает возможность ограничения диапазона версий для ссылок, чья совместимость с новыми версиями нарушена (нарушение прямой совместимости).

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

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

CRAWLING – Сканирование и Сбор данных
На этом этапе система получает deep links от издателей приложений (Application Publishers), из карт приложений (app maps) или других источников.

INDEXING – Индексирование и извлечение признаков
Основной этап применения патента. Здесь происходит верификация ссылок.

1. Тестирование: Система использует User Device OS Virtual Machine для запуска конкретной версии приложения и тестирования полученных глубоких ссылок.
2. Верификация: Deep Link Verifier определяет, корректно ли ссылка инициирует environment instance.
3. Извлечение данных: Data Extractors могут извлекать контент из открытого экземпляра среды.
4. Индексирование: Indexer сохраняет глубокую ссылку, извлеченный контент и Verification Data (минимальный version level) в Application Index.

RANKING – Ранжирование
Search System использует Application Index для поиска релевантных глубоких ссылок в ответ на запрос пользователя. На этом этапе выбираются кандидаты для показа.

RERANKING / SERVING – Переранжирование и Выдача
Финальный этап, на котором применяется логика фильтрации.

1. Определение контекста пользователя: Система определяет версию нативного приложения, установленного на устройстве пользователя.
2. Фильтрация по версии: Система сравнивает версию пользователя с Verification Data из индекса. Если версия пользователя ниже требуемой, ссылка отфильтровывается и не показывается.

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

• Набор глубоких ссылок (URIs).
• Нативное приложение определенной версии (APK или аналог).
• Данные о версии приложения, установленной у пользователя (на этапе Serving).

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

• Verification Data (минимально необходимая версия для ссылки).
• Индексированные данные в Application Index.
• Отфильтрованные результаты поиска (Native Application Search Results) с рабочими глубокими ссылками.

На что влияет

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

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

• Триггеры активации (Индексирование): Получение новых глубоких ссылок или выпуск новой версии нативного приложения.
• Триггеры активации (Выдача): Каждый раз, когда система намеревается показать результат поиска, ведущий в нативное приложение через глубокую ссылку.
• Принцип фильтрации: Система применяет фильтр, основанный на предположении о прямой совместимости (forward compatibility) и предотвращении обратной несовместимости (backward incompatibility).

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

Процесс А: Верификация и Индексирование (На основе FIG. 3)

1. Получение данных: Система получает первый набор глубоких ссылок для нативного приложения.
2. Инициализация тестирования: Система запускает нативное приложение определенной (первой) версии в тестовой среде (например, виртуальной машине).
3. Цикл верификации: Для каждой глубокой ссылки система пытается инициировать соответствующий экземпляр среды.
   • Система отслеживает корректность инициализации (отсутствие ошибок, таймаутов, сбоев приложения).
4. Генерация данных верификации: Только для ссылок, которые успешно прошли проверку, система генерирует Verification Data, указывающие, что ссылка верифицирована для этой первой версии.
5. Индексирование: Глубокая ссылка и Verification Data сохраняются в индексе приложений.

Процесс Б: Обслуживание запроса и Выдача (На основе FIG. 3)

1. Выбор кандидата: Система выбирает глубокую ссылку из индекса для показа пользователю.
2. Определение контекста пользователя: Система определяет версию нативного приложения, установленную на устройстве пользователя.
3. Проверка совместимости: Система сравнивает версию приложения пользователя с версией, указанной в Verification Data для данной глубокой ссылки.
4. Принятие решения:
   • Если версия пользователя МЕНЬШЕ, чем верифицированная версия: Глубокая ссылка НЕ показывается.
   • Если версия пользователя РАВНА ИЛИ БОЛЬШЕ (same as or subsequent to), чем верифицированная версия: Глубокая ссылка показывается.

Процесс В: Обработка нарушений прямой совместимости (Альтернативные реализации, на основе FIG. 4A/4B)

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

1. Повторная верификация: Каждая ссылка проверяется на работоспособность во второй версии приложения.
2. Обновление индекса (Вариант 1 — Удаление несовместимых, FIG. 4A): Если ссылка НЕ работает во второй версии, она может быть удалена из индекса.
3. Обновление индекса (Вариант 2 — Диапазон версий, FIG. 4B): Если ссылка НЕ работает во второй версии, Verification Data обновляются для указания диапазона версий. В индексе фиксируется «failed version» (вторая версия). Ссылка будет показываться, только если версия пользователя больше или равна первой версии И меньше второй версии.

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

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

Патент фокусируется на инфраструктуре верификации и использует следующие типы данных:

• Контентные факторы (Косвенно): Во время верификации система может извлекать контент (текст, изображения) из environment instance для индексации и формирования сниппета (например, сниппет 532 и изображение 534 на FIG. 5).
• Технические факторы:
  • Deep Links (URI или другие инструкции).
  • Version Level (идентификатор версии приложения).
  • Сигналы корректной работы приложения (отсутствие ошибок, сбоев, таймаутов во время тестирования).
• Пользовательские факторы:
  • Версия нативного приложения, установленная на устройстве пользователя (определяется в момент показа результатов).

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

Метрики в патенте носят бинарный характер или основаны на сравнении версий:

• Correct Instantiation (Корректная инициализация): Бинарная метрика (Да/Нет). Определяется путем мониторинга работы приложения в виртуальной машине при активации глубокой ссылки. Отсутствие ошибок означает успех.
• Version Comparison (Сравнение версий): Логическое сравнение. Сравнивается Version Level установленного приложения с Version Level, сохраненным в Verification Data.
• Version Range (Диапазон версий): В альтернативной реализации (FIG. 4B) система может хранить диапазон V_start и V_end (версия, в которой ссылка перестала работать). Ссылка показывается, если V_user >= V_start И V_user < V_end.

Выводы

1. Минимальная версия как требование для показа: Ключевой механизм патента — это фильтрация глубоких ссылок на этапе выдачи. Google не будет показывать ссылку, если версия приложения пользователя старше той, для которой ссылка была верифицирована.
2. Предотвращение негативного опыта (UX): Основная цель — не допустить ситуации, когда пользователь кликает на ссылку в поиске, а приложение падает или не может открыть контент из-за несовместимости версий.
3. Предположение о прямой совместимости (Forward Compatibility): Система по умолчанию предполагает, что ссылка, работающая в версии V1, будет работать и в V2 (subsequent version). Индекс хранит минимальную необходимую версию.
4. Строгая проверка обратной совместимости (Backward Compatibility): Система НЕ предполагает обратную совместимость. Ссылка, верифицированная только для V2, НИКОГДА не будет показана пользователю V1.
5. Автоматизированная верификация: Google использует автоматизированные системы (виртуальные машины) для проверки работоспособности глубоких ссылок в разных версиях приложений, не полагаясь только на данные от разработчиков.
6. Возможность отзыва ссылок: Патент предусматривает механизмы повторной верификации. Если прямая совместимость нарушается (ссылка из V1 перестала работать в V2), ссылка может быть удалена из индекса или для нее может быть установлен диапазон поддерживаемых версий.

Практика

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

• Обеспечение надежности Deep Links: Разработчики и SEO-специалисты, работающие с App Indexing, должны внедрять надежную и устойчивую к изменениям архитектуру глубоких ссылок. Ссылки должны быть максимально универсальными и не ломаться при минорных обновлениях приложения.
• Стимулирование обновлений приложений: Критически важно мотивировать пользователей обновлять приложение до последней версии. Если большая часть аудитории использует устаревшие версии, они не увидят в поиске глубокие ссылки на новый контент, что приведет к потере трафика и вовлеченности.
• Тестирование прямой совместимости: При выпуске новой версии приложения необходимо проводить регрессионное тестирование всех ключевых глубоких ссылок, чтобы убедиться, что они продолжают работать (прямая совместимость). Если ссылка ломается, Google может удалить ее из индекса.
• Мониторинг индексации Deep Links: Необходимо отслеживать статус индексации глубоких ссылок в инструментах для разработчиков (например, Firebase, Google Search Console). Падение количества проиндексированных ссылок может указывать на проблемы с верификацией после обновления приложения.
• Предоставление полных данных для индексации: Убедитесь, что Google имеет доступ ко всем необходимым глубоким ссылкам (через sitemaps, аннотации на сайте или API App Indexing), чтобы система могла их верифицировать сразу после релиза новой версии или добавления нового контента.

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

• Частое изменение схемы Deep Links: Изменение структуры URI или логики обработки глубоких ссылок без обеспечения обратной совместимости приведет к тому, что старые ссылки перестанут верифицироваться в новых версиях и будут удалены из индекса.
• Игнорирование фрагментации версий: Разработка функционала, доступного через deep link, только для последней версии приложения без учета того, что значительная часть пользователей может использовать старые версии.
• Отсутствие тестирования Deep Links перед релизом: Выпуск обновления приложения без проверки работоспособности глубоких ссылок. Это может привести к ошибкам верификации со стороны Google.
• Отправка неверифицируемых ссылок: Отправка в Google глубоких ссылок, которые требуют сложной аутентификации или специфических условий для открытия, которые система верификации Google не сможет воспроизвести в своей тестовой среде.

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

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

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

Сценарий: Приложение интернет-магазина и обработка ошибок совместимости

1. Релиз V1.0: Приложение запускается. Глубокие ссылки на товары (e.g., app://shop/product/123) верифицируются для V1.0 и индексируются.
2. Релиз V1.1: Добавляется новый раздел «Скидки дня». Новые глубокие ссылки (e.g., app://shop/dailydeals) верифицируются для V1.1.
3. Пользователь А (Установлена V1.1): Ищет «Скидки дня в магазине». Google видит, что у пользователя V1.1. Ссылка app://shop/dailydeals требует минимум V1.1. Условие выполняется (1.1 >= 1.1). Ссылка показывается.
4. Пользователь Б (Установлена V1.0): Ищет «Скидки дня в магазине». Google видит, что у пользователя V1.0. Ссылка app://shop/dailydeals требует минимум V1.1. Условие НЕ выполняется (1.0 < 1.1). Ссылка НЕ показывается.
5. Релиз V1.2 (Ошибка совместимости): В этой версии случайно ломается обработка старых ссылок на товары. Google проводит повторную верификацию (Процесс В). Ссылка app://shop/product/123 не работает в V1.2.
6. Действие Google: Google обновляет индекс, помечая ссылку app://shop/product/123 как работающую только в диапазоне V1.0-V1.1 (Вариант 2) или удаляет ее (Вариант 1). Пользователи V1.2 перестают видеть эту ссылку в поиске.

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