Модерация Google Play для многих до сих пор остается лотереей: вроде все загрузил нормально, а в ответ прилетает реджект, High Risk или вообще бан аккаунта. Разбираем вместе с Ильей из Phoenix , что именно Google проверяет, где чаще всего все ломается и как повысить шансы пройти проверку с первого раза.
Что мешает пройти модерацию Google Play
При модерации Google смотрит не только на саму прилку. В первую очередь учитывается история работы с аккаунтом разработчика: с каких устройств в него заходили, как часто менялись IP и насколько в целом поведение аккаунта выглядит нормальным.
Дальше уже разбирается само приложение: код, разрешения, Policy и метаданные. Причем метаданные смотрят не только внутри файла приложения, но и в скриншотах, иконках и других материалах, которые отправляются вместе с публикацией.
Отдельный блок — это соответствие Policy и Data Safety реальному поведению прилки. Если в декларациях написано одно, а внутри приложение или подключенные SDK делают другое, Google это видит. Поэтому заполнять все на автомате здесь точно плохая идея.
Самый опасный момент для нового аккаунта — публикация первой прилки. У аккаунта еще нет нормальной истории: нет прошлых релизов, почти нет активности и Google в целом относится к нему намного внимательнее.
Из-за этого даже относительно небольшие косяки могут закончиться не обычным реджектом приложения, а сразу баном аккаунта по High Risk. На старых аккаунтах с историей шанс отделаться просто замечаниями выше, а на новорегах все намного жестче.
Поэтому первый релиз лучше проверять особенно внимательно: тут цена ошибки выше всего.
High Risk, мультиаккаунтинг и другие причины блокировок
Самая неприятная история в том, что Google обычно не пишет прямо: «вот здесь вы накосячили». Чаще приходит одна из нескольких общих формулировок, и дальше уже приходится самому разбираться, где именно проблема.
High Risk — самая размытая причина. Это может быть не один конкретный косяк, а сразу несколько мелких: где-то неправильно заполнены Policy, где-то часто менялся IP, где-то есть баги в самой прилке или странные метаданные. В таком случае обычно приходится перепроверять вообще весь путь публикации целиком.
Еще один вариант — нарушение правил работы с аккаунтами разработчиков. Тут Google уже скорее намекает, что проблема не в коде приложения, а в самом процессе публикации и данных аккаунта. То есть стоит смотреть, кто и как работал с аккаунтом, и нет ли странностей в метаданных.
Ну и самый понятный случай — мультиаккаунтинг. Если Google связал несколько аккаунтов между собой по метаданным, подписи или IP, под блокировку может попасть не только один аккаунт, а сразу вся связка.
Как пройти модерацию Google Play: частые ошибки
Самая частая проблема — Policy и Data Safety заполняют на автомате, вообще не сверяя их с тем, что реально есть внутри приложения. В декларации пишут, что данные не собираются, а внутри стоит SDK, который спокойно собирает рекламный идентификатор или другую информацию. Google это видит и воспринимает уже не как мелкую ошибку, а как несоответствие или даже обманное поведение.
Причем смотреть нужно не только на то, что собирает сама прилка, но и на подключенные SDK. Если сторонний сервис хранит какие-то данные или использует определенные идентификаторы, это тоже должно нормально отражаться в Policy и Data Safety.
Короче, здесь главная ошибка простая: описать приложение одним образом, а по факту внутри получить совсем другое поведение. И вот такие несостыковки как раз чаще всего потом и вылезают на модерации.
Что нельзя делать в названии, описании и скриншотах
Даже если сама прилка собрана нормально, можно словить проблемы уже на оформлении страницы в Google Play. В названии и описании лучше не использовать формулировки вроде «№1», «лучший», «скидка», «без рекламы» и не злоупотреблять капсом. Для Google такие вещи могут стать дополнительным триггером на проверку.
Отдельная история — чужие бренды. Если в названии, иконке или оформлении используется узнаваемый бренд, особенно тот, вокруг которого уже было много клонов, это тоже может быстро привлечь внимание модерации.
Со скриншотами все еще проще: они должны показывать то, что реально находится внутри приложения. Сейчас часть графики генерируется через ИИ, и легко получить ситуацию, когда на скринах одна прилка, а после установки пользователь видит совсем другое. Для Google это уже явная несостыковка.
И еще момент — отзывы. Если внезапно появляется пачка положительных оценок с совсем свежих аккаунтов, Google может воспринять это как накрутку. Поэтому искусственно разгонять отзывы перед публикацией тоже плохая идея.
Реджект или бан: что можно исправить
Тут важно разделять обычный реджект приложения и бан аккаунта. Если Google просто отклонил прилку, обычно в письме довольно понятно написано, что именно нужно поправить. Исправили ошибку, сделали полный ретест и только после этого отправляем приложение повторно.
Почему именно полный ретест? Потому что модератор может остановиться на первой найденной проблеме. Вы ее исправите, отправите прилку снова, а на следующем круге всплывет уже второй косяк. Поэтому лучше после реджекта перепроверить приложение целиком, а не фиксить только один пункт из письма.
С баном все намного грустнее. По опыту ребят из Phoenix, за несколько лет было подано примерно 200–300 апелляций, а ответ пришел всего на несколько, и те закончились отказом. Шансы выше только в ситуации, когда у вас реально крупное белое приложение и блокировка произошла по ошибке.
Почему приложение могут удалить уже после публикации
То, что прилка один раз прошла модерацию, вообще не значит, что дальше про нее можно забыть. Самый частый сценарий удаления уже после релиза связан с обновлениями: добавили новый SDK, поменяли функционал, но забыли обновить Policy или Data Safety. Для Google это уже снова несостыковка между тем, что заявлено, и тем, что реально происходит внутри приложения.
Еще один триггер — резкое изменение поведения пользователей. Например, до этого люди заходили в приложение на пару минут, а потом без видимых изменений начинают сидеть там по полчаса или часу. Если для такого скачка нет понятного объяснения, Google может отправить прилку на дополнительную проверку.
Если проблема серьезная, последствия могут быть уже не только для одной прилки. При блокировке за мультиаккаунтинг Google может связать между собой несколько аккаунтов и снести всю связку. А если приложение посчитают потенциально опасным, его могут удалить не только из стора, но и с устройств пользователей.
Как проверить приложение до отправки в Google Play
Проверять прилку лучше еще до того, как она вообще улетит на модерацию. У Phoenix для этого как раз сделали отдельного бота, который разбирает приложение и ищет расхождения с требованиями Google еще до публикации.
Минимально ему нужны Policy и AAB-файл. Дальше он смотрит, какие разрешения запрашивает приложение, какие SDK подключены и насколько все это совпадает с тем, что написано в Policy. Если дополнительно загрузить скрины, описание, манифест и Data Safety, проверка становится шире.
Внутри у бота зашито 74 правила, собранных на основе политик Google, а саму систему дорабатывали на базе более чем тысячи приложений, которые прошли через команду Phoenix. На выходе бот подсвечивает расхождения, которые потенциально могут привести к реджекту или бану.
Что проверить перед публикацией
Перед отправкой в Google Play лучше не торопиться и еще раз пройтись по прилке руками. Сейчас разработку сильно ускорили через ИИ, и из-за этого приложения все чаще собираются почти конвейером: один разработчик может делать по 20–30 прилок в неделю. На таком темпе банально проще пропустить косяк.
Проверить стоит, совпадают ли скрины с реальным интерфейсом, правильная ли иконка, действительно ли работают заявленные функции и локализация. В файле как раз есть пример, когда ИИ обещает перевод на десять языков, а по факту везде остается английский.
Отдельно стоит еще раз посмотреть метаданные, картинки и иконки, особенно если материалы приходят от разных людей в команде. Такие мелочи тоже могут связать приложения между собой и потом вылезти уже на модерации.
