Усі URL, які потрібні до подання застосунку
Повний список для Play Console, App Store Connect і AdMob: які з них обов'язкові, а які необов'язкові, що має містити кожна сторінка і в якому порядку все робити.
Більшості застосунків потрібні чотири публічні URL: політика конфіденційності, сторінка видалення облікового запису, якщо в застосунку є облікові записи, сторінка підтримки для App Store і вебсайт розробника, якщо застосунок показує рекламу. Кожен із них — окреме поле в консолі, кожен перевіряють, і всі вони мають працювати ще довго після схвалення застосунку.
Зробіть це за кілька хвилин
AppFoyer розміщує сторінки, про які цей посібник, — політику конфіденційності, умови, підтримку, видалення акаунта та app-ads.txt — на власному піддомені, без вашого домену й сервера. Один застосунок — безкоштовно, і ніщо з того, чого вимагає магазин, ніколи не буває за платним доступом.
Перевірено 19 вересня 2026 р.. Політики магазинів змінюються, іноді без попередження. Усе нижче посилається на офіційну документацію, і авторитетом є та сторінка, а не ця. Якщо вони розходяться, правий магазин. Цей посібник перекладено з англійської; цитати з документації магазинів наведено в англійському оригіналі.
Це список, якого вам ніхто не дає перед першим поданням, тож ви з’ясовуєте його по одній відмові за раз. Зберіть усе це, перш ніж відкривати консоль, і вся справа займе пів дня замість трьох циклів перевірки.
Поля за консолями
| URL | Консоль і поле | Обов’язковий? |
|---|---|---|
| Політика конфіденційності | Play Console → App content → Privacy policy; App Store Connect → App Privacy | Так, в обох магазинах |
| Видалення облікового запису | Play Console → App content → Data deletion | Так, якщо в застосунку є облікові записи |
| Підтримка | App Store Connect → Platform version information версії → Support URL | Так, Apple |
| Вебсайт розробника | Сторінка застосунку в Play (store listing); Marketing URL в App Store Connect | Play: необов’язковий, але на практиці обов’язковий, якщо ви показуєте рекламу, — саме там шукають app-ads.txt. Marketing URL в Apple справді необов’язковий |
| Контактна електронна пошта | Play Console → Store settings → Store listing contact details | Так, Play вимагає електронну пошту для публікації |
Apple також вимагає видалення облікового запису, але як шлях у застосунку, а не як поле з URL, — див. посібник щодо видалення облікового запису в App Store.
Що має містити кожна сторінка
Політика конфіденційності. Що збирається, навіщо, хто ще це бачить, як довго зберігається, як із вами зв’язатися. Розділ, через який вам відмовляють, — “хто ще це бачить”: у ньому мають бути названі сторонні сервіси, тобто кожен SDK у вашій збірці, і він має збігатися з вашими відповідями в Data safety.
Видалення облікового запису. Публічна сторінка, доступна без входу в обліковий запис і без встановленого застосунку, де користувач може попросити вас видалити його обліковий запис. Вона має справді доставляти запит вам — сторінка, яка показує форму й відкидає результат, гірша, ніж відсутність сторінки, бо користувач вірить, що все спрацювало.
Підтримка. Шлях до живої людини. Достатньо адреси електронної пошти, яку ви читаєте. Не ваша маркетингова сторінка, не сторінка в App Store, не профіль у соцмережі.
Вебсайт розробника. Сторінка про ваш застосунок на хості, який ви контролюєте, — і саме з кореня
цього хоста рекламна мережа завантажуватиме /app-ads.txt.
Чотири перевірки, які має пройти кожна з них
Ті самі чотири щоразу, тому їх варто робити пакетом:
- Вона відкривається без входу в обліковий запис. Відкрийте її в приватному вікні. Класична помилка — сторінка, яка працює лише тому, що ви увійшли в сервіс, який її хостить.
- Це не ланцюжок перенаправлень. Особливо для
app-ads.txt, який має віддаватися напряму. - Вона називає ваш застосунок і вашу компанію. Політика, у якій названо інший застосунок, — явна ознака копіювання, і рецензенти це помічають.
- Вона буде на місці й через два роки. Сторінку застосунку в магазині перевіряють не один раз, а забутий безкоштовний хостинг — найпоширеніша причина, чому ламається живий застосунок.
curl -i https://your-url.example/privacy
200 OK, читабельний вміст, жодного заголовка Location:.
У якому порядку це робити
- Вирішіть, де житимуть усі вони, один раз. Розкидавши їх між сторінкою в Notion, сайтом на GitHub Pages і сервісом форм, ви отримаєте три речі для підтримки, одна з яких зламається.
- Пишіть політику конфіденційності на основі списку залежностей, а не шаблону. Відкрийте
build.gradle/Podfile/pubspec.yamlі пройдіться ним згори донизу. - Побудуйте шлях видалення облікового запису — і в застосунку, і вебверсію. Це єдиний пункт зі справжньою інженерною роботою, тож саме він визначає ваші терміни.
- Спершу опублікуйте, потім заповнюйте поля в консолі. Не навпаки: поле, яке вказує на сторінку, якої ще не існує, — саме та відмова, якої ви намагаєтеся уникнути.
- Заповнюйте Data safety / App Privacy з того самого списку, з якого писали політику, щоб вони не могли розійтися.
app-ads.txt— наостанок, і лише якщо ви показуєте рекламу.
Що тут робить AppFoyer
Цей список і є продуктом. Усі п’ять сторінок — головна, конфіденційність, умови, підтримка, видалення
облікового запису — плюс app-ads.txt з’являються разом на власному піддомені вашого застосунку, тож ви
вставляєте робочі URL у кожне поле за один прохід. Сторінка видалення облікового запису приймає запит і
повідомляє вас; видалення ви виконуєте у власних системах.
У дашборді також є чекліст, який показує, яке поле в консолі ще порожнє і чому це важливо. Один застосунок — безкоштовно, і ніщо, чого вимагає магазин, ніколи не буде за пейволом.
Офіційні джерела
- Вимоги до політики конфіденційності — Довідка Google Play
- Вимоги Google Play щодо видалення облікових записів у застосунках — Довідка Google Play
- Required, localizable, and editable properties (обов’язкові, локалізовані та редаговані властивості) — Apple. Саме ця таблиця вказує, що Support URL і Privacy Policy URL обов’язкові, а Marketing URL — ні.
- Налаштування app-ads.txt — Довідка AdMob