Політика cookies та CMP-системи

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

Встановити єдині правила законного зберігання/читання ідентифікаторів (cookies, local storage, SDK) і управління згодою через CMP у всіх поверхнях: веб, iOS/Android, e-mail/SMS/push, афіліатні лендінги, стріми. Документ доповнює: «GDPR: управління згодою", "Перевірка віку", "Рекламні стандарти".

2) Правові основи (коротко)

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

3) Принципи

1. Prior Consent: ніяких не-необхідних тегів до вибору в CMP.
2. Роздільність цілей: аналітика, персоналізація, маркетинг, ремаркетинг, геолокація, A/B - окремі тумблери.
3. Відгук = по клацанню: так само просто, як згода; моментальне припинення обробки.
4. Без темних патернів: рівна помітність «Прийняти все »/« Відхилити все »/« Налаштувати».
5. Доказовість: версії текстів, хеші, скріншоти UI, логи firing-правил.
6. Мінімізація/локалізація: ставимо і зберігаємо тільки те, що потрібно, в допустимих регіонах.

4) Ролі та RACI

DPO/Compliance (Owner) - політика, DPIA, відповіді на скарги. (A)

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

Product/UX - банери/панелі, доступність і локалі. (R)

Engineering/CMP Owner - блокування тегів, SDK, API, версії. (R)

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

CRM/Ads - suppression за відкликаними згодою. (R)

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

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

5) Таксономія cookies/SDK

• Сесія/автентифікація, баланс/кошик, захист від фроду і навантажувальний розподіл, збереження вибору приватності.

• Аналітика (user-level, крос-девайс ID).
• Персоналізація (контент/ігри, рекомендації).
• Маркетинг (e-mail/SMS/push - канали окремо).
• Ремаркетинг/Ads (пікселі/SDK третіх осіб).
• A/B-тестування (якщо використовує ідентифікатори).
• Геолокація «місто/регіон» (нестрога).

6) CMP: UX-патерни та тексти

Перший шар (банер): коротка мета, 3 рівнозначні кнопки: Відхилити все/Налаштувати/Прийняти все.
Другий шар (панель): тумблери цілей, список вендорів і термінів зберігання, посилання на політику.
Преференс-центр: у профілі гравця - канальні прапори маркетингу (e-mail/SMS/push/телефон), «Відписатися від усього».
Доступність: контраст AA +, фокус-пастка, screen-readers, локалізація, мобільна адаптація.
GPC/Do Not Track: глобальний сигнал = відхилити все (крім строго необхідних).
Аппи: in-app CMP + системні OS-prompts; синхронізація з серверним профілем.

7) IAB TCF 2. 2 (каркас)

Генерація і зберігання TC-рядка, версія вендор-листа, маппінг цілей ↔ наші прапори.
Блокування третіх тегів до отримання TC (prior consent).
Повага дозволів/заборон по кожному вендору і мети.
Для ринків поза TCF - кастомна CMP з аналогічним журналюванням.

8) Теги, Tag Manager і Server-side

Deny by default: правила в TM блокують всі не-необхідні теги до згоди.
Server-side tagging: проксі-контур з обнуленням/маскуванням ідентифікаторів за відсутності згоди; конфігурація зберігається в дозволеному регіоні.
SDK-гейти: ініціалізація маркетингових/аналітичних SDK тільки при true-прапорі мети.
Firing-логи: хто/що/коли «стрельнуло», при якому статусі згоди.

9) Дані, артефакти та ретенція (мінімальна модель)

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

WORM-журнали згоди/відгуків, версії текстів, скріншоти UI-варіантів.
Ретенція: поки діє мета/відносини + локальні терміни; маркетинг - обмежено (часто ≤ 24 міс неактивності).

10) Інтеграції: CRM/Ads/Афіліати

Suppression: відгук → миттєва деактивація каналів і ремаркетингу (near-real-time + нічні бетчі).
E-mail/SMS: розсилка тільки при явно true для каналу (double opt-in по ринках).
Афіліати: ліди без БМР/валідного статусу згоди - не кваліфікуються; version/hash умов - обов'язковий.

