Поиск на естественном языке и инженерия релевантности в ASO

Поиск в App Store, Google Play – основной канал открытия приложений для пользователей. Более 65% скачиваний происходит через поиск, поэтому релевантность поисковой выдачи напрямую влияет на видимость приложений и бизнес результаты. Современные поисковые системы вышли далеко за рамки простого сопоставления ключевых слов запросов с базой данных – они используют методы искусственного интеллекта и обучаются на основе каждого обновления контента и взаимодействия пользователей. Apple и Google постоянно совершенствуют алгоритмы, чтобы показывать пользователям наиболее полезные и качественные приложения. Для разработчиков и маркетологов это значит, что App Store Optimization (ASO) эволюционировала: побеждают не те, кто больше раз повторил ключевое слово, а те, кто обеспечивает соответствие намерениям пользователя, высокое качество продукта и позитивный пользовательский отклик.

Архитектура поискового конвейера

Классический поисковый движок выполняет три основных действия: индексирует контент, находит (сопоставляет) документы по запросу и ранжирует найденные результаты. В контексте магазина приложений это означает: (1) сбор и обработка данных о приложениях (метаданные, текстовые описания, отзывы, поведенческие сигналы), (2) быстрый поиск по этой информации приложений, подходящих под пользовательский запрос, (3) сортировка найденных приложений по релевантности и другим факторам, прежде чем показать их пользователю.

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

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

• Обработка пользовательского запроса: когда пользователь вводит запрос в поиск, система сначала понимает запрос. Происходит лингвистический анализ: токенизация (разбиение фразы на слова), приведение к базовым формам (стемминг/лемматизация), удаление стоп-слов, учёт опечаток. Например, “дневник тренировок” может быть приведён к токенам дневник и тренировка. Кроме того, движок определяет намерение: пытается выяснить, ищет ли пользователь конкретное приложение (навигационный запрос по названию) или категорию/функцию. Google Play явно пытается распознать, является ли запрос названием приложения или общим понятием, и даже рассматривает синонимичные слова, чтобы расширить охват результатов. Apple заявляет, что пользователь может вводить запросы на естественном языке, а алгоритм постарается вернуть релевантные результаты, понимая повседневный язык запроса. Например, запрос “приложение чтобы сделать фото красивым” не содержит буквального названия функции, но поиск должен понять намерение «редактирование фото/фильтры» и найти соответствующие приложения. Такой семантический разбор – новая черта поиска на естественном языке.

• Сопоставление (matching) кандидатов: следующий этап – поиск кандидатов приложений, соответствующих запросу. Классический подход – лексический поиск: система ищет в индексе приложения, где встречаются слова из запроса. Это как поиск по ключевым словам: если слова запроса входят в название, ключевые поля или описание приложения, оно попадает в кандидаты. Например, для запроса “фитнес планер” найдутся приложения, где есть слова “фитнес” или “планер”. Однако чисто лексический подход не понимает смысла: для него запрос “фитнес-планер” и “дневник тренировок” – совершенно разные строки, хотя для пользователя это одна и та же потребность. Поэтому современные системы дополняют или заменяют лексическое сопоставление семантическим поиском. Семантический подход строит понимание смысла запроса (например, “улучшить фото” → редактирование изображения) и находит приложения, даже если они не содержат этих буквальных слов. Для этого используются модели плотных эмбеддингов: и запрос, и описания приложений представляются как математические векторы в пространстве смыслов, и поиск кандидатов – это нахождение ближайших векторов (по косинусному расстоянию, эвклидову или dot-product). Такой поиск ближайшего соседа требует специальных алгоритмов (Approximate Nearest Neighbor – ANN) для скорости, иначе сравнение каждого запроса со всеми приложениями было бы слишком медленным. Итог: система получает список кандидатов – набор приложений, потенциально подходящих запросу по лексическому совпадению и/или по семантической близости.

• Ранжирование результатов: кандидаты затем проходят через систему ранжирования. На этом этапе учитывается множество факторов, чтобы отсортировать приложения по убыванию вероятности удовлетворить пользователя. Базово, алгоритм присваивает каждому кандидату оценку релевантности. В простейшем случае это могла бы быть формула, комбинирующая текстовое сходство (например, по TF-IDF/BM25), популярность и качество. Исторически App Store использовал упрощённые модели: документы оценивались выше при точном совпадении ключевых слов, особенно если слово в названии приложения (Title) – этому полю дан повышенный вес. Также учитывались «бустеры»: новый или часто обновляемый апп может получить повышенный балл, приложения от известного издателя имели начальный boost при ранжировании. Сегодня ранжирование – более сложный многофакторный процесс, обычно с применением машинного обучения (learning-to-rank). Алгоритм обучается на больших данных (логи поисковых запросов, клики и установки) и учится расставлять результаты в порядке максимальной вероятности клика или установки. Задача LTR – используя множество примеров запросов и оценки релевантности для них, построить модель, которая будет поднимать более релевантные документы наверх выдачи. Внутри ранжирования могут применяться дополнительные приемы: фильтрация и бизнес-правила (например, не показывать более одного приложения от одного разработчика в топ-результатах, чтобы выдача была разнообразной; или блокировать приложения, нарушающие политику), а также пост-обработка вроде персонализации.

