Как Google определяет, какое приложение открыть, если контент доступен в нескольких приложениях на устройстве (Приоритетный диплинкинг)

Описание

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

Патент решает проблему неоднозначности при открытии контента на мобильных устройствах, когда один и тот же ресурс (например, видео, статья или товар) может быть обработан несколькими разными нативными приложениями (Native Applications). Например, видео может быть доступно в основном приложении YouTube, YouTube Kids или YouTube Music. Изобретение улучшает пользовательский опыт (UX), автоматически направляя пользователя в наиболее подходящее приложение для данного типа контента, основываясь на заданных предпочтениях.

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

Запатентована система генерации и ранжирования нескольких диплинков (Deeplinks) для одного ресурса. Для контента определяется набор подходящих приложений, и для каждого генерируется диплинк. Затем эти диплинки ранжируются на основе оценки предпочтения (Rank Score), определяя порядок предпочтения (Order of Preference). Эта ранжированная информация сохраняется в метаданных (Metadata), ассоциированных с ресурсом.

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

Механизм работает в два этапа:

• Этап 1 (Серверная сторона / Индексирование): Система идентифицирует ресурс и список приложений, которые могут его отобразить. Генерируются диплинки, которые затем ранжируются (часто на основе предпочтений издателя контента). Ранжированный список сохраняется в метаданных ресурса.
• Этап 2 (Клиентская сторона / Взаимодействие): Когда пользователь кликает по ссылке на ресурс (в поиске, браузере или другом приложении), его устройство получает эти метаданные. Устройство проверяет, какие из указанных приложений установлены локально, и автоматически запускает то установленное приложение, которое имеет наивысший ранг в списке предпочтений.

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

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

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

Влияние на классическое веб-SEO минимально (3/10), так как патент не описывает ранжирование веб-страниц. Однако он имеет существенное значение для App SEO (ASO) и стратегий App Indexing. Механизм позволяет контролировать путь пользователя из поиска или веб-страницы в наиболее релевантное нативное приложение, что критично для обеспечения надлежащего UX, вовлеченности и трекинга мобильного трафика.

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

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

Deeplink (Диплинк)

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

Metadata (Метаданные)

Данные, ассоциированные с ресурсом. В контексте патента содержат ранжированный список диплинков и их соответствующие ранги (Rank Scores).

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

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

Order of Preference (Порядок предпочтения)

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

Rank Score (Оценка ранжирования / Ранг предпочтения)

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

Resource (Ресурс)

Адресуемый контент, доступный устройству (веб-страница, видео, аудио, документ и т.д.).

Scheme Name (Имя схемы)