11) Регіональні профілі (шаблон)

Market: ______
Required banner elements:...
Retention and localization:...
Requirements for TCF/vendor lists:...
GPC/DNT status:...
Documents/mandatory links:...

12) Контроль, тести та аудит

CI-лінтер: перевірка наявності «Відхилити все», GPC-обробки, блокування тегів до згоди.
E2E-тести: сценарії accept/deny/withdraw → перевірка firing-логів і suppression в CRM.
Вибірки: квартальний аудит записів згоди та скріншотів UI; звірка версій текстів.
Інциденти: будь-який запуск тега без згоди → негайний takedown, причина/фікс, CAPA.

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

Opt-in Rate по цілям/ринкам/пристроям.
Withdraw Rate і Time-to-Apply (медіана).
GPC Honor Rate (коректна обробка глоб. сигналу).
Tag Firing Violations (на 1k завантажень).
Suppression Integrity (маркетинг при відкликанні = 0).
Complaint Rate / Reg Findings.
Auditability Score (% записів з повним пакетом артефактів).

14) Чек-листи

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

• Банер з «Відхилити всі», локалі, доступність AA +.
• Категорії цілей і список вендорів узгоджені (Legal/DPO).
• Tag Manager: deny-by-default; SDK-гейти.
• GPC розпізнається і застосовується.
• Преференс-центр з канальними прапорами і «Відписатися від усього».
• WORM-сховище доказів включено.

В операціях

• Моніторинг firing-порушень і GPC.
• Звірка suppression в CRM/Ads.
• DSAR повертає поточні статуси і журнал.

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

• Квартальні вибірки згоди та UI-скріншотів.
• A/B-рев'ю банера на відсутність темних патернів.
• Оновлення регіональних профілів і текстів.

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

A) Банер (перший шар)

B) Панель (мета «Ремаркетинг/Ads»)

C) Відкликання згоди (підтвердження)

D) Відповідь на скаргу «неможливо відмовитися»

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

Події: `cmp_banner_shown`, `consent_given/denied/withdrawn`, `gpc_detected`, `tag_fired_blocked`, `sdk_initialized/blocked`, `marketing_unsubscribed`, `dsar_fulfilled`.

• `GET /consents? user_id=…`
• `POST /consents` (create/withdraw/update)
• `POST /marketing/preferences`
• `POST /gpc/signal`
• Інфраструктура: серверний кеш згоди, гео-прив'язка логів, маскування ідентифікаторів при deny.

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

→ Deny-by-default, E2E-тести, тривоги.
Темні патерни в банері. → Дизайн-рев'ю, рівна помітність кнопок.
Розбіжність статусів в CRM/Ads. → Єдиний suppression-сервіс і щоденні звірки.
Збір зайвих ідентифікаторів. → Мінімізація, маскування, регіональні профілі.
Відсутність доказів. → Скріншоти/хеші/логи в WORM.

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

Тиждень 1

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

Тиждень 2

4) Реалізувати deny-by-default в Tag Manager, серверний кеш згоди, SDK-гейти.
5) Побудувати преференс-центр (канальні прапори, «Відписатися від усього»).
6) Налаштувати suppression в CRM/Ads і афіліат-фідах.

Тиждень 3

7) Пілот на 10-20% трафіку: Opt-in/Withdraw/GPC Honor, тест firing-логів.
8) Виправлення UX/копірайту/правил TM з фідбеку та інцидентів.

Тиждень 4

9) Повний реліз; увімкнути дашборд KPI/KRI та алерти.
10) Квартальний план аудитів і CAPA.
11) План v1. 1: server-side tagging для всіх ринків, авто-репорти за згодою.

• GDPR: управління згодою користувачів
• Перевірка віку та вікові фільтри
• Рекламні стандарти та заборони/Дисклеймери та правдивість реклами
• Прозорість бонусних умов
• Локалізація даних по юрисдикціях
• Дашборд комплаєнсу та моніторинг/Внутрішній та зовнішній аудит