GDPR: управління згодою користувачів

1) Мета і область

Створити єдиний, що перевіряється і зручний для користувача процес управління згодою і комунікаційними перевагами, сумісний з GDPR і ePrivacy, застосовний до всіх поверхонь: веб, мобільні додатки/SDK, e-mail/SMS/push, афіліатні лендінги, стріми/соцмережі, вендорські теги.

2) Базові принципи

Вільне, конкретне, інформоване і однозначне вираження волі (без преса/умовності доступу).
Роздільність цілей: аналітика, персоналізація, маркетинг, геолокація, A/B-тести, сторонні теги - окремі тумблери.
Відгук так само простий, як згода. Ніяких «квестів» для відмови.
Відсутність темних патернів. Ніяких візуальних перекосів/локерів.
Доказовість. Логи, версії текстів, скріншоти UI-варіанту, хеші політик.
Мінімізація і приватність за замовчуванням.

3) Правові підстави (короткий довідник)

Art. 6 (1) (a) Згода: маркетинг, персоналізація, аналітика з ідентифікаторами, небезумовні cookies/SDK.
Art. 6 (1) (b) Договір: операції, необхідні для надання послуги (строго необхідні cookies).
Art. 6 (1) (f) Законний інтерес (LIA): обмежені вимірювання продуктивності при сильних гарантіях і праві заперечення.
Art. 8 Діти: вік для згоди дитини - поріг по країні; при неповнолітніх - заборона маркетингу.
Art. 9 Особливі категорії: біометрія/здоров'я - поза маркетингом; окремі правові підстави/заборони.
ePrivacy: зберігання/доступ до пристрою (cookies/local storage/SDK) - тільки «строго необхідні» без згоди; решта - за згодою.

4) Ролі та RACI

DPO/Head of Compliance - політика, DPIA, контроль скарг/ризиків. (A)

Legal - тексти, локалізація вимог, матриця основ. (R)

Product/UX - банери/преференс-центр, анти-dark-patterns. (R)

Engineering/CMP Owner - інтеграції CMP/SDK, API, версії, GPC/DNT. (R)

CRM/Marketing - сегментація за прапорами згоди, suppression. (R)

Data/Analytics - режими де-ідентифікації, обмеження трекінгу. (C)

InfoSec - шифрування, ключі, RBAC/ABAC до логів згоди. (C)

Internal Audit - вибірки доказів, CAPA. (C)

5) Таксономія згоди та переваг

Функціональні (без згоди): строго необхідні (автентифікація, кошик, баланс, захист від фроду).

1. Аналітика (ідентифікатори/крос-девайс)

2. Персоналізація контенту/ігор

3. Маркетинг (e-mail/SMS/push/in-арр/телематика) - канали окремо

4. Ремаркетинг/Ads (включаючи пікселі/SDK третіх осіб)

5. Геолокація нестрога (місто/регіон)

6. A/B-тестування (якщо використовує ідентифікатори)

7. Афіліатні теги/партнерські пікселі

6) UX-патерни CMP (веб/мобайл)

Перший шар (банер): коротка мета + «Прийняти все», «Відхилити все», «Налаштувати» - однакова помітність.
Другий шар (панель): тумблери за категоріями і розворот «Детальніше» (вендори, цілі, терміни).
Преференс-центр (в акаунті): канали маркетингу (e-mail/SMS/push/телефон) - роздільно; посилання «Відписатися від усього».
Відгук/зміна: в 1-2 кліки з будь-якого екрану; не змінює доступ до обов'язкових функцій.
Доступність: контраст, клавіатура, screen-reader, локалі.
GPC/“Do Not Track”: глобальний сигнал трактується як відхилити все, крім строго необхідних.
Мобільний SDK: in-app CMP + системні дозволи (OS prompts) → синхронізація з серверним профілем.

7) IAB TCF 2. 2 (каркас впровадження)

Підтримка стека цілей/особливостей, списку вендорів, string TC на стороні клієнта.
Збереження TC-рядка, версії, вендор-листа; маппінг в наші прапори.
Блокування тегів/SDK до отримання TC (prior consent).
Повага статусу «Deny All» і пермісій за вендорами.
Для non-TCF ринків - «кастомна» CMP з тим же UX і журналюванням.

8) Неповнолітні та вразливі

Якщо вік <порогу ринку - відсутні маркетингові канали і персоналізація; аналітика - тільки строго необхідна/PII-free.
Перевірка віку до завантаження маркетингових SDK/пікселів.
SE/RG-прапори: при самовиключенні - примусовий marketing suppression незалежно від згоди.

9) Приватність, зберігання та ретенція

Модель мінімізації: зберігати факти дій (accept/deny/withdraw), версії текстів, TC-рядок/хеші, а не «сирі» cookie-ід.
Ретенція: поки діє мета/відносини + терміни по ринку (зазвичай ≤ 24 міс без активності для маркетингу).
Доступ: RBAC, незмінні журнали (WORM), час - в UTC.
Видалення: відгук → негайний stop-processing; cron чистить невикористовувані id/SDK-кеші.

10) Дані та докази (мінімальна модель)

consent_id, user_id/device_id, market, locale,
ui_variant_id, policy_version, tcf_string, vendors[],
purpose_id, lawful_basis{consent    contract    legit_interest},
status{accept    deny    withdraw}, source{web    app    email    sdk    api},
captured_at_utc, ip_hash, ua_hash, gpc{true    false},
evidence{banner_screenshot_id, copy_hash}, expires_at

