Все, что вы хотели знать о том, как работают алгоритмы App Store и Google Play

Давайте представим, что мы неожиданно оказались в Иране. Первым делом, наверное, нужно вызвать такси до аэропорта.

Привычные App Store и Google Play здесь недоступны, значит идем в локальный стор CafeBazaar.

Открываем, вводим «taxi» — в выдаче только игры про такси.
Переключаемся на фарси, вводим снова — снова игры.
Где такси? 

Мы привыкли к релевантной выдаче, особенно когда по запросу «такси» ожидаем увидеть приложение, а не игру. Мы отвыкли от того, что если допустить ошибку в запросе, можем вообще не получить выдачу. Но задумывались ли вы, как алгоритмы понимают, что нам нужно?

Об этом я рассказывал на Mobile 2025 в Москве, где привел конкретный кейс по поиску на естественном языке в App Store. 

Запрос «Driver crashed».

Сравните эти две выдачи в одной стране на разных iOS.

На скриншотах видно: в старой iOS по этому запросу были игры (ничего не напоминает?). В новой выдача уже учитывает разные намерения пользователя и подбирает разные типы результатов. Иными словами, в современном поиске цель запроса важнее буквального совпадения ключевого слова. Но об этом позже.

Итак, нам нужно такси. По общим словам найти сервис не удается. Вводим «taxi snapp» — целевое приложение оказывается на первом месте (выдача начинается справа), но другое приложение от этого бренда на третьем месте, а между ними игра. А главный конкурент на четвертом месте.

Хм. А ведь мы сейчас смотрим десктопную версию CafeBazaar. Логично, что выдача может отличаться — пользовательские сценарии здесь другие, и большинство установок совершается вовсе не через браузер. Проверим, как обстоят дела в мобильной версии.

В мобильной выдаче конкурент Snapp поднимается выше не из-за повторения ключей конкурента, а из-за неявных поведенческих сигналов: установки, открытия и удержание после показа. Поэтому мобильная выдача отличается от десктопной — система отдает приоритет тому, что подтверждено мобильным поведением пользователей. 

Похоже на логику Google Play, где персонализация и контекст устройства влияют на порядок, правда?

Иранский стор — наглядный способ показать, как эволюционировал поиск в Google Play и App Store и как он устроен сейчас. Типовое ASO, которое до сих пор делают многие, по сути иранская модель: лексический мэтч и поверхностные сигналы.

Ввели слово с ошибкой — результатов нет, даже похожих.

В тайтле нет ключа — вряд ли пользователь увидит ваше приложение.

Вставили ключ — ожидаем рост по нему.

Слово с ошибкой (левое изображение) – выдача полностью отсутствует

Так работает иранское ASO, но современные алгоритмы релевантности устроены иначе — вокруг намерения и поведения. Объяснить это без инженерных заумностей проще через сравнение, и CafeBazaar — идеальный кейс. Так что наберитесь терпения и дочитайте статью до конца — я обещаю, вы не разочаруетесь.

Как попасть в топ на CafeBazaar

Документация разработчика — кладезь информации о том, как работают алгоритмы.

Краткая выжимка, как попасть в топ:

1. Доступ к ключевым функциям без лишних действий.
2. Удачное название, иконка, изображения, видео, описание.
3. Бесперебойная работа.
4. UI соответствует базовым требованиям.
5. Отсутствие негативных отзывов за последнее время.
6. Встроенные покупки не ограничивают пользователей.
7. Обновление было не так давно.
8. Обильный и ценный контент.
9. Тематическая актуальность (события, инфоповоды).
10. Чем выше установки, продажи и рейтинг, тем выше шансы на продвижение.

И снова — ничего неожиданного, все это нам знакомо.

Значит ли это, что любая поисковая система устроена по одному принципу?

Что в основе любой поисковой системы

Не хотелось погружаться в технические детали, но они очень важны.

