Privacy Nutrition Label в iOS: същност, етикети за поверителност и данни в App Store

Какво е Privacy Nutrition Label?

Privacy Nutrition Label е визуален блок на страницата на приложението в App Store, който показва обобщение на събирането на данни. Apple представи етикетите през декември 2020 г. като аналог на хранителната стойност върху продуктите: вместо калории и мазнини, потребителят вижда какви данни събира приложението и как се използват.

Етикетите се състоят от две секции: „Данни, използвани за проследяване" и „Данни, свързани с потребителя". В първата се посочват данни, предавани на трети страни за проследяване. Във втората — всички данни, които приложението събира и свързва с акаунта или устройството на потребителя.

Всеки елемент от данни се маркира с цвят: жълт (данните са свързани с потребителя) или зелен (данните не са свързани с потребителя). Колкото повече жълти етикети, толкова повече внимание отделя потребителят на това какви данни се събират. Според данни на Adjust (2024), приложенията с 8+ жълти етикета имат 22% по-малко реализации на инсталации.

Попълването на етикети става в App Store Connect чрез уеб интерфейс. Разработчикът отговаря на въпроси: дали приложението събира определен тип данни, дали е свързано с потребителя и за какви цели се използва. Apple не проверява програмно истинността на етикетите, но несъответствието на декларацията с реалното поведение може да доведе до отхвърляне.

История на появата на Privacy Nutrition Label

Apple обяви етикетите на WWDC 2020 заедно с iOS 14. Първоначално те бяха част от по-широка инициатива за поверителност, включваща ATT и Privacy Manife. Попълването на етикети стана задължително за всички приложения и актуализации от 8 декември 2020 г.

Етикетите бяха отговорът на Apple на нарастващото внимание на регулаторите и потребителите към събирането на данни. За разлика от GDPR и CCPA, които изискват формално съгласие, Apple постави акцент върху прозрачността: потребителят веднага вижда какви данни се събират, още преди инсталирането на приложението.

През 2022 г. Apple добави интерактивност към етикетите: потребителят може да кликне върху всяка категория и да види за какви цели се използват данните. През 2024 г. Apple започна да изисква етикетите да съответстват на данните, декларирани в Privacy Manife вътре в двоичния файл.

Разлика от Android Data Safety

Google въведе подобен раздел „Безопасност на данните" (Data Safety) в Google Play през април 2022 г. Основната разлика: Google проверява етикетите чрез автоматично сканиране на код и може да поиска потвърждение от разработчика, докато Apple разчита на декларацията на разработчика с проверка при преглед.

Освен това Google Play изисква посочване на мерки за сигурност (криптиране на данни в покой и при пренос, съответствие с програми за сигурност). Apple не изисква тази информация, но проверява изпълнението на изискванията чрез задължителни функции като ATS (App Transport Security).

Как Apple събира данни за етикети

Apple не анализира кода на приложението за попълване на етикети — разработчикът самостоятелно декларира събираните данни. Въпреки това през 2024 г. Apple започна да сравнява етикетите с Privacy Manife вътре в двоичния файл, което прави процеса по-формализиран.

Процес на попълване в App Store Connect

Разработчикът влиза в App Store Connect → избира приложението → раздел „Поверителност на приложението" → „Етикети за поверителност". Отваря се въпросник с въпроси за всяка от 14-те категории данни. За всяка категория трябва да посочите: дали събирате този тип данни, дали е свързан с потребителя (linked) и за какви цели.

Целите на събиране включват: реклама на трети страни, аналитика на разработчика, разработка на продукт (Product Personalization), персонализиране на съдържание, изпълнение на функции на приложението (App Functionality). Една категория данни може да се използва за множество цели. Важно: ако данните се предават на трети страни, това трябва да бъде отбелязано като проследяване.

След запазване на промените, Apple генерира нова версия на етикетите, която се показва в App Store в рамките на 24 часа. При изпращане на нова компилация, етикетите се проверяват автоматично: ако не са попълнени, бутонът за изпращане се блокира. Apple Developer (2024) препоръчва актуализиране на етикетите при всяка промяна в логиката на събиране на данни.

