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

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

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

База данных (индекс) страниц приложений (application pages) для нативных приложений.

Application Page (Страница приложения)

Конкретная среда отображения контента внутри нативного приложения. Отличается от веб-страницы тем, что генерируется внутри приложения, специфичного для ОС устройства.

Corresponding Web Resource (Соответствующий веб-ресурс)

Веб-ресурс (сайт или страница), который предоставляет ту же или схожую функцию и/или информацию, что и нативное приложение.

Cross-resource attribution (Межресурсная атрибуция)

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

Deep Linking (Глубинное связывание)

Функция, при которой выбор результата поиска приложения запускает приложение (если оно установлено) и открывает конкретную Application Page, релевантную запросу.

Global Signals (Глобальные сигналы)

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

Native Application Score (Оценка нативного приложения)

Мера релевантности или качества приложения до нормализации.

Normalization Factor (Коэффициент нормализации)

Коэффициент, используемый для приведения оценок приложений к шкале оценок веб-ресурсов. Может быть рассчитан с помощью линейной регрессии или представлен в виде взвешенного вектора (weighted vector).

Notionally Common Scale (Условно общая шкала)

Единая шкала измерения, к которой приводятся оценки веб-ресурсов и приложений после нормализации.

Proper Subset (Надлежащее подмножество)

Группа нативных приложений, для которых система идентифицировала Corresponding Web Resource. Эта группа используется как калибровочный набор для расчета Normalization Factor.

User Device Specific Signals (Сигналы, специфичные для устройства пользователя)

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

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

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

1. Система получает оценки веб-ресурсов (web resource scores).
2. Система определяет оценки нативных приложений (native application scores).
3. Определяется первое надлежащее подмножество (proper subset) приложений, для которых найдены соответствующие веб-ресурсы.
4. На основе оценок приложений и соответствующих им веб-ресурсов из этого подмножества вычисляется normalization factor, который приводит оценки к notionally common scale.
5. Normalization factor применяется к оценкам приложений для генерации normalized native application scores.
6. Веб-ресурсы и нативные приложения ранжируются совместно на основе веб-оценок и нормализованных оценок приложений.

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

Определение коэффициента нормализации включает линейную регрессию (linearly regressing) оценок приложений как переменной, зависимой от соответствующих веб-оценок.

Claims 3-7 (Зависимые): Детализируют глобальные факторы (Global Signals), используемые для расчета native application score.

• (Claim 3, 4, 5): Использование ссылочных данных: количество ссылок на приложение и оценка качества (quality score) этих ссылок. Ссылки могут быть как веб-ссылками (web links с сайтов), так и ссылками из других приложений (application links).
• (Claim 6): Использование данных об установках: количество загрузок (number of downloads) приложения.
• (Claim 7): Использование контентных данных: выбор данных страниц приложения (application page data) из индекса приложений и генерация оценки на основе этих данных и поискового запроса.

Claims 8-9 (Зависимые): Детализируют факторы, специфичные для устройства (User Device Specific Signals).

• (Claim 8): Генерация оценки приложения на основе данных, специфичных для устройства (device specific data), с которого был получен запрос.
• (Claim 9): Эти данные включают статус установки (установлено ли приложение на устройстве) и частоту использования (frequency of use) приложения на этом устройстве.

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

Изобретение является ключевым компонентом инфраструктуры Универсального Поиска и затрагивает несколько этапов.

INDEXING – Индексирование и извлечение признаков
На этом этапе происходит сбор данных для Web Index и Application Index (App Indexing). Извлекаются признаки для расчета глобальных сигналов качества приложений (количество установок, рейтинги, ссылки). Также сохраняется информация о соответствии между приложениями и веб-ресурсами.

RANKING – Ранжирование
Resource Scorer и Application Scorer параллельно рассчитывают предварительные оценки релевантности. Application Scorer использует как Global Signals, так и User Device Specific Signals (персонализация) для расчета Native Application Score.

METASEARCH – Метапоиск и Смешивание
Это основной этап применения патента. Normalizer получает предварительные оценки из двух разных систем скоринга. Он вычисляет Normalization Factor, используя данные о Proper Subset, и приводит оценки приложений к Notionally Common Scale. Затем Score Adjuster And Ranker объединяет и ранжирует результаты из обоих индексов в единый список.

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

• Web resource scores.
• Native application scores.
• Данные о соответствии приложений и веб-ресурсов (для определения Proper Subset).
• User Device Specific Signals.
• Поисковый запрос.

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

• Объединенный ранжированный список результатов (SERP), включающий веб-ресурсы и нативные приложения (Deep Links).

На что влияет

• Конкретные типы контента и Ниши: Влияет на ранжирование нативных мобильных приложений относительно веб-страниц. Наибольшее влияние в нишах, где приложения активно используются: e-commerce, путешествия, финансы, медиа, социальные сети.
• Специфические запросы: Запросы, где интент пользователя может быть удовлетворен как через веб-сайт, так и через приложение (например, бронирование отелей, проверка погоды, поиск товаров).
• Окружение: Применяется преимущественно в мобильном поиске (смартфоны, планшеты).

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