Я буду описывать широкими мазками чтобы не перегружать вас и дополнять комментариями от Tech Expert Дима Митя. 

Отдельная благодарность Сергею Николаеву, CEO Manticore Search. Свое знакомство с инженерией релевантности я начал с Elasticsearch и подходов Дага Тарнбулла (соавтора книги «Релевантный поиск») и не ожидал, что существует столь мощная альтернатива. В конце статьи, при разборе практических приемов хакинга поисковых системам, будет прикладной комментарий от Сергея.

Итак, поиск обычно состоит из трех составляющих:

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

Поисковые системы заранее (с некоторой регулярностью) индексируют приложения. Именно поэтому нужно время «чтобы стор считал новую мету». Ключевым элементом в поисковых системах традиционно являлся инвертированный индекс.

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

Его главный минус в том, что он видит только совпадение слов, но не понимает смысл. Для него “Digicala” и “Digikala” — это два разных запроса, хотя для пользователя это может быть одно и то же. Иными словами, если ключевое слово нигде не упомянуто в метаданных, приложение не будет найдено по этому запросу.

И в основе поиска CafeBazaar — точное лексическое сопоставление токенов: система формирует пул кандидатов по буквальному совпадению запроса с метой приложения, затем сортирует их собственным скором релевантности.

Если бы решала только одна частотность, в топ-1 неизбежно оказывались бы приложения с максимальным повтором ключа. Такси-сервисы добавляли бы «taxi» по одному слову в каждом релизе, и вместо описаний мы видели бы «taxi, taxi, taxi…».

Этого не допустит ни один разработчик поисковых систем. Поэтому всегда применяется механизм, который гасит спам (после определенного порога повторы перестают давать прирост, а могу даже и пессимизировать) и поднимает действительно релевантные результаты — так удерживается качество выдачи.

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

Технический контекст:

BM25 — это вероятностная модель ранжирования, которая учитывает:

1. Term frequency (TF) с насыщением: после N повторений прирост релевантности падает
2. Inverse document frequency (IDF): редкие термины весят больше
3. Document length normalization: длинные документы не получают преимущества

Формула (упрощенная):
score(q,d) = Σ IDF(t) · [TF(t,d) · (k₁+1)] / [TF(t,d) + k₁·(1-b+b·|d|/avgdl)]
Где:- `k₁` (обычно 1.2-2.0) — контролирует насыщение TF- `b` (обычно 0.75) — контролирует нормализацию по длине

В контексте App Store (BM25F):
- Title может иметь `field_boost` = 3-5x
- Subtitle = 2-3x
- Description = 1x- Keywords field (iOS) = 2x

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

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

CEO Bazaar публично отмечал, что ранее поиск сильнее зависел от кликов и установок из выдачи — по сути, поведенческого буста. Сейчас Bazaar заявляет об улучшении формулы и расширении набора сигналов. Но пока что он все еще как архив старой поисковой логики, на его примере легче понять, как из лексического поиска выросли современные алгоритмы.

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

Персонализированный поиск

Там, где Bazaar «считает в среднем по рынку», Google Play рассчитывает для конкретного пользователя. Он знает, на какие типы приложений вы кликаете, какие удаляете, с какими взаимодействуете чаще, и на этой основе пересчитывает релевантность.

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

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

С позиции хакинга персонализированный поиск — один из самых сложных: он защищен многоуровневыми сигналами и моделями, устойчивыми к простым манипуляциям. Поэтому у многих ASO-специалистов стандартные приемы не срабатывают в Google Play: простая вставка ключей в Title не гарантирует роста позиций; накрутка отзывов или краткосрочные всплески установок дают либо неустойчивый эффект, либо отфильтровываются. В итоге отдача от манипуляций часто минимальна.

Вообще, рекомендательные системы — это отдельная тема. Довольно сложная, но интересная.

Поиск на естественном языке