• Масштабирование и отдача результатов: финальная часть конвейера – отдать пользователю топ-N результатов быстро и с минимальной задержкой. Поисковая система магазинов оптимизирована под высокую нагрузку (миллионы пользователей, миллиарды запросов), поэтому применяется кэширование популярных запросов, распределённые индексы, асинхронное обновление рангов (предварительное вычисление позиций для часто используемых ключевых слов). В Apple App Store, например, результаты поиска могут включать не только сами приложения, но и другие объекты – карточки разработчиков, события внутри приложений, статьи редакции, рекламные слоты – все они также должны быть отранжированы и отфильтрованы по релевантности. Google Play при формировании выдачи учитывает устройство пользователя (телефон, планшет, TV) и совместимость приложений с ним, а также местоположение (например, локальные приложения). Это часть организации результатов, чтобы показать пользователю релевантный контент в удобном формате . 

На уровне системы разработчики поискового движка измеряют время ответа (латентность) каждого этапа, отзыв (какой процент релевантных приложений вообще попал в кандидаты), точность ранжирования. Для владельца приложения эти внутренние метрики недоступны, но важным косвенным показателем служит позиция приложения по релевантным запросам и насколько быстро обновления метаданных отражаются в поиске (индексация). Если вы изменили описание или выпустили новую версию, а приложение спустя месяц не появляется по ожидаемым ключевым фразам – есть проблемы либо на этапе индексирования (возможно, из-за фильтров качества) либо вы неправильно учли механизм сопоставления. Зная конвейер, вы можете диагностировать: достаточно ли вы охватываете семантику запроса (этап сопоставления) и соответствуете ли факторам ранжирования (этап сортировки).

Не нужно пытаться “взломать” работу конвейера ненадежными способами: например, генерировать тысячи поисковых запросов с кликами по своему приложению в надежде улучшить позиции – магазины легко отфильтруют такие аномалии (один пользователь = один голос, миллион фейковых кликов приравняется к одному сигналу) . Также опасно злоупотреблять instant indexing – частыми мета-обновлениями приложения ради переиндексации, это может выглядеть подозрительно. Алгоритмы спроектированы так, чтобы не поддаваться простым манипуляциям: лучше направить усилия на повышение реальной релевантности.

Модели сопоставления

Этап сопоставления определяет, какие приложения вообще будут рассмотрены для ответа на запрос. Если релевантное приложение не попало в кандидаты, никакое дальнейшее ранжирование его не спасет. Исторически ASO уделяло огромное внимание подбору “правильных” ключевых слов – то есть лексическому соответствию. Однако поиск на естественном языке привносит семантический уровень: чтобы заявить о себе, приложению мало содержать точное ключевое слово – важно значение, контекст. Инженеру релевантности нужно понимать возможности и ограничения разных моделей matching, чтобы комбинировать их для лучшего результата.

Лексический поиск: базовый вариант – keyword matching. App Store и Google Play по-прежнему используют его как часть алгоритма. Например, Apple прямо указывает: текстовая релевантность вычисляется по совпадениям запроса с названием приложения, подзаголовком, ключевыми словами и категорией. От того, какие слова включены в эти поля, зависит видимость вашего приложения. Лексическое сопоставление отлично работает для конкретных запросов (например, название приложения или бренда). Пользователь ввел “Spotify” – и магазин найдет приложение Spotify по прямому совпадению имени. Также это основа для синонимов: если пользователь ввел “photo editor”, система ищет те же слова. Ключевой показатель – отзыв (recall) лексического поиска. Если пользователь ввел слово X, а ваше приложение релевантно, но слово X нигде не фигурирует в метаданных – вы выпали из поиска. Потому в ASO до сих пор актуален исследование поисковых запросов: собирать список топ-ключевых фраз пользователей и включать самые нужные из них в название, подзаголовок или keyword-лист (в iOS).

Однако в условиях семантического поиска слово-формы и близкие термины могут учитываться автоматически: нет нужды дублировать “заметка, заметки, заметками” – алгоритм видит в них одну лемму без контекста, и частое повторение не даст роста. Важно покрыть разные смыслы, а не все морфологические вариации. Приведенный пример: запрос “фитнес-планер” vs “дневник тренировок” – лексически разные слова, семантически одна идея (приложение для планирования тренировок) . Ранее App Store просто не сопоставил бы их, и приложение, продвигаемое по “планер”, не появилось бы по “дневник”. Отсюда старая тактика – перечислять в keywords все синонимы. Но у лексического подхода есть и другая крайность: шум от совпадений. Если слово распространенное (например “game”), оно даст тысячи совпадений. Система вынуждена потом агрессивно фильтровать и сортировать их. Вдобавок, лексический поиск уязвим к манипуляциям: разработчики вставляли популярные слова не по теме, лишь бы их приложение показывалось – из-за чего результаты могли быть нерелевантными. Например, приложение без отношения к фото вставляло “photo” в ключевые слова и могло появляться в поиске, засоряя выдачу.

