Управление согласиями

1) Термины и границы ответственности

Согласие (consent): добровольное, информированное, конкретное и однозначное волеизъявление; может быть отозвано.
Правовое основание: согласие — лишь один из вариантов (договор, законное основание, легитимный интерес и т. п.). Модель должна хранить и основание, и цель.
Цель обработки (purpose): атомарная причина: analytics, personalization, ads, email_marketing, data_sharing_vendor_X.
Гранулярность: согласия хранятся по целям, каналам, вендорам, регионам, категориям данных.
Профиль субъекта: человек, устройство, домохозяйство, аккаунт ребенка (особые правила для несовершеннолетних).

2) Жизненный цикл согласия

1. Сбор: баннер/CMP, настройки в профиле, API/SDK, оффлайн-канал (контакт-центр).
2. Валидация: возраст, регион, доступность альтернатив (без «темных паттернов»).
3. Регистрация: создание события согласия и текущего снимка состояний для целей.
4. Распространение: публикация в шину событий, обновление кэшей на edge, синхронизация с вендорами.
5. Исполнение: применение в real-time (шлюзы/пиксели/SDK), в batch (ETL/аналитика), в ML-пайплайнах.
6. Изменение/отзыв: немедленный запрет на новый сбор/активацию, последующая «зачистка» исторических данных по политике.
7. Аудит/отчетность: доказуемость согласия в момент обработки (кто, когда, какая версия текста).

3) Архитектурные компоненты

CMP (Consent Management Platform): UI/SDK + API, форматирующие варианты согласий под UX/юрисдикции; источник истины по текстам и версиям.
Consent Registry (реестр): надежное хранилище состояний и событий согласий (append-only журнал + актуальная проекция).
Consent PDP/PEP: Policy Decision/Enforcement Point. PDP решает «можно ли?», PEP применяет решение на API-шлюзе, в ETL, в SDK и пр.
Edge-кэш согласий: низкая латентность для проверки на периметре.
Partner/GPP/IAB-шлюз: трансляция локальных целей в партнерские сигналы и обратно.
Data Lineage & Tagging: маркировка данных флагами согласия/основания по всей цепочке.

4) Модель данных (схемы)

json
{
"subject_id": "usr_123",
"subject_scope": "user",
"region": "EU",
"legal_basis": {
"analytics": "consent",
"personalization": "consent",
"security": "legitimate_interest",
"contract_core": "contract"
},
"purposes": {
"analytics": {"status": "granted", "version": "v5", "updated_at": "2025-10-31T13:20:10Z"},
"personalization": {"status": "denied", "version": "v5", "updated_at": "2025-10-31T13:21:31Z"},
"ads": {"status": "denied", "version": "v5", "updated_at": "2025-10-31T13:21:31Z"},
"email_marketing": {"status": "granted", "channel":"email","updated_at":"2025-10-31T13:22:05Z"}
},
"text_bundle": {"locale":"uk-UA","policy_version":"2025-09"},
"evidence": {"capture_ip":"203. 0. 113. 5","capture_ua":"Chrome/142"}
}

json
{
"event_id": "cse_987",
"subject_id": "usr_123",
"purpose": "personalization",
"previous": "denied",
"current": "granted",
"legal_basis": "consent",
"policy_version": "2025-09",
"captured_at": "2025-10-31T13:21:31Z",
"channel": "web",
"evidence": {
"banner_id": "cmp_v3",
"text_hash": "sha256:...",
"ip": "203. 0. 113. 5",
"ua": "Chrome/142",
"locale": "uk-UA"
}
}

5) Протоколы сигналов и распространение

Web/App/SDK: хранение маркера согласий (cookie/local storage/secure storage) + подпись/проверка целостности; авто-ресинк при логине.
Server-side: хедеры `X-Consent-Token`/`X-Purposes`, двунаправленный обмен при SSR/edge-рендеринге.
Партнеры/вендоры: трансляция в их форматы (например, вектор целей, общий сигнал «GPP/TCF»); при отказе — нулевой сигнал/ограниченный режим.
Оффлайн-канал: запись аудио-согласия/чекбокса оператором с последующей верификацией и привязкой к `subject_id`.

6) Исполнение: где и как «режется» трафик

• Блокировать эндпоинты/поля без согласия (/profile/enrich, /ads/, /events/track).
• Мутировать ответ/запрос: вырезать трекеры, поля персонализации, идентификаторы.
• Присваивать контекст согласий в запрос к бэкенду (JWT-клеймы или отдельные заголовки).

• Трансформер событий удаляет/маскирует поля по флагам согласия.
• Маркировка датасетов: `dataset.consent_scope=analytics:granted;ads:denied`.
• В ML-пайплайне исключаются записи без соответствующих согласий; отключается тренинг/активация для запрещенных целей.

7) Псевдокод: решение на шлюзе