И вот в сентябре 2025 Google официально представил Guided Search для Play Store? где можно будет искать по цели или идее, а не по названию приложения и не по набору ключей вроде «игры без интернета для девочек 2025».

Когда я читал это, у меня случилось дежавю. Ранее, в мае, Apple объявила:

«Поиск на естественном языке позволяет людям использовать повседневный язык для получения более качественных и релевантных результатов; теперь можно описывать свои цели или искать конкретные функции и получать более релевантные ответы».

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

Как работает современный поиск

Чтобы понять, как работают новые поисковые системы, достаточно взглянуть на документацию Apple. Это, конечно же, не объяснение алгоритма их поиска, но дает базовое понимание, что делает Natural Language.

Например, пользователь вводит запрос: «найти приложение, чтобы экономить на поездках».

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

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

Далее выполняется лемматизация: сведение слова к его базовой форме. Например, «поездках» → «поездка». 

найти	1	0	0	0
приложение	0	1	0	0
экономить	0	0	1	0
поездка	0	0	0	1
найти + приложение + экономить + поездка	1	1	1	1

Таблица иллюстрирует one-hot для лучшего понимания. На практике используются плотные эмбеддинги, где близость численно отражает смысловую близость, например, “найти” мог бы выглядеть так [0.81, 0.25, –0.14, 0.33].

Векторы содержат контекстные связи: «экономить» близко к «сберегать», «поездки» — к «транспорт».

Технический контекст:

Близость в векторном пространстве — это смысловая близость. И векторы зависят от контекста, где "Apple" (фрукт) ≠ "Apple" (компания).

Пример:
Запрос: "экономить на поездках" → Encoder_query → [0.81, -0.14, 0.33, ...] (768d)
App "Snapp Taxi": Мета: "Недорогие поездки по городу"→ Encoder_doc → [0.79, -0.12, 0.35, ...] (768d)
Similarity = cosine(q_vec, doc_vec) = 0.94 (высокая)

Когда стор ищет похожие приложения среди миллионов, каждое из них описывается вектором из 768 числовых параметров. Чтобы найти топ-100 наиболее близких, система не перебирает все подряд, а использует специальные методы. Один из них — HNSW, который строит граф и позволяет быстро переходить от общих связей к самым похожим точкам. Другой — IVF, который делит все пространство на смысловые кластеры и ищет только внутри ближайших групп. Набивка меты около релевантными ключами только снизит видимость.

Простой пример семантической карты. Только представьте, что можно сделать, если выгрузить все запросы и спарсить мету всех приложений по этим запросам. Наверное, будет открыт путь к понимаю, какую мету нужно сделать, чтобы быть в топе. Но… не все так просто. Об этом как-нибудь в следующий раз

После этого вступает в работу модель намерений — нейросеть, обученная на миллионах пар «запрос → цель». Например:

• «найти игру без интернета» → офлайн игры
• «сделать фотографии лучше» → фото редактор
• «экономить на поездках» → райдшеринг

Алгоритм фактически классифицирует не слова, а цель пользователя.

Далее поисковик сравнивает вектор намерения не с текстом, а с векторными описаниями приложений в одном пространстве. Если у Snapp Taxi в эмбеддингах есть координаты, близкие к ride-sharing, он поднимется в выдаче — даже если в тексте нет слов «экономить» или «поездки».

Вот в этом и заключается принцип семантического поиска: поиска по смыслу, а не по набору ключевых слов.

Если бы в иранском CafeBazaar был такой механизм, он понял бы, что Snapp — это служба такси, даже без слова «такси» в Title. Но пока там используется лексический поиск, поэтому по общим запросам вроде «такси» мы видим смещение в сторону игр и нерелевантных категорий.

Давайте посмотрим различия на примерах старой iOS и новой.

Раньше длинные запросы стор не понимал:

Выдавал приложения набитые ключами, а не релевантные:

И…

А вот тут интересный случай!