Семантический поиск: современный тренд – понимание смысла запроса и сопоставление по этому смыслу. Алгоритм семантического поиска может разобрать сложные фразы и не требовать прямых ключей. Когда Apple анонсировала, что App Store “понимает повседневный язык” запросов, это означало внедрение NLP и, скорее всего, моделей машинного обучения для matching. Как отмечает эксперт, Apple вероятно добавила семантический поиск на основе плотных векторов эмбеддингов. Вместо точного совпадения слов вычисляются представления: например, фраза “сделать фото красивым” преобразуется моделью языка в вектор, близкий к вектору, представляющему текст “редактор фотографий” или “фильтр для селфи”. И даже без общего слова, по близости эмбеддингов система узнает, что пользовательское намерение – найти фоторедактор. В результате в выдаче появляются приложения, где вообще нет слов “сделать” или “красивым”, но есть “фото редактор” – то есть релевантные по смыслу. Еще пример: запрос пользователя “игры про ферму”. Семантический поиск “понимает”, что ферма связана с коровами, полями и т.д., поэтому может показать игру с названием “Веселая корова» даже если в ней нет слова “ферма” . Смысл перевешивает буквальное совпадение – это качественно новый уровень релевантности. Внедрение знаний и контекста: Семантический matching часто опирается на знания о мире приложения. Google Play при анализе приложения автоматически выявляет его характеристики – например, что игра является “мультипользовательской” – и учитывает это при поиске . То есть формируется неявный граф знаний: сущности (игра, мультиплеер, жанр гонки и т.п.) привязываются к приложению. Apple пошла путём генерации тегов с помощью больших языковых моделей (LLM): теперь в результатах App Store под приложением могут быть показаны теги, описывающие его ключевые качества (напр. “головоломка”, “пошаговая стратегия”) . Причем эти теги автоматизировано выводятся из вашего описания и скриншотов посредством ИИ. Такая технология позволяет алгоритму расширить представление о приложении. Например, если описание явно не содержит слово “offline”, но LLM распознал по скриншотам, что игра не требует интернета, она может получить тег “offline” – и показываться тем, кто ищет игры офлайн . Это приближает поиск к поиску по смысловым особенностям приложения, а не только по словам, которые разработчик указал.

Комбинация подходов (гибридный поиск): полностью полагаться только на векторный поиск тоже нельзя. Он имеет один нюанс: точные уникальные совпадения. Если пользователь вводит конкретное название приложения или конкретный термин, чисто семантический поиск, усредняя смысл, может даже не вернуть то самое приложение (векторы могут считаться “слишком близкими” к множеству других). Как отметил авторитетный специалист по поиску, Apple вряд ли перешла на чисто плотный векторный поиск, иначе могли бы “теряться конкретные идентификаторы и названия приложений”, что критично для App Store. Поэтому, вероятно, реализован гибридный поиск: сначала проверяется точное совпадение – если запрос выглядит как название конкретного приложения, оно выводится наверх (правило “если intent узкий – показать именно этот тайтл” ). Для более общих запросов комбинация: пересечение или объединение множеств результатов от лексического индекса и семантического. Из них уже выбирает финальная модель ранжирования.

Нужно оптимизировать и под лексический алгоритм (иметь необходимые ключевые слова в основных полях), и под семантический – то есть обеспечивать, чтобы совокупный “смысл» вашего текста (название + описание) действительно отражал сценарии использования. Если вы видите, что по некоторому пользовательскому запросу ваше приложение не появляется, подумайте – не выражена ли явно эта тема в описании? Возможно, стоит добавить фразу целиком. Например, вместо разрозненных слов “заметка, папка, тег” включить осмысленное описание “приложение позволяет вести заметки по папкам и с тегами” – так вы даёте алгоритму больше контекста . Если же оставить только разрозненные ключи, алгоритм может сам попытаться “додумать” связь, но, как предупреждают эксперты, не всегда верно .

Избегать следует попыток обмануть семантическую модель вставкой нерелевантных фраз. Алгоритмы ИИ становятся довольно умными – например, они способны читать скриншоты приложений и извлекать оттуда текстовые описания функционала . Поэтому не пытайтесь, например, засунуть ключ в изображение мелким шрифтом – лучше реально показать фичу на скриншоте с пояснением. В будущем поиск всё больше будет смотреть “сквозь” текст на сам продукт, и задача маркетолога – честно и ясно донести, чем ваше приложение решает запрос пользователя.

Модели ранжирования

Когда список кандидатов приложений получен, нужно решить, в каком порядке их показать. Пользователь обычно просматривает лишь первые несколько результатов, поэтому правильное ранжирование – ключ к успешному поиску. Даже если ваше приложение попало в кандидаты, но ранжирование его поместило на 50-ю позицию, шанс скачивания близок к нулю. Модели ранжирования эволюционировали от простых экспертных правил к сложным алгоритмам, обученным на данных.

В App Store и Google Play они частично известны из официальных источников. Apple указывает, что на позицию влияют текстовая релевантность (насколько метаданные приложения соответствуют запросу) и поведение пользователей (например, количество загрузок, рейтинг, вовлеченность). Google описывает, что для результатов поиска наибольший вес имеет релевантность запросу, но также учитываются качество приложения и реакции пользователей на результаты . Проще говоря, топ выдачи – это приложения, которые и подходят по теме запроса, и популярны/любимы пользователями, и технически хороши. 

Ранние алгоритмы могли использовать формулу вида:

Score = w1*TextMatch + w2*Popularity + w3*Quality , где TextMatch – балл схожести по ключевым словам, Popularity – прокси популярности (количество установок, тренд скачиваний), а Quality – показатель качества (средний рейтинг, наличие обновлений). 

Например, так условно выглядел “упрощённый ранговый рецепт” App Store до введения нейронных сетей: большие веса на Title/ключи, бонус обновляющимся приложениям, небольшое преимущество известным разработчикам , и, разумеется, огромное влияние общего числа скачиваний (топ-чарты исторически коррелировали с поиском). Однако главный изъян такого подхода – самоподдерживающийся цикл: популярные приложения всегда получат больший Score за счёт высокой популярности и будут чаще показаны, получат еще больше установок и станут еще популярнее. Новичкам пробиться почти нереально. Возникает предвзятость к популярности (rich get richer). 

Чтобы улучшить выдачу, инженеры ввели корректировки – бусты. Примеры бустингов, применяемых в поиске:

