Посібники Форми магазинів і SDK
Як заповнити форму Data safety у Google Play і відомості App Privacy в Apple
Що запитує кожна анкета, як ваші SDK змінюють відповіді, три запитання, на які часто відповідають неправильно, і де кожен постачальник публікує потрібні вам відповіді.
Складіть список усіх SDK у збірці, відкрийте власну сторінку розкриття інформації або маніфест конфіденційності кожного постачальника і додайте власний збір даних, наприклад облікові записи. Потім відповідайте на обидві анкети за цим одним списком. Play запитує, що збирається, що передається і навіщо. Apple запитує те саме, а також чи пов’язаний кожен тип даних із користувачем і чи використовується для відстеження.
Зробіть це за кілька хвилин
AppFoyer розміщує сторінки, про які цей посібник, — політику конфіденційності, умови, підтримку, видалення акаунта та app-ads.txt — на власному піддомені, без вашого домену й сервера. Один застосунок — безкоштовно, і ніщо з того, чого вимагає магазин, ніколи не буває за платним доступом.
Перевірено 25 вересня 2026 р.. Політики магазинів змінюються, іноді без попередження. Усе нижче посилається на офіційну документацію, і авторитетом є та сторінка, а не ця. Якщо вони розходяться, правий магазин. Цей посібник перекладено з англійської; цитати з документації магазинів наведено в англійському оригіналі.
Складіть один список того, що ваш застосунок надсилає за межі пристрою, разом із SDK, і відповідайте за ним на обидві анкети. Форма Data safety у Google Play і відомості App Privacy в Apple запитують про ті самі факти різними словами. Коли ваші відповіді походять із двох окремих спогадів, вони розходяться.
Кожен застосунок у Google Play має заповнити форму Data safety, навіть застосунок, який нічого не збирає. Звільнені лише застосунки, опубліковані тільки на доріжках внутрішнього тестування (довідка Google Play про Data safety). Apple вимагає відомостей App Privacy для кожного застосунку в App Store (відомості App Privacy від Apple).
Де ці форми
- Google Play: Play Console → ваш застосунок → App content → Data safety.
- App Store: App Store Connect → ваш застосунок → App Privacy.
Крок 1: складіть список
- Кожен сторонній SDK. Прочитайте файли залежностей:
build.gradle/libs.versions.toml,Podfile/Package.swift,pubspec.yaml,package.json. Обидва магазини вважають те, що збирає SDK, вашим. Apple покладає на вас відповідальність за весь код у застосунку, зокрема код, який ви не писали. - Що надсилає кожен із них. Користуйтеся власною сторінкою постачальника. Деякі постачальники
публікують свої відповіді у термінах самого Play, зокрема RevenueCat, Unity Ads і OneSignal.
Google публікує таблиці для AdMob і для кожного продукту Firebase. На iOS більшість сучасних SDK
постачаються з маніфестом конфіденційності (
PrivacyInfo.xcprivacy). У Xcode відкрийте Organizer, клацніть архів правою кнопкою і виберіть Generate Privacy Report, щоб побачити всі маніфести вашої збірки на одній сторінці (документація Apple про маніфести конфіденційності). - Ваш власний збір даних. Облікові записи (електронна пошта, ідентифікатор користувача), усе, що зберігає ваш бекенд, геолокація, яку читає ваш власний код, записи про покупки, які зберігає ваш сервер.
Деякі постачальники не публікують нічого. AppLovin не має списку типів даних для жодного з магазинів, а кілька SDK аналітики не мають відповідності для Play. Для них прочитайте власну документацію SDK про те, що він передає, і запишіть прогалину. Не вгадуйте.
Крок 2: запитання Google Play
Для кожного типу даних Play запитує:
- Collected, shared чи обидва? «Collected» (зібрано) означає надіслано за межі пристрою. «Shared» (передано) означає надіслано третій стороні. Постачальник послуг, який обробляє дані від вашого імені, не вважається передаванням, так само як і повністю анонімізовані дані. Саме тому Firebase Analytics зазвичай «collected, not shared», а рекламний SDK зазвичай «collected and shared».
- Processed ephemerally (обробляється тимчасово)? Лише якщо дані зберігаються в пам’яті рівно стільки, скільки потрібно, щоб обслужити цей один запит, — наприклад, геолокація, надіслана, щоб отримати погоду, і не збережена.
- Required чи optional (обов’язково чи необов’язково)? Необов’язково означає, що користувач може вибрати, чи збиратимуться ці дані.
- Навіщо? Цілі в Play такі: App functionality, Analytics, Developer communications, Advertising or marketing, Fraud prevention, security, and compliance, Personalization, Account management. Для збору і для передавання цілі вказуються окремо.
Далі два запитання про безпеку. Чи всі дані користувачів шифруються під час передавання?
Перевірити це можете лише ви. Одна звичайна кінцева точка http:// робить відповідь «Ні». Чи
можуть користувачі попросити про видалення? Можна відповісти «Так», якщо ви пропонуєте спосіб
попросити про це або якщо видаляєте дані автоматично протягом 90 днів.
Якщо ваш застосунок дає змогу створювати облікові записи, запитання Data deletion у тій самій формі також просять вебпосилання, за яким користувачі можуть попросити видалити обліковий запис (вимоги Google Play щодо видалення облікових записів). Дивіться посібник про URL-адресу для видалення облікового запису.
Платіжні дані, введені у власному платіжному вікні Google Play, не потрібно декларувати, доки ваш застосунок не має до них доступу. Записи про покупки, які отримує ваш застосунок або SDK, однаково декларуєте ви.
Крок 3: запитання Apple
Для кожного типу даних Apple запитує мету і два запитання «так/ні»:
- Linked to the user (пов’язано з користувачем)? Дані вважаються пов’язаними, якщо їх не знеособили до збору. Облікового запису, ідентифікатора користувача чи ідентифікатора пристрою достатньо, щоб їх пов’язати.
- Used for tracking (використовується для відстеження)? Відстеження означає поєднання даних вашого застосунку про користувача чи пристрій із даними інших компаній для таргетованої реклами або вимірювання реклами, або їх передавання брокерові даних. SDK може робити це, навіть якщо ви ніколи не користуєтеся цією функцією. Якщо щось використовується для відстеження, застосунок має спершу попросити дозвіл через App Tracking Transparency (конфіденційність користувачів і використання даних від Apple).
Цілі в Apple такі: Third-Party Advertising, Developer’s Advertising or Marketing, Analytics, Product Personalization, App Functionality, Other Purposes.
Apple дозволяє не вказувати тип даних лише тоді, коли виконуються всі чотири умови. Дані не мають використовуватися для відстеження чи реклами. Їх мають збирати лише зрідка, поза основною функцією застосунку і за вибором користувача. І користувач має щоразу надавати їх свідомо. Більшість даних SDK не проходить уже першу умову.
Три відповіді, які часто дають неправильно
- «Ми нічого не збираємо». Збирачі звітів про збої та аналітика надсилають ідентифікатори пристрою і діагностику, навіть коли ваш власний код нічого не надсилає.
- «Not shared» для рекламного SDK. Рекламні мережі отримують ідентифікатори і взаємодії для власних рекламних цілей. Це передавання.
- Форма, яка розходиться з політикою конфіденційності. Магазини читають їх разом, тож розбіжності самої по собі достатньо. Пишіть обидві за одним списком. Дивіться коли ці два документи розходяться.
Як підтримувати актуальність
Відповіді актуальні рівно настільки, наскільки актуальний ваш список SDK. Коли ви додаєте SDK, оновіть обидві форми і політику конфіденційності в тій самій зміні. Постачальники теж переглядають свої розкриття з новими версіями SDK.
Нехай AI-асистент знайде SDK
Повільна частина — крок 1, і агент для програмування, відкритий у репозиторії вашого застосунку, може зробити її за вас: Claude Code, Cursor, Codex тощо. Промпт нижче просить його прочитати лише файли збірки і назвати кожен SDK і кожен факт про дані разом із файлом, звідки він узятий. Він не запитує, що збирає кожен SDK. Те, що модель пам’ятає про розкриття постачальника, — це здогадка, і ця частина має надходити від постачальника.
Він відповідає в невеликому JSON-форматі, який читає дашборд AppFoyer. Без AppFoyer список, який він покаже вам у step 2, однаково той, за яким слід заповнювати обидві форми.
You are helping me fill in Google Play's Data safety form and Apple's App Privacy details for my mobile app. AppFoyer turns your answer into draft answers for both forms, using each SDK vendor's own published disclosure. Your job is only to find what is in the build — not to say what any SDK collects.
## About the app
- App name: [app name]
- Platforms: [Android, iOS or both]
## Step 1 — read the build files
Read only the app's build, manifest and store-metadata files — for example `build.gradle(.kts)`, `gradle/libs.versions.toml`, `AndroidManifest.xml`, `Podfile.lock`, `Package.swift`, `Package.resolved`, `Info.plist`, `*.entitlements`, `PrivacyInfo.xcprivacy`, `pubspec.yaml`, `package.json`, `app.json`. Do not open `.env` files, keystores, credentials or any other secrets, and do not change any file. If you cannot read the code, ask me which SDKs the app uses instead.
Find:
1. Every third-party SDK in the build. Match it to one of these ids where it fits:
- `admob` — Google Mobile Ads (AdMob)
- `applovin-max` — AppLovin MAX
- `unity-ads` — Unity Ads
- `firebase-analytics` — Google Analytics for Firebase
- `mixpanel` — Mixpanel
- `amplitude` — Amplitude
- `meta-app-events` — Meta SDK — App Events
- `firebase-crashlytics` — Firebase Crashlytics
- `sentry` — Sentry
- `firebase-auth` — Firebase Authentication
- `google-sign-in` — Google Sign-In
- `meta-login` — Meta SDK — Facebook Login
- `revenuecat` — RevenueCat
- `firebase-messaging` — Firebase Cloud Messaging
- `onesignal` — OneSignal
An SDK that fits none of them goes under `otherSdks` with its package name. Never force a match.
2. Which of these facts are true, from the dependencies, permissions and usage-description keys:
- `account` — users sign in or create accounts
- `analytics` — usage analytics
- `ads` — advertising
- `crash` — crash reporting or diagnostics
- `location` — the app reads the device location
- `purchases` — in-app purchases or subscriptions
If none is true, the facts are `["none"]`.
Keep the file, and the line where you can, for every SDK and every fact. A README sentence is not evidence.
## Step 2 — confirm with me
Show me the list, grouped as SDKs, other SDKs and facts, each with its file. Ask me to confirm or correct it, and to add anything the build files cannot show — for example an SDK loaded at runtime. Wait for my answer.
## Step 3 — reply in AppFoyer's format
Reply with one ```json code block and nothing after it, exactly in this shape:
```json
{
"format": "appfoyer-store-forms/1",
"platform": "android | ios | both",
"sdks": [{ "id": "admob", "file": "app/build.gradle.kts", "line": 42 }],
"otherSdks": [{ "name": "com.example:tracker", "file": "app/build.gradle.kts", "line": 57 }],
"facts": [{ "fact": "ads", "file": "app/src/main/AndroidManifest.xml", "line": 12 }]
}
```
- `id` is one of the ids above, spelled exactly. `fact` is one of the facts above, or `none`.
- `line` is a number, or leave it out when you do not know it.
- Empty lists are `[]`. No comments inside the JSON.
- Do not describe what an SDK collects, and do not add fields.
З AppFoyer
Кожен застосунок у дашборді має вкладку Store forms. Позначте SDK, які є у вашій збірці, і вона підготує чернетки відповідей для Data safety і App Privacy на їх основі та на основі налаштувань вашого застосунку. Кожна відповідь називає своє джерело: власні відповіді постачальника, його маніфест конфіденційності або наше прочитання його списку даних. Вкладка позначає SDK, якого не згадує ваша політика конфіденційності, і дає посилання для видалення облікового запису, яке треба вставити. Плагін Claude Code заповнює список SDK з ваших файлів збірки. З іншим асистентом скопіюйте промпт із вкладки, запустіть його і вставте відповідь назад: вкладка покаже відповіді, які з неї випливають, перш ніж щось буде збережено. Вводити відповіді в кожній консолі і перевіряти їх там однаково вам. Це чернетки, а не юридична порада. Вкладка безкоштовна на будь-якому тарифі.