Як підтримувати відповідність вимогам у десяти застосунках
Що справді має бути окремим для кожного застосунку, що можна спільно використовувати, дві помилки портфоліо і реєстр, який перетворює щорічну паніку на пів дня роботи.
Обсяг роботи не масштабується лінійно — кожному застосунку потрібні власні URL, власний шлях видалення облікового запису й власні декларації, бо в кожного своя сторінка в магазині. Масштабується метод: один шаблон імен хостів, один шаблон для кожного типу сторінки і перелік залежностей для кожного застосунку, який ви генеруєте заново, а не тримаєте в пам’яті.
Зробіть це за кілька хвилин
AppFoyer розміщує сторінки, про які цей посібник, — політику конфіденційності, умови, підтримку, видалення акаунта та app-ads.txt — на власному піддомені, без вашого домену й сервера. Один застосунок — безкоштовно, і ніщо з того, чого вимагає магазин, ніколи не буває за платним доступом.
Перевірено 19 вересня 2026 р.. Політики магазинів змінюються, іноді без попередження. Усе нижче посилається на офіційну документацію, і авторитетом є та сторінка, а не ця. Якщо вони розходяться, правий магазин. Цей посібник перекладено з англійської; цитати з документації магазинів наведено в англійському оригіналі.
Один застосунок — це чекліст. Десять застосунків — це система, і характер збоїв змінюється: нічого не є складним, але щось завжди трохи застаріло, і ви дізнаєтеся про це з відхилення застосунку, до якого найдовше не торкалися.
Що має бути окремим для кожного застосунку
Це не обговорюється, бо в кожного застосунку своя сторінка в магазині і своя поведінка щодо даних:
- Політика конфіденційності. Різні набори SDK означають різні розкриття інформації. Спільна політика, що охоплює «наші застосунки», — класична помилка портфоліо, див. нижче.
- Сторінка видалення облікового запису і шлях, яким запит доходить до вас, — для кожного застосунку.
- Декларації Data safety та App Privacy. Заповнюються для кожної сторінки в магазині, на основі переліку залежностей саме цього застосунку.
app-ads.txt, якщо застосунок показує рекламу, — його шукають через вебсайт, вказаний на сторінці саме цього застосунку.- Самі URL, бо кожна сторінка в магазині має власні поля.
Що справді можна використовувати спільно
- Шаблон. Одна структура для кожної політики конфіденційності, одна для умов, заповнені для кожного застосунку окремо.
- Шаблон імен хостів. Передбачувана адреса для кожного застосунку краща за теку розрізнених URL, створених нашвидкуруч.
- Адресу підтримки, якщо одна скринька справді обслуговує всі застосунки.
- Ваші знання про SDK. Що збирає Crashlytics чи AdMob — той самий факт у кожному застосунку; відрізняється лише те, які застосунки їх містять.
- Процес — чекліст релізу, ритм перевірок, реєстр, описаний нижче.
Дві помилки портфоліо
Одна політика для всіх застосунків. Це очевидна економія, і вона не спрацьовує в обидва боки: політика перелічує дані, яких тихий застосунок-утиліта ніколи не торкається, і пропускає щось, що наймолодший застосунок додав минулого місяця. І те, і інше — розбіжності з формою Data safety, яку ви заповнили чесно, і рецензент, який їх порівнює, бачить політику, що не стосується цього застосунку.
Спільна скринька для запитів на видалення, де ніхто не визначає застосунок. Надходять запити «будь ласка, видаліть мій обліковий запис» без жодної вказівки, який із ваших десяти застосунків мається на увазі. Ви не можете виконати те, чого не можете ідентифікувати, а годинник GDPR іде, поки ви з’ясовуєте. Спрямовуйте запити кожного застосунку так, щоб застосунок був очевидний зі сповіщення.
Реєстр
Портфоліо стає керованим завдяки одній таблиці, яку ви справді підтримуєте, — електронна таблиця цілком підійде. Один рядок на застосунок і такі стовпці:
| Стовпець | Навіщо |
|---|---|
| Назва застосунку, bundle id / application id | Ідентифікація |
| Магазини, де він опублікований | Визначає, скільки консолей оновлювати |
| URL політики конфіденційності | Той, який ви вставляєте знову і знову |
| URL видалення облікового запису | Так само |
| Адреса / сторінка підтримки | Так само |
| Заявлений вебсайт розробника | Де шукають app-ads.txt |
| Показує рекламу? | Чи стосується його app-ads.txt взагалі |
| Має облікові записи? | Чи стосується його видалення взагалі |
| Ключові SDK | Перелік залежностей, коротко |
| Остання перевірка політики | Дата, яка підказує, що застаріло |
Останній стовпець недарма тут. Обидва магазини вимагають, щоб декларації залишалися точними, — а не просто були точними на момент запуску, — і «остання перевірка» дає змогу знайти три застосунки, що розійшлися з реальністю, не перечитуючи всі десять.
Ритм, який працює
- На кожен реліз, для кожного застосунку: чи змінилася якась залежність? Якщо так, перевірте заново політику цього застосунку й обидві форми даних. Внесіть це в чекліст релізу, а не тримайте в пам’яті.
- Щокварталу, для всього портфоліо: відкрийте реєстр, відсортуйте за «остання перевірка», перевірте кілька найстаріших. Переконайтеся, що кожен URL досі повертає 200 без входу в обліковий запис.
- Щоразу, коли URL переїжджає: оновіть кожну консоль для кожного застосунку, якого це стосується, і залиште на старій адресі переспрямування. З десятьма застосунками саме цю зміну найімовірніше буде зроблено на дев’ять десятих.
Скрипт на десять рядків, який робить curl на кожен URL із реєстру й повідомляє про відповіді, відмінні від 200, — це пів дня роботи, і він виявляє той збій, який справді трапляється: хостинг, що тихо зник.
Що тут робить AppFoyer
Кожен застосунок — окремий застосунок: власний піддомен, власні п’ять сторінок, власний
app-ads.txt, власні канали сповіщень, власний чекліст. Немає спільної політики, у якій можна
помилитися, і запити на видалення кожного застосунку надходять із зазначенням застосунку.
Чекліст у панелі керування — це «жива» половина реєстру: для кожного застосунку він показує, яке поле в магазині досі порожнє і чому це важливо, тож «що застаріло» — це екран, а не стовпець електронної таблиці, який ви забули оновити. Тарифи відрізняються тим, скільки застосунків можна опублікувати: один на Free, десять на Pro, п’ятдесят на Advanced.
Чесно про обмеження: масового редагування і груп застосунків поки немає. Додати рядок рекламної мережі до п’ятнадцяти застосунків сьогодні — це п’ятнадцять редагувань. Цю роботу заплановано, але вона не випущена, а сторінка, що продає вам інструмент для портфоліо, має казати, що з цього вже реальне.
Першоджерела
- Provide information for Google Play’s Data safety section — довідка Google Play Console, про підтримання декларацій точними
- App privacy details on the App Store — Apple, про підтримання відповідей актуальними
- Set up app-ads.txt — довідка AdMob