Модерация Google Play давно уже не сводится к тому, чтобы просто загрузить приложение и дождаться проверки. Google смотрит на саму прилку, аккаунт разработчика, IP, отпечатки устройств, SDK, разрешения, метаданные, Policy и Data Safety. И если где-то есть странные пересечения или несостыковки, можно получить не обычный реджект, а сразу High Risk или блокировку аккаунта. В этом материале разберем, за что чаще всего банят приложения и аккаунты разработчиков и что лучше проверить еще до первой отправки в стор.
А если вы ищите Google и Apple аккаунты от проверенного поставщика смело пишите ребятам из Phoenix.
Как проходит модерация Google Play: что проверяет Google
После отправки приложения Google смотрит не на одну конкретную вещь, а сразу на весь комплект. Само приложение, аккаунт разработчика, окружение, с которого с ним работали, Policy, Data Safety и то, насколько все это вообще совпадает между собой.
Отдельно проверяется работа с аккаунтом. Google смотрит на смену IP, отпечатки устройств и пересечения с другими аккаунтами. Если, например, слетел прокси и засветился IP, который уже использовался на другом аккаунте, это может закончиться баном за High Risk или мультиаккаунтинг.
Дальше идет сама прилка: код, SDK, разрешения, подпись и метаданные. Здесь тоже важно, чтобы нигде не оставалось следов связи с другими приложениями, а сама прилка выглядела как нормальный законченный продукт, а не пустая заглушка.
И еще один важный момент — Policy и Data Safety. Если в декларации написано, что приложение ничего не собирает, а внутри стоит аналитика или рекламный SDK, который данные собирает, для Google это уже несостыковка и повод копать глубже.
На каком этапе чаще всего прилетает бан
Самый опасный момент — первая публикация приложения, особенно если речь идет о новом аккаунте разработчика. Именно на новорегах Google чаще всего не ограничивается обычным реджектом, а сразу кидает High Risk и блокирует аккаунт.
Со старыми аккаунтами, у которых уже есть история работы в Play Console, ситуация обычно мягче: сначала может прилететь реджект с замечаниями, а не моментальный бан. Поэтому возраст и история аккаунта тут реально имеют значение.
Самое неприятное, что Google обычно не объясняет причину нормально. Приходит одно из типовых писем вроде High Risk, Related Account Violation или нарушения требований Play Console, и дальше уже приходится самому разбираться, где именно был косяк: в аккаунте, окружении, приложении или публикации.
High Risk, Related Account Violation и другие блокировки
По самому письму от Google точную причину бана обычно не понять, но хотя бы направление для проверки оно дает. Чаще всего встречаются три формулировки.
High Risk — самая размытая история. Тут проблема может быть сразу в нескольких местах: аккаунте, приложении, окружении или самом процессе публикации. Поэтому после такого письма приходится перепроверять почти все целиком, а не искать один конкретный косяк.
Нарушение Соглашения для разработчиков и требований Play Console — уже чуть более понятный сигнал. В таких письмах может встречаться ссылка на пункт 11.4 про достоверность предоставленной информации. Тогда стоит смотреть, как именно работали с аккаунтом во время публикации, а также проверять метаданные в бинарнике и материалах, которые отправлялись в стор.
Related Account Violation означает, что Google увидел связь с другим аккаунтом. Тут уже надо искать пересечения: код, метаданные, IP и другие следы, которые могли связать аккаунты между собой. В последнее время такие баны стали чаще всплывать и при неаккуратной автоматизации через AI, когда инструменты работают через API и случайно светят реальный IP устройства.
Какие ошибки чаще всего мешают пройти модерацию
Самая банальная причина — приложение просто нормально не проверили перед отправкой. Сейчас часть прилок собирается с помощью AI, и иногда в стор улетает сырой результат: одна иконка в листинге, другая внутри, скрины не совпадают с интерфейсом, какие-то элементы вообще работают не так, как обещано в описании. Перед публикацией лучше руками пройти всю прилку от начала до конца и сравнить ее с тем, что увидит пользователь в Google Play.
Еще часто забывают про метаданные. Сам билд вроде проверили, а в картинках, скринах или других материалах остались лишние следы. В итоге приложение может словить проблемы вообще не из-за функционала, а из-за того, что кто-то не дочистил файлы перед отправкой.
Отдельная боль — Policy и Data Safety. Если в декларациях написано одно, а реально приложение вместе с SDK делает другое, Google это может заметить. То же самое касается разрешений: если приложение просит доступ к чему-то, что никак не используется в основной функциональности, это сразу выглядит подозрительно.
Ну и совсем пустые шаблонные прилки тоже проходят все хуже. Один экран, кнопка, примитивная механика или очередной клон калькулятора уже мало кого впечатляют. Если лезете в забитую категорию, нужна хотя бы какая-то нормальная фича, которая отличает приложение от сотен таких же.
Читать статью: Как выбрать поставщика консолей и не купить бан: что проверить до оплаты, чтобы аккаунт дожил до окупаемости
Что Google не любит в названии, описании и скриншотах
Даже если сама прилка собрана нормально, можно словить проблемы тупо на оформлении витрины. В названии и иконке лучше не использовать формулировки вроде «№1», «лучший», «бесплатно», «Sale» и не превращать название в набор ключевых слов.
Отдельно Google смотрит на чужие бренды. Если в названии, иконке или оформлении приложение выглядит так, будто связано с известной компанией, а прав на это нет, это уже повод для проблем. То же самое касается персонажей и чужого фирменного стиля.
С описанием история такая же: без фейковых отзывов и обещаний в духе «минус 10 кг за неделю», «вылечит бессонницу» или «абсолютно бесплатно», если это нельзя нормально подтвердить. А скриншоты должны показывать именно то приложение, которое человек реально получит после установки, а не красивую фантазию дизайнера.
Реджект или бан: есть ли смысл подавать апелляцию
Тут важно не путать обычный реджект и полноценный бан аккаунта. Если прилетел реджект, ситуация еще рабочая: читаем замечания, исправляем косяки и отправляем приложение повторно. При этом лучше перепроверить всю прилку целиком, потому что модератор мог остановиться на первой серьезной проблеме и просто не перечислить остальные.
С баном все сильно хуже. По внутренней практике ребят из Phoenix за пять лет было отправлено около 200 апелляций, ответ пришел только два раза, и оба раза это был отказ. Ни одного аккаунта через апелляцию восстановить не удалось.
Это не значит, что апелляцию вообще не стоит подавать. Попробовать можно, особенно если есть уверенность, что блокировка прилетела по ошибке. Но рассчитывать на нее как на нормальный способ вернуть аккаунт точно не стоит.
Поэтому главный вывод здесь простой: реджект еще можно спокойно исправить, а бан лучше воспринимать как серьезную проблему, которую намного проще не допустить, чем потом пытаться откатить назад.
Почему приложение могут удалить уже после публикации
То, что прилка один раз прошла модерацию, вообще не значит, что дальше про нее можно забыть. Google продолжает смотреть на приложение и после публикации, особенно если в нем что-то резко меняется.
Один из самых частых триггеров — обновление. Если в новой версии внезапно появляется куча новых SDK, WebView или сильно меняется логика приложения, это может привести к более глубокой проверке. Поэтому крупные изменения лучше не выкатывать одним махом, а внедрять постепенно и следить, чтобы новая функциональность нормально объяснялась внутри самой прилки.
Еще Google может насторожить резкая смена поведения аудитории. Например, приложение долго почти никто не открывал, а потом внезапно пошли тысячи пользователей, которые проводят внутри по несколько часов. Если при этом никаких понятных изменений в продукте не было, это выглядит подозрительно.
Плюс никто не отменял банальные вещи: пропущенные требования, непрочитанные письма в Play Console, жалобы пользователей и отзывы на то, что внутри работает какая-то серая функциональность. Если Google находит проблему уже после публикации, приложение могут удалить из стора, а при бане аккаунта под раздачу могут попасть и остальные прилки.
Что проверить перед модерацией Google Play
Перед первой отправкой лучше не торопиться и пройтись по всей сборке еще раз. Не только по самой прилке, а вообще по всему, что уходит в Google Play вместе с ней.
Проверяем саму работу приложения, SDK, разрешения, метаданные, подпись, листинг, Policy и Data Safety. Особенно важно, чтобы все это не противоречило друг другу: если в декларациях написано одно, а прилка по факту делает другое, это лишний повод для проверки.
Отдельно стоит еще раз посмотреть, что скрины и описание реально соответствуют приложению, а в сборке не осталось лишних пересечений, старых файлов или ненужных разрешений.
Короче, первая публикация — не тот момент, где стоит спешить. Лучше потратить лишний час на проверку до отправки, чем потом пытаться понять, из-за какого мелкого косяка прилетел реджект или бан.
