Как Google персонализирует мобильную выдачу, повышая в ранжировании приложения, которые пользователь часто использует (Affinity Score)

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

Affinity Data (Данные об аффинности)

Хранилище, содержащее рассчитанные Affinity Scores для пользователей и их нативных приложений.

Affinity Score (Оценка Аффинности)

Метрика, которая измеряет приверженность (аффинность) пользователя к конкретному нативному приложению относительно других приложений, установленных на устройстве.

Affinity Score Adjuster (Корректировщик оценки аффинности)

Компонент поисковой системы, отвечающий за доступ к Affinity Data и корректировку оценок ранжирования на основе Affinity Scores.

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

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

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

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

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

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

Native Application Search Result (Результат поиска по нативному приложению)

Элемент поисковой выдачи, который содержит Deep Link в нативное приложение.

Relative Engagement Measure (Мера относительного вовлечения)

Ключевой показатель для расчета Affinity Score. Определяется как соотношение времени использования конкретного приложения ко времени использования всех приложений на устройстве.

Reporting Data (Отчетные данные)

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

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

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

1. Система получает поисковый запрос с устройства пользователя.
2. Система получает доступ к application affinity data для этого устройства. Эти данные содержат Affinity Scores для установленных приложений и получены в результате процесса отчетности (reporting process), отдельного от поисковой операции.
3. Система получает набор результатов поиска, включающий один или несколько native application search results с deep links в установленные приложения.
4. Для каждого такого результата определяется Affinity Score приложения. Определение включает:
   • Определение первой меры времени (общее время использования всех приложений на устройстве).
   • Определение второй меры времени (время использования конкретного приложения).
   • Определение Relative Engagement Measure на основе соотношения первой и второй мер времени.
   • Определение Affinity Score на основе Relative Engagement Measure.
5. Система корректирует результаты поиска на основе Affinity Scores для генерации скорректированного набора.
6. Скорректированный набор предоставляется устройству.

Ядро изобретения — это использование предварительно рассчитанных персональных метрик вовлеченности в приложения (Affinity Score, основанный на Relative Engagement) для переранжирования поисковой выдачи в реальном времени.

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

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

Это важный нюанс: если приложения были на позициях 3, 5 и 7, то после корректировки они будут переупорядочены между собой, но по-прежнему займут позиции 3, 5 и 7. Веб-результаты не затрагиваются этим конкретным вариантом реализации.

Claim 8 (Зависимый от 1): Описывает процесс получения application affinity data.

1. Получение native application reporting data от множества устройств отдельно от поисковых запросов.
2. Определение Affinity Score для приложений на основе этих данных для каждого устройства.
3. Сохранение ассоциации между Affinity Score, приложением и устройством в хранилище данных.

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

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

INDEXING – Индексирование и извлечение признаков
Патент описывает процесс, аналогичный индексированию пользовательских сигналов. Reporting Data собираются, обрабатываются, и на их основе рассчитываются Affinity Scores. Эти данные сохраняются в Affinity Data для последующего быстрого доступа. Этот процесс происходит офлайн (в фоне), отдельно от обработки поисковых запросов.

RANKING – Ранжирование
На этом этапе генерируется первичный набор результатов (веб и приложения) на основе стандартных сигналов релевантности, без учета Affinity Score.

RERANKING – Переранжирование
Основное применение патента. Компонент Affinity Score Adjuster активируется после основного ранжирования.

1. Идентифицируются результаты, ведущие в установленные нативные приложения.
2. Для пользователя/устройства извлекаются соответствующие Affinity Scores из Affinity Data.
3. Оценки ранжирования (Search Scores) этих результатов корректируются (повышаются или понижаются) на основе Affinity Scores.
4. Происходит финальная сортировка (переранжирование) скорректированного набора.

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

• Поисковый запрос.
• Идентификатор пользователя или устройства.
• Первичный набор результатов поиска с их оценками ранжирования.
• Affinity Data (предварительно рассчитанные Affinity Scores).

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

• Скорректированный (персонализированный) набор результатов поиска.

На что влияет

• Конкретные типы контента: Влияет исключительно на Native Application Search Results, то есть результаты, содержащие Deep Links в приложения, установленные на устройстве пользователя (App Indexing). Не влияет на ранжирование стандартных веб-страниц.
• Специфические запросы: Наибольшее влияние оказывается на запросы, где у пользователя есть выбор между несколькими релевантными приложениями или между приложением и веб-сайтом (например, запросы о бронировании, покупках, просмотре медиа).
• Конкретные ниши или тематики: Влияет на все ниши, где активно используются мобильные приложения: eCommerce, Travel, Финансы, Медиа, Продуктивность, Социальные сети.
• Географические и языковые ограничения: Применяется глобально на мобильных устройствах, при условии доступности функционала App Indexing и сбора Reporting Data.

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