Артефакти: хеш тексту політики і банера, скріншот варіанту, список активних тегів/SDK в момент згоди.
Зв'язки: 'consent _ id'↔ події CRM/Ads для трасування suppression.

11) API/SDK і блокування тегів

Edge/CMP-SDK: до вибору - вантажимо тільки строго необхідні скрипти.

• `GET /consents? user_id=...`
• `POST /consents` (create/withdraw)
• 'POST/marketing/preferences'( канальні прапори)
• `POST /gpc/signal`
• Tag Manager Guards: правила "fire if consent. purpose. marketing == true».
• E-mail/SMS: розсилки тільки по'marketing. email = = true'і «double opt-in» (при необхідності ринку).

12) Сумісність з CRM/Ads/Афіліатами

Suppression-потоки: відгук → оновлення suppression в CRM, Ads, афіліат-фідах (batch + near-real-time).
UTM/постбеки: передавати тільки техпараметри; згода не «перекидається» партнерам без окремої правової бази.
Афіліати: зобов'язані відображати той же СМР/дисклеймер; без цього ліди не кваліфікуються.

13) Процеси і кейси

Відгук через лист: в кожному e-mail «Unsubscribe all» і «Налаштувати». Відписка - миттєво, підтвердження на сторінці/в листі.
DSAR/звернення: показати поточні прапори згоди, журнал дій; експорт без PII третіх осіб.
Зміна цілей: нова мета → новий запит згоди (не «ретроактивно»).
A/B-тест: зміна UI CMP - версія/скрін в артефакти, аудит на відсутність темних патернів.
Інциденти: неправильне завантаження тегу без згоди → негайний takedown, аудит логів, CAPA.

14) KPI/KRI і дашборд

Opt-in Rate по цілям/ринкам/пристроям

Withdraw/Change Rate і медіана «Time-to-Withdraw-Apply»

GPC Honor Rate (частка коректно оброблених GPC-сигналів)

Tag Firing Violations (запуски за відсутності згоди)

Suppression Integrity (маркетинг при відкликанні = 0)

Complaint Rate и Regulatory Findings

Auditability Score (% записів з повним пакетом артефактів)

15) Чек-листи

Перед запуском

• Матриця основ і цілей узгоджена (Legal/DPO).
• CMP підтримує «Відхилити всі», GPC, локалі.
• Tag Manager блокує всі не-необхідні теги до згоди.
• Преференс-центр з каналами (e-mail/SMS/push/телефон).
• Зв'язок з CRM/Ads/афіліатами для suppression.
• Версії текстів/скріншоти в WORM.

В операціях

• Моніторинг порушень firing-правил і GPC.
• DSAR відповідає поточними прапорами і журналом.
• Скарги та інциденти - SLA і CAPA.

Аудит/поліпшення

Квартальні вибірки записів на повноту доказів.

• A/B-рев'ю CMP на темні патерни.
• Оновлення локалей/правових текстів.

16) Шаблони (швидкі вставки)

17) Технічний каркас і події

Події: `consent_banner_shown`, `consent_given/denied/withdrawn`, `gpc_detected`, `tag_fired_blocked`, `marketing_unsubscribed`, `dsar_fulfilled`.
Фічі: автоматичне читання GPC; SDK-гейти; server-side consent cache; integrity-перевірки Tag Manager; експорт «PII-free» для аналітики.
Тести в CI/CD: лінтер блокування тегів, міграції схем версій, скрін-тести CMP.

18) Ризики та профілактика

→ Правила в Tag Manager «deny by default».
Залежність від вендорів → Список вендорів/цілей/юрисдикцій, DPA і аудит.
Темні патерни → дизайн-рев'ю і контроль рівноцінності кнопок.
→ Скріншоти, хеші текстів, WORM-журнали.
Розбіжність статусів в CRM/Ads. → Єдиний сервіс suppression + щоденні звірки.

19) 30-денний план впровадження

Тиждень 1

1. Затвердити матрицю цілей/основ і тексти (локалі).
2. Вибрати/налаштувати CMP (TCF 2. 2 + кастомні цілі).
3. Специфікувати модель даних і артефактів, включити WORM.

Тиждень 2

4. Інтегрувати CMP/SDK, Tag Manager «deny by default», GPC.
5. Побудувати преференс-центр і API suppression для CRM/Ads.
6. Підготувати A/B-варіанти банера, скрін-фіксацію.

Тиждень 3

7. Пілот 10-20% трафіку: завмер Opt-in/Withdraw/GPC Honor.
8. Ретро за скаргами/інцидентами; правки UX/текстів.
9. Підключити афіліатів до обов'язкового CMP-шару.

Тиждень 4

10. Повний реліз; увімкнути дашборд KPI/KRI та алерти.
11. Квартальний план аудитів і CAPA.
12. План v1. 1: серверний consent cache, автоматичні звіти по ринках.

20) Пов'язані розділи

Перевірка віку та вікові фільтри

Рекламні стандарти та заборони/Дисклеймери та правдивість реклами

Прозорість бонусних умов

Комплаєнс афіліатів і партнерів

Локалізація даних по юрисдикціях

Відповідальна гра та ліміти/Самовиключення/Reality Checks

Регуляторні звіти та формати даних/Внутрішній та зовнішній аудит