Управління даними

1) Навіщо це потрібно

Управління даними - це операційна система роботи з даними, яка з'єднує людей, процеси і технології, щоб дані були якісними, захищеними, зрозумілими і придатними до використання. Для iGaming це критично через високу регуляторику (KYC/AML, відповідальна гра, платежі), обсяг подій (ставки, спини, транзакції) і міжкомандної координації (продукт, ризик, маркетинг, фінанси).

• Надійність метрик (єдине джерело істини для GGR, LTV, ARPPU).
• Зниження ризиків (штрафи, витоки, інциденти).
• Прискорення аналітики і ML (передбачення відтоку, антифрод, персоналізація).
• Керована масштабованість (нові ринки/бренди/провайдери).

2) Модель управління (Operating Model)

• Централізована: єдина команда даних встановлює стандарти і реалізує процеси. Плюс - швидкість уніфікації; мінус - можлива «вузька горлечко».
• Федеративна: доменні команди володіють своїми наборами, загальні політики - центральні. Баланс швидкості і контролю.
• Data Mesh: домени - як «продукти даних» з SLO/SLI, каталогом і контрактами; сильне самоврядування + платформна підтримка.

Порада: стартуйте з «федеративної» моделі і поступово еволюціонуйте до Mesh по зрілості.

3) Ролі та відповідальність

Data Governance Council: крос-функціональний орган (C-level + домени) - затверджує політики, пріоритети, KPI.
CDO (Chief Data Officer): власник стратегії даних, якості, каталогу, культури.
DPO/Privacy Lead: захист даних, відповідність регуляториці, DPIA, інциденти.
Data Owners (за доменами): фінанси, продукт, маркетинг, ризик, CRM - відповідають за семантику і якість наборів.
Data Stewards: операційні «хранителі» - глосарій, метадані, DQ-правила, тікети якості.
Security & Compliance: шифрування, контроль доступів, аудит.
Platform/Engineering: каталог, лінійдж, схема-регістри, пайплайни, MDM, Lakehouse/DWH.
Analysts/Scientists: споживачі та співвласники доменних вимог до якості та доступності.

RACI (скорочений приклад)

Політики: CDO (A), Council (R/A), DPO (C), Sec (C), Owners (C), Eng (I)

Каталог/глосарій: CDO (A), Stewards (R), Owners (C), Eng (C)

Доступи до даних: DPO/Sec (A), Owners (R), IT (R), HR (I)

Якість даних: Owners (A), Stewards (R), Eng (C), Analysts (C)

4) Артефакти Data Governance

1. Політика управління даними (umbrella-документ): принципи, ролі, контроль, ескалації.
2. Каталог даних: реєстр наборів (KYC, транзакції, ігрові раунди, ліміти RG, платежі, провайдерські фіди), власники, теги, класифікація.
3. Бізнес-глосарій: визначення GGR/Net Gaming Revenue, бонусна відповідальність, churn, активний гравець, VIP-сегменти.
4. Лінійдж (Data Lineage): від джерела (провайдери, PSP, CRM) до вітрин/моделей - для довіри та аудиту.
5. Data Contracts: формальні угоди між продюсером і споживачем даних - схеми, типи, SLA якості/своєчасності.
6. Schema Registry & Versioning: еволюція схем без поломок (семвер, депрекейшн-план, зворотна/пряма сумісність).
7. MDM (Master Data Management): реєстри гравців, брендів, провайдерів, ігор (game_id, studio, RTP, волатильність).
8. Політика зберігання/видалення: терміни, Legal Hold, анонімізація/псевдонімізація.
9. Паспорти наборів даних (Data Product Canvas): призначення, споживачі, інциденти, метрики якості, SLO/SLI.

5) Процеси і практики

5. 1 Якість даних (Data Quality)

• Повнота, точність, валідність, узгодженість, своєчасність, унікальність.
• DQ-правила в пайплайнах (наприклад, сума ставок ≥ сума виграшів, формат IBAN/карти, вік ≥ 18 +).
• DQ-алерти і тікети: при регресі - автоескалація власнику домену.

5. 2 Управління доступом і класифікація

Класи даних: Public/Internal/Confidential/Restricted (PII/фінансові).
RBAC/ABAC: ролі за завданнями (аналіз, продукт, ризик), атрибути (країна, бренд, проект).
Принцип найменших прав, тимчасові доступи (Just-in-Time), журналювання запитів.

5. 3 Приватність і безпека

Шифрування in transit і at rest; управління ключами та ротація.
Псевдонімізація для аналітики, анонімізація для досліджень/пісочниць.
Політика мінімізації: зберігати тільки потрібне, стільки, скільки потрібно.
Управління інцидентами: план реакції, повідомлення зацікавлених сторін.

5. 4 Життєвий цикл даних

Створення → Інгест → Зберігання → Збагачення → Доступ/Аналітика → Архів/Видалення.
Для iGaming: події раундів (spin/hand), сесії, платежі, ліміти гравця, тікети саппорта, скарги, DSAR.

5. 5 Зберігання, видалення, Legal Hold

Графіки зберігання: операційні логи - X міс., звітність - Y років, PII - за мінімумом і за законом.
Legal Hold: заморожування видалення при розслідуваннях/судах.
Техніки видалення: soft-delete (мітка), hard-delete, криптостирання, анонімізація.

5. 6 Управління змінами даних