• Условия работы алгоритма: Алгоритм применяется при поиске с мобильного устройства, когда выполняются все следующие условия:
  1. Пользователь разрешил сбор Reporting Data (явно или через настройки ОС).
  2. У пользователя установлены нативные приложения, релевантные запросу.
  3. Эти приложения корректно реализуют Deep Linking/App Indexing.
  4. В поисковой выдаче присутствуют Native Application Search Results.
  5. Система имеет рассчитанные Affinity Scores для этих приложений и этого пользователя.

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

Алгоритм состоит из двух основных процессов.

Процесс А: Генерация Affinity Data (Офлайн/Фоновый режим)

1. Сбор данных: Получение Reporting Data с пользовательских устройств. Этот процесс происходит непрерывно и отдельно от поисковых сессий. Данные включают метрики использования установленных приложений.
2. Анализ использования: Для каждого устройства определяется общее время использования всех приложений (Первая мера времени) и время использования каждого отдельного приложения (Вторая мера времени).
3. Расчет относительного вовлечения: Вычисление Relative Engagement Measure для каждого приложения путем сравнения времени его использования с общим временем использования всех приложений.
4. Расчет Affinity Score: Генерация итогового Affinity Score для каждого приложения. Этот расчет может учитывать Relative Engagement Measure и другие факторы из Reporting Data (например, отзывы, шаринг, статус платной версии) с использованием весовых коэффициентов.
5. Агрегация (Опционально): Расчет агрегированных Affinity Scores по категориям приложений (например, финансы) или по издателям.
6. Сохранение: Запись рассчитанных Affinity Scores в базу данных Affinity Data в привязке к идентификатору пользователя/устройства и приложения.

Процесс Б: Корректировка ранжирования (Онлайн/Реальное время)

1. Получение запроса: Прием поискового запроса и идентификатора пользователя/устройства.
2. Первичное ранжирование: Генерация стандартного набора поисковых результатов с исходными оценками (Search Scores).
3. Идентификация приложений: Определение в выдаче Native Application Search Results, которые ведут в приложения, установленные на устройстве.
4. Извлечение Affinity Scores: Запрос к базе Affinity Data для получения Affinity Scores идентифицированных приложений для данного пользователя.
5. Корректировка оценок: Применение Affinity Score к Search Score. Это может быть бустинг (если Affinity Score выше порога) или демпинг (если ниже порога), или относительная корректировка (сравнение Affinity Scores разных приложений между собой).
6. Переранжирование: Генерация скорректированного набора результатов. В одном из вариантов реализации (Claim 3), переупорядочиваются только результаты приложений относительно друг друга в пределах их исходных позиций.
7. Предоставление результатов: Отправка скорректированной выдачи пользователю.

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

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

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

• Поведенческие факторы (Reporting Data): Это основной тип данных, используемых системой. Включает:
  • Частота использования (Frequency): Как часто пользователь открывает приложение.
  • Продолжительность использования (Duration): Средняя и общая продолжительность сессий в приложении.
  • Относительное вовлечение (Relative Engagement): Какую долю времени от общего использования всех приложений занимает конкретное приложение. Это ключевой фактор, явно указанный в Claim 1.
  • Действия в приложении (Actions): Описание действий, совершаемых пользователем в приложении.
  • Предпочитаемое приложение (Preferred Status): Является ли приложение предпочитаемым для выполнения определенной операции (например, навигации) среди других доступных приложений.
  • Отзывы (Reviews): Оценки, которые пользователь поставил приложению.
  • Шаринг контента (Sharing Activity): Как часто пользователь делится контентом из приложения.
• Пользовательские факторы:
  • Статус установки: Установлено ли приложение на момент запроса.
  • Версия приложения: Используется ли бесплатная или платная версия.

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

• Relative Engagement Measure: Рассчитывается на основе времени использования.

  Формула (интерпретация на основе Claim 1):

  $\text{Relative Engagement} = \frac{\text{Время использования Приложения X}}{\text{Общее время использования всех приложений}}$

• Affinity Score: Агрегированная метрика, основанная на Relative Engagement Measure и, возможно, взвешенной комбинации других факторов из Reporting Data. Чем выше уровень вовлеченности, тем выше Affinity Score.
• Пороговые значения: Патент упоминает возможность использования порогов для определения бустинга или демпинга (например, бустинг, если Affinity Score превышает первый порог; демпинг, если он ниже второго порога).