Интуитивно каждый вспомнит Duolingo, когда речь зайдет про приложение с совой. Раньше так и было: система понимала ассоциацию или был определенный бустинг, а может в тот момент в мете были ключи «app» и «owl». Теперь же выдача сместилась: наверху появляются буквально «игры про сову».

Почему?

Семантический слой еще не дополнил себя графом знаний — базой контекстных связей между объектами. Такой граф помогает системе снимать неоднозначность и понимать, что «сова» может означать элемент бренда, а не просто птицу. (Но тут зависит от разработчика — помогает ли это пользователю получать релевантную выдачу.)

В идеальной архитектуре запрос проходил бы через semantic knowledge graph, который сверяет термины не только с Title, но и с полем Body — полным описанием приложения, где могли бы встречаться связанные понятия. Ведь откуда брать контекст, как не из полного описания?

Я задал вопрос Трею Грейнджеру — автору книги AI-Powered Search и одному из ведущих экспертов в области поисковых систем на основе эмбеддингов — чтобы узнать, как, по его мнению, сегодня работает алгоритм.

Он предположил, что под «поиском на естественном языке» они просто добавили семантический поиск с частичными плотными векторами, иначе пропускались бы идентификаторы и названия приложений, а это критично для App Store.

Технический контекст:

Knowledge Graph — это не просто "база связей". Технически:
Entities:  - Duolingo [app_id: 123, type: App]  - Owl [id: 456, type: Brand_Element]  - Education [id: 789, type: Category]
Relations:  - Duolingo --has_mascot--> Owl  - Duolingo --belongs_to--> Education  - Owl --is_character--> true

Почему на запрос "приложение с совой" вместо Duolingo появляются "игры про сову"? Semantic embedding для "сова" ближе к "птица", чем к "Duolingo mascot". Система не распознала, что "сова" в данном контексте = Duo (персонаж). Решить это можно, но проблема в поддержании актуальности графа знаний (новые приложения, изменения в брендинге и т.п.). 

Дополнение от Сергея Николаева: возможно, потому что нет поиска по картинкам в виде логотипов приложений. Это тоже может быть, но возможно для них неважно. Пример: https://image.mnt.cr/. В конкретно этом случае, мне кажется, достаточно было подмешивать в результаты поиск по картинкам. Граф знаний может быть не нужен. Вопрос — насколько это нужно и насколько ухудшит результаты поиска. Может быть, сова еще у тысячи приложений в лого и они тоже полезут в топ и будет только хуже.

И в итоге мы получаем гибридную модель: лексический поиск и поиск по векторным представлениям. Дальше результаты объединяются — либо через единое ранжирование, либо через дополнительный этап, который оптимизирует финальную выдачу.

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

Технический контекст:

Почему именно гибрид:

1. Lexical хорош для:   - Точных названий: "Telegram", "Chrome"   - Unique identifiers: "com.example.app"   - Редких терминов: "BNPL", "zkSync"
2. Semantic хорош для:   - Естественных запросов: "приложение для фотографий"   - Синонимов: "такси" = "cab" = "ride"   - Intent-based: "экономить на поездках"
3. Hybrid дает:   - Precision (точность) от lexical   - Recall (полноту) от semantic   - Robustness (устойчивость) к опечаткам

Что будет с ASO в 2026 году?

ASO в классическом виде — про ключевые слова, частоты и плотность — уходит на второй план. Раньше алгоритмы стора в основном ловили лексические совпадения.

Сегодня ядро поиска становится семантическим и поведенческим. Ключевые слова по-прежнему важны для индексации, но решающим все чаще становится смысл: система восстанавливает намерение пользователя и сравнивает его вектор с векторами приложений.

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

Иными словами: лексика — это входной билет в выдачу, но место в очереди определяет семантика + поведение.

Технический контекст:

Старый подход:
Ключи: "такси, taxi, cab, заказ такси, вызов такси, дешевое такси, такси индонезия"