• Буст поля: совпадение запроса с определенным полем (например, названием) даёт больше очков, чем совпадение только в описании. Таким образом, приложение с ключом в заголовке обгонит то, у кого ключ лишь в тексте.
• Буст свежести: более новые или недавно обновленные приложения получают прибавку к релевантности. Это стимулирует разработчиков поддерживать продукт и помогает избегать выдачи устаревших, брошенных приложений.
• Буст популярности: приложение с большим числом установок, активных пользователей или высокой частотой использования может ранжироваться выше. Логика – “раз многим нравится, вероятно, и новому пользователю подойдет”. Но важно дозировать, чтобы не усилить ту самую предвзятость.
• Буст категории/жанра: если запрос содержит название категории или жанра, приложения из этой категории немного поднимаются. Например, запрос “шутер игра” – игры помеченные жанром “Shooter” получат преимущество.
• Буст фразы: приложения, где встречается вся поисковая фраза целиком, могут быть выше, чем те, у кого слова разрозненно. Это повышает точность для многословных запросов.
• Буст семантической близости: если приложение содержит термины, связанные с запросом (даже не совпадающие точно), оно может получать прибавку. Например, при запросе “diet app” приложение с словами “calorie tracker” может быть немного повышено из-за близости темы (диета – калории).

Эти бусты – своего рода ручные настройки, подсказывающие алгоритму, что считать более важным. Они помогают алгоритмически скорректировать итоговый счет. В старой парадигме ASO специалисты знали о некоторых бустах и оптимизировали под них (например, всегда включать ключ в Title, понимать, что первичная категория индексируется и влияет на поиск , поэтому выбирать правильную категорию). Однако с ростом числа факторов и усложнением запросов ручное тюнингование достигло предела.

Сегодня поисковые команды Apple/Google используют обучение модели ранжирования на больших данных кликов и успехов. Концепция обучения ранжированию (Learning to Rank, LTR) состоит в том, чтобы собрать датасет из многих троек (запрос, документ, метрика успеха) и натренировать модель, предсказывающую релевантность. Модель может быть градиентным бустингом деревьев или нейросетью. В случае магазинов метрика успеха – скорее всего CTR или установка на запрос. Т.е. если по запросу “игра гонки” большинство пользователей кликают и устанавливают игру X, модель должна выучить признаки игры X и поднять её выше для этого и похожих запросов. По логу запросов и кликов обучается модель, чтобы более кликабельные для запроса документы получали выше ранг. Но здесь есть тонкость: клики и установки – не идеальные учителя. Они содержат смещения (bias): например, позиционный bias – верхние результаты получают больше кликов просто из-за позиции, а не релевантности. Если обучать на сырых кликах, модель будет переучиваться на то, что уже наверху. Чтобы решить это, применяют модели кликов и unbiased learning to rank, которые компенсируют known biases. Например, используют метод пропорциональных обратных оценок или модели, оценивающие вероятность клика с учетом позиции.

Google (в веб-поиске) известен своим компонентом RankBrain – нейросетью, помогающей с ранжированием, и использованием BERT для понимания запросов. В контексте Google Play подобные ML-компоненты, вероятно, тоже работают. Например, Google упоминает, что при широком намерении (запрос типа “photo editing”) они учитывают как пользователи реагируют на результаты для данного запроса. Это намекает на модель, которая наблюдает CTR/установки и подстраивает ранги. Алгоритмы ранжирования в e-commerce и app stores часто являются ансамблями множества моделей и правил: сначала быстрый отбор кандидатов простыми методами, затем более тяжелый ML-ранжировщик, возможно еще и с переранжировкой с учетом персонализации. Например, 3-уровневая схема: BM25 + бусты для top-500 кандидатов -> градиентный бустинг модель для top-50 -> персонализирующая нейросеть для top-10.

Поведенческие сигналы пользователей

Поведенческие сигналы – это данные о том, как пользователи взаимодействуют с поисковой выдачей и приложениями, и как они демонстрируют свою удовлетворенность. В контексте поиска в сторах ключевые поведенческие метрики включают: просмотры страниц приложений, клики “Установить”, сами установки, частоту открытий установленного приложения, время использования, удаления приложения, а также косвенные – например, если пользователь после поиска не выбрал ничего (поисковая неудовлетворенность). Эти сигналы выступают своего рода “краудсорсинговой” оценкой релевантности: если по запросу многие пользователи кликают на конкретное приложение, это сигнал, что приложение хорошо отвечает намерению по этому запросу .

Поведенческие факторы привносят обратную связь в алгоритм. Они позволяют поиску автоматически улучшаться, учитывая реальный опыт множества людей – концепция, известная как “отраженный интеллект” или обучение на обратной связи. Без поведенческих сигналов релевантность определялась бы только статическими признаками (совпадение текста, рейтинг и т.п.). Но пользователи могут показать неявно, что для них важнее. Например, если по запросу “бюджет расходов” все игнорируют приложение с высоким рейтингом, но активно ставят другое – значит второе лучше соответствует запросу (возможно, у первого просто рейтинг высокий за другой функционал). Учет поведения позволяет ловить такие случаи. Примеры сигналов:

• CTR (Click-Through Rate): доля пользователей, кликнувших на приложение в выдаче. Если приложение появляется, но на него редко нажимают, его релевантность под вопросом.
• Conversion to Install: доля тех, кто установил после просмотра страницы приложения. Это еще сильнее сигнал: приложение соответствует поиску настолько, что люди его ставят.
• Retention и долгосрочное использование: Google Play может отслеживать, продолжает ли пользователь использовать приложение спустя N дней после установки, насколько активно. Высокий retention по пользователям, пришедшим из поиска, указывает: они нашли то, что искали.
• Отзывы после установки: если пользователь пришел по запросу и потом оставил положительный отзыв (“это приложение как раз то, что искал для X”) – это тоже поведенческий результат. Правда, отзывы – смешанный сигнал
• Поисковая сессия: например, пользователь ввел запрос, просмотрел несколько вариантов и ничего не скачал – возможно, ни один не удовлетворил. Либо он уточнил запрос – значит, первая выдача не подошла. Такие случаи (“нулевой результат”) тоже учитываются: либо это нишевый запрос без достойных приложений, либо алгоритм плохо понял намерение – он может попытаться скорректировать выдачу в будущем.

Поведенческие сигналы могут идти в модель ранжирования напрямую как фичи. Например, CTR по запросу X для приложения Y – важный признак для ранжирования по X. По сути, это “коллективное голосование” пользователей за релевантность Y для X. Однако есть и сложности: позиционный эффект (верхние места собирают больше кликов просто из-за места). Поэтому в сыром виде эти сигналы не равны. Поисковые системы вводят поправки: один пользователь не может сильно исказить выдачу – сотня кликов от одного бота засчитывается как один голос . Также сигналы могут дисконтироваться по времени: свежие поведенческие данные ценнее устаревших (вкус аудитории меняется). 

Google прямо отмечает: если запрос широкий, они учитывают “как пользователи откликаются на результаты по этому запросу” , то есть поведение помогает отранжировать при множестве релевантных кандидатов. Apple официально включает в факторы “user behavior (downloads, ratings and more)” – под more скорее всего и понимаются клики, повторные поиски, et al.

Инженерия релевантности на основе поведения делает поиск самообучающимся. Концепция “поисковый движок, обучающийся на каждом взаимодействии” реализуется именно через эти сигналы. Алгоритм может автоматически выявлять новые тенденции (например, внезапно все начали искать “игра со сливами” и массово качают одну игру – алгоритм поднимет ее, даже если изначально не планировал, потому что видит аномально высокий отклик). Это хорошо реагирует на изменчивые интересы аудитории.

Поведенческие сигналы привлекательны для манипуляций – что если накрутить установок и кликов, можно подняться? Так думали многие, и первые попытки “ASO-черной магии” были именно такими: нанимались “фермы” или боты, которые искали нужное ключевое слово и скачивали продвигаемое приложение, пытаясь “научить” алгоритм. Сторы хорошо это понимают. Как уже упоминалось, одна учётная запись или устройство не смогут дать весомый вклад более одного голоса. Алгоритмы детектируют неестественную активность: 1000 поисковых установок из одного региона за ночь для неизвестного приложения – скорее всего, будет подозрительно. Apple прямо в правилах предупреждает, что применение мотивированного трафика (то есть оплаченные установки или отзывы) может привести к санкциям. Google Play следит за качеством трафика, удаляет фальшивые отзывы, а подозрительные установки может не учитывать в ранке.

Как улучшить поведенческие сигналы легально:

• Повысить CTR в поиске: здесь помогает иконка приложения, название и рейтинг. Это первые элементы, что видит пользователь в выдаче. Яркая и понятная иконка, четкое название, указывающее на функцию (без перегруза ключами) и высокий звёздный рейтинг увеличат шанс клика. Также Apple теперь показывает до 3 скриншотов прямо на странице поиска – убедитесь, что ваши первые скриншоты информативны и привлекательны, т.к. пользователь может не кликать вовсе, а сразу по ним судить.
• Повысить Conversion to Install: когда пользователь зашел на страницу приложения, ключевое – сильные скриншоты/видео и описание. Если запрос “учить английский”, и пользователь видит на скриншотах интерфейс с уроками, отзывы учеников – больше доверия и мотивации установить. Высокая конверсия дает сигнал алгоритму, что выдача по этому запросу привела к успешному скачиванию. Также правильное соответствие ожиданиям: не заманивать несуществующими функциями. Иначе будут установки, но затем разочарование (что видно по retention и отзывам).
• Удержание и вовлеченность: это уже про сам продукт. Если ваше приложение по сути плохо решает задачу, пользователи удалят его через день. И даже если ASO привело их к установке, в долгосроке алгоритм может “разочароваться” в вашем приложении, понизив за низкое удержание. Поэтому инженерия релевантности тесно связана с качеством: лучший способ получить хорошие поведенческие сигналы – сделать приложение полезным и понятным для пришедших пользователей.

Качественные сигналы и показатели качества приложения

Под качественными сигналами понимаются факторы, отражающие внутреннее качество продукта и удовлетворенность пользователей, не связанные напрямую с конкретным поисковым запросом. Если поведенческие сигналы часто запрос-зависимы (CTR по конкретному ключу), то качественные – более общие: рейтинг звезд, отзывы, стабильность приложения (краши), производительность, соответствие гайдлайнам платформы, регулярность обновлений и т.д. Это характеристики приложения, которые индикативно влияют на его успех и доверие со стороны алгоритма.

Магазины хотят продвигать качественные приложения, потому что их задача – удовлетворить пользователя. “Высококачественные приложения, предоставляющие хороший пользовательский опыт, как правило, показываются выше низкокачественных” – прямо заявлено Google . App Store аналогично учитывает рейтинг и отзывы при вычислении позиции. Представим, есть два приложения, релевантных запросу “сканер документов”: одно со средним рейтингом 4.7, другое – 3.0. При прочих равных, первое получит преимущество. Почему? Высокий рейтинг – концентрированная мудрость толпы: приложение ценят, значит, скорее всего новый пользователь тоже будет доволен. Аналогично, количество звезд – простой числовой показатель качества. Кроме рейтинга, Apple/Google могут анализировать и текст отзывов (например, LLM-системы Apple даже суммируют отзывы с помощью ИИ , хотя это скорее для представления). Наличие частых жалоб на баги, монетизацию, обман – вероятно, негативный фактор.