1. Вовлеченность в приложение как фактор ранжирования в Google Search: Это ключевой вывод. Патент явно связывает поведение пользователя внутри нативного приложения (частота, продолжительность использования) с ранжированием этого приложения в органической поисковой выдаче Google.
2. Критичность «Относительного вовлечения» (Relative Engagement): Система не просто учитывает общее время, проведенное в приложении, а нормализует его относительно общего времени использования всех приложений (Claim 1). Это позволяет объективно сравнивать предпочтения разных пользователей. Пользователь, который тратит 90% своего времени в одном приложении, демонстрирует более высокую аффинность к нему, чем тот, кто тратит в нем 10%, даже если абсолютное время одинаково.
3. Персонализация мобильной выдачи: Affinity Score является сильным сигналом персонализации. Он позволяет Google предпочесть приложение, которое пользователь реально использует, приложению, которое установлено, но игнорируется.
4. Эффективность за счет предварительного расчета: Сбор данных и расчет Affinity Score происходят офлайн, отдельно от поисковых операций. Это позволяет системе быстро применять персонализацию в реальном времени без задержек на сложные вычисления.
5. Варианты реализации корректировки: Система может как изменять позиции приложений относительно всей выдачи, так и применять более консервативный подход (Claim 3), переупорядочивая только результаты приложений между собой в пределах их исходных слотов.

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

• Обеспечить корректную реализацию App Indexing и Deep Linking: Это базовая необходимость. Без индексации контента приложения и настройки глубинных ссылок система не сможет показывать Native Application Search Results, и Affinity Score не будет применяться.
• Фокус на удержании (Retention) и вовлеченности (Engagement) пользователей: Стратегии ASO должны быть направлены не только на привлечение установок, но и на стимулирование активного использования приложения. Необходимо улучшать UX/UI, повышать ценность приложения, использовать пуш-уведомления и другие механики для возвращения пользователей.
• Увеличивать Relative Engagement: Необходимо стремиться к тому, чтобы приложение занимало значительную долю времени пользователя, проведенного в мобильных приложениях. Это напрямую влияет на Affinity Score.
• Мониторинг метрик использования приложений: SEO- и ASO-специалисты должны анализировать данные о частоте запуска, длительности сессий и действиях пользователей внутри приложения, так как эти метрики теперь являются факторами ранжирования в поиске.
• Стимулировать положительные сигналы: Поощрять пользователей оставлять отзывы о приложении и делиться контентом из него, так как эти данные могут входить в Reporting Data и влиять на Affinity Score.

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

• Игнорирование App Indexing: Рассматривать приложение как изолированный продукт без связи с веб-поиском. Это лишает приложение дополнительного трафика из Google Search.
• Фокус только на количестве установок: Использование "серых" механик для накрутки установок без заботы о качестве пользователей. Если приложение установлено, но не используется, его Affinity Score будет низким, что может привести к демпингу в поиске.
• Плохой UX и низкая производительность приложения: Если приложение работает медленно, неудобно или не решает задачу пользователя, это приведет к коротким сессиям и низкому Relative Engagement, ухудшая видимость в поиске.

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

Патент подтверждает стратегическую важность интеграции SEO и ASO. Качество мобильного приложения и поведение пользователей в нем становятся неотъемлемой частью стратегии продвижения в органическом поиске. Для бизнеса это означает необходимость инвестиций в развитие и поддержку нативных приложений как полноценного канала взаимодействия с аудиторией. Система Affinity Score дает преимущество тем приложениям, которые успешно выстраивают долгосрочные отношения с пользователями.

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

Сценарий: Поиск отеля в определенном городе

1. Контекст: Пользователь ищет с мобильного устройства [отели в Праге]. У него установлены приложения Booking.com и Expedia.
2. Анализ использования (Офлайн): Система Google предварительно проанализировала Reporting Data. Пользователь проводит в Booking.com 5% своего общего времени в приложениях, а в Expedia — 0.1%. Affinity Score для Booking.com значительно выше.
3. Обработка запроса (Онлайн): Google формирует выдачу. И Booking.com, и Expedia релевантны запросу и предоставляют Deep Links на страницу с отелями в Праге.
4. Корректировка: Affinity Score Adjuster получает данные об аффинности и применяет бустинг к результату Booking.com.
5. Результат: В персонализированной выдаче Deep Link на Booking.com будет показан выше, чем Deep Link на Expedia (и, возможно, выше некоторых веб-результатов), так как система знает, что пользователь предпочитает использовать это приложение.