Google Play заблокував гру: що реально впливає на розблокування і чому більшість апеляцій провалюється

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

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

До цього правила цікавили лише при запуску проєкту на платформі. Як щось формальне. Як угода, яку прийняли і забули. Ми ж білі та пухнасті, гра зроблена нами на совість, без шахрайств. У нас нормальна гра. Що може піти не так?

А потім неочікувано — Suspended. В такий момент політики раптом стають найважливішим текстом у світі.

«Але ми нічого не порушували» — це перша фраза, яку я чую майже в кожному кейсі. І я її розумію. Коли у продукт вкладено рік життя, емоційно хочеться довести, що рішення несправедливе.

Але тут є неприємна правда: Google точно не цікавить, що ви мали на увазі. Їх цікавить, як ви виглядаєте з боку ризику.

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

Це ж американська компанія. Договір підпорядковується праву Каліфорнії. І стандарт тут — не «доведіть вину», а «чи виглядає це безпечним».

Поки розробник думає: «Я нічого не порушив», система думає: «Чи повториться це завтра?»

Кейс, який багато хто пам’ятає

У 2023 році в Reddit обговорювали історію невеликої студії, яка втратила акаунт із мільйонами завантажень. Причина в листі — «pattern of high-risk behavior».

Жодних конкретних пунктів. Жодних прикладів.

Хронологія виглядала болісно знайомо:

  • день 1 — блокування;
  • день 2 — апеляція з аргументом «ми нічого не порушували»;
  • день 5 — відповідь: рішення остаточне;
  • день 7 — друга апеляція з проханням пояснити деталі;
  • день 10 — фінальна відмова.

Пізніше в коментарях з’явилася версія: сторонній SDK передавав дані, не задекларовані в Data Safety. Команда навіть не знала, що відбувається на рівні трафіку.

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

Алгоритм не бачить намір

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

Алгоритм не грає у вашу гру. Він читає сигнали. Тому слово «casino» в описі може стати тригером навіть без азартної механіки. Банер, який перекриває кнопку на три пікселі, — достатній для «disruptive ads». Іконка, що надто нагадує популярний бренд, — потенційний ризик IP.

Кілька пікселів можуть коштувати вам продукту. Це звучить абсурдно, поки не стикаєшся з цим особисто.

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

IP — коли стає по-справжньому серйозно

Є чимало історій, де алгоритм ні до чого. Наприклад, розробник використав фонову музику з «free library». Ліцензію дочитав поверхово. Правовласник подав DMCA-скаргу. Гру видалили.

Тут уже не ризик-модель. Тут юридична процедура. Google зобов’язаний реагувати на DMCA. Якщо хочеш відновлення — подаєш counter-notice. У заяві ти фактично підтверджуєш готовність відповідати юридично.

І багато хто в цей момент раптом починає розуміти, що «безкоштовно» не означає «можна все».

Чому апеляції провалюються

Тому що більшість із них — це емоції:

  • «Ми не могли щось порушити».
  • «Це помилка».
  • «Просимо переглянути».

Платформа не реагує на емоційний крик. Вона реагує на контроль. Коли ми працювали з одним із кейсів, довелося спершу дати можливість клієнту охолонути. Прибрати емоцію. Розкласти ситуацію на частини. Визначити, який саме пункт політики міг спрацювати. Видалити конкретний SDK. Переписати Data Safety. Переробити механіку реклами.

І лише потім — апеляція. Не з аргументом «ви помилилися». А з аргументом «ризик усунуто».

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

І це вдало працювало не один раз.

Чого не варто робити

  • Створювати новий акаунт після бану.
  • Перезаливати ту саму гру з мінімальними змінами.
  • Засипати Google однаковими апеляціями.

Повторюваність — найгірший сигнал для системи. Google може пробачити помилку. А от патерн — рідко.

Про компенсацію і реальність

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

Теоретично шлях існує. Практично — для більшості інді-студій він економічно невиправданий. Платформа грає довгу гру. І розраховує, що ви — ні.

Що робити після бану

Після блокування є два сценарії:

  • Перший — пояснювати всім, що Google несправедливий.
  • Другий — змінити процеси.

Що маю на увазі під зміною процесів:

  • Аудит SDK.
  • Перевірка ліцензій.
  • Окреме тестування реклами.
  • Читання оновлень політик до релізу.

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

