Мы проводим аудит и внедряем полное соответствие мобильного приложения требованиям GDPR. Это не одна галочка «добавить кнопку согласия» и не одна неделя работы. Это сквозное изменение архитектуры: от того, что собирается при установке, до того, как обрабатывается запрос на удаление данных через 18 месяцев после регистрации. Большинство приложений проваливают именно технические проверки, а не формальные — Data Protection Authority смотрит на реальное поведение SDK, а не на текст Privacy Policy. Более 5 лет мы помогаем стартапам и enterprise-проектам избегать штрафов до 4% годового оборота.
Почему GDPR-соответствие требует перестройки архитектуры
Типичный стартап присылает приложение с фразой «мы уже GDPR-compliant». После аудита находим:
Firebase Analytics инициализируется до согласия. SDK пишет app_open и first_open события при первом запуске — до того, как пользователь увидел экран согласия. Это нарушение принципа Data Minimisation. Решение — отложенная инициализация через FirebaseApp.initializeApp() только после получения согласия на аналитику.
Advertising ID считывается автоматически. AdvertisingIdClient.getAdvertisingIdInfo() на Android и ASIdentifierManager.shared().advertisingIdentifier на iOS — оба читаются при старте AppsFlyerSDK или Adjust. Без согласия на маркетинг эти идентификаторы трогать нельзя.
Crashlytics отправляет данные без разбора. По умолчанию Firebase Crashlytics включён с момента сборки. Технически crash report содержит device model, OS version, free disk space — это личные данные по GDPR определению. Нужно либо отключать до согласия, либо настраивать с isCrashlyticsCollectionEnabled = false по умолчанию.
Логи содержат персональные данные. Android Logcat и iOS os_log часто содержат email, userId, content of API responses. Если crashlytics или сторонний SDK собирает логи — они уходят на сервера вне EU без явного согласия.
Наша методика отложенной инициализации снижает объём отправляемых данных на 70% по сравнению с обычным запуском.
Как мы строим GDPR-compliant архитектуру
Consent Gate — обязательный первый экран — соответствие мобильного приложения
До любой инициализации аналитических, рекламных или профилирующих SDK — экран согласия. Не pop-up поверх контента, не «принять всё» как единственная опция. IAB TCF v2.2 устанавливает стандарт для mobile: гранулярные категории с возможностью отклонить каждую.
Согласие хранится локально и синхронизируется на сервер. Структура:
struct ConsentRecord: Codable {
let userId: String? // nil до регистрации
let deviceId: String // IDFV или ANDROID_ID
let timestamp: Date
let version: String // версия Privacy Policy
let purposes: [ConsentPurpose: Bool]
// Источник согласия для аудита
let collectionMethod: String // "explicit_ui_v2", "imported_from_v1"
}
enum ConsentPurpose: String, Codable {
case necessary
case analytics
case marketing
case personalization
case thirdPartySharing
}
SDK-оркестрация на основе согласия
Создаём единую точку инициализации SDK, которая проверяет consent перед каждой инициализацией:
class SDKOrchestrator(private val consentManager: ConsentManager) {
fun onConsentUpdated(consent: ConsentRecord) {
// Necessary — всегда
initializeCrashReporting(minimal = true)
// Analytics — только с согласия
if (consent.purposes[ANALYTICS] == true) {
FirebaseAnalytics.getInstance(context).setAnalyticsCollectionEnabled(true)
} else {
FirebaseAnalytics.getInstance(context).setAnalyticsCollectionEnabled(false)
}
// Marketing — GAID/IDFA только с согласия
if (consent.purposes[MARKETING] == true) {
initializeAppsFlyer()
// requestTrackingAuthorization для iOS 14.5+
}
// Third-party sharing — другие рекламные сети
if (consent.purposes[THIRD_PARTY_SHARING] == true) {
initializeAdjust()
}
}
}
На iOS 14.5+ маркетинговые SDK требуют ATTrackingManager.requestTrackingAuthorization — это системный диалог, отдельный от нашего consent UI. Порядок важен: сначала наш экран с объяснением, потом системный диалог Apple.
Как реализовать право на доступ (Data Subject Access Request)
Пользователь вправе запросить все данные, которые мы о нём храним. В мобильном приложении это означает:
- Экран «Мои данные» в настройках профиля
- Кнопка «Запросить выгрузку» → сервер получает задачу
- В течение 30 дней (требование GDPR) — ответ на email или in-app уведомление с архивом
Сервер должен агрегировать данные из всех источников: основная БД, аналитические события, push-токены, история сессий, данные третьих сторон (если они хранятся). Согласно GDPR Article 15, пользователь имеет право на копию данных.
Право на удаление (Right to Erasure)
Детально рассматривается в отдельной услуге. В контексте GDPR: удаление должно быть полным, включая резервные копии (с допустимым сроком до следующего цикла backup retention), данные у субпроцессоров, anonymized logs где anonymization обратима.
Технические сложности: данные, необходимые для исполнения договора (история заказов, платежи) могут храниться дольше — до истечения законодательно установленного срока. Нужна классификация данных с разными retention policies.
Обработка данных несовершеннолетних
Если приложение может использоваться детьми до 16 лет (в большинстве стран EU — 16, в некоторых — 13), нужна дополнительная верификация возраста и согласие родителей. Профилирование и поведенческая реклама для несовершеннолетних — под запретом.
Data Processing Agreement с субпроцессорами
Firebase, Amplitude, Braze, Mixpanel, Adjust — все они субпроцессоры. С каждым должен быть подписан DPA. Google/Firebase предоставляют стандартный DPA через Google Cloud Console. Amplitude — отдельно. Большинство команд об этом не думают до первого аудита.
Трансграничная передача данных
Серверы в US принимают данные EU пользователей? Нужно Standard Contractual Clauses (SCC, последние обновления). Самоcертификация EU-US Data Privacy Framework заменила Privacy Shield, но требует регистрации в Министерстве торговли США — актуально для компаний с US-юрисдикцией.
В мобильном приложении это влияет на выбор дата-центра Firebase (можно выбрать EU region для Firestore/Functions), регион Amplitude (api.eu.amplitude.com) и другие SDK с настройкой региона.
Типичные нарушения и решения (таблица)
| Нарушение | Частота | Решение |
|---|---|---|
| Инициализация Firebase Analytics до согласия | 90% приложений | Отложенная инициализация |
| Сбор Advertising ID без согласия | 80% приложений с маркетинговыми SDK | Условный запуск SDK |
| Crashlytics отправляет данные с первого запуска | 70% приложений | Отключение до согласия |
| Отсутствие механизма DSAR | 95% малых приложений | Внедрение экрана "Мои данные" |
Что входит в работу
- Аудит всех SDK и конфигураций (проксирование трафика, анализ логов)
- Разработка и интеграция consent-экрана с гранулярными настройками
- Настройка отложенной инициализации всех SDK
- Реализация DSAR и Right to Erasure
- Подготовка и подписание DPA с субпроцессорами
- Документация Record of Processing Activities (ROPA)
- Код-ревью и тестирование
- Поддержка при прохождении проверки DPA
Как внедрить GDPR: пошаговая инструкция
- Проведите аудит всех SDK и отследите их поведение при первом запуске.
- Разработайте экран согласия в соответствии с IAB TCF v2.2.
- Реализуйте consent-менеджер и отложенную инициализацию.
- Настройте DSAR workflow на сервере.
- Проверьте retention policies в базе данных.
- Подпишите DPA со всеми субпроцессорами.
- Протестируйте сценарии отзыва согласия и удаления данных.
Сроки
| Объём | Срок |
|---|---|
| Consent UI + отложенная инициализация SDK | 3–5 дней |
| + DSAR workflow + Right to Erasure | +5–7 дней |
| + Аудит субпроцессоров + DPA | +3–5 дней |
| Полный GDPR compliance с нуля | 3–6 недель |
Чек-лист для самостоятельной проверки
- SDK инициализируются только после согласия? - Собирается ли Advertising ID до согласия на маркетинг? - Есть ли экран "Мои данные" с возможностью выгрузки? - Реализовано ли удаление профиля с полной очисткой? - Подписан ли DPA с Firebase, Amplitude и другими?Закажите аудит текущего приложения. Получите консультацию по вашему случаю — мы оценим проект и предложим оптимальный план внедрения.