Новый подход:
Semantic clusters:
├─ Transportation intent: "добраться", "доехать", "поездка"
├─ Cost intent: "экономить", "недорого", "дешево"
├─ Speed intent: "быстро", "срочно", "мгновенно"
├─ Safety intent: "безопасно", "надежно", "проверенный"
└─ и т.д.

Вместо плотности ключей система учитывает:

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

Именно поэтому (а не потому что добрые) Apple в 2025 году открыла Custom Product Pages (CPP) для всех разработчиков, а не только для рекламных кампаний. По сути, CPP стало инструментом не маркетинга, а инженерии поисковой релевантности: теперь разработчик может адаптировать не просто ключи, а саму визуальную структуру страницы под разные поисковые контексты.

В результате топ-1 получает не тот, кто повторяет ключ, а тот, чье содержание и поведение пользователей убедили алгоритм, что именно это приложение решает задачу запроса.

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

Отсюда и перелом для индустрии ASO. Уже недостаточно знать, «куда поставить ключ». Нужно понимать, как модель понимает язык и намерения, как она агрегирует сигналы и как работает бустинг. Фокус смещается с чистого текста к его семантической геометрии: векторы, контексты, интенты, поведенческие паттерны.

На смену «традиционному ASO» приходит, как я называю, ASO-инжиниринг — дисциплина на стыке лингвистики, машинного обучения, продуктовой аналитики и маркетинга. Делать то, что делали — недостаточно. Пройти ASO курс и стать джуном — недостаточно. И старый вопрос «какие ключи поставить?» теряет смысл. Правильный вопрос теперь такой: как объяснить алгоритму, что наше приложение — лучший ответ на задачу пользователя. А чтобы объяснить, нужно влезть под капот механизма поиска.

Сергей Николаев, CEO Manticore Search, открытой высокопроизводительной СУБД для полнотекстового, семантического и векторного поиска; альтернатива Elasticsearch

Кажется, что сегодня ранжирование в сторах — это сумма трех слоев:лексическая индексация как входной билетсемантика через эмбеддинги текста и, возможно, визуальных элементовповедение и качество продукта как финальный арбитр.Любая накрутка бьется о слой 3 и может быстро обнулиться.Что можно делать практично:Мыслить не ключевыми словами, а темами и задачами пользователя. Вместо плотности ключей стоит смотреть, насколько описание и контент приложения близки к приложениям, которые уже в топе по нужной тематике.  Строить свои эмбеддинги текстов описаний и отзывов, чтобы понимать, где ваше приложение находится в семантическом пространстве стора. Для этого подойдут модели вроде Sentence-BERT или других мультиязычных трансформеров, которые помогают измерять смысловую близость между текстами.Не забывать про визуалы: все указывает на то, что сторы и другие системы поиска постепенно переходят к мультимодальным моделям, похожим на CLIP, где изображения и тексты связаны в одном пространстве. Даже если это пока не массово внедрено, логика эволюции алгоритмов ведет именно туда — к учету визуального контекста при оценке релевантности.  Оценивать не только позиции, но и реальные поведенческие сигналы: клики, установки, удержание. Если позиции растут, а вовлеченность пользователей нет, значит алгоритм видит несоответствие и вскоре скорректирует ранжирование.  Я полностью согласен с автором, что векторный поиск играет все большую и большую роль в поиске, в сторах в том числе. Может быть векторным поиском дело не ограничится и даже дойдет до RAG’а (пример – google ai overview, который теперь есть во всех результатах поиска) и пользователи будут сперва читать краткую справку о приложениях и из нее уже решать, что выбрать.

Как хакнуть современные поисковые системы?

Задача — не хакнуть модель, а убедить ее, что ваш продукт идеально подходит именно этому пользователю, именно под этот запрос лучше, чем любые другие приложения. (Небольшое уточнение: поисковые модели различаются от стора к стору, поэтому я буду полагаться на то, как это должно работать в идеальной архитектуре, не хочу уходить в дебри нюансов.)

