Управління згодою

1) Терміни та межі відповідальності

Згода (consent): добровільне, інформоване, конкретне і однозначне волевиявлення; може бути відкликано.
Правова підстава: згода - лише один з варіантів (договір, законна підстава, легітимний інтерес і т.п.). Модель повинна зберігати і основу, і мету.
Мета обробки (purpose): Атомарна причина: analytics, personalization, ads, email_marketing, data_sharing_vendor_X.
Гранулярність: згоди зберігаються по цілях, каналах, вендорах, регіонах, категоріях даних.
Профіль суб'єкта: людина, пристрій, домогосподарство, акаунт дитини (особливі правила для неповнолітніх).

2) Життєвий цикл згоди

1. Збір: банер/СМР, налаштування в профілі, 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 на всіх шарах, повноцінна телеметрія і процедури очищення перетворюють комплаєнс в конкурентну перевагу - платформу, якій довіряють.