Як казино використовує telemetry для аналітики

Навіщо казино телеметрія

Телеметрія - це стандартизований потік подій про дії гравця і роботу платформи (ставки, депозити, помилки, якість стріму, фрод-патерни). Вона потрібна, щоб:

керувати P&L (GGR/NGR, LTV, утримання);
тримати SLO критичних шляхів (ставка, гаманець, каса);
виконувати комплаєнс (RG/KYC/AML/KYT) і знижувати ризики;
оптимізувати маркетинг (атрибуція, ROAS, інкрементальність);
підвищувати якість контенту (категорії, рекомендації, турніри).

Карта телеметрії: що збирати

1) Ігрові події

`lobby_impression`, `tile_click`, `game_launch`

`bet_place` (stake, gameId, roundId, paytable/market)
`bet_accept`, `bet_reject` (code, latency)
`round_settle` (outcome, payout, rtp_snapshot)
`void/refund` (reason_code)

2) Гроші і каса

`deposit_initiated/success/chargeback`

`withdrawal_request/approved/declined`
`wallet_debit/credit/hold_release`
`bonus_issued/wager_progress/wager_complete`
Джерело коштів/канал, валюта, FX-курс (зафіксований)

3) RG/Комплаенс

`rg_limit_set/updated/blocked_bet`

`session_timeout/self_exclusion`
`kyc_started/verified/failed`
`kyt_address_risk_scored` (on-chain), `aml_screening`

4) Маркетинг і продукт

`utm_attribution`, `install_referrer`, `campaign_view/click`

`onboarding_step`, `paywall_view`
`ab_variant_exposed`, `feature_flag_on/off`

5) Техкацтво і QoS

`api_latency` (endpoint, p95), `error_5xx`

`stream_qos` (fps, dropped_frames, webrtc_rtt, bitrate)

`provider_sla` (timeouts, aborted_rounds)

Контракт подій: єдиний словник

Принципи:

Єдина схема: обов'язкові поля'event','ts','playerId','sessionId','traceId','source','schemaVer'.
Грошові величини завжди як рядок/decimal +'currency'.
Часові значення в UTC з мілісекундами.
PII окремо: персональні дані не потрапляють в «сирий» потік продуктових подій.

Приклад'bet _ place':

json
{
"event": "bet_place",  "schemaVer": "1. 8",  "ts": "2025-10-17T14:23:11. 482Z",  "playerId": "p_82917",  "sessionId": "s_2f4c",  "traceId": "tr_b1d7",  "gameId": "pragm_doghouse_megaways",  "roundId": "R-2025-10-17-14:23:10-PRAGM-12",  "stake": {"amount":"2. 00","currency":"EUR"},  "wallet": {"type":"cash", "balanceBefore":"154. 40"},  "device": {"ua":"Mozilla/...","os":"Android","app":"web"},  "geo": {"country":"DE", "ip":"203. 0. 113. 5"},  "ab": {"exp":"lobby-grid","var":"B"}
}

Приклад'stream _ qos':

json
{
"event": "stream_qos",  "ts": "2025-10-17T14:23:12. 013Z",  "playerId": "p_82917",  "tableId": "evo_blackjack_23",  "webrtc_rtt_ms": 142,  "fps": 28,  "dropped_frames": 6,  "bitrate_kbps": 2400,  "network":"4g"
}

Пайплайн: від збору до інсайтів

1. Ingest: SDK/collector (web/app/server) → шина (Kafka/NATS) → stream-processing (Flink/Spark/Kafka Streams).

2. Storage ріл-тайм: ClickHouse/BigQuery (латентність секунд-хвилин), гарячі агрегати в Redis.

3. Batch-сховище: об'єкти (S3) для «сирих» подій (immutable, versioned).

4. Семантичний шар: єдині таблиці фактів/вимірів (players, sessions, bets, payments, rg_events).

5. Доставка/активація: дашборди (Grafana/Metabase/Looker), алерти, тригери персоналізації, зворотне вивантаження в марк-інструменти/CDP.

6. Data contracts: тести схем (CI), контроль сумісності, каталог даних (описи полів, SLA).

Ключові вітрини та моделі

Фанел маркетингу: `view → click → register → KYC → deposit → bet`. p95-час переходів, витоку, воронки по каналах/креативах.

Когорти та утримання: D1/D7/D30 retention, sticky factor (WAU/MAU), rolling-retention.

LTV і маржа: LTV per source/country/segment, payback-період, NGR після бонусів/комісій.

RTP/волатильність: за іграми/провайдерами/сегментами; відхилення від очікуваних діапазонів.

