Відповідність ePrivacy Directive для мобільних застосунків

Багато мобільних розробників стикаються з ситуацією: застосунок відхиляють через відсутність запиту на трекінг або неправильного consent UI. Особливо строгі до цього Apple — після впровадження ATT в iOS стало складніше. Ми допомагаємо уникнути таких проблем, приводячи застосунок у відповідність з ePrivacy Directive (Директива 2002/58/EC). Для мобільних застосунків вона значно суворіша, ніж для веб-сайтів, оскільки зачіпає не тільки cookies, але й будь-які трекери, SDK, а advertising ID вважається еквівалентом cookie. За нашою статистикою, близько 70% проєктів при первинному аудиті мають порушення в зоні consent — від некоректного таймінгу запиту до відсутності IAB TCF-рядка. При цьому доналаштування згод не потребує капітальної переробки: достатньо закласти 2-3 тижні на впровадження та тестування.

Чим ePrivacy відрізняється від GDPR для мобільного?

GDPR регулює обробку персональних даних. ePrivacy регулює доступ до пристрою та зберігання інформації на ньому. Це різні правові підстави. Рекламний ідентифікатор IDFA або GAID — зберігання на пристрої. Для його зчитування потрібна згода за ePrivacy, незалежно від того, чи є він персональними даними за GDPR. Саме тому Apple ввела ATT — вони буквально реалізували ePrivacy в системному діалозі. Fingerprinting (збір характеристик пристрою для ідентифікації без cookies) також підпадає під ePrivacy. Якщо SDK збирає screen resolution + OS version + device model + timezone і хешує їх в ідентифікатор — це те саме, що cookie, тільки без можливості видалити.

Які дані вимагають згоди за ePrivacy?

Згода не потрібна для:

• Технічно необхідних операцій: зберігання сесійного токена, кошика покупок, налаштувань користувача.
• Безпеки: виявлення шахрайства, захист від DDoS.
• Аналітики в агрегованому вигляді без крос-девайс трекінгу (спірний момент між регуляторами, але в 80% випадків аудитори вимагають згоду).

Згода потрібна для:

• Advertising ID / IDFA для будь-яких цілей, окрім attributing install.
• Поведінкової реклами.
• Cross-app або cross-site трекінгу.
• Fingerprinting.
• Push-сповіщень, якщо вони не функціональні (транзакційні), а маркетингові.

Як правильно реалізувати ATT?

AppTrackingTransparency.framework — обов'язковий компонент для будь-якого iOS застосунку, який використовує IDFA або cross-app трекінг. Покрокова інструкція:

1. Додайте дозвіл NSUserTrackingUsageDescription в Info.plist з описом, навіщо потрібен трекінг.
2. Імпортуйте AppTrackingTransparency в коді.
3. Викликайте ATTrackingManager.requestTrackingAuthorization у слушний момент — наприклад, після онбордингу, коли користувач уже зрозумів цінність застосунку.
4. Обробіть статуси: .authorized — можна читати IDFA; .denied, .restricted — не можна; .notDetermined — повторно запитайте пізніше.

import AppTrackingTransparency func requestTrackingPermission() { ATTrackingManager.requestTrackingAuthorization { status in switch status { case .authorized: // Можна читати IDFA let idfa = ASIdentifierManager.shared().advertisingIdentifier self.initializeMarketingSDKs(with: idfa) case .denied, .restricted: // Не можна використовувати IDFA, не можна передавати в рекламні мережі self.initializeMarketingSDKsWithoutIDFA() case .notDetermined: break } } } 

Apple може відхилити застосунок, якщо запит з'являється занадто рано. На Android аналогічного системного діалогу немає, тому згода управляється через власний consent UI застосунку + IAB TCF/GPP рядки. Порівняння: на iOS процес обов'язковий і займає в середньому 2 дні, на Android — до 5 днів через необхідність кастомного UI.

Чому згода потрібна навіть для аналітики?

Багато розробників вважають, що аналітика в агрегованому вигляді не вимагає згоди. Однак регулятори часто трактують це інакше. Наприклад, якщо аналітичний SDK (Firebase, Amplitude) передає device model + OS version + app version з унікальним інсталяційним ідентифікатором, це вже потенційний трекінг. На практиці 90% SDK, що використовуються в мобільних застосунках, запитують рекламний ідентифікатор або передають дані, які можуть бути використані для ідентифікації. Тому краще перестрахуватися і запитувати згоду для будь-яких сторонніх SDK, окрім технічно необхідних.

Consent Management для ePrivacy

IAB Europe розробила Transparency and Consent Framework (TCF v2.2) для мобільних застосунків. Реалізація через IAB-certified Consent Management Platform (CMP):

// Читання TCF consent string з SharedPreferences (стандарт IAB) val consentString = sharedPrefs.getString("IABTCF_TCString", null) val purposeConsents = sharedPrefs.getString("IABTCF_PurposeConsents", null) // "1" в позиції N = згода на purpose N надана // Purpose 1 — базова реклама val adStorageConsent = purposeConsents?.getOrNull(0) == '1' // Purpose 3 — персоналізований профіль val personalizationConsent = purposeConsents?.getOrNull(2) == '1' 

Стандартні ключі IABTCF_* читаються всіма сумісними SDK автоматично — AdMob, Criteo, The Trade Desk та інші IAB-сумісні партнери.

Що входить в роботу з приведення у відповідність ePrivacy

Ми пропонуємо комплексний аудит та впровадження:

• Перевірка всіх SDK на відповідність ePrivacy (аналітика, реклама, краш-репортинг).
• Інтеграція ATT на iOS з правильним таймінгом.
• Розробка або інтеграція CMP (Google User Messaging Platform, OneTrust, Quantcast).
• Налаштування IAB TCF v2.2 рядків та передача в SDK.
• Тестування на реальних пристроях та в TestFlight.
• Підготовка документації для App Store Review та Google Play Console.
• Навчання команди роботі з консентами.

У нас 5+ років досвіду в мобільній розробці, понад 40 проєктів пройшли аудит та відповідають вимогам регуляторів. Отримайте консультацію — оцінимо ваш застосунок за 2-3 дні та запропонуємо план робіт. Зв'яжіться з нами, щоб гарантувати проходження перевірок App Store та Google Play. Ми проведемо аудит вашого застосунку — від згод до конфігурації SDK.