High-risk behaviour: як Google Play може забанити вас за «чужі гріхи»

Мене звати Ярослав Огнев’юк. Я очолюю юридичну фірму AMBASSADORS і понад 20 років працюю з інтелектуальною власністю та технологічними проєктами. Сьогодні Google Play більше схожий не на магазин додатків, а на великий аеропорт безпеки. Мільйони програм проходять через систему перевірок, і алгоритм працює як сканер: він не намагається зрозуміти наміри розробника. Він шукає сигнали ризику.

Коли гра зникає з магазину, компанія втрачає не лише дистрибуцію. Зникає маркетинговий бюджет, ламається user acquisition, падає рейтинг студії перед інвесторами. У мобільній економіці один бан може коштувати дорожче, ніж рік розробки.

У першій частині ми говорили про те, чому апеляції в Google Play рідко дають результат. Платформа не розглядає ситуацію як суд. Система дивиться насамперед на ризик. Якщо система вирішує, що додаток може створювати проблему для користувачів або для самої екосистеми магазину, рішення приймається швидко, і воно часто доволі жорстке.

Але після блокувань дуже часто команда не розуміє, що саме сталося. Гра працює, користувачі не скаржаться, нічого явно забороненого в коді немає. І раптом у консолі з’являється повідомлення про high-risk behaviour. У певному сенсі це дуже схоже на фінансовий моніторинг у банках. Коли транзакція виглядає підозрілою, банк не зобов’язаний доводити злочин — він може просто зупинити операцію. З платформами працює така сама логіка: система керує ризиком екосистеми, а не доводить провину конкретного розробника.

Тут важливий нюанс: ця «машина ризику» в 2025 році стала ще жорсткішою. Google офіційно повідомив, що лише за 2025 рік заблокував публікацію понад 1,75 млн застосунків і забанив понад 80 тисяч developer-акаунтів — і прямо пише, що активно використовує AI/GenAI-моделі у процесі перевірок.

Тобто «людський здоровий глузд» там є, але перший фільтр — це все ж таки масштабна автоматизація.

Це формулювання виглядає серйозно, але майже нічого не пояснює. В такі моменти починається одна з менш очевидних особливостей Google Play.

Іноді Google дивиться не лише на ваш додаток. Він оцінює весь контекст навколо нього: SDK, рекламні мережі, історію акаунта і навіть технічні зв’язки між людьми, які мали доступ до консолі. У підсумку бан може прилетіти не через конкретний рядок коду, а через поведінку системи, яка виглядає підозрілою з точки зору алгоритму.

Дослідники AppCensus прямо пишуть, що сторонні SDK можуть збирати дані так, що розробник може навіть не усвідомлювати обсяг збору, бо SDK успадковують доступи додатка. Саме через такі випадки Google у нових версіях політик все більше перекладає відповідальність за SDK на розробника.

З боку розробника це виглядає дивно. З боку алгоритму платформи все цілком логічно. Магазин із мільйонами додатків не може проводити розслідування кожного випадку. Тому система працює простіше: вона шукає патерни ризику. І часто ці патерни з’являються там, де команда навіть не підозрює.

На деяких спеціалізованих юрфорумах іноді згадують ще одну особливість перевірок. Якщо додаток кілька разів поспіль отримує реджекти або скарги користувачів, система може переводити акаунт у так званий escalated review mode. У такому режимі перевірки стають значно суворішими: додаток може тестуватися довше, а будь-який ризиковий сигнал перевіряється глибше.

Коли проблема не у вашій грі

Сучасна мобільна гра майже ніколи не складається лише з коду самої команди. Усередині працює ціла екосистема сторонніх компонентів:

• аналітика;
• рекламні мережі;
• push-сервіси;
• crash-репортери;
• системи авторизації.

Саме ці бібліотеки часто визначають, як додаток поводиться з даними користувача і як працює реклама. Проблема в тому, що їхня поведінка може змінюватися без участі розробника — після оновлення SDK або після зміни політик рекламної мережі. І це не лише теорія: дослідження Android-екосистеми регулярно показують випадки over-collection і непрозорих практик збору даних сторонніми бібліотеками.

І це б’є не лише по безпеці, а й по декларуванню даних у Data Safety. Дослідження 2024 року показують, що розробники регулярно недо- або пере-декларують збір даних у Data Safety. Часто не навмисно, а тому що реальний data flow через SDK важко точно відстежити. Для Google це означає одне: якщо декларація не збігається з реальністю, система буде трактувати це як ризик.