RFM-сегментація: recency/frequency/monetary → персональні оффери/ліміти.

RG-сигнали: нічні сесії, зростання частоти і суми ставок, скасування висновків, «догон» після програшу.

Фрод/AML/KYT: кореляція пристроїв/карт/адрес, velocity-правила, on-chain ризик-скор.

QoS лайва: вплив FPS/RTT на'bet _ reject'і churn; алерти на деградацію.

Real-time vs Batch

Real-time (секунди): антифрод, RG-блокування, алерти по SLO, персональні промо в сесії, ротація мереж/PSP.

Near-real-time (хвилини): дашборди менеджменту, кампанійні оптимізації, ліміти провайдерів.

Batch (годинник): звіти регуляторам, інкрементальні моделі LTV/Churn, атрибуція MMM.

Вбудовані метрики та алерти (приклад набору)

SLO API: `bet. place p95 < 200ms`, `error_rate < 0. 3%`, `settle_latency p95 < 2s`.

Game health: різке зростання'void/refund', падіння RTP нижче довірчого інтервалу.

Cashier: drop на кроці'3DS', зростання'declined _ by _ issuer'.

Live QoS: 'webrtc _ rtt _ ms> 300'у> 5% гравців регіону,'aborted _ rounds'> порогу.

RG: підряд> N сесій> X годин,'rg _ blocked _ bet'сплеск по сегменту.

Fraud: однакові карти/пристрої у декількох акаунтів, «каруселі» depozit→vyvod, повтори webhooks без idempotency.

Приватність і комплаєнс

PII-ізоляція: персональні дані в окремому домені/сховищі, лінк за псевдонімним'playerId'.

Мінімізація: «сирі» події без PII; enrich - тільки на сервері, по білому списку полів.

Retention: різні TTL для подій (ігрові/каса/лог-безпека) за вимогами юрисдикцій.

Правові підстави: consent/legitimate interest/contract; аудит доступу, маскування, видалення за запитом.

Immutable-логування: WORM для критичних журналів, контроль змін схем.

Приклад аналітичних розрахунків (ідеї)

Anomaly RTP: ковзне вікно по грі/столу; алерт при відхиленні> N σ.

Promo uplift: CUPED/інкрементальність A/B по'deposit _ rate'і'bet _ frequency'.

Churn-модель: градієнтний бустинг за ознаками 7-денної поведінки (частота/суми/QoS/відмови каси).

Real-time next best action: правило/модель на вітрині фіч → персональний оффер або порада зробити паузу (RG).

Анти-патерни

Змішування OLTP і OLAP: важкі звіти по бойовій БД ламають затримки ставок.

PII в сирих подіях і «витоку» в BI-дашборди.

Відсутність data contracts: «поле сьогодні рядок, завтра число».

Лічильники без traceId - неможливо зв'язати шлях гравця end-to-end.

«Сліпий» real-time без дедуплікації - подвійні дебети/виплати.

KPI без бізнес-контексту: дивитися тільки'pageviews'замість'TTFB→bet '/' CR deposit→bet'.

Абсолютні цифри без когортизації: не видно, хто дійсно приносить GGR.

Чек-лист впровадження телеметрії

Контракт і збір

Єдина схема подій, словник полів, версії, UTC-час.
SDK/collector для web/app/server; трейсинг («traceId») наскрізний.
Idempotency і дедуплікація на ingest.

Сховища та пайплайн

Kafka/NATS + ClickHouse/BigQuery; S3 - «сирі» події (immutable).
Семантичний шар: факти/вимірювання, тести сумісності (CI).
Дашборди real-time і batch; алерти SLO/QoS/RG/Fraud.

Безпека і приватність

PII-ізоляція, політика доступу (RBAC/ABAC), аудит.
Маскування, ретеншн, юридичні підстави, процедури видалення.

Моделі та дії

LTV/Retention/Churn, а також RG-правила real-time.
Атрибуція: UTM + post-install + інкрементальність.
Персоналізація: next best action/offer.

Експлуатація

Каталог даних і власники таблиць; SLO на вітрини.
Тести на регрес схем; моніторинг лагів і помилок ingest.
Навчання: реплей топіків, аварійне відновлення вітрин.

Телеметрія - це «нервова система» казино: вона пов'язує гроші, продукт, стрімінг, маркетинг і комплаєнс в одне кероване ціле. Суворий контракт подій, надійний пайплайн, приватність за замовчуванням і зв'язка real-time + batch перетворюють сирі логи в рішення: кого і чим утримувати, куди вкладати маркетинг, як покращувати UX і де знижувати ризики. Робіть телеметрію дисципліною - і платформа буде рости передбачувано і безпечно.