Поиск приложений в “открытом Интернете” (патент US20140006418A1, AT&T → Google, публ. 2014)
Авторы: Andrea G. Forte и соавторы (первоначально AT&T Labs; патент позже передан Google в 2017)
Решение: всеобъемлющий подход к поиску приложений, рассматривающий весь интернет как источник данных. В патенте “Method and apparatus for ranking apps in the wide-open Internet” заложена идея агрегировать информацию об мобильных приложениях не только из официальных стор, но и с веб-сайтов, и учитывать контекст использования при поиске приложения.
Архитектура и компоненты:
Патент описывает четырёхфазный конвейер поиска приложений:
- Фаза I: Глобальный сбор и анализ приложений. Система заранее (в фоновом режиме, без запроса пользователя) сканирует различные источники приложений: официальные магазины (App Store, Google Play, Amazon Appstore и т.д.), альтернативные каталоги, сайты разработчиков. Каждое найденное приложение “краулится” – извлекаются метаданные: название, описание, категории, ключевые слова, имя разработчика и др.. Затем для приложения генерируется некий “отпечаток” (возможно, хеш или уникальный ID) – это нужно, чтобы идентифицировать одно и то же приложение, встречающееся на разных платформах. Важное новшество – вычисляется репутация разработчика в каждой тематике. Например, если разработчик “Антивирус Inc.” имеет много успешных антивирусов, то его новое приложение безопасности получит высокий вес по теме “security”. Репутацию оценивают по данным из интернета: поисковые рейтинги бренда по ключевым словам темы, отзывы пользователей о продуктах разработчика, число приложений в данной категории и их успех. Результат фазы I – для каждого приложения заготовлен расширенный профиль (метаданные + доп. информация из веба), который можно использовать в поиске.
- Фаза II: Обработка пользовательского запроса. Когда пользователь вводит поисковый запрос (через интерфейс какого-либо “app search engine”), система начинает активные действия. Запрос может обрабатываться разными способами:
- Обычный поиск по ключевым словам (как привычно).
- Семантический разбор/NLP – понимание намерения, синонимов, скрытого смысла запроса.
- Контекстно-ориентированный поиск – учитывается контекст пользователя: что он делает, где находится, когда ищет и т.д.. Патент особо перечисляет: доступные чувства (например, заняты ли руки или может ли он смотреть на экран), текущая активность (“бег”, “готовка”, “еду в машине”), локация (дом, работа, определённый адрес), время (утро, выходной) и социальный контекст (с семьёй, с коллегами). Эти данные могут либо вводиться самим пользователем как часть запроса (“apps to use while I’m cooking”), либо считываться автоматически с датчиков устройства – GPS, акселерометра, микрофона, камеры (например, телефон чувствует, что человек бежит, или видит Bluetooth-наушники). Всё это – опциональный слой: если контекст есть, он будет учтён, если нет – поиск пройдёт как обычно. Результатом фазы II является интерпретация запроса: что ищет пользователь (в том числе возможно явное или неявное определение категории приложения) и при каком контексте это искать.
- Фаза III: Ранжирование кандидатов. Используя данные фазы I (база всех приложений) и выводы фазы II (тип запроса и контекст), система формирует список подходящих приложений и ранжирует их. Точный алгоритм ранжирования не детализирован (видимо, может быть разным), но из текста патента можно выделить важные сигналы:
- Релевантность по теме/ключевым словам. Если запрос текстовый, соотносятся слова запроса с описаниями и названиями приложений. Возможно, используется тематическое соответствие (раз работа упоминает семантику).
- Репутация разработчика. Как отмечалось, приложение от “экспертного” разработчика в данной области получит дополнительный вес. Например, по запросу “антивирус” выше окажется приложение от известного бренда вроде Symantec, чем от неизвестного новичка – при прочих равных.
- Популярность и качество. Количество скачиваний, рейтинг пользователей, наличие наград – вероятно, тоже включены (патент прямо этого не перечисляет, но логично для ранжирования).
- Контекстный фильтр. Если указан контекст, из списка исключаются приложения, не подходящие под него. Например, если пользователь указал, что руки заняты (он готовит) и хочет приложение-помощник, поиск отфильтрует приложения, требующие ввода с клавиатуры или постоянного взгляда на экран (т.е. предложит голосовых ассистентов, таймеры с голосовым управлением и т.п.). Это достигается тем, что на этапе I приложения могли быть помечены “требует зрения/рук/слуха”, и алгоритм сравнивает с текущими свободными чувствами пользователя. Аналогично с локацией: если он на улице, могут порекомендоваться AR-навигации, а если дома вечером – приложения для отдыха.
- Фаза IV: Выдача и довыбор. Пользователю показываются отсортированные результаты. Возможен интерактив: если ничего не подошло, пользователь уточняет запрос или контекст, и процесс повторяется. Также подразумевается, что система может на лету подгружать ещё приложения (“lazy load”) или предлагать смежные категории. Эту фазу патент особо не описывает – она стандартна.
Ключевые технические особенности. Эта система примечательна тем, что выходит за пределы одного стора. Она пытается объединить информацию отовсюду – вплоть до того, что сам стор выступает как поисковик, краулящий интернет ради данных об приложениях. Для 2012 года это был новаторский взгляд (хотя на практике Google Play впоследствии внедрил схожие элементы). Также ярко то, как учитывается контекст пользователя: фактически, это предвосхищает функции ассистентов типа Google Now, которые рекомендовали приложения “по ситуации”. Инженерно, задача сложна – требовалось интегрировать данные с датчиков, профили поведения, NLP запросов и большой индекс приложений. Патент во многом концептуальный, но в нём видны зачатки идей: семантический поиск, обогащённый профиль приложения (метаданные + внешние данные), cross-store поиск (когда один поисковик знает про приложения из разных источников) и адаптивный ранжирующий алгоритм.
Цель и метрики. Цель – решить проблему, когда “сотни тысяч приложений, и пользователю трудно найти нужное”. Метрика – качество поиска: пользователь быстрее и точнее находит полезное приложение. Это может измеряться CTR по результатам, количеством шагов до установки (идеально – сразу из поиска установил), временем на поиски. Для контекстных рекомендаций – метрика успеха это активация сценария: например, если система сама распознала, что вы за рулём, и предложила навигатор, и вы его поставили – это победа (значит, контекст учтён правильно). В целом, повышение релевантности – главный KPI.
Этап эволюции Google Play. В 2012 году Google Play (ещё недавно Android Market) был менее развит в поиске. Этот патент (не напрямую от Google изначально, но позже приобретённый) можно считать отражением идей, которые витали в индустрии. Некоторые элементы Google реализовал: например, поиск с синонимами и тематическими словами – сегодня Play это умеет; учёт репутации – в косвенной форме (брендовые приложения часто выше в выдаче); контекст – Google Now в mid-2010s действительно рекомендовал приложения “по ситуации”, а сейчас Google Ассистент может предлагать установить приложение под определённый кейс. В самом же Google Play сейчас есть разделы типа “Игры для тебя”, которые учитывают жанры ранее сыгранных игр – тоже контекст, но уже пользовательского профиля. Так что патент хоть и не воплощён дословно, но его идеи явно прослеживаются в развитии экосистемы Google.
Влияние на ASO/SEO. Для оптимизаторов понимание такого подхода означает, что присутствие приложения в информационном поле интернета приносит пользу. Даже сейчас Google Play, помимо своих данных, вероятно использует сигналы извне – например, ссылки на приложение, обзоры, упоминания. Патент прямо указывает, что поиск может ходить по внешним API и сайтам за данными. Это значит, что стратегия ASO = SEO становится актуальной: надо заботиться об отзывах на профильных сайтах, о рейтингах в СМИ, о том, чтобы сайт приложения был наполнен ключевыми словами и попадал в топ Google-поиска по тематике. Также стоит работать над репутацией разработчика: выпускать приложения последовательно в своей нише, собирать хороший feedback – тогда последующие продукты будут ранжироваться легче. Что касается контекста – здесь меньше контроля со стороны разработчика, но это намёк: если ваше приложение имеет явный сценарий использования (скажем, “приложение для походов”), то стоит это чётко отражать в описании и метаданных. Тогда, когда поисковые алгоритмы (или ассистенты) ищут по ключу “что взять в поход”, ваше приложение получит дополнительные очки релевантности. В целом, этот патент – про экосистемный подход: игра уже идёт не только внутри магазина, но и во внешнем инфополе.
Выявление трендовых приложений (Google, патент US8819025B2, публ. 2014)
Авторы: Fabio Di Bona, Bhaskar Mehta (Google Inc.)
Решение: алгоритм обнаружения “набирающих популярность” приложений (Trending) по динамике установок. Патент “Recommending Applications… Based on Installation Histories” описывает, как на основе временных рядов установок вычислять скор популярности и формировать список трендов, помогающий и пользователям, и разработчикам отслеживать, что сейчас “взлетает”.
Архитектура и компоненты:
– Сбор телеметрии установок. Google Play (и/или ОС Android) непрерывно фиксирует события установки, обновления и удаления приложений на устройствах. Эти данные агрегируются по приложениям и по временным интервалам (например, дневная или почасовая частота установок).
– Формирование временных рядов. Для каждого приложения строится таймлайн количества установок за равные промежутки времени – в патенте указан пример: каждый день в течение недели. Вероятно, учитываются чистые установки (новые установки + апдейты – удаления), чтобы отражать реальный рост аудитории.
– Вычисление метрик тренда. Алгоритм рассчитывает несколько показателей:
- Скорость изменения (первая производная) – рост или падение числа установок за день.
- Ускорение (вторая производная) – как изменяется сама скорость роста. Именно ускорение указывает на “трендовость”: положительное ускорение значит, что каждый день устанавливают всё больше (кривая экспоненциально идёт вверх).
- Фракция рынка (fractional volume) – доля приложения в общем количестве установок по сравнению со всеми остальными приложениям. Например, 0.5% от всех ежедневных установок на Google Play – уже немало. Считаются и локальные доли – среди приложений той же категории или региона, чтобы выявлять тренды в узких сегментах.
Перед вычислением могут применяться коэффициенты затухания (decay factors) на старые дни, чтобы сильнее реагировать на последние изменения. Также отсеиваются приложения с совсем малым числом установок (чтобы статистический шум не считался трендом) – задаётся порог минимального объёма для участия в расчёте.
– Формирование индекса трендов. Все приложения получают некоторый вес трендовости (например, комбинация ускорения и доли рынка). Затем отбирается топ приложений, чей скор превышает порог или которые занимают верхние позиции рейтинга. Эти приложения заносятся в список “Trending”, сохраняемый в базе данных и обновляемый периодически (в реалтайме или с определённым интервалом).
– Использование индекса. Далее этот индекс может: (1) отображаться пользователям – раздел “Trending Apps” в Google Play, (2) использоваться в аналитических панелях для разработчиков (например, видеть, что ваше приложение попало в тренды), (3) служить сигналом для других алгоритмов – например, поисковой выдаче или персональным рекомендациям, повышая ранк стремительно растущих приложений. Патент прямо упоминает, что трендовость может использоваться как сигнал в других сервисах. Например, если приложение стало трендом, Google мог бы временно выше ранжировать его по релевантным запросам, ожидая повышенного пользовательского интереса.
Ключевые особенности. Алгоритм фокусируется не на абсолютной популярности, а на динамике. Таким образом, для молодого приложения с низкой базой, но резко взлетевшего в установках, появляется шанс быть замеченным. Технически здесь реализуется детектор всплесков: использование второй производной – новшество, отличающее “просто стабильный рост” от ускоряющегося роста, характерного для вирусных хитов. Введение относительной доли рынка тоже важно: если общие установки на маркете выросли (например, сезон праздников), то рост конкретного приложения соразмерно масштабу вселенной. По сути, это нормализация, чтобы “тренд” был таковым именно относительно других. Инженерно, патент решает задачи масштабирования – нужно в реальном времени обрабатывать телеметрию от миллионов устройств, обновлять счётчики, применять фильтры. Но основной вклад – метод ранжирования тренда, который затем очень широко применялся. (Аналоги есть и в App Store – например, “Top Growing” в аналитике).
Цель и метрики. Цель – “assist users discover interesting apps that may otherwise be difficult to discover through searching”, то есть подсветить пользователю приложения, которые вдруг стали популярными, хотя он бы их не нашёл по обычным спискам. Метрика – доля новых установок, приходящих через раздел “Trending”. Если благодаря выделению трендов пользователи начали чаще устанавливать новые приложения, значит, цель достигнута. Также цель – “enable developers to understand what topics are trendy” – здесь метрика успеха могла бы быть вовлечённость разработчиков (например, использование ими инструментов анализа трендов, реакция на тенденции рынка). Для самого алгоритма качество измеряется тем, насколько корректно он идентифицирует настоящие тренды и не реагирует на шум. Здесь применимы метрики типа precision/recall: доля действительно “взлетевших” приложений среди отмеченных и покрытие всех значимых всплесков.
Эволюция Google Play. Этот механизм появился на Google Play примерно в середине 2010-х как раздел “Popular Rising” или “Trending”. Патент 2014 года совпадает по времени – вероятно, сразу внедрён. Со временем, Google интегрировал трендовость и в топ-чарты (например, стрелочки роста/падения позиций). Сейчас подобные алгоритмы – стандарт: и Apple имеет “Тренды поисковых запросов”, и топ-чарты сортируются с учётом скачков. Но Google был одним из первых, кто автоматизировал выявление трендов в сторе, и данный патент закрепил этот приоритет.
Влияние на ASO. Знание о существовании “трендовых” алгоритмов подсказывает стратегиям продвижения: резкий всплеск установок может сыграть вам на пользу, дав непропорционально большую видимость. Например, приложение, которое благодаря удачной кампании за пару дней получило скачковый рост +500% установок, может появиться в разделе “Trending” и привлечь еще органический трафик. Это объясняет, почему многие маркетологи планируют “burst campaigns” – краткосрочные интенсивные рекламы, чтобы взлететь в чартах. Однако, помимо объёма, патент говорит и о качествах: учитывается процент позитивных оценок, удержание (косвенно через продолжение роста), отсеиваются приложения, пытающиеся накрутить немного установок (порог отсечения низких чисел). Таким образом, накрутка ботами нескольких тысяч инсталлов, растянутых во времени, не сделает вас трендом – нужен искренний вирусный эффект. Для оптимизаторов важен тайминг: лучше сконцентрировать маркетинговые усилия в коротком окне, чем равномерно распределять – алгоритм любит ускорение. Кроме того, сопровождайте рост высоким качеством продукта: пользователи должны реально пользоваться, иначе тренд быстро схлынет и алгоритм заметит падение (и может исключить приложение столь же быстро). Ещё нюанс – тренды часто локальны. Поэтому ASO-специалисты делают упор на отдельных регионах: завоевать одну страну, попасть там в тренды, затем расширяться. Патент неявно поддерживает такую тактику, т.к. доля рынка может считаться в пределах категории или страны. В итоге, алгоритм трендов добавляет в ASO фактор времени и скорости: важно не только сколько скачали, но и насколько быстро это произошло.
Улучшение поиска приложений на основе веб-данных (Google, патент US10635725B2, публ. 2020)
Авторы: Rajhans Samdani, Amarnag Subramanya, Fernando Pereira, Hrishikesh Aradhye (Google LLC)
Решение: гибрид веб-поиска и поиска по магазину приложений. Патент “Providing app store search results” предложил использовать результаты обычного поисковика (Google) для обогащения выдачи в Google Play. Проще говоря, когда пользователь ищет приложение, алгоритм параллельно смотрит, что о таком запросе знает веб, и находит приложения через упоминания на сайтах, а не только через внутренний индекс стора.
Архитектура и компоненты:
– Переформулировка запроса. Когда приходит запрос в Google Play (например, “calendar app”), движок определяет, что это именно поиск приложения (а не веб-поиск) и запускает специальный модуль. Этот модуль создаёт модифицированный запрос для веб-поиска. Часто добавляется контекст, связанный с мобильными приложениями – например, подстановка платформы (“for Android”) или категории (“smartphone”). В примере из патента: “calendar app” превращается в “calendar app smartphone type A” – т.е. явно указано устройство или ОС. Цель – сузить веб-поиск на релевантные именно приложенческие результаты.
– Поиск по веб-индексу. Далее стандартный Google Search выполняет поиск по полученному запросу и возвращает топ-N результатов (веб-страниц). Вместо того чтобы просто показать их пользователю, эти результаты передаются обратно в движок магазина.
– Извлечение приложений с веб-страниц. Алгоритм парсит контент страниц (HTML) в поисках упоминаний приложений. Как он понимает, что упомянуто приложение? Варианты: название приложения (сопоставление с базой данных Google Play), прямые ссылки на страницу приложения (URL Google Play или App Store), схожие фразы (“… app on Google Play”). Патент описывает оба подхода – и по содержимому текста, и по ссылкам. Например, если страница – обзор “10 лучших календарей для Android”, то она, скорее всего, содержит ссылки на конкретные приложения и их названия. Система может классифицировать, что “Calendar App 3” упоминается рядом со словами “App Store A” – значит, это может быть релевантное приложение. Или если на странице есть прямая ссылка на приложение, это еще явнее сигнал. Собрав все такие упоминания, алгоритм формирует список кандидатов приложений со всей выборки веб-страниц.
– Оценка релевантности кандидатов. Не каждое найденное упоминание равноценно – алгоритм присваивает вес. Во-первых, если приложение упомянуто сразу на нескольких топ-страницах, его значимость выше. Во-вторых, можно учесть тональность контекста – патент пример приводит, что если страница говорит “эта версия календаря плохая, лучше версия на другом маркетплейсе”, то релевантность приложения снижается. Для этого используется семантический анализ текста вокруг названия (возможно, sentiment analysis). В-третьих, можно задействовать “традиционные” факторы: рейтинг страницы в поиске (на 1-м месте или на 10-м), авторитет домена, свежесть – т.е. качество самого веб-результата. В итоге каждому приложению-кандидату присваивается некий внешний скор релевантности относительно исходного запроса.
– Комбинирование с внутренним поиском. Параллельно Google Play имеет свой собственный индекс (по названиям, ключевым словам, категориям). Первичный поиск возвращает обычный список результатов (как если бы работал без веб-данных). Теперь алгоритм объединяет оба списка. Возможны две стратегии: (1) дополнить выдачу – если какое-то приложение появилось через веб, но не было в топе внутреннего поиска, добавить его (особенно если внутренний поиск дал мало результатов). (2) переранжировать – скорректировать позиции: например, если приложение А было на 8-м месте, но веб-сайты упоминают его часто, поднять его выше. Патент явно говорит про ранжирование на основе сигналов из веба. Может применяться и фильтрация: если приложение было найдено через веб, но его релевантность ниже порога – не показывать. В одном из примеров указывается, что приложение может вовсе исключаться, если его “внешняя” релевантность низкая. Конечный шаг – сформировать для пользователя финальный список app-результатов и выдать в интерфейс.
Ключевые особенности. Это фактически слияние поисковой технологии Google с магазином приложений. У Google уникальное преимущество – гигантский индекс интернета, и здесь оно используется для решения проблемы неполноты данных в сторе. Ведь описание приложения может быть скудным, а вот обзоры и обсуждения содержат дополнительную информацию и ассоциации с запросами пользователей. По сути, этот алгоритм – способ учесть SEO-сигналы внутри ASO. Интересно также, что автоматическая переформулировка запроса делает систему умнее: пользователь мог просто набрать общий термин, а алгоритм за него добавил контекст платформы, чтобы отсечь лишний шум. Это улучшает precision поиска приложений. С инженерной стороны, вызов – успеть все это выполнить на лету без ощутимой задержки: нужно выполнить веб-поиск, спарсить страницы – но Google решает это, вероятно, кэшированием (популярные запросы обрабатываются заранее) либо параллельной асинхронной выдачей (сначала показать стандартные результаты, а через доли секунды обновить список веб-дополнениями).
Цель и метрики. Цель – расширить и улучшить поиск в магазине приложений. Метрика: увеличение click-through rate и конверсии в установки по “длинному хвосту” запросов, где раньше поиск мог вернуть нерелевантные или нулевые результаты. Например, запрос “calendar” – тысячи календарей, сложно – но если в интернете все говорят про 2-3 лучших, то они должны всплыть. Еще метрика – user satisfaction: меньше пользователей, уходящих ни с чем (bounce rate из поиска стора). Для Google также ценно, что таким образом можно продвигать качественный контент: если приложение получило много обзоров (значит, оно интересное), поиск его выделит – то есть, непрямо метрика успеха это снижение влияния чисто ASO-манипуляций (название + ключевые слова) и повышение роли реальной ценности, отраженной в интернете.
Этап развития. Патент имеет приоритет 2015, опубликован 2020 – это соответствует периоду, когда Google Play Search несколько раз заметно улучшался. Вероятно, уже к 2016–2017 некие веб-сигналы влияли на поиск. Косвенное подтверждение – появление на Android устройств системного Google App Indexing, когда приложения могли показываться при поиске в Google (и наоборот). Сейчас, в 2020-х, Google Play поиск считается довольно “умным” – он часто понимает общие запросы, показывает свежие трендовые приложения. Можно предположить, что веб-интеграция либо используется до сих пор, либо переросла в нечто более ML (например, обученные модели на основе веб-контента). Но сам подход – отличительная черта экосистемы Google, которую Apple лишь ограниченно может повторить (Applebot существует, но далеко не такого масштаба).
Влияние на ASO/SEO. Для разработчика это означает, что традиционные SEO-факторы теперь важны и для видимости в Google Play. Наличие вашего приложения в обзорах, блогах, новостях улучшает его поисковый ранг в Google Play. Поэтому PR-активность, работа с комьюнити, пресс-релизы и обзоры – это не только про создание спроса, но и про прямое влияние на алгоритм. Кроме того, ссылочное окружение (backlinks) тоже может влиять: если много сайтов ссылаются на страницу вашего приложения в Google Play, система это отметит. Это ставит интересный вопрос: можно ли делать внешнюю “SEO-оптимизацию” страницы приложения? В некоторой степени да – например, убедиться, что сайт приложения содержит ссылку на Google Play (чтобы поиск по сайту ассоциировал приложение), распространять такую ссылку партнёрам. Также, важно правильно называть приложение: если название слишком общее или однозначно совпадает с другим брендом, веб-поиск может давать шум. Тот факт, что алгоритм учитывает тональность упоминаний, говорит разработчикам: следите за репутацией! Плохие обзоры не только отпугивают пользователей напрямую, но и могут снизить ранжирование. И наконец, ASO и SEO команды должны работать вместе – семантическое ядро для приложения должно охватывать и поисковые запросы в вебе. Пользователи часто гуглят “лучшее {категория} приложение android” – убедитесь, что ваш маркетинг охватывает такие запросы, и тогда Google Play тоже вас наградит. Этот патент буквально объединяет два мира, поэтому успешная стратегия распространения приложения учитывает оба канала поиска – внутри стора и в вебе – как единое целое.