python def enforce_consent(request, consent_snapshot):
purpose = map_endpoint_to_purpose(request. path) # /ads/ -> "ads"
basis  = consent_snapshot. legal_basis. get(purpose)
status = consent_snapshot. purposes. get(purpose, {}). get("status", "denied")

if basis! = "consent": # e.g. security/contract - allowed without return ALLOW banner

if status!= "granted":
return DENY # or ALLOW with redaction if degradation is allowed

return ALLOW

8) Версионирование и доказуемость

Версия текста согласия: храните `policy_version`, `text_hash`, `banner_id`.
Локаль и регион: какой именно текст и на каком языке показан.
Снимок в момент обработки: возможность ответить «почему реклама была показана 2025-10-15 в 09:03?».
Неизменяемый журнал: WORM/append-only с криптоподписью событий.

9) Особые кейсы

Несовершеннолетние: валидация возраста, родительское согласие, отдельные цели и сроки.
Гость → логин: слияние анонимного маркера с учеткой; правила при конфликте (строжайшее побеждает).
Мультиустройство: консистентный ресинк; при отзыве — push-инвалидация токенов на всех устройствах.
Региональные режимы: «строгий» (EU) vs «опт-аут» (некоторые рынки) — переключение пресетов CMP.
A/B-тесты: эксперименты на данных — отдельная цель experimentation; без нее — только функциональные тесты без персональных данных.
Право на удаление: отзыв может инициировать удаление/анонимизацию исторических данных по цели (политика «purge on revoke»).

10) Анти-паттерны

Один «общий» чекбокс на все.
Отсутствие версий текстов и доказуемости показа.
Хранение только cookie-флага без серверного реестра.
Применение согласия лишь в UI, но не в ETL/ML/экспортах.
Конфликтующие источники истины (SDK ≠ бэкенд).
Dark patterns, навязывание согласия: юридические и репутационные риски.

11) Наблюдаемость и метрики

Coverage: доля трафика с валидным маркером согласий.
Latency PDP: время принятия решения на периметре.
Drift: несовпадение между SDK и серверным снимком.
Revoke SLA: время отзыва → время полной деактивации/очистки.
Vendor Compliance: процент партнерских вызовов с корректным сигналом.
Incidents: попытки обработки без согласия, заблокированные вызовы.

Дашборды: «воронки согласия», карта регионов/каналов, тепловые карты отказов.

12) Тестирование и верификация

Контрактные тесты PDP/PEP: таблица истинности по комбинациям целей/регионов.
Chaos/Drift-тесты: несинхронные состояния SDK ↔ сервер; истечение TTL кэша.
Релизы CMP: A/B-валидация текстов и нейтральности UX (без темных паттернов).
E2E-трассировка: событие user-revoke → отсутствие отправки в партнерские пиксели и пайплайны.

13) Взаимосвязанные способности

Анонимизация/псевдонимизация: исполнение отказов до и после обезличивания.
Шифрование и KMS: защита маркеров/журнала.
Geo-маршрутизация: выбор региональных текстов/правил.
Наблюдаемость: приватные дашборды без ПДн; корреляция только по токенам.
Data Lineage: в каждом датасете — отпечаток согласий.

14) Мини-рецепты

yaml purposes:
analytics:
legal_basis: consent enforcement: redact_fields: [ad_id, gaid, idfa]
personalization:
legal_basis: consent enforcement: deny_endpoints: [/recs/, /profile/enrich]
security:
legal_basis: legitimate_interest enforcement: allow email_marketing:
legal_basis: consent channel: email

event. meta. consent. analytics = granted    denied event. meta. consent. ads    = denied event. meta. legal_basis    = consent    contract    li

on user_revoke(purpose):
mark subject_id + purpose as "purge_pending"
schedule purge jobs over datasets with lineage(purpose)
emit audit_event("purge_started", scope=purpose)

15) Чек-лист архитектора

1. Есть ли единый реестр и неизменяемый журнал согласий?
2. Везде ли цели заданы атомарно и версионируемы?
3. Исполнение есть на периметре, в потоках, в аналитике и в ML?
4. Реализованы отзыв и политика очистки исторических данных?
5. Согласованы UI/SDK/серверные снимки и механизмы ресинка?
6. Настроены метрики Coverage/Drift/Revoke SLA и отчетность?
7. Есть runbook по инцидентам (нарушения, жалобы, регулятор)?
8. Поддержаны особые режимы (дети, регионы, B2B-партнеры)?

Заключение

Управление согласиями — это не модальное окно, а сквозная архитектурная функция: от декларирования целей и версионирования текстов до машинного исполнения решений в реальном времени и последующей отчетности. Строгая модель данных, единый реестр, PDP/PEP на всех слоях, полноценная телеметрия и процедуры очистки превращают комплаенс в конкурентное преимущество — платформу, которой доверяют.