Мені цікаво, чи мали ви подібний досвід. Чи був бан, який досі здається абсурдним? Чи спрацювала апеляція? Чи хтось подавав серію counter-notice?

Буде цікаво почути про ваші кейси. Найцінніші уроки — у деталях.

У другій частині поговоримо про те, що залишається за лаштунками: американська юрисдикція, DMA/DSA в ЄС і що робити, коли двері зачинені остаточно.

Бо в екосистемі Google грають ті, хто розуміє правила їхнього покерного столу.

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

👍ПодобаєтьсяСподобалось6
До обраногоВ обраному3
LinkedIn


Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Оці privacy-policy та data safety form дуже чутлива тема, а зараз найкращий чіт це просити ШІ і одне написати і порекомендувати як заповнити. Отак прямо, головне розказати що саме робить ваш додаток з даними:

I am developing a mobile application XYZ it uses own self-written server for API backend and store data in a database. The data store is just email address (and a player nickname if user decide to use it). Please write a n absolute effective, but concise privacy policy to display in app.

А тоді:

what options should I select in Data Safety in google playmarket console to be fully compliant?

Дякую за коментар! ШІ явно може написати акуратний текст policy за хвилину. Але головний ризик саме у розриві між текстом і реальністю. Крім того, згенеровані політики часто не враховують актуальні вимоги Google або зміни в регуляторці.

Наприклад:
— email зберігається, але чи логуються IP?
— чи працює crash-аналітика?
— що реально збирає рекламний SDK?

У Data Safety потрібно декларувати фактичний data flow, а не те, що красиво звучить у policy. І саме на цьому найчастіше виникають проблеми.

Може і написано за допомогою ШІ але все одно цікаво і корисно — я сам стакнувся з реджектом апдейту пет проекта — «The app crashed during testing and couldn’t be evaluated for policy compliance», хоча ніяких крашів не було. Допомогло тільки змінити target age на 18+ (або щось інше допомогло, бо я 9 чи 10 апдейтів зробив, намагаючись пофіксити все що могло би впасти)

Дякую за приклад!

«The app crashed...» насправді не завжди означає реальний краш. Часто це про те, що їхній тестовий сценарій не зміг коректно пройти певний флоу.

Зміна вікової категорії могла змінити набір перевірок. А серія апдейтів частенько просто «перезавантажує» процес модерації.

Приклад демонструє, що проблема часто не в багу, а в тому, як система інтерпретує поведінку додатка.

А розгадка проста: сторам вже не потрібні мільони апп щоб мірятись в кого більше цих мільйонів. Трафік продається, органіки немає, топові паблішери мають пріорітетну лінію підтримки з живими людьми, маленькі девелопери їм не цікаві і отримують атвобани за кожний випадковий скріншот чи СКД котрий раптово застаріває кожні 2 тижні. Якщо ви шукаєте адекватну точку входу для маленького девелопера то зі свого досвіду раджу Стім

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

Мій досвід показує, що і малі девелопери можуть знизити ризики, якщо мислити саме категоріями ризиків.

Steam це хороший варіант для певних жанрів, але ж мобільна аудиторія живе в інших магазинах.

Без ШІ навіть статтю не написати

Дякую за коментар
Останнім часом люди часто бачать ШІ там, де його немає, і навіть є термін для цього — AI over-detection bias. Можливо, структурований текст із чіткою логікою тепер автоматично викликає такі асоціації, проте всі юристи так пишуть ).

Я поділився моїм практичним досвідом, його і пропоную обговорити 🙂

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

Не після суду. Не після доказування. А просто на підставі власної оцінки.

Хоча ця риторична форма валідна, але вона притаманна чату жпт — і тут їх повно

І стандарт тут — не «доведіть вину», а «чи виглядає це безпечним».
Поки розробник думає: «Я нічого не порушив», система думає: «Чи повториться це завтра?»

Це інша риторична форма чата жп

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

Ще одна форма

...

Юристи (особливо судові) працюють із риторикою так само, як розробники з кодом. Це інструмент. У блозі мій практичний досвід. Якщо маєте інший досвід, то пропоную ним поділитися.

Два однакові коментарі підряд, тепер уже можна підозрювати ботів

Підписатись на коментарі