Часть URI в диплинке, которая идентифицирует нативное приложение и используется операционной системой для его запуска (например, youtube://).

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

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

1. Доступ к данным, которые описывают набор нативных приложений для определенного ресурса (контента). Важное уточнение: каждое приложение в наборе предоставляет уникальную среду отображения (presentation environment unique to the native application), отличную от других.
2. Генерация соответствующего диплинка для каждого нативного приложения в наборе.
3. Ранжирование сгенерированных диплинков на основе соответствующего rank score для каждого приложения. Это ранжирование определяет порядок предпочтения (order of preference) приложений для отображения контента.
4. Уточняется, что этот порядок предпочтения используется устройством пользователя для выбора приложения при активации ссылки на ресурс.
5. Ассоциирование ранжированных диплинков с ресурсом.

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

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

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

Данные о наборе приложений включают список, определяющий приложения и их порядковые ранги (ordinal rank scores), которые и задают порядок предпочтения. Ранжирование диплинков основывается на этих порядковых рангах.

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

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

INDEXING – Индексирование и извлечение признаков
На этом этапе происходит генерация метаданных. Система (например, Deeplink Generator) анализирует ресурсы и определяет, какие нативные приложения могут их обработать. Система вычисляет или получает Rank Scores (например, от издателя) и сохраняет ранжированный список диплинков в Metadata Database или основном индексе, ассоциируя его с ресурсом.

RANKING / METASEARCH – Ранжирование и Смешивание
Когда поисковая система (Search Engine) формирует выдачу (SERP) или веб-сервер (Web Server) отдает веб-страницу, система включает в ответ метаданные с ранжированными диплинками. В случае веб-страницы эти данные могут быть встроены в HTML (например, в тег <HEAD>).

Клиентская сторона (User Device)
Это ключевой момент применения патента. Устройство пользователя получает метаданные. При взаимодействии пользователя с ссылкой, операционная система или приложение-посредник (например, браузер или приложение Google Search) обрабатывает эти метаданные, проверяет наличие установленных приложений и запускает наиболее предпочтительное.

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

• Идентификатор и тип ресурса.
• Список нативных приложений, способных отобразить ресурс.
• Rank Scores (предпочтения) для этих приложений (часто задаются издателем контента).

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

• Метаданные, содержащие ранжированный список диплинков (URI), ассоциированные с ресурсом.

На что влияет

• Конкретные типы контента: Наибольшее влияние на мультимедийный контент (видео, музыка), игры, товары, а также любой контент, для которого издатель поддерживает экосистему из нескольких специализированных приложений.
• Устройства: Влияет на смартфоны и планшеты, где распространены нативные приложения и используется App Indexing.
• Конкретные ниши или тематики: Медиа, развлечения, крупные платформы (например, Google с YouTube, YouTube Music, YouTube Kids; крупные игроки e-commerce или новостные агрегаторы со специализированными приложениями).

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

• Условия работы (Индексирование): Алгоритм генерации применяется, когда при индексации ресурса обнаруживается, что он доступен для отображения более чем в одном нативном приложении, и для этих приложений известны ранги предпочтения.
• Триггеры активации (Клиентская сторона): Механизм выбора приложения активируется, когда пользователь на мобильном устройстве взаимодействует с ссылкой, ведущей на такой ресурс, и на устройстве установлено хотя бы одно из указанных приложений.

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

Процесс А: Генерация и ранжирование диплинков (Серверная сторона / Индексатор)

1. Получение данных: Система получает данные, указывающие несколько нативных приложений для конкретного ресурса.
2. Генерация диплинков: Для каждого нативного приложения генерируется соответствующий диплинк. Диплинк включает имя схемы (Scheme Name) и параметры для доступа к ресурсу.
3. Ранжирование диплинков: Сгенерированные диплинки ранжируются на основе Rank Score, связанного с каждым приложением. Это определяет Order of Preference.
4. Генерация метаданных: Система генерирует метаданные, которые ассоциируют ранжированный список диплинков с конкретным ресурсом.
5. Сохранение: Метаданные сохраняются для последующего использования (например, в индексе или базе данных метаданных).

Процесс Б: Обработка клика (Клиентская сторона / Устройство пользователя)

1. Получение ввода: Система получает ввод пользователя, взаимодействующего с ссылкой, которая ссылается на ресурс.
2. Получение метаданных: В ответ на ввод пользователя система получает метаданные, ассоциированные с ссылкой (из SERP, HTML страницы или кэша). Метаданные содержат ранжированный список диплинков.
3. Проверка установленных приложений: Система определяет (например, через функции ОС), какие из нативных приложений, указанных в списке диплинков, установлены на устройстве.
4. Выбор и запуск приложения: Система выбирает приложение, которое установлено на устройстве и имеет наивысший ранг (highest rank) среди установленных приложений. Выбранное приложение запускается с использованием соответствующего диплинка.

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

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

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

• Технические факторы: URL или идентификатор ресурса. Идентификаторы нативных приложений (Scheme Name или ID пакета). Конфигурационные файлы приложений.
• Контентные/Структурные факторы: Тип или жанр контента ресурса (например, «kids», «games»). Эти данные могут влиять на определение Rank Scores.
• Системные данные (Publisher Preferences): Данные, предоставленные издателем контента, указывающие предпочтения для использования приложений. Это основной источник для определения Rank Score.
• Пользовательские факторы (Используются на стороне клиента): Информация о том, какие нативные приложения установлены на устройстве пользователя в момент взаимодействия с ссылкой.

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

• Rank Score (Оценка ранжирования / Ранг предпочтения): Это ключевая метрика патента. Она определяет Order of Preference. Патент не детализирует алгоритмы расчета, но указывает, что она может быть предопределена (predetermined) или основана на списке предпочтений издателя (preference list of the publisher). В Claim 3 упоминаются порядковые ранги (ordinal rank scores), что подразумевает простую сортировку по предпочтительности (1-е место, 2-е место и т.д.).
• Статус установки приложения: Булево значение (установлено/не установлено), используемое на стороне клиента.

Выводы

1. Ранжирование диплинков для управления UX: Основное нововведение — это не просто наличие нескольких диплинков, а их явное ранжирование (Order of Preference). Система стремится выбрать наилучшую среду для потребления контента из установленных приложений.
2. Контроль издателя над путем пользователя: Механизм дает издателям контента инструмент для управления тем, в каком приложении пользователь будет взаимодействовать с контентом. Это позволяет направлять трафик в специализированные приложения (например, YouTube Kids), которые обеспечивают лучший UX для конкретного типа контента.
3. Двухуровневая архитектура (Сервер/Клиент): Работа разделена между серверной частью (генерация и ранжирование диплинков во время индексации) и клиентской частью (проверка установленных приложений и выбор наилучшего варианта в момент клика).
4. Инфраструктурный характер: Патент описывает инфраструктуру для улучшения мобильного UX (App Indexing), а не алгоритм ранжирования контента в поиске.
5. Важность корректной технической реализации: Для работы механизма необходимо, чтобы связь между ресурсами и нативными приложениями была корректно настроена издателем (например, через Firebase App Indexing или разметку на сайте).

Практика

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

• Внедрение App Indexing: Необходимо убедиться, что контент в ваших приложениях доступен по диплинкам и индексируется Google (например, через Firebase App Indexing). Это базовая необходимость для работы описанного механизма.
• Настройка ассоциации сайта и приложений: Гарантируйте корректную связь между веб-страницами и соответствующим контентом в приложениях. Это включает использование файлов ассоциации (например, assetlinks.json для Android App Links).
• Использование разметки на веб-страницах: Патент упоминает, что метаданные с диплинками могут быть встроены в <HEAD> тег веб-страницы. Используйте разметку rel=»alternate» с указанием диплинков (Android/iOS app URIs) на всех страницах, имеющих эквивалент в приложении.
• (Для владельцев нескольких приложений) Определение и передача предпочтений: Если ваш бренд имеет экосистему приложений (например, основное и специализированное), необходимо разработать логику предпочтений (Rank Scores). Определите, какой контент в каком приложении должен открываться в приоритетном порядке, и настройте передачу этих метаданных поисковой системе.
• Тестирование пути пользователя: Регулярно проверяйте, как работает диплинкинг из SERP и с веб-страниц на устройствах с различными наборами установленных приложений, чтобы убедиться, что Order of Preference работает корректно.

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

• Игнорирование диплинкинга и App Indexing: Полагаться только на веб-версию сайта на мобильных устройствах, игнорируя возможности перенаправления пользователей в нативные приложения, приводит к потере вовлеченности и ухудшению UX.
• Отсутствие явных предпочтений (для мульти-апп): Если не определить Order of Preference при наличии нескольких приложений, система может выбрать неоптимальное приложение по умолчанию, что может ухудшить пользовательский опыт.
• Некорректная настройка диплинков: Ошибки в URI, ведущие на несуществующий контент или главную страницу приложения вместо конкретного ресурса, аннулируют преимущества механизма.

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

Патент подтверждает стратегию Google по интеграции веб-поиска и поиска по приложениям. Контент рассматривается как независимая сущность, а браузер и различные нативные приложения — как среды для его отображения. Цель системы — выбрать оптимальную среду. Для SEO это означает, что оптимизация присутствия в поиске должна включать не только веб-сайт, но и полноценную стратегию App Indexing, гарантируя, что пользователи попадают в наиболее релевантную и удобную среду.

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

Сценарий 1: Экосистема YouTube

1. Ресурс: Видеоклип детской песни.
2. Доступные приложения: YouTube (Основное), YouTube Kids, YouTube Music.
3. Настройка (Best Practice): Издатель устанавливает Order of Preference: 1. YouTube Kids (наивысший приоритет), 2. YouTube Music, 3. YouTube (Основное).
4. Действие пользователя: Пользователь ищет видео на планшете и нажимает на ссылку в поиске Google.
5. Результат:
   • Если установлен YouTube Kids, видео откроется в нем.
   • Если YouTube Kids не установлен, но установлен YouTube Music, откроется он.
   • Если установлено только основное приложение YouTube, откроется оно.

Сценарий 2: Новостной портал с несколькими вертикалями

1. Ресурс: Статья о результатах футбольного матча.
2. Доступные приложения: «Главные Новости» (основное), «Спорт» (специализированное).
3. Настройка (Best Practice): Устанавливается Order of Preference: 1. Приложение «Спорт» (лучше оптимизировано под этот сегмент), 2. Приложение «Главные Новости».
4. Действие пользователя: Пользователь нажимает на ссылку статьи в браузере.
5. Результат: Если у пользователя установлены оба приложения, система автоматически откроет статью в приложении «Спорт», обеспечивая лучший тематический UX.

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