Инсайды от Google: категории оценки приложения в Google Play

Начало истории тут: кейс о том, как Google ADS без предупреждения выкинул приложение из КМС. Выяснилось, что у гугла есть свой механизм оценки продукта: если у вас недостаточно качественные метрики, то вы недостойны быть в КМС (или в выдаче АСО, такие случаи тоже опубликованы на канале)

В кейсе ребята исправили только 1 метрику и вернулись в плейсмент. Она будет в конце статьи.

Как Google оценивает качество приложения: разбор всех параметров приватного аудита

Когда у приложения начинаются проблемы с раздачей трафика в UAC или падает органика, аккаунт-менеджер Google Play может прислать отчёт формата full_audit — именно такой отчет мне удалось поизучать, предоставили мне его друзья из соседней команды, которые работают с утилитами на Android, с гибридной моделью монетизации (реклама + подписки, 1M+ инсталлов, рейтинг 3.54, общий балл по отчету 3/10).

Это не письмо и не ручное ревью — это выгрузка из внутреннего тула, который собирает данные из четырёх источников:

Прогон приложения в Firebase Test Lab: автоматический краулер запускает приложение на живом устройстве, кликает по интерфейсу и пишет видео.
Парсинг манифеста. Все пермишены, сверка с тем, что заявлено в Data Safety.
Скрейп отзывов — своих и по каждому конкуренту, с выделением повторяющихся паттернов.
ASO-разбор — плотность ключей в описании, сравнение иконки, фичеграфика и скриншотов с конкурентами по десятку измерений.

Всё это прогоняется через LLM, которая выставляет баллы по фиксированной рубрике:

Архитектура оценки

16 категорий, сгруппированных в 4 пиллара:

Core Value: App Listing, User Reviews, Misleading Details Page, Content Depth, Feature Depth, Gameplay Loop*, Engagement.
User Experience: Visual Appeal, Craftsmanship*, FTUE, Usability, Ads Impact, IAP Impact*.
Privacy & Data Safety: Developer Trustworthiness, Privacy & Data Safety.
Technical Quality: App Stability.

* — только для игр. Для не-игр остаётся 13 категорий, максимум 130 баллов.

Общий балл — невзвешенное среднее. В разобранном отчёте = 3.15 → итоговые 3/10 (на скрине выше). Это ключевая механика. Стабильность на 10 баллов весит ровно столько же, сколько Visual Appeal: пять нулей тянут всё вниз и никакая техническая безупречность их не компенсирует.

Шкалы разной гранулярности. Часть категорий трёхбалльные: 0 / 5 / 10, без промежуточных значений.

Трёхбалльные: Misleading Details Page, Visual Appeal, FTUE, Usability, Content Depth, Feature Depth, Stability.
Четырёхбалльные: Developer Trustworthiness, Ads Impact (0 / 3.33 / 6.66 / 10).
Пятибалльные: App Listing, User Reviews, Privacy, Engagement.

Практический вывод: на трёхбалльной шкале нет частичного кредита. «Почти нормально» = 5, «плохо» = 0. Переход с 0 на 5 обычно стоит одного продуктового решения и даёт те же 5 баллов, что и героический рывок с 5 на 10. То есть, из “говна” перейти в разряд “неплохо” — достаточно просто, используйте это

Pre-install: что видно до установки

1. Perceived Quality of App Listing

Шкала: Very Low (0) → Low (2.5) → Medium (5) → High (7.5) → Very High (10).
Пиллар: Core Value.
В разобранном отчёте: 7.5 — High.

Что оценивают: качество всех ассетов стора — иконка, заголовок, фичеграфик, скриншоты, описание, превью-видео. Оценивается не «красиво / некрасиво», а по конкретному чек-листу с бенчмарками конверсии.

Что смотрит алгоритм:

Иконка — понятна ли функция приложения за секунду, отличается ли от конкурентов, читается ли в мелком размере.
Заголовок — есть ли ключи, не переспамлен ли.
Фичеграфик — узнаётся ли фокусный объект менее чем за 1 секунду, нет ли визуального мусора, укладывается ли копирайт в 5 слов, читается ли в размере превью.
Скриншоты — иерархия информации, покрытие фич, визуальная консистентность, панорамная непрерывность фона, сила первого кадра, наличие CTA, человеческие лица, социальные пруфы, длина подписей, локализация.
Описание — объём, плотность ключей, структура, опечатки, наличие FAQ и контактов.
Видео — есть или нет, ориентация, длина.

Что нашли в предоставленном отчёте:

Плюсы: единая айдентика между иконкой, фичеграфиком и скриншотами; жирные контрастные подписи на скриншотах; незахламлённый фичеграфик.
Минусы: описание всего ~220 слов при норме 325–450; орфографическая ошибка прямо в описании; последние два скриншота — дубликаты первых двух; превью-видео отсутствует полностью; нет человеческих лиц и социальных пруфов; нет FAQ и контактов поддержки.

Вертикальные видео дают +9% к watch rate и +10% к completion; трейлеры короче 30 секунд имеют примерно вдвое большую досматриваемость, чем трейлеры длиннее 45 секунд.

Как фиксить:

Снять превью-видео: вертикальное, до 30 секунд, хук в первые 3–5 секунд, показ реального действия (не логотипа).
Довести описание до 325–450 слов и 2000+ символов. Разбить на подсекции с заголовками. Добавить FAQ и контакт поддержки.
Занять все 8 слотов скриншотов уникальными кадрами. Первый кадр — с социальным пруфом («50M пользователей»). Панорамный фон, сшивающий первые три кадра. Последний кадр — с CTA.
Проверить описание на опечатки. Это звучит смешно, но в отчёте это отдельный critical-пункт.

2. Perceived Quality from Reviews

Шкала: Very Low (0) → Low (2.5) → Medium (5) → High (7.5) → Very High (10).
Пиллар: Core Value.
В разобранном отчёте: 5 — Medium.

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

Что смотрит алгоритм:

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

Что нашли из отчёта:

Хвалят: скорость переноса больших объёмов без потерь, простой интерфейс, кроссплатформенность.
Жалуются: неожиданное списание подписки (в отчёте это названо «severe sticker shock»), назойливая реклама, не работает пейринг по QR-коду, иногда падает передача файлов
Отдельно отмечено: reply rate 100%, но ответы шаблонные. И почта поддержки на Yahoo
Рейтинг 3.54 против 3.9 среднего по категории

Как фиксить:

Разобрать негатив по кластерам и починить топ-2 технических (в этом кейсе — QR-пейринг и обрывы соединения).
Сделать экран подписки недвусмысленным по цене. Отзывы со словом «scam» — самый дорогой тип негатива, он бьёт и по рейтингу, и по Trustworthiness одновременно.
Перестать отвечать шаблоном на 1 звезду. Персональный ответ по конкретному багу заметно чаще приводит к пересмотру оценки.
Перевести поддержку на почту своего домена.
Встроить in-app rating prompt в момент успеха — сразу после завершённого переноса. Свежий сентимент в этом кейсе сильно лучше исторического рейтинга, задача — конвертировать его в оценку в сторе.

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

3. Developer Trustworthiness

Шкала: Many Red Flags (0) → Some Red Flags (3.33) → No Red Flags (6.66) → Trustworthy (10).
Пиллар: Privacy & Data Safety.
В разобранном отчёте: 1 — Too Many Red Flags.

Что оценивают: доверие к разработчику как к субъекту: имя, почта, сайт, политика конфиденциальности, признаки накрутки.

Что смотрит алгоритм:

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

Что нашли в конкретном отчёте: несовпадающие домены почты (Gmail и Yahoo при наличии собственного сайта), серьёзные обвинения в обмане с подпиской, и — самое опасное — отзывы, хвалящие приложение за «отправку денег». То есть, закупленные отзывы (мотив), написанные под другое приложение

