Как казино использует 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: одинаковые карты/устройства у нескольких аккаунтов, «карусели» депозит→вывод, повторы 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 и где снижать риски. Делайте телеметрию дисциплиной — и платформа будет расти предсказуемо и безопасно.