Соответствие 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.