Google Play открыто говорит о “strong technical performance” – то есть они отслеживают краши, ANR (приложение не отвечает), потребление батареи, соответствие рекомендациям Material Design и т.п. . В Play Console даже есть раздел Android Vitals, где видно, как у вас с производительностью. Если приложение стабильно падает у 5% пользователей, алгоритм может счесть его “низкого качества” и реже показывать в рекомендациях и поиске. Apple не настолько прозрачно делится, но мы знаем, что они ценят user experience: а это и отсутствие багов, и хороший интерфейс, и соответствие правилам (например, не злоупотреблять запросами оценить, не показывать неприемлемый контент). 

Интересно, что Google относит даже иконку, скриншоты, описание к составляющим качества: они говорят, что эти элементы должны давать пользователю четкое представление о приложении и помогать принять решение. То есть, плохо оформленная страница (размытые скриншоты, пустое описание) – тоже признак потенциально небрежного продукта. Все это в сумме влияет, будет ли приложение “повышено” или “занижено”.

Персонализация качества

Персонализация в поиске означает, что разные пользователи могут получить разные результаты под один и тот же запрос, в зависимости от их индивидуальных предпочтений, истории и контекста. Это приближает поисковую систему к рекомендательной: учитывается кто ищет, а не только что ищет. В App Store и Google Play персонализация пока ограничена (они относительно консервативны, чтобы не обескураживать разработчиков непредсказуемостью). Но уже есть элементы: особенно на Google Play, известном более персонализированным опытом.

Персонализация обычно реализуется через доп. сигналы и rerank на последнем этапе. Представьте: есть глобальный список релевантных приложений для запроса. Затем алгоритм применяет модель пользователя, чтобы чуть сдвинуть порядок – приложению, с которым вы вероятнее взаимодействуете, поднять на 1-2 позиции, а менее подходящему – опустить. Модель пользователя может быть вектором интересов (в книге это описано как генерация вектора, представляющего интересы, усреднив векторы предметов, с которыми пользователь взаимодействовал ). Такой вектор интересов сравнивается с векторами приложений-кандидатов. Например, пользователь много пользуется фитнес и диета приложениями – их профиль будет смещен к “health & fitness”. Если они ищут “трекер”, возможно им сперва покажут “трекер калорий”, а другому человеку – “трекер привычек”, в зависимости от профиля.

Пользователь получает более релевантные именно ему результаты, что повышает шанс удовлетворения. По статистике, персонализированный поиск/рекомендации часто повышают CTR и конверсию. Для платформы – это конкурентное преимущество (удерживает пользователей внутри экосистемы, т.к. быстрее находят нужное). Например, Google Play может рекомендовать “игры, похожие на те, что вам понравились” прямо внутри поиска. Главная проблема – непредсказуемость для разработчиков. Если каждый пользователь видит свой порядок, как тогда SEO-специалисту понять, на каком месте его приложение? Поэтому обычно персонализация ограничена: может влиять на не топ-1 слот, а скажем на микс позиций 4-10. А за первые слоты борются наиболее “универсально” релевантные и популярные. Кроме того, чрезмерная персонализация ведет к “пузырю фильтров” – пользователю всегда показывают однотипные вещи, затрудняя открытие нового. Магазинам важно и продвижение новых, разнообразных приложений.

Для поиска с персонализацией традиционные метрики усложняются: приходится измерять по сегментам. Например, смотрят CTR для новых пользователей vs старых, или разбивку по интересам. Если персонализация работает, то средние показатели по всей базе улучшаются, даже если разные подгруппы видят разное. В Google Play, очевидно, тестируют персонализированные алгоритмы через A/B эксперименты: часть трафика видит персонализированную выдачу, часть – обычную, и сравнивают retention, установки и пр.

Не пытайтесь создавать двойную личность приложения (например, менять описание при каждом запросе) – алгоритмы видят консистентность. Персонализация должна исходить из платформы, а не от вас. Вы даёте четкий сигнал, кто ваша аудитория, а система уже найдет ей вас. Плохая идея – искусственно расширять тематику приложения, думая охватить больше персонализированных профилей (например, добавить в описание несколько несвязанных функций в надежде понравиться разным группам). Это размывает позиционирование и скорее снизит релевантность.

Метрики качества поисковой системы (IR-метрики): 

• Precision@K (точность на топ-K): доля релевантных результатов среди первых K. Например, Precision@3 = 2/3 означает из первых 3 приложений 2 действительно подходили запросу. Высокая точность важна, потому что пользователь обычно смотрит первые 3-5 позиций.
  
• Recall (полнота): доля релевантных, которые вообще появились где-то в результатах. Например, из 10 реально подходящих приложений в сторе, поиск показал 8 – recall=0.8. Если recall низкий, пользователи могут не найти даже скроллингом то, что хотели. Но в app store recall вторичен – там не тысячи результатов отображаются, и пользователь не пролистает 50 позиций.
  
• MRR (Mean Reciprocal Rank): среднее обратного ранга первого релевантного результата. Если правильное приложение обычно на 1 месте, MRR≈1, если на 5-м, MRR=0.2. Это метрика “насколько быстро мы даем ответ”.
  
