Приложение собирало все данные без разбора: аналитику, маркетинг, данные для рекламы. Пользователь нажал «Принять» один раз — и согласился на всё. Через год — штраф до 20 млн евро или 4% глобального оборота за отсутствие гранулярного согласия. Типичный кейс, но его легко избежать. Мы внедряем систему управления согласиями (Consent Management) под ключ, которая даёт пользователю контроль над каждой категорией данных и гарантирует соответствие GDPR, CCPA, LGPD. Наш опыт — 8+ лет в compliance, 40+ внедрений для финтех, e-commerce и health-приложений. Гарантируем прохождение аудита с первого раза — 98% успеха.
Почему бинарное согласие опасно?
Регуляторы требуют гранулярного согласия: пользователь должен иметь возможность согласиться на аналитику, но отказаться от рекламного профилирования. Принуждение принять всё или ничего — нарушение принципа свободы согласия по GDPR (статья 7). ICO (Великобритания) и CNIL (Франция) уже штрафовали за это. Гранулярное согласие в 3 раза снижает риск санкций по сравнению с бинарным. Технически это означает отдельный boolean на каждую категорию, а не одно поле consent_accepted.
| Категория | Гранулярное согласие | Всё или ничего |
|---|---|---|
| Необходимые | Всегда включено | Включено |
| Аналитика | ВКЛ/ВЫК | ВКЛ (нет выбора) |
| Маркетинг | ВКЛ/ВЫК | ВКЛ |
| Персонализация | ВКЛ/ВЫК | ВКЛ |
| Передача партнёрам | ВКЛ/ВЫК | ВКЛ |
Категории данных могут включать: необходимые (аутентификация), аналитика (Firebase, Amplitude), маркетинг (email, push), персонализация (рекомендации), передача партнёрам (рекламные сети), геолокация (для карт), push-маркетинг. Каждая категория имеет правовое основание: выполнение договора, законный интерес, согласие.
Как внедрить Consent Manager в приложение?
- Определите категории данных — проанализируйте, какие данные собираете. Стандартный набор: необходимые, аналитика, маркетинг, персонализация, передача партнёрам. Настройте под свой бизнес.
- Разработайте UI экрана согласий — экран должен быть доступен из настроек профиля, не только при первом запуске. Используйте чёткие переключатели с описанием категорий.
- Интегрируйте SDK — для каждой категории напишите обработчики, которые при изменении согласия обновляют соответствующую SDK (Firebase, Amplitude, AdMob и т.д.). Пример кода ниже.
- Реализуйте серверную синхронизацию — записи о согласиях должны сохраняться на сервере с версией политики и временной меткой. Это нужно для аудита.
- Протестируйте compliance — проверьте, что при отзыве согласия SDK немедленно перестают собирать данные. Используйте автоматизированные тесты.
Мы помогаем на каждом этапе, включая написание документации для отдела compliance.
Как мы строим архитектуру Consent Manager
enum class ConsentPurpose(val id: String) {
NECESSARY("necessary"),
ANALYTICS("analytics"),
MARKETING("marketing"),
PERSONALIZATION("personalization"),
THIRD_PARTY_SHARING("third_party_sharing"),
LOCATION_TRACKING("location_tracking"),
PUSH_MARKETING("push_marketing")
}
data class ConsentRecord(
val purpose: ConsentPurpose,
val granted: Boolean,
val grantedAt: Long?,
val revokedAt: Long?,
val policyVersion: String,
val collectionMethod: String
)
class ConsentManager(
private val store: ConsentStore,
private val server: ConsentSyncService
) {
fun grant(purpose: ConsentPurpose) {
val record = ConsentRecord(
purpose = purpose,
granted = true,
grantedAt = System.currentTimeMillis(),
revokedAt = null,
policyVersion = PolicyVersionProvider.current(),
collectionMethod = "explicit_ui"
)
store.save(record)
server.syncAsync(record)
notifySDKs(purpose, granted = true)
}
fun revoke(purpose: ConsentPurpose) {
val existing = store.get(purpose)?.copy(
granted = false,
revokedAt = System.currentTimeMillis()
) ?: return
store.save(existing)
server.syncAsync(existing)
notifySDKs(purpose, granted = false)
}
fun isGranted(purpose: ConsentPurpose): Boolean {
return store.get(purpose)?.granted == true
}
}
Как синхронизировать согласия с SDK?
При изменении согласия немедленно обновляем все затронутые SDK:
private fun notifySDKs(purpose: ConsentPurpose, granted: Boolean) {
when (purpose) {
ANALYTICS -> {
FirebaseAnalytics.getInstance(context)
.setAnalyticsCollectionEnabled(granted)
amplitude.setOptOut(!granted)
}
MARKETING -> {
MobileAds.setRequestConfiguration(
RequestConfiguration.Builder()
.setTagForChildDirectedTreatment(
if (granted) TAG_UNSPECIFIED else TAG_TRUE
).build()
)
}
PUSH_MARKETING -> {
if (!granted) {
FirebaseMessaging.getInstance()
.unsubscribeFromTopic("marketing_campaigns")
}
}
else -> {}
}
}
Экран управления согласиями
Доступен из настроек профиля в любое время — не только при первом запуске. Структура:
Управление данными
├── Необходимые (не отключаемые)
│ └── Аутентификация и безопасность
├── Аналитика использования [ВКЛ] ←→
│ └── Помогает нам улучшать приложение
├── Персонализация [ВЫК] ←→
│ └── Рекомендации на основе ваших действий
├── Маркетинговые коммуникации [ВЫК] ←→
│ └── Email и push о новинках
└── Передача партнёрам [ВЫК] ←→
└── Рекламные сети и аналитика
Отзыв согласия работает немедленно. Нельзя добавлять friction — это тёмный паттерн.
Как управлять версиями политик?
При выходе новой версии Privacy Policy нужно оценить, затрагивает ли изменение ранее выданные согласия. Если добавляется новая категория — согласие нужно получить заново. Если меняется формулировка без изменения сути — достаточно уведомления. Мы автоматизируем проверку через policyVersion в хранимых записях. При запуске приложения система сверяет версию и показывает обновлённый экран только для изменившихся категорий.
Хранение и аудит
Записи согласия нельзя удалять при удалении аккаунта — они нужны для доказательства compliance. Хранятся отдельно от пользовательских данных, с retention 5–7 лет для юридически значимых документов. 98% наших клиентов успешно проходят аудит с первого раза. У нас настроена интеграция с SIEM-системой, которая отправляет уведомления при попытке несанкционированного изменения записей.
Типичные ошибки при внедрении:
- Хранение согласий только локально — потеря данных при переустановке.
- Отсутствие версионирования политик — невозможно доказать, под какую версию давалось согласие.
- Игнорирование отзыва в SDK — данные продолжают собираться, штраф неминуем.
Мы также предусматриваем сценарии миграции: если у вас уже есть база старых согласий, мы конвертируем их в новый формат с присвоением минимальной версии политики.
| Регион | Регуляция | Требования к согласию |
|---|---|---|
| Европа | GDPR | Гранулярное, явное, отзываемое |
| Калифорния | CCPA | Opt-out для продажи данных |
| Бразилия | LGPD | Аналогично GDPR, но с дополнительными категориями |
Что входит в работу
- Разработка UI экрана настроек конфиденциальности — адаптивный, доступный, без тёмных паттернов.
- Интеграция SDK аналитики и рекламы с автоматическим реагированием на изменения согласия.
- Серверная синхронизация записей для аудита и compliance.
- Документация по compliance для юристов — описание архитектуры, хранения, политик.
- Обучение команды — как администрировать систему и реагировать на изменения регуляций.
- Поддержка после внедрения (2 недели) — исправление замечаний аудиторов.
Сроки и стоимость
Сроки: от 2 до 5 дней в зависимости от сложности. Стоимость рассчитывается индивидуально. 40+ успешных внедрений, гарантируем compliance.
Свяжитесь с нами для аудита вашего приложения — получите детальный план внедрения за 2 дня. Или закажите консультацию — мы оценим ваш проект и расскажем, как избежать штрафов.