Как фиксить:

Единый домен: [email protected], тот же домен в политике конфиденциальности и на сайте. Это одна из самых дешёвых правок с наибольшим эффектом на балл.
Провести аудит отзывов и отрепортить накрутку самому. Google расценивает найденную накрутку как нарушение политики, а не как низкий балл.
Убрать любые сомнительные практики с биллингом — обвинения в мошенничестве бьют по этой категории напрямую.

4. Privacy & Data Safety

Шкала: Poor (0) → Concerning (2.5) → Acceptable (5) → Good (7.5) → Excellent (10).
Пиллар: Privacy & Data Safety.
В разобранном отчёте: 2.5 — Concerning.

Что оценивают: гигиену пермишенов и честность секции Data Safety. Алгоритм парсит манифест и сверяет его с декларацией.

Что смотрит алгоритм:

Высокий риск: ACCESS_FINE_LOCATION, MANAGE_EXTERNAL_STORAGE, READ_CONTACTS, WRITE_CONTACTS, REQUEST_INSTALL_PACKAGES. Средний риск: CAMERA, QUERY_ALL_PACKAGES, READ_EXTERNAL_STORAGE, WRITE_EXTERNAL_STORAGE.

По каждому — вопрос «есть ли видимая пользователю фича, которой это реально нужно»
Отдельно сверяется декларация Data Safety с наличием рекламных и биллинговых SDK в манифесте.

Что нашли в конкретном отчёте:

33 пермишена, 9 зафлагано. Сам отчёт признаёт, что для переносилки данных они оправданы: полный доступ к хранилищу нужен для переноса файлов, видимость пакетов — для переноса приложений, контакты — для телефонной книги, локация — для legacy WiFi-Direct пейринга.
Но балл всё равно 2.5, потому что: в Data Safety заявлен нулевой сбор данных, при том что в манифесте лежат AD_ID, ACCESS_ADSERVICES_ATTRIBUTION и ACCESS_ADSERVICES_TOPICS. Это прямое противоречие.
Плюсом отмечено: в манифесте есть NEARBY_WIFI_DEVICES — правильная приватная альтернатива локации на Android 12+.

Как фиксить:

Привести Data Safety в соответствие с реальностью. Если в приложении есть рекламный SDK — задекларировать сбор Device IDs и App activity. Это не «низкий балл», это ложная декларация.
Добавить in-app disclosure перед системным запросом каждого страшного пермишена: экран, объясняющий, зачем нужен доступ, до того как всплывёт системный диалог.
Запрашивать ACCESS_FINE_LOCATION только на Android 11 и ниже, а на 12+ полагаться исключительно на NEARBY_WIFI_DEVICES.
Пройтись по манифесту и вычистить пермишены, оставшиеся от выпиленных фич.

Post-install: что видно после установки

1. Misleading Details Page

Шкала: Completely Misleading (0) → Somewhat Misleading (5) → Not Misleading (10).
Пиллар: Core Value.
В разобранном отчёте: 5 — Somewhat Misleading.

Что оценивают: совпадает ли то, что обещает страница в сторе, с тем, что пользователь видит после установки.

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

Что нашли в конкретном отчёте: фичи из листинга в приложении есть, но листинг полностью умалчивает о том, что определяет реальный опыт: полноэкранная реклама чужого приложения при запуске, агрессивный пейволл на $XX/мес и — отдельно — фейковые отзывы внутри самого пейволла, не подтянутые из Google Play. Формулировка отчёта: страница в сторе показывает чистый доступный инструмент, а приложение ведёт себя как fleeceware.

Как фиксить:

Если приложение требует подписку для нормальной работы — написать это в описании. Пользователь должен принимать решение об установке, зная цену.
Убрать сфабрикованные отзывы из пейволла. Это отдельный deceptive-практикум, за него прилетает не балл, а санкция.
Добавить в скриншоты кадры, показывающие онбординг и условия подписки.
Убрать рекламу чужих приложений до главного экрана.

2. Visual Appeal

Шкала: Negative Impact (0) → Neutral (5) → Positive Impact (10)
Пиллар: User Experience
В разобранном отчёте: 5 — Neutral

Что оценивают: влияет ли дизайн на опыт положительно, нейтрально или отрицательно. Это трёхбалльная шкала, и большинство утилит стабильно получают ровно 5.

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

Что нашли в конкретном отчёте: «функциональный минимализм, который не раздражает и не впечатляет». Генеричные векторные иллюстрации в онбординге, простые пульсирующие анимации, главное меню из одноцветных прямоугольных карточек, стандартные иконки. Пейволл чистый, но перегружен текстом.

Как фиксить:

Заменить стоковые иконки на кастомные иллюстрации или 3D-ассеты.
Добавить глубину карточкам главного меню.
Разбить текстовый пейволл типографикой и визуальными представлениями фич.
Сделать переходы между экранами плавными.

3. First Time User Experience

Шкала: Poor (0) → Decent (5) → Great (10).
Пиллар: User Experience.
В разобранном отчёте: 0 — Poor.

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

Что смотрит алгоритм: порядок событий по таймкодам видеозаписи. Главный вопрос: что случилось раньше — пользователь понял ценность или у него попросили денег.

Как фиксить:

Убрать рекламу до главного экрана. Полностью. Это одно решение переводит балл с 0.
Сдвинуть пейволл за первое успешное действие. Не после туториала, а после первого переноса.
Заменить статичные слайды интерактивным туториалом, который ведёт через реальное подключение двух устройств.
Сделать кнопку закрытия пейволла явно видимой.

4. Usability

Шкала: Negative Impact (0) → Neutral (5) → Positive Impact (10).
Пиллар: User Experience.
В разобранном отчёте: 0 — Negative Impact.

Что оценивают: может ли пользователь достичь своей цели. Формулировка нулевого уровня в рубрике: «пользователю будет очень трудно достичь цели».

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

Что нашли в конкретном отчёте:

Самое жёсткое место всего отчёта. Кнопка «продолжить бесплатно» на пейволле повторно вызывала диалог покупки Google Play — на таймкодах 02:44, 03:50, 06:06. То есть пользователь почти пять минут не мог выйти из пейволла, нажимая кнопку отказа.
Плюс: 9+ минут до главного меню, и падающая авторизация в облачном бэкапе на 12:13.

Как фиксить:

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

5. Ads Impact on UX

Шкала: Very Negative (0) → Some Negative (3.33) → Little to No (6.66) → No Impact (10).
Пиллар: User Experience.
В разобранном отчёте: 0 — Very Negative.

Что оценивают: насколько реклама разрушает пользовательский путь. Для приложений на рекламной монетизации это самая важная категория рубрики.

Что смотрит алгоритм:

Частота интерстишилов и их расположение относительно пользовательского пути.
Обманчивый дизайн креативов — маскировка под системные диалоги или под интерфейс самого приложения.
Принудительные редиректы — уводит ли закрытие рекламы в браузер или стор без явного клика по CTA.
Пропускаемость видео.

Что нашли в конкретном отчёте:

На 01:54 показывается полноэкранная реклама, мимикрирующая под экран установки с крупной кнопкой INSTALL. Пользователь думает, что это часть настройки приложения.
На 08:19 и 08:48 закрытие рекламы принудительно выкидывает сначала в браузер, потом в Google Play — без согласия пользователя.
Последовательность реклама → редирект повторяется несколько раз до того, как пользователь доберётся до главного экрана.
Отчёт прямо называет это основным драйвером негативных отзывов в категории.

Как фиксить:

Забанить креативы, мимикрирующие под системный UI. Реклама должна визуально отличаться от интерфейса приложения.
Убрать форс-редиректы. Уход из приложения — только по явному клику по CTA внутри креатива.
Ограничить частоту интерстишлов и привязать их к точкам завершения задачи.
Пересмотреть тайминг монетизации целиком: гонять пользователя через рекламу до показа ценности — гарантированный высокий uninstall rate.

Пункты 1 и 2 — это не «низкий балл», это нарушение Disruptive Ads и Deceptive Ads одновременно в политике Play и в publisher policy AdMob. Для приложения, которое само закупается в UAC, это ещё и конфликт: оно одновременно покупатель трафика и площадка с плохими креативами, и Google видит обе стороны в одном ad-quality контуре.

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

6. Content Depth

Шкала: Less Than Expected (0) → As Expected (5) → More Than Expected (10).
Пиллар: Core Value.
В разобранном отчёте: 5 — As Expected.

Что оценивают: объём «потребляемого» содержимого относительно ожиданий категории. Для игр это уровни и контент, для утилит — набор инструментов и вспомогательных материалов.

Что смотрит алгоритм: сравнение набора фич с тем, что предлагают конкуренты в той же категории.

Что нашли в конкретном отчёте: пять фич на главном экране — перенос файлов, клонирование телефона, перенос с iOS, iCloud, облачный бэкап. Базовые ожидания закрыты, но нет продвинутого: переноса истории WhatsApp, переноса раскладки домашнего экрана, SMS и логов звонков.

Как фиксить:

Добавить специализированные модули, которых обычно нет в базовых инструментах: перенос данных конкретных приложений, SMS, раскладка экрана.
Добавить раздел Help с гайдами и FAQ — отчёт прямо засчитывает это как «потребляемый контент».
Дать превью медиа внутри приложения до переноса.

7. Feature Depth

Шкала: Less Than Expected (0) → As Expected (5) → More Than Expected (10).
Пиллар: Core Value.
В разобранном отчёте: 0 — Less Than Expected.

Что оценивают: работающую широту функциональности. Отличие от Content Depth: здесь ключевое слово — работающую.

Что смотрит алгоритм: проверяет, что заявленные на главном экране фичи реально запускаются. Неработающая фича обнуляет категорию независимо от того, сколько других фич есть.

Что нашли в конкретном отчёте:

Балл 0 при том, что фичи на дашборде те же самые, что дали 5 в Content Depth. Причина: облачный бэкап падает на Google Sign-in (12:13), а доступ к остальному заблокирован пейволлом и рекламой. Это хорошая иллюстрация того, как одна сломанная кнопка стоит целой категории.

Как фиксить:

Прогнать все точки входа с главного экрана и убедиться, что каждая открывается. Это буквально то, что делает краулер Test Lab.
Фичи-заглушки либо доделать, либо убрать, либо явно пометить «скоро».
Не блокировать базовую функциональность пейволлом — заблокированная фича для аудита равна отсутствующей.

8. App Stability

Шкала: Very Unstable (0) → Somewhat Stable (5) → Stable (10).
Пиллар: Technical Quality.
В разобранном отчёте: 10 — Stable.

Что оценивают: краши, ANR, фризы, частота кадров. Единственная категория с объективными метриками, а не с оценкой LLM.

Что смотрит алгоритм: данные Firebase Test Lab: количество крашей, количество ANR, время до первой отрисовки.

Что нашли в конкретном отчёте: 0 крашей, 0 ANR, splash screen 0.61 секунды. Отдельно отмечено, что приложение стабильно проходит через ресурсоёмкие сценарии — рендер сложного пейволла, загрузка и проигрывание полноэкранного видео, переходы в webview и в Play Store. Функциональная ошибка Google Sign-in засчитана в Feature Depth, но не в стабильность: приложение не падает, значит категория чистая.

Как фиксить:

Конкретно здесь чинить нечего, но полезно понимать: это единственная категория, которую можно закрыть на 10 чисто инженерными средствами, и она даёт всего 1/13 общего балла. Команды, привыкшие мерить качество Crashlytics, систематически переоценивают свой балл в этой рубрике.
Что стоит держать: мониторинг Crashlytics, отдельное тестирование переходов в полноэкранную рекламу и обратно на разных сетевых условиях — это типовая точка утечек памяти и ANR.

9. Engagement

Шкала: Very Low (0) → Low (2.5) → Somewhat (5) → Mostly (7.5) → Very Engaging (10).
Пиллар: Core Value.
В разобранном отчёте: 0 — Very Low.

Что оценивают: вероятность того, что пользователь оставит приложение и вернётся в него.

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

Что нашли в конкретном отчёте: логика оценки здесь показательна. Отчёт признаёт, что переносилка данных по своей природе одноразовая, и долгосрочный retention для неё физически невозможен. Но балл всё равно 0, потому что приложение не удерживает пользователя даже на одну сессию, нужную для выполнения единственной задачи.

Отдельный аргумент отчёта: подписка $XX/мес за инструмент, который используют раз в несколько лет, — модель, которая сама по себе гарантирует отвал.

Как фиксить:

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

Это про связь с DAU/MAU, по которому Google режет раздачу в GDN, — количественная метрика, которую платформа считает автоматически по всем приложениям. Это два разных механизма: рубрика выше — инструмент разговора с аккаунт-менеджером, DAU/MAU — вход в автоматический контур раздачи трафика. Но описывают они одно и то же явление с двух сторон, и фиксятся одними и теми же продуктовыми решениями

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

Дам еще один спойлер: сейчас многие АСО-команды сосредоточены именно на этой метрике. Она позволяет держаться дольше в топе. Наши тесты показывают то же самое. Выпущу отдельный пост об этом

Три категории только для игр

Craftsmanship & Polish (0 → 2.5 → 5 → 7.5 → 10, от Very Unpolished до Very Polished) — качество отделки графики, звука, сюжета, интерфейса, темы.
In-App Purchases Impact (0 / 3.33 / 6.66 / 10) — влияние внутриигровых покупок на опыт. Зеркало категории Ads Impact, с той же логикой: агрессивность, обманчивость, частота.
Gameplay Loop Quality (0 / 5 / 10) — эмоциональное воздействие и баланс целей, вызовов и наград.
Итого для игры: 16 категорий, максимум 160 баллов.

Что здесь не балл, а блокер

Отдельно стоит выделить пункты, которые лежат в другой плоскости. Они не влияют на «оценку качества» — они влияют на то, останется ли приложение в сторе:

Разница принципиальная: у балла есть градиент, у политики его нет. Приложение с баллом 3 — работает и заливает трафик. Приложение с ложной декларацией Data Safety не будет работать вообще.

Логический порядок починки

Если исходить из арифметики (невзвешенное среднее, трёхбалльные шкалы без частичного кредита), приоритет выглядит так:

Уровень 0 — блокеры. Data Safety, deceptive ads, накрутка отзывов
Уровень 1 — нули на трёхбалльных шкалах. FTUE, Usability, Feature Depth, Engagement. Все четыре в разобранном кейсе чинятся тремя решениями: убрать рекламу до главного экрана, сдвинуть пейволл за первое успешное действие, починить сломанную авторизацию. Это +20 баллов из 130, то есть общий балл с 3.15 до 4.7
Уровень 2 — дешёвые правки в pre-install. Почта на своём домене, описание до 325–450 слов, восемь уникальных скриншотов, превью-видео. Каждый пункт имеет измеренный вклад в конверсию
Уровень 3 — глубина продукта. Content Depth и Feature Depth до 10, Visual Appeal до 10. Дорого, долго, и для утилиты обычно не окупается

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

Автор: Ден Марков

YouTube | Telegram | Сообщество