Мітки конфіденційності App Store: спершу перевірте SDK аналітики (чекліст 2026)

Ваші мітки конфіденційності App Store мають охоплювати те, що збирають SDK аналітики та інші сторонні SDK, а не лише те, що надсилає ваш власний код. Перш ніж відповідати на питання App Privacy в App Store Connect, складіть список усіх SDK у релізі, зафіксуйте дані, які кожен із них надсилає за межі пристрою, і визначте, чи щось із цього використовується для трекінгу. Відповідайте за цим списком, а не з пам'яті.

Чи мають мітки конфіденційності App Store враховувати дані сторонніх SDK?

Так. Apple вимагає декларувати дані, які збирає код сторонніх партнерів, навіть якщо SDK збирає ці дані не для аналітики чи реклами.

На сторінці App Privacy Apple визначає сторонніх партнерів як «інструменти аналітики, рекламні мережі, сторонні SDK або інших зовнішніх постачальників, чий код ви додали до свого застосунку». Тож засіб звітування про збої чи бібліотека входу теж мають бути у вашому списку. Критерій збору стосується передавання: «збирати» означає «передавати дані за межі пристрою так, що ви та/або ваші сторонні партнери можете отримати до них доступ протягом періоду, довшого, ніж потрібно для обслуговування переданого запиту в реальному часі». Дані, що обробляються лише на пристрої, не вважаються зібраними.

Як скласти інвентаризацію SDK для міток конфіденційності?

Складайте інвентаризацію на основі розв'язаних залежностей релізної збірки, включно з транзитивними, і записуйте назву та версію кожного SDK.

1. Експортуйте список розв'язаних залежностей для кожної платформи: Podfile.lock, Package.resolved, pubspec.lock або дерево залежностей Gradle.
2. Не відкидайте транзитивні залежності. У вимогах до сторонніх SDK Apple зазначено, що ви «відповідаєте за весь код, який SDK додає до вашого застосунку», тож спільний модуль, який підтягує SDK, теж враховується.
3. Записуйте назву та версію кожного елемента. Постачальники змінюють способи обробки даних між версіями, тому версія має бути у ваших нотатках аудиту.
4. Позначте SDK, які є в списку Apple поширених сторонніх SDK. Для них Apple вимагає маніфести конфіденційності, коли ви надсилаєте новий застосунок або оновлення, яке їх додає, а також підписи, якщо це бінарні залежності. «Враховуються будь-які версії SDK зі списку, а також будь-які SDK, що перепаковують SDK зі списку».

Додайте цей крок до свого чекліста подання в App Store, щоб він виконувався для кожного релізу, а не лише для першого.

Яким типам даних App Store відповідає кожен SDK?

Кожен SDK відповідає одному чи кільком фіксованим типам даних Apple, як-от Crash Data (дані про збої), Performance Data (дані продуктивності), Product Interaction (взаємодія з продуктом), Device ID (ідентифікатор пристрою) та Advertising Data (рекламні дані). Прочитайте документацію постачальника щодо даних і заповніть рядок для кожного SDK:

Apple зазначає, що зібрані дані «часто пов'язані з особою користувача, якщо до збору не вжито спеціальних заходів захисту конфіденційності для деідентифікації чи анонімізації», як-от видалення прямих ідентифікаторів на кшталт ID користувача чи імені. Після збору ви також не повинні знову пов'язувати дані з користувачем або з іншими наборами даних, що його ідентифікують. Якщо ви не можете підтвердити, що SDK деідентифікує дані, позначайте їх як пов'язані з користувачем.

Коли SDK аналітики вважається трекінгом?

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

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

Пастка — партнер, який не є рекламним SDK. Приклад Apple — «SDK для входу, який повторно використовує дані, зібрані у вашому застосунку, для таргетованої реклами в застосунках інших розробників»; це вважається трекінгом, навіть якщо ви не використовуєте SDK з цією метою. Якщо один із ваших SDK так робить, зазвичай рішенням є зміна конфігурації, що припиняє використання даних між застосунками, або інший постачальник.

Чи можна не вказувати в мітках конфіденційності якісь дані SDK?

Лише якщо тип даних відповідає всім чотирьом критеріям Apple для необов'язкового розкриття, а дані аналітики та збоїв майже ніколи їм не відповідають. Критерії такі:

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

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

Як виглядає завершений аудит SDK?

У завершеному аудиті кожному SDK відповідає один рядок, де вказано, що декларувати, чи пов'язані дані з користувачем і чи використовуються вони для трекінгу. Ось шаблон для гіпотетичного застосунку для відстеження звичок із трьома SDK. Відповіді залежать від документації кожного постачальника, тож це не висновки щодо реальних продуктів.

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

Що пішло не так в інших розробників?

Публічно описані випадки показують три точки збою: мітки, які не відповідають бінарному файлу, дані SDK, про які розробник не знав, і SDK зі списку, випущені без маніфестів.

• Розробник на Apple Developer Forums прибрав трекінг із нової збірки, але не зміг прибрати його з мітки. App Store Connect повідомляв: «Ваш застосунок містить NSUserTrackingUsageDescription, що вказує на те, що ви запитуватимете дозвіл на трекінг користувачів», а перевірка раз у раз відхиляла застосунок із формулюванням: «Інформація про конфіденційність застосунку, яку ви надали в App Store Connect, вказує, що ви збираєте дані для трекінгу користувача… Однак ви не використовуєте App Tracking Transparency». За словами розробника, застосунок схвалили після того, як він подав апеляцію й дочекався відповіді, перш ніж надсилати повторно.
• Інший розробник на Apple Developer Forums використовував Firebase Analytics із вимкненим збором IDFA та IDFV і міткою «без трекінгу», але все одно отримав відмову за Guideline 5.1.2. У повідомленні сказано: «Збір файлів cookie є формою трекінгу». Ідеться про cookie у вебвмісті, який завантажував застосунок, а не про Firebase. В одній із відповідей вказали на цю невідповідність, але рішення так і не опублікували.
• Розробники в issue на GitHub RxSwift отримали «ITMS-91061: Missing privacy manifest» для RxSwift, RxRelay та RxCocoa. Один користувач налаштував CocoaPods на гілку 6.8.0, яка містить маніфест, і повідомив, що випустив наступне оновлення «без жодних попереджень від Apple».

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

Як опублікувати й оновити мітки конфіденційності в App Store Connect?

Публікуйте мітки конфіденційності в розділі App Privacy вашого застосунку в App Store Connect. Відповіді стають чинними лише після натискання Publish, і, за словами Apple, їх можна змінити будь-коли без надсилання оновлення застосунку.

1. В App Store Connect виберіть застосунок, натисніть App Privacy на бічній панелі, а потім Get Started.
2. Вкажіть, чи збираєте дані ви або ваші сторонні партнери, виберіть усі типи даних зі свого аудиту й натисніть Save.
3. Дайте відповіді на додаткові питання для кожного типу даних, натисніть Save і перегляньте Product Page Preview.
4. Натисніть Publish у правому верхньому куті й підтвердьте діалог про точність даних.

Згідно з Manage app privacy, вам потрібна роль Account Holder, Admin або App Manager. Якщо сторінка продукту ще не опублікована, ваші відповіді з'являться, коли вона стане доступною. Якщо застосунок уже продається, відповіді мають відображати лише дані, які збирає ця версія. Зміни URL політики конфіденційності «виходять разом із наступною версією застосунку». Якщо перевірка вже виявила проблеми з конфіденційністю, почніть із посібника з виправлення відмов App Store.