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

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

Application Link (Ссылка приложения)

Строка символов (например, URI), которая ведет на определенное место или контент внутри мобильного приложения (Deep Link).

Presentation Duration (Длительность презентации)

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

Duration Monitor (Монитор длительности)

Компонент на клиентском устройстве, который отслеживает, записывает и отправляет данные о Presentation Duration в систему.

Duration Groups (Группы длительности)

Заданные диапазоны времени (например, 0-2 сек, 2-4 сек). Используются для построения распределения (гистограммы) Presentation Durations.

Machine Learning Model (Модель машинного обучения)

Модель (например, линейная регрессия), обученная на размеченных данных (labeled training data) для предсказания статуса ссылки (битая/рабочая) на основе анализа распределения ее Presentation Durations.

Application Link Prefix Pattern (Паттерн префикса ссылки приложения)

Строка символов, общая для двух или более ссылок приложения (например, appname:category1/). Используется для группировки ссылок, относящихся к одному разделу приложения.

Broken Link (Битая ссылка)

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

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

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

1. Система получает данные (Presentation Durations) о множестве взаимодействий пользователей со ссылками приложения.
2. Система классифицирует каждую ссылку как битую или рабочую, применяя Machine Learning Model.
3. Модель ML генерируется с использованием размеченных обучающих данных.
4. Критически важный элемент: Модель ML классифицирует ссылку на основе распределения (distribution) Presentation Durations. Распределение определяет, сколько сессий попадает в каждый из множества временных диапазонов (plurality of time duration ranges).
5. Система генерирует и выводит оповещение, если ссылка классифицирована как битая.

Claim 2 (Зависимый от 1): Детализирует, как модель ML использует распределение.

1. Каждая Presentation Duration назначается одной из Duration Groups (временных диапазонов).
2. Классификация ссылки основана на паттерне (pattern), определяемом количеством Presentation Durations, назначенных каждой группе. (На практике это анализ формы гистограммы распределения).

Claim 4 (Зависимый от 1): Описывает механизм группировки ссылок для повышения эффективности и точности.

1. Система идентифицирует Application Link Prefix Patterns (общие строки символов) для набора ссылок.
2. Для каждого префикса:
   1. Идентифицируется группа ссылок с этим префиксом.
   2. Идентифицируется набор Presentation Durations для этой группы (агрегация).
   3. Модель ML применяется к агрегированным данным группы.
   4. Генерируется оповещение для группы ссылок, если модель классифицирует набор ссылок как битый.

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

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

CRAWLING – Сканирование и Сбор данных
Вместо активного сканирования контента краулером, система пассивно собирает данные о пользовательском опыте (Presentation Durations) с клиентских устройств через Duration Monitors. Это позволяет валидировать ссылки, которые сложно проверить прямым сканированием (например, контент за логином).

INDEXING – Индексирование и извлечение признаков
Основное применение. Собранные Presentation Durations обрабатываются, строятся распределения (гистограммы), и ML-модель используется для классификации здоровья ссылок. Эта классификация (рабочая/битая) используется для валидации и контроля качества Application Links, хранящихся в индексе Google (например, App Indexing).

RERANKING – Переранжирование (Фильтрация)
Результаты работы системы используются для улучшения качества SERP. Ссылки, классифицированные как битые, вероятно, будут отфильтрованы или удалены из поисковой выдачи, чтобы предотвратить негативный пользовательский опыт.

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

• Идентификаторы ссылок приложения (Deep Links URI).
• Presentation Durations для множества взаимодействий с этими ссылками.

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

• Классификация ссылки или группы ссылок (Рабочая/Битая).
• Оповещения (Alerts) о битых ссылках.

На что влияет

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

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

• Условия работы алгоритма: Алгоритм применяется для ссылок приложений, по которым доступно достаточное количество статистических данных о Presentation Durations от реальных пользователей.
• Частота применения: Сбор данных происходит непрерывно. Классификация может выполняться периодически или при накоплении определенного объема данных по ссылке или группе ссылок. Группировка по префиксам позволяет быстрее достичь статистической значимости.

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

Процесс А: Обучение модели (Офлайн)

1. Подготовка данных: Выбирается набор тренировочных ссылок приложения (training application links), для которых известен статус (рабочая/битая – label) и доступны данные о Presentation Durations.
2. Генерация признаков: Для каждой ссылки строится распределение Presentation Durations по Duration Groups, формируя вектор признаков.
3. Обучение модели: Модель машинного обучения тренируется для распознавания паттернов распределения, которые коррелируют с метками статуса.

Процесс Б: Классификация ссылок

1. Сбор данных: Система получает данные о Presentation Durations от Duration Monitors на клиентских устройствах.
2. Агрегация и Группировка (Опционально): Данные агрегируются по отдельным ссылкам. Система может идентифицировать Application Link Prefix Patterns и агрегировать данные по группам ссылок с общим префиксом.
3. Анализ распределения: Для каждой ссылки (или группы) система строит распределение Presentation Durations:
   1. Назначение каждой продолжительности в соответствующую Duration Group (например, 0-2 сек).
   2. Подсчет количества продолжительностей в каждой группе.
4. Применение модели ML: Обученная модель применяется к полученному распределению (вектору признаков).
5. Классификация: Модель выводит классификацию. Например, паттерн с доминированием очень коротких длительностей классифицируется как битый.
6. Генерация оповещения: Если ссылка или группа классифицирована как битая, система генерирует оповещение.

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

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

Патент фокусируется на специфическом наборе данных:

• Поведенческие факторы: Presentation Duration. Это основная метрика, отражающая время взаимодействия пользователя с контентом приложения после клика по ссылке.
• Технические факторы: Идентификаторы ссылок приложения (URI). Они используются для агрегации данных и для идентификации Application Link Prefix Patterns. Также используются данные о сбоях приложений (crash data) для определения момента окончания Presentation Duration в случае сбоя.

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

• Распределение длительностей (Distribution of Presentation Durations): Ключевой набор признаков для ML-модели. Строится путем разделения временной шкалы на Duration Groups и подсчета количества сессий, попадающих в каждую группу. Система анализирует паттерн распределения, а не среднее значение.
• Вектор признаков (Feature Vector): Числовое представление распределения. Вектор содержит элементы, соответствующие каждой Duration Group, а значение элемента равно количеству (или пропорционально количеству) Presentation Durations в этой группе.
• Алгоритмы машинного обучения: Используется модель классификации (Supervised Learning). В патенте (Claim 6) конкретно упоминается возможность использования линейной регрессии (linear regression model).

1. Google оценивает качество Deep Links через поведение пользователей: Патент подтверждает, что Google активно отслеживает, что происходит после клика по ссылке в мобильное приложение. Вместо попыток сканировать сложный контент приложений, используется анализ реального пользовательского опыта как источник истины.
2. Presentation Duration как ключевой сигнал здоровья ссылки: Время, проведенное пользователем в приложении после перехода (аналог Dwell Time), является основным индикатором работоспособности. Короткие сессии или сбои приложений интерпретируются как признак битой ссылки.
3. Важность анализа распределения, а не средних значений: Система анализирует гистограмму временных интервалов. Паттерн, сильно смещенный в сторону коротких сессий (0-3 сек), является сильным негативным сигналом, указывающим на технические проблемы или нерелевантность контента.
4. Эффективность за счет группировки по префиксам: Google использует анализ структуры URI (Prefix Patterns) для масштабирования и повышения точности. Если целый раздел приложения (например, app://store/category/*) демонстрирует негативные паттерны, вся группа ссылок может быть признана некачественной одновременно.
5. Техническое состояние приложения напрямую влияет на App SEO: Работоспособность приложения, скорость загрузки контента и отсутствие сбоев при переходе по Deep Links напрямую влияют на сохранение этих ссылок в индексе Google и их видимость в поиске.

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

Рекомендации критически важны для специалистов, занимающихся App Indexing (например, Firebase App Indexing) и ASO.

• Комплексный мониторинг Deep Links и UX: Анализируйте внутреннюю аналитику приложений (например, Firebase Analytics), фокусируясь на времени, проведенном на экране (Time on Screen), и показателях отказов для пользователей, пришедших через Deep Links из поиска. Ищите экраны с аномально короткими сессиями.
• Мониторинг сбоев приложений (Crash Monitoring): Активно отслеживайте сбои (crashes), происходящие при переходе по внешним ссылкам (например, через Firebase Crashlytics). Сбои приводят к очень коротким Presentation Durations и быстрой классификации ссылки как битой.
• Тщательное тестирование после обновлений: Регулярно проверяйте работоспособность всех индексируемых Deep Links, особенно после обновлений приложения или изменений на бэкенде.
• Оптимизация скорости загрузки внутри приложения: Убедитесь, что контент по Deep Link загружается быстро. Медленная загрузка может побудить пользователей покинуть приложение, что система интерпретирует как проблему.
• Поддержание консистентной структуры URI: При изменении структуры приложения убедитесь, что старые URI корректно обрабатываются. Группировка по Prefix Patterns означает, что ошибка в структуре раздела может повлиять на все ссылки с этим префиксом.
• Обеспечение релевантности контента: Убедитесь, что Deep Link ведет на релевантный контент. Если ссылка технически работает, но ведет на неверный экран, пользователи будут быстро уходить, что система также интерпретирует как "битую" ссылку.

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

• Игнорирование стабильности приложения: Рассматривать App SEO отдельно от технического состояния приложения. Сбои приложения при переходе из поиска напрямую вредят видимости в Google.
• Изменение структуры приложения без учета Deep Links: Обновление приложения, которое меняет внутреннюю навигацию или структуру URI, может мгновенно сделать все существующие индексированные Deep Links битыми.
• Показ промежуточных страниц или агрессивных Pop-up: Показ полноэкранной рекламы, запросов на авторизацию или других промежуточных экранов сразу после перехода по Deep Link может привести к быстрому уходу пользователя, что будет интерпретировано как негативный сигнал (короткая Presentation Duration).

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

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

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

Сценарий: Ошибка в разделе E-commerce приложения после сбоя API

1. Ситуация: В приложении интернет-магазина произошел сбой API, из-за которого не загружаются товары в категории "Ноутбуки" (префикс app://store/laptops/). При переходе по Deep Link на товар из этой категории пользователь видит пустой экран или ошибку.
2. Поведение пользователей: Пользователи кликают на эти ссылки в поиске Google. Duration Monitor фиксирует сбой или быстрый выход пользователя. Presentation Durations составляют 0-3 секунды.
3. Анализ Google: Система агрегирует данные для префикса app://store/laptops/. Модель машинного обучения видит распределение, сильно смещенное к коротким сессиям (пик в 0-3 сек).
4. Результат: Система классифицирует всю группу ссылок с этим префиксом как битые и удаляет их из поисковой выдачи до устранения проблемы и нормализации поведенческих сигналов.