Но чтобы двигаться дальше, зафиксируем типовую логику отрасли:

Поиск в App Store, Google Play сопоставляет запрос пользователя с метаданными и поведенческими данными, вычисляя итоговую релевантность как взвешенную сумму групп сигналов. В гибридных поисках комбинируются результаты из нескольких подсистем — например, текстового и семантического поиска, а итоговое ранжирование строится на относительном вкладе каждого из них.

Я свел все это в своеобразный шаблон (условную формулу-трафарет), отражающую ключевые моменты работы.

Score_s(q,app,u,t) = α_lex·LEX(q,app) + β_sem·SEM(q,app) + γ_vis·VIS(q,app) + δ_gen·GEN(app,s) + ε_rrk·RRK(q,app) + ζ_pers·PERS(q,app,u) + η_beh·BEH(q,app,s) + θ_qual·QUAL(app) + ι_trst·TRUST(app) + κ_graph·GRAPH(app) + λ_time·TIME(q,app,t) − μ_pen·PEN(app,q,s)

Не понятно, да? Давайте представим, что пользователь вводит запрос. Допустим, он пишет просто «taxi». С этого момента начинается его путешествие по поисковой системе.

На первом этапе формируется пул кандидатов. Алгоритм смотрит LEX — буквальное совпадение: BM25 или TF-IDF-подобный скор по полям (например: Title, Subtitle и Description) с бустами за точные вхождения и приоритетные поля.

Есть интересный патент US10635725B2, где алгоритм стора может переписать запрос, сходить в веб-поиск, извлечь идентификаторы приложений со страниц и добавить их в пул кандидатов для дальнейшего ранжирования. Интересно, для какого app store это реализовано 🙂

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

Далее вступает SEM — семантический слой. Он расширяет смысл запроса: “taxi” связывается с “ride”, “cab”, “driver”, “city”, “rideshare”. Поэтому выдача включает не только сервисы с буквальным совпадением, но и ride-sharing-приложения. Тут же работает NER — извлекаются сущности вроде брендов или городов.

После этого активируется VIS — визуальная релевантность. Система анализирует скриншоты: наличие карты, автомобиля, кнопки вызова, интерфейса поездки. Игровые или сторонние приложения, даже с совпадением по ключу, отсекаются на этом этапе. Это может быть OCR-анализ текста или CLIP-модель, связывающая изображение с понятием.

GEN — это бизнес-правила и ручные приоритеты: редакционные блоки, квоты, стартовые пулы. Они не влияют на релевантность напрямую, но корректируют стартовую выборку. Крупные, проверенные бренды получают стартовый вес, чтобы выдача была предсказуемой и безопасной.

Дальше вступает RRK — ранжирующая модель (Learning-to-Rank), которая объединяет все в единый скор. На этом этапе применяются PERS-сигналы: устройство, регион, язык, история поиска, установки и просмотры. По сути — персонализация.

Следом идут BEH-метрики: CTR по позиции, конверсия кликов в установки, глубина сессий, возвраты.

Технический контекст:

Проблемы с поведенческими сигналами (BEH):

1. Position bias:   - Приложения на топовых позициях получают больше кликов   - Как исправляют: debiasing через causal inference, inverse propensity weighting
2. Cold start:   - Новые приложения не имеют истории   - Как исправляют: exploration (ε-greedy, Thompson sampling), контент-фичи
3. Feedback loop:   - Плохое приложение в топе → получает клики → остается в топе   - Как исправляют: diversity, randomization, качественные сигналы (crash_rate)
4. Manipulation:   - Накрутка кликов/установок   - Как исправляют: fraud detection, anomaly detection, behavioral patterns