RFC на зміни схем/контрактів, імпакт-аналіз по лінійджу.
Backfill-процедури та план міграцій.
Версіонування вітрин і моделей (v1 → v2 з паралельним прогоном і порівнянням).

6) Архітектурні принципи

Lakehouse + DWH: сирі та очищені шари, вітрини для BI/ML; формати з транзакційністю (ACID-таблиці).
Streaming + Batch: real-time антифрод/персоналізація і щоденна звітність.
Data Contracts по шині подій: Avro/Proto, еволюція схем, ідемпотентність.
Золоті набори (Gold): сертифіковані таблиці для ключових KPI (GGR, DAU, утримання).
Observability даних: моніторинг свіжості, об'єму, дрифту ознак для ML.

7) Метрики і KPI Governance

% сертифікованих наборів в каталозі.
Покриття глосарієм (частка термінів з власниками).
DQ-SLA: своєчасність (freshness), відсоток успішних перевірок якості.
Час підключення нового джерела/доменного продукту.
Кількість інцидентів за даними і середній час відновлення (MTTR).
Частка запитів на доступ, оброблених в SLO.
Задоволеність аналітиків/DS (опитування).

8) Інструменти (зразкові категорії)

Catalog & Glossary & Lineage: корпоративний каталог з автозбором метаданих і графом.
Quality/Observability: правила, тести, моніторинг свіжості та аномалій.
Access & Security: централізовані політики, провізія доступів, журнал аудиту.
Schema Registry / Contracts: реєстр схем, перевірки сумісності на CI.
MDM/Reference Data: майстер-записи гравців/ігор/брендів, довідники валют, країн, провайдерів.
Workflow & Ticketing: пайплайни узгоджень, RACI-шаблони, SLA-черги.

9) Приклади доменів даних в iGaming

Ігрові події: game_round, bet, win, RTP за часом/грі/провайдеру.
Платежі: депозити, висновки, chargeback, методи (карти, крипто, локальні PSP).
Користувачі: KYC/KYB статуси, ліміти RG, самовиключення, скарги.
Маркетинг/CRM: кампанії, джерела трафіку, сегменти, бонуси і відіграш.
Ризик/AML: скоринги, аномалії, алерти, розслідування.
Фінанси: звіти GGR/NET, податки, розрізи по країнах і брендах.

10) Шаблони (готово до використання)

10. 1 Картка набору даних

• Класифікація/PII: Public/Internal/Confidential/Restricted
• Схема (версія): посилання на контракт/реєстр
• Лінійдж: джерело → трансформації → вітрина

10. 2 Data Contract (ескіз)

• Схема: поля, типи, nullable, словники.
• Семантика: визначення, бізнес-правила.
• SLA: затримка доставки, доступність.
• Сумісність: політика версій (SEMVER), депрекейшн-вікно.
• Якість: обов'язкові перевірки (унікальний key, діапазони, референсні довідники).
• Безпека: маскування/псевдонімізація/шифрування.

10. 3 Політика доступу (витримка)

Принцип: найменші привілеї, обґрунтування запиту.
Потоки: заявка → узгодження Owner/DPO → провізія → журнал.
Термін: тимчасові доступи з автовідзивом.
Моніторинг: регулярні рев'ю прав.

11) Покрокова дорожня карта впровадження

Перші 30 днів (MVP Governance)

1. Призначити Council, CDO, Owners/Stewards по доменах.
2. Прийняти «Політику управління даними» і мінімальну модель класифікації.
3. Розгорнути базовий каталог + глосарій, описати 10 критичних наборів (GGR, транзакції, KYC).
4. Включити 5-10 DQ-правил в основних пайплайнах (freshness/унікальність/валідність).
5. Запустити процес запитів на доступ з журналюванням.

60-90 днів

1. Ввести Data Contracts на подіях ігрового ядра і платежах.
2. Увімкнути Schema Registry з перевіркою сумісності на CI.
3. Налаштувати базовий лінійдж за ключовими потоками.
4. Оформити графіки зберігання/видалення і процедуру Legal Hold.
5. Узгодити KPI Governance і публікувати щомісячний звіт.

3-6 місяців

1. Сертифікувати «золоті» вітрини KPI і MDM реєстри (гравці/ігри/провайдери).
2. Включити observability даних (freshness, volume, drift), алерти і автотикети.
3. Провести аудит доступів і roll-back зайвих прав.
4. Каталог покриває ≥70% активних наборів, глосарій - топ-метрики.
5. Навчити стюардів і доменні команди (шаблони, чек-листи, SLO).

12) Ризики та анти-патерни

«Каталог заради каталогу» без володіння доменами.
Прихована «data shadow IT» (невраховані Excel/ноутбуки з PII).
Контракти без автоматичних перевірок сумісності.
Занадто жорстка централізація - черги і гальма.
Відсутність метрик якості та звітності - немає зворотного зв'язку.

13) Зв'язок з сусідніми практиками розділу

Якість даних, Моніторинг моделей, Дрейф даних, DSAR/Privacy, Legal Hold, Розгортання ML - все спирається на єдині політики, контракти, каталог і ролі.

Підсумок

Управління даними - це не тільки документи, а щоденні ритуали: хто володіє, як вимірюємо якість, за якими правилами змінюємо схеми, як даємо доступ і коли видаляємо. У iGaming виграє той, у кого дані достовірні, доступні і захищені, а рішення на їх основі - повторювані і перевіряються.