Я кілька разів бачив ситуацію, коли команда шукала причину реджекту в коді гри, а проблема виявлялася у сторонньому SDK. Наприклад, рекламна мережа починала показувати оголошення, які алгоритм Google класифікував як misleading ads. Для користувача це виглядає як частина додатка, тому відповідальність автоматично переходить на нього.

В результаті бан отримує сама гра, хоча розробник навіть не контролює контент реклами. Найнеприємніше в таких історіях те, що команда дізнається про проблему вже після блокування. У випадках, з якими ми стикалися, причину блокування вдалося знайти лише після технічного аудиту SDK і data flow. Проблема була в сторонніх бібліотеках.

У складніших кейсах це перетворюється на повноцінний аудит додатка: аналіз SDK, data flow, рекламних механік і доступів до консолі. Іноді саме така перевірка дозволяє знайти причину блокування, яку команда не могла знайти в коді.

У таких кейсах насправді стикаються три різні світи: технічна архітектура додатка, рекламна екосистема і політики платформи. Тому пошук причини блокування часто виглядає дивно: код перевіряють інженери, SDK аналізують фахівці з мобільної реклами, а саму логіку блокування доводиться читати крізь правила Developer Distribution Agreement.

Ще на практиці ми бачили ситуацію, коли невелика студія інтегрувала рекламну мережу, яка після оновлення SDK почала підвантажувати оголошення з misleading mechanics. Гра працювала без змін, але алгоритм класифікував рекламу як deceptive behaviour і додаток отримав блокування.

Деякі розробники на форумах Android навіть жартують, що додаток у Google Play іноді поводиться як «командна гра». Навіть якщо ваш код ідеальний, один проблемний SDK може зіпсувати результат для всього продукту.

Репутація акаунта теж має значення

Ще один фактор, який часто недооцінюють, власне це історія самого акаунта розробника. У практиці іноді трапляється парадоксальна ситуація: новий додаток виглядає чистим, але акаунт уже має «історію», яка впливає на ризикову модель. Google дивиться не лише на окремий додаток — він дивиться на поведінку акаунта в цілому.

«Якщо раніше були порушення політик, агресивна реклама або додатки, що збирали багато скарг, нові релізи можуть перевірятися значно жорсткіше.»

На американських форумах розробників часто обговорюють ще одну деталь, яка офіційно майже не пояснюється: акаунт розробника має свій умовний «risk score». Це не формальний показник у консолі, але поведінка системи дуже на нього схожа. Якщо акаунт довго працює без порушень, релізи проходять швидше і перевірки м’якші. Якщо ж історія акаунта містить реджекти або policy strikes, нові релізи можуть автоматично потрапляти в жорсткіший режим перевірки.

Є ще один ефект, який розробники помічають на практиці: після policy strike різко змінюється швидкість перевірок. Якщо раніше реліз міг проходити за кілька годин, після серії реджектів або скарг модерація іноді починає тривати дні. У спільнотах Android це часто пояснюють просто: акаунт потрапляє у більш суворий режим перевірок.

Це трохи схоже на кредитну історію. Навіть якщо новий проєкт виглядає чистим, старі проблеми іноді продовжують впливати на репутацію акаунта певний період. Іноді це проявляється не одразу. Може пройти кілька місяців або кілька релізів, перш ніж система почне оцінювати акаунт як ризиковий.

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

Є ще один механізм, який розробники часто недооцінюють це circumvention policy. Якщо система вважає, що команда намагається обійти попередні обмеження платформи, реакція може бути дуже жорсткою. Наприклад, коли після реджекту створюється новий акаунт, публікується майже ідентичний додаток або змінюються технічні параметри, але сама поведінка програми залишається тією ж.

Для алгоритму це виглядає не як новий продукт, а як спроба обійти попереднє рішення. І в таких випадках блокування може поширюватися вже не на один додаток, а на весь акаунт.

Найзагадковіший механізм — пов’язані акаунти

Найбільше питань у розробників зазвичай викликає інша категорія блокувань — association bans. У Google Developer Community це формулюється максимально сухо і без деталей: акаунт може залишатися terminated через порушення «this or associated, previously terminated accounts». Така «асоціація» зазвичай і ламає людям логіку: код чистий, команда інша, а сигнал уже прилетів. На практиці такими сигналами можуть бути спільні пристрої, однакові платіжні профілі, IP-адреси, shared developer machines або навіть історія тестових акаунтів.