QUAL — стабильность и удержание: D1/D7/D30, ANR, краши, время запуска, LTV, ARPU.
TRUST — репутация: рейтинг, отзывы, свежесть и тональность фидбэка, флаги нарушений.
GRAPH — связи: совместные просмотры, кросс-установки, принадлежность к бренду или серии.
TIME — фактор времени: сезонность, тренды, актуальность контента.
И наконец, PEN — штрафные сигналы: переспам, искусственные установки, нарушение политики.

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

Коллеги из агентства JenLi тоже показали другой пример: связь показателя crash rate и его влияние на ASO. После устранения причин сбоев понадобилось время, чтобы 28-дневная средняя по crash rate опустилась ниже критического уровня 1,09%, и только тогда позиции начали расти по широкому пулу ключевых запросов.

Все эти элементы складываются в итоговый скор релевантности, который решает, кто окажется на вершине выдачи. 

Технический контекст:

Линейная комбинация (вышеуказанная формула) — это упрощение. В реальности:

1. Staged scoring:     Stage 1 (Retrieval): простая формула, быстро   Stage 2 (Pre-ranking): умеренная сложность, средняя скорость   Stage 3 (Ranking): сложная модель (neural net), медленно, но точно
2. Non-linear interactions:   - LEX × SEM: если лексически похоже И семантически близко → бонус   - BEH × QUAL: хороший retention, но высокий crash_rate → penalty
3. Learning-to-Rank (LTR):   Современные системы используют ML модели:   - Pointwise: предсказание абсолютного скора   - Pairwise: предсказание относительного порядка (A > B?)   - Listwise: оптимизация всего списка (NDCG, MAP)

Линейная формула хороша для проверки гипотез, выстраивания работы ASO-специалиста, но важно понимать, что техническая модель более сложная, например:

# Stage 1: Fast candidate retrieval (100K+ candidates → 1K)candidates = bm25_search(query, top_k=500) ∪ vector_search(query, top_k=500)
# Stage 2: Feature-based pre-ranking (1K → 100)for app in candidates:    features = {        'lex_score': bm25(query, app),        'sem_score': cosine(query_emb, app_emb),        'vis_score': clip_similarity(query, app.screenshots),        'ctr': app.ctr_for_query(query),        'install_rate': app.install_rate,        'retention_d7': app.retention[7],        'rating': app.rating,        'freshness': days_since_update(app),        ...    }    score = simple_model.predict(features)  # GBDT, LightGBM
candidates = top_100(candidates, by=score)
# Stage 3: Neural reranking (100 → 20)for app in candidates:    # Cross-encoder: encodes query+app together    score = neural_ranker(query, app)  # BERT-based
    # Personalization boost    score *= personalization_factor(user, app)
    # Business rules    if app.has_violations():        score *= 0.1  # strong penalty
final_results = top_20(candidates, by=score)

На слайде мой пример разработки плана работы для одного из приложений:

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

На каждом этапе есть свои нюансы, контрольные метрики, эксперименты и пороговые значения. В итоге, мы понимаем, какие факторы влияют на итоговую выдачу, но точные веса и их взаимодействия неизвестны и известны не будут. ASO меняется, но кое-что остается неизменным – все надо тестировать!

Современное ASO не заканчивается на текстовых итерациях — оно стыкуется с компьютерной лингвистикой, продуктовой аналитикой, валидацией гипотез и все, о чем я писал выше. Именно поэтому на схеме лексика открыта, а остальное размыто: базу знают все, а конкурентный результат дают следующие слои, где и лежит основная работа.

—

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

Базовые ASO-услуги агентства остаются доступными: как и у других агентств, они ориентированы на лексический поиск. Но для оптимизации под семантический поиск привычные подходы к ASO больше не работают.

Если вам интересен переход к новому пониманию ASO и работе с семантическим поиском, напишите мне в Telegram @avtrener — обсудим формат и условия.

—

Надеюсь, эта статья натолкнет вас на переосмысление своего подхода к работе.
Сейчас самое время этим заняться, чтобы потом не пришлось делать ASO в Иране 😉