• DCG/NDCG (Discounted Cumulative Gain): суммарная полезность списка с учетом позиции. Полезность (gain) обычно берется как оценка релевантности (например, по рейтингу экспертов от 0 до 3), а discount – логарифмическое снижение ценности с каждой позицией. NDCG – нормированный DCG, деленный на идеальный DCG (чтобы 1.0 = идеально возможно). Эти метрики широко используются в научных работах по поиску и, вероятно, внутри Google/Apple для оценок. Они хороши тем, что учитывают весь ранжированный список, а не только первые несколько.
  
• Success Rate (показатель успеха поиска): доля поисковых сессий, которые закончились успешным действием – например, установкой приложения или хотя бы переходом на страницу. Если пользователи часто ничего не находят (0 кликов, 0 установок) – это alarm для качества.
  
• Session Length/Refinement: среднее количество попыток (переформулировок) до находки. Если люди вынуждены менять запрос 2-3 раза – значит исходная выдача недостаточно хороша.
  
• Coverage (охват запросов): сколько % популярных запросов имеют хоть какие-то результаты. Плохо, если у многих запросов пусто (в магазинах “пусто” – редкость, разве что опечатка; обычно всегда что-то покажут).

Для научной оценки качества поиска часто привлекают асессоров – людей, которые оценивают вручную соответствие результатов запросам. Такая ручная разметка позволяет получить “эталоны” релевантности, по которым считают вышеописанные метрики. Неизвестно, делают ли так Apple/Google (в веб-поиске точно делают). В app store, возможно, тоже время от времени ранжирование проверяется вручную (особенно по чувствительным запросам, типа “Covid” или “gambling” – чтобы убедиться, что алгоритм не выдает запрещенное).

Формулы и алгоритмы информационного поиска

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

• TF-IDF (Term Frequency – Inverse Document Frequency): классический способ оценить важность термина в документе. Формула веса термина t в документе d:
  wt,d=TFt,d×IDFt,w_{t,d} = TF_{t,d} \times IDF_{t},wt,d​=TFt,d​×IDFt​,
  где $TF_{t,d}$ – частота термина t в документе d (обычно либо само количество вхождений, либо нормированное), а $IDF_{t} = \log\frac{N}{n_t}$ – логарифм отношения общего числа документов N к числу документов $n_t$, где встречается термин t. Таким образом, часто встречающиеся во всех документах слова (типа “the”, “app”) получают IDF≈0, а редкие значимые – высокий IDF. TF-IDF векторизация используется в лексическом поиске: считается для каждого термина и затем косинусное сходство между векторами запроса и документа. Применение: базовый score лексической релевантности. Ограничения: не учитывает порядок слов и контекст, только “мешок слов”.
  
• BM25: усовершенствование TF-IDF, учитывает насыщение частоты и длину документа. Формула для оценки соответствия документа d запросу Q:
  BM25(d,Q)=∑t∈QIDF(t)⋅TFt,d⋅(k+1)TFt,d+k⋅(1−b+b⋅∣d∣avgdl),\text{BM25}(d, Q) = \sum_{t \in Q} IDF(t) \cdot \frac{TF_{t,d} \cdot (k+1)}{TF_{t,d} + k \cdot \left(1 – b + b \cdot \frac{|d|}{avgdl}\right)},BM25(d,Q)=∑t∈Q​IDF(t)⋅TFt,d​+k⋅(1−b+b⋅avgdl∣d∣​)TFt,d​⋅(k+1)​,
  где k и b – параметры (обычно k≈1.2, b≈0.75), $|d|$ – длина документа (кол-во терминов), avgdl – средняя длина по коллекции. Важно: эта формула дает убывающую отдачу от повторений слова (при большом TF добавка веса замедляется) и нормирует на длину (длинным докам не дает неоправданного преимущества). В поиске App Store аналогии BM25 применяются, например, чтобы оценить насколько описание приложения подходит запросу: повтор одного и того же слова 100 раз не даст линейного роста очков (k+1 фактор ограничивает), а слишком длинное описание разводит вес (b-фактор).
  
• Cosine similarity (косинусное сходство): Косинусное сходство между двумя векторами ( \vec{a} ) и ( \vec{b} ): [\cos(\vec{a}, \vec{b}) = \frac{\vec{a} \cdot \vec{b}}{|\vec{a}||\vec{b}|}= \frac{\sum_i a_i b_i}{\sqrt{\sum_i a_i^2} \cdot \sqrt{\sum_i b_i^2}}]
  В поиске используется для сравнения векторных представлений – классически TF-IDF векторов (тогда это просто мера текстового сходства). Также и для эмбеддингов: если запрос и документ представлены dense-векторами, косинус схожести (или эквивалентно скалярное произведение при нормированных векторах) определяет семантическую близость. В ANN-поиске часто используют dot-product напрямую, либо Евклидово расстояние, но косинус наиболее интерпретируем.
  
• Approximate Nearest Neighbor (ANN) search: набор алгоритмов для поиска ближайших векторов быстро, без полного перебора. Конкретных формул нет в двух словах, но принципы: структуру данных типа HNSW (граф меньшей размерности) или Product Quantization (разбиение векторов на субкомпоненты с квантованием). Важно знать: ANN дает приближенный результат, т.е. иногда не строго самые ближайшие, но с большим ускорением. Параметр recall у ANN означает долю реально самых ближних найденных (e.g. recall 95% – означает 5% пропущены). В контексте App Store – если Apple использует векторный поиск, они наверняка применяют ANN (open-source решения: FAISS от Facebook, Annoy, ScaNN, etc). Это позволяет за миллисекунды находить схожие приложения по смыслу среди миллионов.
  