• Условия работы: Алгоритм применяется, когда поисковая система определяет, что и веб-ресурсы, и нативные приложения могут быть релевантны запросу пользователя.
• Триггеры активации: Необходимость сравнить и объединить результаты из Web Index и Application Index в единую выдачу, особенно при поиске с мобильного устройства.

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

Процесс нормализации и ранжирования (соответствует FIG. 3):

1. Получение веб-оценок: Система получает web resource scores для релевантных веб-ресурсов.
2. Расчет оценок приложений: Система определяет native application scores для релевантных приложений. Этот расчет включает:
   • Учет глобальных сигналов (установки, рейтинги, ссылки, контент).
   • Учет сигналов, специфичных для устройства пользователя (установлено ли, как часто используется, стабильность).
3. Определение подмножества для калибровки: Система идентифицирует proper subset – приложения, у которых есть соответствующие веб-ресурсы, также получившие оценки.
4. Расчет коэффициента нормализации: Используя оценки (веб и апп) из proper subset, система определяет normalization factor. Основной метод, указанный в патенте, – линейная регрессия, где оценки приложений рассматриваются как зависимые от оценок соответствующих веб-ресурсов.
5. Нормализация оценок: Система применяет normalization factor ко всем native application scores (включая приложения, не входящие в proper subset), чтобы сгенерировать normalized native application scores.
6. Объединенное ранжирование: Система ранжирует веб-ресурсы и нативные приложения совместно, используя web resource scores и normalized native application scores.

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

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

Патент детализирует факторы, используемые для расчета Native Application Score. Они делятся на две категории: Глобальные и Специфичные для устройства.

Глобальные сигналы (Global Signals):

• Ссылочные факторы (Link data): Количество и качество ссылок на нативное приложение или на ресурс, с которого его можно установить. Включает как веб-ссылки (web links), так и ссылки из других приложений (application links).
• Поведенческие/Вовлеченность (Installation/Usage data):
  • Installation data: Количество установок или загрузок (number of downloads).
  • Usage data: Общее использование приложения (время запуска (time instantiated), вовлеченность на основе количества просмотров страниц приложения (application page views) и взаимодействий пользователя).
• Рейтинги и Отзывы (Ratings/Semantic signals data):
  • Ratings data: Пользовательские рейтинги (например, "звезды").
  • Semantic signals data: Анализ настроений (sentiment detection) в отзывах пользователей.
• Контентные факторы (Keywords and text content): Ключевые слова и текстовый контент, извлеченные из Application Pages и хранящиеся в Application Index.
• Временные факторы (Application recency): Как давно было выпущено приложение или его текущая версия. Очень новые приложения могут получать штраф или ограничение оценки.
• Межресурсная атрибуция (Cross-resource attribution): Сигналы качества соответствующего веб-ресурса могут быть перенесены на приложение, особенно если данных по приложению мало.

Сигналы, специфичные для устройства (User Device Specific Signals): (Учитываются во время запроса)

• Пользовательские факторы:
  • Installation status: Установлено ли приложение на устройстве пользователя.
  • Instantiation status: Запущено ли приложение в данный момент.
  • Use frequency: Как часто пользователь использует приложение на данном устройстве.
• Технические факторы (Application stability): Насколько стабильно работает приложение на данном устройстве (склонность к сбоям, зависаниям).

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

• Native Application Score: Агрегированная оценка, основанная на взвешивании глобальных и специфичных для устройства сигналов, описанных выше.
• Normalization Factor: Рассчитывается для приведения Native Application Score к шкале Web Resource Score.
  • Метод расчета: Линейная регрессия (Linear Regression). Система строит модель зависимости оценок приложений от оценок соответствующих веб-сайтов на основе данных Proper Subset.
  • Альтернативный метод: Машинное обучение для корректировки весов различных сигналов. В этом случае Normalization Factor представляет собой взвешенный вектор (weighted vector).
• Cross-resource attribution Scaling: Упоминается механизм масштабирования переноса оценок. По мере того как набор данных для приложения становится больше и надежнее, атрибуция с веб-сайта на приложение может масштабироваться от 100% до 0%.

1. Веб-авторитет как эталон для ранжирования приложений: Система использует шкалу оценок веб-ресурсов в качестве базовой для нормализации. Это означает, что авторитетность и качество веб-сайтов напрямую влияют на то, как система интерпретирует сигналы качества приложений.
2. Синергия SEO и ASO (Cross-resource attribution): Подтверждается механизм прямого переноса сигналов качества с сайта на приложение, особенно если данных по приложению недостаточно. Авторитетный сайт может значительно улучшить ранжирование своего приложения.
3. Подтверждение факторов ранжирования приложений (ASO): Патент явно перечисляет ключевые метрики ASO, используемые в Google Поиске: количество и качество ссылок (веб и апп), количество установок/загрузок, активность использования, рейтинги и анализ тональности отзывов.
4. Контент внутри приложений (App Indexing) является фактором: Для ранжирования используется контент, извлеченный из страниц приложений (application pages) и хранящийся в Application Index. Без App Indexing контентная релевантность не может быть оценена.
5. Сильная персонализация ранжирования приложений: Патент описывает использование сигналов, специфичных для устройства пользователя (User Device Specific Signals). Приложения, которые установлены у пользователя, используются часто и работают стабильно, получают значительное повышение в ранжировании для этого конкретного пользователя.
6. Калибровочный набор (Proper Subset) критически важен: Приложения, имеющие соответствующие веб-сайты, формируют основу для расчета Normalization Factor. Качество этих приложений и сайтов задает стандарт для всей экосистемы.

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