Google прямо зазначає у своїх правилах, що може блокувати акаунти, пов’язані з іншими акаунтами, які порушували політики. Як саме визначаються такі зв’язки, платформа детально не пояснює. Але очевидно, що система аналізує технічні сигнали — від пристроїв і IP-адрес до платіжних профілів. Іноді достатньо кількох таких сигналів, щоб акаунти опинилися в одному ризиковому кластері.

З погляду алгоритму це виглядає як профілактика. Якщо один акаунт уже створював проблеми, система намагається запобігти повторенню схожих сценаріїв.

З погляду розробників такі історії іноді виглядають як детектив. Команда може бути впевнена, що працює абсолютно незалежно, але система знаходить технічний зв’язок, про який ніхто навіть не думав.

Алгоритм не читає ваш README і не знає, що ви «чесний інді-розробник». Він бачить лише сигнали. Умовно кажучи, алгоритм працює як система фінансового моніторингу: якщо кілька сигналів збігаються, транзакція виглядає підозрілою навіть без прямого доказу порушення.

Є ще один феномен, який жартома називають shadow investigation. Іноді система певний час просто спостерігає за поведінкою додатка і акаунта, збираючи сигнали. У цей період додаток може працювати нормально. Але якщо ризикові сигнали накопичуються, блокування може відбутися раптово — навіть через кілька релізів після появи проблеми.

Чому система працює саме так

У масштабі Google Play іншого варіанту майже немає. У магазині мільйони додатків, і більшість перевірок проводяться автоматично.

Тому система працює як великий ризик-фільтр. Вона не доводить провину. Вона оцінює ймовірність проблеми. Якщо кілька сигналів виглядають підозріло, то платформа може вирішити, що простіше зупинити додаток, ніж ризикувати безпекою користувачів або репутацією магазину.

Іноді це виглядає надто жорстко. Але з точки зору платформи це раціональна модель.

Що реально зменшує ризик

Є кілька речей, які значно знижують шанс потрапити в таку ситуацію.

По-перше, варто регулярно перевіряти сторонні SDK, особливо рекламні. Іноді зміни в їхній поведінці відбуваються без явних сигналів для розробника.

По-друге, має значення історія акаунта. Навіть експериментальні додатки можуть впливати на його репутацію.

По-третє, важливо контролювати доступ до консолі розробника і розуміти, хто саме працює з акаунтом.

Ці речі звучать досить буденно, але вони впливають на ключове питання для команди: як зменшити ймовірність того, що система класифікує додаток як ризиковий. У зрілих командах це вже виглядає як окремий процес — policy compliance review перед кожним релізом.

Чому про це зазвичай дізнаються запізно

Більшість команд починає вивчати політики Google Play лише після першого реджекту або блокування. На практиці такі історії майже ніколи не бувають простими. Ми бачили кейси, де причина блокування лежала в рекламному SDK, кейси де проблема виникала через association signals між акаунтами, і кейси де все впиралося в некоректно задекларований data flow у Data Safety. І постає питання: який саме сигнал ризику побачила система.

До цього моменту магазин сприймається як нейтральна інфраструктура — місце, де просто публікуються додатки. Google Play давно перестав бути просто каналом дистрибуції. Це складна система ризик-менеджменту. І команди, які сприймають її саме так, набагато рідше опиняються в ситуації, коли гра зникає з магазину без зрозумілої причини.

З юридичної точки зору це означає одну важливу річ: відносини між платформою і розробником побудовані не на класичному принципі доведення порушення, а на праві платформи управляти ризиком для своєї екосистеми. З цієї причини багато рішень виглядають для команд несподіваними, але формально вони випливають із умов Developer Distribution Agreement.

З досвіду найскладніше в таких кейсах це не сам бан, а пошук причини. Інколи вона лежить у коді, інколи в партнерських SDK, а інколи — у технічних зв’язках між акаунтами, про які команда навіть не підозрює. Тому блокування в Google Play майже ніколи не вирішується однією апеляцією. Спочатку потрібно зрозуміти, який сигнал ризику побачила система.

Підписуйтеся на Telegram-канал @gamedev_dou, щоб не пропустити найважливіші статті і новини