Разлика между self-reporting и автоматична проверка

До 2024 г. етикетите бяха напълно self-reported — Apple вярваше на отговорите на разработчика. С появата на Privacy Manife и интегрирането на етикетите с манифеста, Apple започна автоматично сравнение. Например, ако манифестът декларира събиране на идентификатори (IDFA) за реклама, но етикетите не отбелязват тази категория, App Store Connect показва предупреждение.

Пълна автоматична проверка обаче все още не съществува. Разработчикът е длъжен да поддържа и двата източника на данни (етикети + манифест) в актуално състояние. Несъответствието може да бъде открито при ръчна проверка от рецензент, особено за големи актуализации или приложения с голямо количество данни.

Видове данни в Privacy Nutrition Label

Apple разделя данните на 14 категории, групирани в 3 раздела: данни, използвани за проследяване; данни, свързани с потребителя; данни, несвързани с потребителя. Нека разгледаме основните категории.

Контактна информация и идентификатори

Категорията „Контактна информация" включва име, имейл, телефон, физически адрес. Категорията „Идентификатори" — IDFA, User ID, потребителско име. Ако приложението използва вход чрез социални мрежи и получава имейла на потребителя, трябва да посочите тази категория с цел „Изпълнение на функции".

Категорията „Платежни данни" включва информация за покупки: номер на карта (ако не се използва Apple Pay), история на покупките. Apple Pay не изисква посочване на тази категория, тъй като Apple обработва плащанията от своя страна и не предава данни на разработчика.

Данни за използване и диагностика

Категорията „Данни за използване" включва журнали на взаимодействие, кликвания върху реклами, прегледи на страници, време на сесия. Повечето приложения събират тези данни за аналитика. Важно: ако данните се предават на трети страни (Google Analytics, Firebase), трябва да се отбележи цел „Аналитика".

Категорията „Диагностика" включва crash журнали, данни за производителност, отчети за стартиране. Тези данни обикновено не са свързани с потребителя (not linked) и се събират в агрегиран вид. Въпреки това, те трябва да бъдат отразени в етикетите, ако приложението използва Crashlytics или Sentry.

Съдържание на потребителя и покупки

Категорията „Съдържание на потребителя" включва снимки, видео, аудио, файлове, съдържание, създадено от потребителя (съобщения, коментари). Ако приложението поиска достъп до снимки или файлове, тази категория е задължителна. Дори ако приложението само чете снимки, това се счита за събиране на данни.

Категорията „История на покупки" — агрегирани данни за покупки в приложението, абонаменти, плащания. Да не се бърка с „Финансова информация". Историята на покупки са метаданни на транзакции, а не платежни данни.

Как да попълните етикети в App Store Connect

Ръководство стъпка по стъпка за попълване на Privacy Nutrition Label в App Store Connect за ново или актуализирано приложение.

Подготовка за попълване

Преди попълване на етикетите, съставете пълен списък на всички SDK и услуги, които събират данни: Firebase, AppsFlyer, Google Ads, Facebook SDK, Sentry, Amplitude. За всяко SDK проверете какви данни събира и дали ги предава на трети страни. Adjust (2024) препоръчва водене на таблица с видове данни, цели и свързване за всяко SDK.

Определете какви данни директно събира вашият код. Например, ако приложението съхранява история на търсенията и я свързва с акаунта на потребителя — това са „Данни за използване" linked за цел „Разработка на продукт". Винаги проверявайте дали данните не се предават на трети страни (рекламни мрежи, аналитика).

Попълване на въпросника

В App Store Connect изберете приложението → раздел „Поверителност на приложението". Кликнете върху „Започни" и изберете дали вашето приложение събира данни за проследяване. Ако не, преминете към въпросника. Отговорете на всеки въпрос последователно за всички 14 категории данни.

Пример: ако приложението използва Firebase Analytics, отговорете с „Да" за категорията „Данни за използване", посочете linked (Firebase свързва данни с Instance ID) и цел „Аналитика". Ако също използвате Firebase Crashlytics, добавете категорията „Диагностика" с цел „Разработка на продукт".