• Синхронизация SEO и ASO стратегий: Рассматривайте веб-сайт и приложение как единую сущность. Авторитетность сайта (SEO) напрямую влияет на потенциал ранжирования приложения через механизмы Cross-resource attribution и Normalization. Убедитесь, что соответствие между сайтом и приложением технически корректно настроено (например, через Firebase, Digital Asset Links).
• Внедрение App Indexing и Deep Linking: Это необходимое условие для появления контента приложения в поиске. Патент подтверждает, что контент страниц приложения (application page data) используется для оценки релевантности.
• Стимулирование установок и активного использования (Retention): Installation data и Usage data являются сильными глобальными сигналами. Use frequency на устройстве пользователя является сильным персонализированным сигналом. Стратегии по удержанию пользователей напрямую влияют на видимость в поиске.
• Работа над рейтингами и отзывами: Ratings data и Semantic signals data (анализ тональности отзывов) используются для оценки качества приложения. Высокие оценки и позитивные отзывы повышают Native Application Score.
• Привлечение качественных ссылок на приложение: Работайте над получением упоминаний и ссылок на страницу загрузки приложения с авторитетных веб-ресурсов (web links), а также стимулируйте шеринг контента из приложения (что может генерировать application links).
• Обеспечение технической стабильности приложения: Application stability является фактором ранжирования. Приложения, которые часто дают сбои у пользователя, будут ранжироваться ниже для него.

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

• Изолированная работа над ASO: Попытки оптимизировать ранжирование приложения без учета качества и авторитетности соответствующего веб-сайта будут менее эффективны из-за механизмов нормализации и атрибуции.
• Накрутка установок и рейтингов: Хотя эти метрики важны, система также анализирует Usage data (активность использования). Искусственное завышение установок без реального использования не даст устойчивого результата и несет риски санкций.
• Игнорирование App Indexing: Если контент приложения не индексируется, система не сможет оценить его релевантность запросам, выходящим за рамки бренда или названия приложения.
• Создание низкокачественного приложения для авторитетного сайта: Патент упоминает, что система может учитывать низкое качество приложения. Также указано, что нормализация может не применяться для пар с сильно разнящимися оценками, чтобы не пенализировать качественный сайт из-за плохого приложения.

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

Этот патент является ключевым элементом для понимания Универсального Поиска на мобильных устройствах. Он объясняет, как Google технически решает задачу смешивания результатов из разных индексов (Web и App). Стратегически это подчеркивает важность присутствия бренда как в вебе, так и в виде нативных приложений. Для SEO-специалистов это означает необходимость расширения компетенций в область ASO и App Indexing, а также понимание того, что веб-авторитет служит фундаментом для ранжирования всех связанных цифровых активов, включая приложения.

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

Сценарий 1: Ранжирование приложения за счет авторитетности сайта (Cross-resource attribution)

1. Ситуация: Крупный авторитетный ритейлер (например, Amazon) запускает новое мобильное приложение.
2. Проблема: На начальном этапе у приложения мало собственных данных (загрузок, рейтингов).
3. Как работает механизм: Система идентифицирует связь между приложением и сайтом (Corresponding Web Resource). Поскольку данных по приложению мало, активируется Cross-resource attribution.
4. Действие: Сигналы качества и авторитетности веб-сайта Amazon переносятся на приложение.
5. Результат: Приложение Amazon получает высокий Native Application Score в поиске Google с момента запуска, опережая приложения менее авторитетных магазинов.

Сценарий 2: Персонализированное ранжирование (User Device Specific Signals)

Пользователь ищет "отели в Берлине" на смартфоне.

1. Скоринг: Google оценивает сайты и приложения (например, Booking, Expedia). Оба имеют высокие глобальные оценки.
2. Персонализация: Система проверяет User Device Specific Signals. У пользователя установлено приложение Expedia, и он часто им пользуется (высокий Use frequency). Приложение Booking не установлено.
3. Действие: Native Application Score для Expedia повышается для этого конкретного пользователя.
4. Нормализация и Ранжирование: После нормализации приложение Expedia получает преимущество для данного пользователя.
5. Результат: В поисковой выдаче пользователя результат с Deep Link в приложение Expedia будет показан выше, чем ссылка на скачивание приложения Booking или даже выше веб-сайта Booking.com.