• Learning to Rank (LTR) – упрощенно: Здесь формул много, но идея: оптимизируется функция потерь, отражающая “недовольство” неправильным порядком. Например, популярный подход – pairwise LTR: модель рассматривает пары документов (di, dj) для запроса q и пытается предсказать более релевантный. Лосс – логистическая:
  L(model)=∑q,i,jσ(score(q,dj)−score(q,di)),L(\text{model}) = \sum_{q, i, j} \sigma(\text{score}(q, d_j) – \text{score}(q, d_i)),L(model)=∑q,i,j​σ(score(q,dj​)−score(q,di​)),
  где (i,j) – такая пара, что di релевантнее dj в истине, а σ(x) – сигмоид. Модель штрафуется, если она оценила худший документ выше. Решая такую оптимизацию, модель настраивает веса признаков. Другой – listwise подход: напрямую оптимизировать NDCG, но там сложнее функции. Важно знать: LTR – это обычно градиентный бустинг (например, LambdaMART), и он способен учесть десятки факторов (признаки: match score, rating, installs, freshness и т.п.). Фактически, внутренний алгоритм App Store может быть моделью ранжирования, обученной на больших данных. Для ASO-специалиста подробная формула не нужна, достаточно понимать: модель выдает скалярный рейтинг для каждого (запрос, приложение), и его величина зависит от многих входов.
  
• Метрики оценок ранжирования:
  
  • DCG: Пусть есть упорядоченный список результатов $r_1, r_2, …, r_n$ с оценками релевантности $rel_i$. Тогда:
    DCG@n=∑i=1n2reli−1log⁡2(i+1).DCG@n = \sum_{i=1}^n \frac{2^{rel_i} – 1}{\log_2(i+1)}.DCG@n=∑i=1n​log2​(i+1)2reli​−1​.
    Здесь использована экспоненциальная шкала полезности (чтобы высокорелевантные сильнее влияли). Деление на $\log_2(i+1)$ делает вклад позиций убывающим (2-я позиция делится на log2(3)≈1.585, 3-я на log2(4)=2 и т.д.).
    NDCG: NDCG@n=DCG@nIDCG@n,NDCG@n = \frac{DCG@n}{IDCG@n},NDCG@n=IDCG@nDCG@n​, где $IDCG$ – DCG идеальной упорядоченной по убыванию релевантности выдачи. NDCG@n получается в пределах [0,1]. В практике поисков if NDCG@5 вырос с 0.5 до 0.7 – значительное улучшение качества.
    
  • Precision@k: P@k = \frac{\text{# релевантных среди первых k}}{k}.
    
  • Recall@k: R@k = \frac{\text{# релевантных среди первых k}}{\text{общее # релевантных в коллекции}}.
    
  • MRR: MRR=1∣Q∣∑q∈Q1rankq,MRR = \frac{1}{|Q|} \sum_{q \in Q} \frac{1}{rank_{q}},MRR=∣Q∣1​∑q∈Q​rankq​1​, где $rank_q$ – позиция первого релевантного для запроса q.
    
• Расчет рейтинга приложения: Рейтинг – важный агрегат качества. Хотя не формула алгоритма поиска, но собственная: обычно средневзвешенная оценка. Apple/Google используют, видимо, байесовскую оценку со сглаживанием (чтобы при малом числе отзывов рейтинг был приближен к среднему по сторам, а не сразу 5.0 от двух оценок). Формула типа:
  Rating=rˉ⋅m+∑i=1Nrim+N,Rating = \frac{\bar{r} \cdot m + \sum_{i=1}^N r_i}{m + N},Rating=m+Nrˉ⋅m+∑i=1N​ri​​,
  где $\bar{r}$ – глобальная средняя (скажем 4.0), $m$ – минимальное кол-во отзывов для уверенности (скажем 50), $r_i$ – оценки пользователей. Это не подтверждено, но многие маркетологи считают, что первые 5-10 отзывов не сразу дают чистый 5.0 видимый рейтинг.
  

Эти формулы могут пригодиться, чтобы лучше понимать, как внутренне работают компоненты поиска. Например, осознавая форму BM25, вы поймете почему бесконечное повторение ключа бесполезно; зная про cosine similarity – ценность уникальных ключей vs общих. А метрики ранжирования важны при проведении экспериментов (если вы моделируете свой поиск).

Шаблон карты намерений:

Запрос пользователя	Категория намерения	Что хочет пользователь	Элементы вашего приложения/листинга, отвечающие на это	Примечания
пример: “учет личных финансов”	Функциональный поиск	Найти приложение для ведения бюджета	В описании есть раздел про бюджетирование, скрин с бюджетной диаграммой. Ключ “бюджет” в подзаголовке.	Конкуренты акцентируют “счета и расходы” – учесть эти синонимы.
пример: “игры про ферму для детей”	Жанровой + Аудиторный	Игру про ферму, подходящую ребенку	Категория “Дети”, указано 3+ возраст. Скриншоты с мультяшной фермой. Тег “для детей” (если появится).	Возможно, стоит сделать отдельную продуктовую страницу с упором на детский контент.
пример: “аналог WhatsApp с защитой”	Навигационный + Фича	Мессенджер, похожий на WhatsApp, но безопаснее	В описании сравнение: “в отличие от WhatsApp, у нас сквозное шифрование по умолчанию…”. Ключ “secure messaging”.	Осторожно с упоминанием WhatsApp (не включать в keywords). Можно в блоге сравнить, а в сторе без названий.