След попълване запазете етикетите. Ако имате няколко приложения, етикетите са уникални за всяко — копирането не е предвидено. Актуализирайте етикетите при всяка промяна в логиката на събиране на данни, в противен случай старите етикети може да не съответстват на новата функционалност.

// Пример: проверка на изпращане на данни за аналитика
import FirebaseAnalytics

final class AnalyticsService {
    static func logEvent(_ name: String, params: [String: Any]) {
        Analytics.logEvent(name, parameters: params)
    }

    static func logPurchase(amount: Double, currency: String) {
        Analytics.logEvent(AnalyticsEventPurchase, parameters: [
            AnalyticsParameterValue: amount,
            AnalyticsParameterCurrency: currency
        ])
    }
}

Актуализиране на съществуващи етикети

За да актуализирате етикетите на публикувано приложение, отворете версията на приложението в App Store Connect и направете промени в раздела „Поверителност на приложението". Промените влизат в сила след преминаване на преглед. Новите етикети се показват на потребителите в рамките на 24 часа след публикуване на актуализацията.

Важно: премахването на данни от етикетите (например, спрели сте да предавате данни на трети страни) не изисква нова компилация — достатъчно е да промените етикетите в App Store Connect. Добавянето на нови данни изисква както промяна на етикетите, така и съответно актуализиране на Privacy Manife в кода.

Чести проблеми с етикетите за поверителност

Разработчиците често допускат грешки при попълване на етикети, което води до отхвърляне на актуализации или жалби на потребители.

Непълно деклариране на SDK

Най-честата грешка — разработчикът попълва етикети само въз основа на своя код, забравяйки за SDK на трети страни. Firebase, AppsFlyer, Facebook SDK и други събират данни автоматично без допълнителен код от разработчика. Например Firebase Analytics събира данни за използване (събития, екрани) и идентификатори (Instance ID, IDFV).

Препоръка: за всяко интегрирано SDK прочетете раздела „Data Collected" в документацията и добавете съответните категории към етикетите. AppsFlyer (2024) публикува списък на събираните данни за всяка версия на SDK, което помага на разработчиците да проверяват етикетите.

Объркване между linked и not linked

Много разработчици отбелязват данни като not linked, въпреки че са свързани с акаунт. Ако потребителят има акаунт и вие съхранявате неговото име или имейл — това е linked. Ако събирате crash журнали без връзка с акаунт — това е not linked. Грешка в свързването може да се счита за заблуждаване на потребителя.

Linked данните се показват в жълто и привличат повече внимание от потребителя. Ако не сте сигурни дали конкретен тип данни е linked, по-добре посочете linked и дайте обяснение при преглед. Apple не глобява за прекомерно деклариране, но може да отхвърли за недостатъчно.

Проследяването не е отбелязано като tracking

Ако данните се предават на трети страни и се използват за целенасочена реклама, това трябва да бъде отбелязано като „Данни, използвани за проследяване". Някои разработчици скриват проследяването, предавайки данни под предлог за аналитика — това нарушава правилата на Apple и може да доведе до забрана.

Правило на Apple: ако данните се предават на трета страна и се използват за персонализиране на реклама или атрибуция — това е проследяване. Дори ако приложението само не показва реклами, но използва Google Ads за атрибуция на инсталации, данните за прегледи се считат за проследяване.

Етикетите не се актуализират след промяна на код

Стари етикети, които не отговарят на текущата логика на събиране на данни — чест проблем при дългосрочна поддръжка на приложение. Разработчиците сменят SDK, добавят нови функции, но забравят да актуализират етикетите. В резултат потребителят вижда неактуална информация, което намалява доверието.

Най-добра практика: при всяка промяна на кода, свързана с данни, проверявайте етикетите и манифеста. Препоръчва се настройване на CI проверка, която предупреждава за необходимостта от актуализиране на етикетите при промяна на файловете PrivacyInfo.xcprivacy или списъка със SDK.