Оператор крипто-казино з 50 000 активних гравців виявив, що GGR падає на 15% квартал до кварталу. Причина — неоптимізовані бонуси та плаваючий RTP. Без якісної аналітики казино працює наосліп: бонусні кампанії витрачаються безконтрольно, відтік зростає.
Ми розробляємо системи аналітики для крипто-казино, які перетворюють сирі дані на управлінські рішення. Наша команда — сертифіковані інженери ClickHouse з 5+ річним досвідом в iGaming-аналітиці. Ми реалізували 30+ проєктів, що обробляють до 10 млн ставок на день. Один із клієнтів втрачав $250 000 щомісяця через неоптимізовані бонуси — після впровадження системи аналітики збиток скоротився на 40%. В іншому проєкті моніторинг RTP допоміг усунути баг у смарт-контракті, заощадивши $75 000 за квартал. Почніть із пілотного проєкту — отримайте перші метрики за 2 тижні.
Система будується на ClickHouse з моделлю star schema та ETL-пайплайнами на Python. Колонкова СКБД дає 10-50-кратне прискорення агрегацій порівняно з PostgreSQL. Star schema розділяє факти (ставки) і виміри (гравці, ігри), що спрощує масштабування. Дашборди в реальному часі дають повну картину бізнесу: від ігрової сесії до глобальних трендів. Проєкт від нуля до продакшену займає від 4 тижнів.
Ключові метрики аналітики крипто-казино
Ось показники, які ми відстежуємо:
| Метрика | Формула / Опис | Призначення |
|---|---|---|
| GGR | Ставки − Виграші | Валовий дохід |
| NGR | GGR − Бонуси − Рейкбек | Реальний дохід |
| RTP | (Виграші / Ставки) × 100% | Фактична віддача ігор |
| LTV | Прогнозований NGR за весь час | Цінність гравця |
| Churn Rate | % тих, хто пішов, за період | Утримання |
GGR, NGR та RTP — база для будь-якої аналітики. Без них неможливо оцінити ефективність бонусів, виявити точки зливу та спланувати ліквідність. Наприклад, якщо RTP по слоту перевищує 100%, це сигнал для негайного аудиту контракту.
Як побудувати ефективне аналітичне сховище?
Оптимальна архітектура — star schema на ClickHouse. Порівняно з PostgreSQL запити на агрегацію працюють у 10–50 разів швидше завдяки колонковому зберіганню. Приклад структури:
-- Fact table: кожна ставка CREATE TABLE fact_bets ( bet_id String, user_id String, game_id String, session_id String, bet_time DateTime, amount Decimal(24, 8), currency LowCardinality(String), winnings Decimal(24, 8), ggr Decimal(24, 8), is_free_bet Bool, bonus_used Nullable(String), game_category LowCardinality(String), country LowCardinality(String), device_type LowCardinality(String), ) ENGINE = MergeTree() PARTITION BY toYYYYMM(bet_time) ORDER BY (user_id, bet_time); -- Dimension: гравці CREATE TABLE dim_users ( user_id String, registration_date Date, country LowCardinality(String), acquisition_channel LowCardinality(String), vip_level LowCardinality(String), first_deposit_date Nullable(Date), total_deposits Decimal(24, 8), total_withdrawals Decimal(24, 8), ) ENGINE = ReplacingMergeTree() ORDER BY user_id; ETL-процес: від ставки до дашборду
За кожну годину ми збираємо сирі дані з операційної БД, трансформуємо та завантажуємо в ClickHouse. Приклад пайплайну:
class CasinoAnalyticsETL: async def run_hourly_aggregation(self): now = datetime.utcnow() hour_start = now.replace(minute=0, second=0, microsecond=0) bets = await self.bet_repo.get_settled_bets_since(hour_start - timedelta(hours=1)) rows = [self.transform_bet(bet) for bet in bets] if rows: await self.clickhouse.insert('fact_bets', rows) await self.update_materialized_views() def transform_bet(self, bet: Bet) -> dict: return { "bet_id": str(bet.id), "user_id": str(bet.user_id), "game_id": bet.game_id, "bet_time": bet.settled_at, "amount": float(bet.amount), "currency": bet.currency, "winnings": float(bet.winnings), "ggr": float(bet.amount - bet.winnings), "is_free_bet": bet.is_free_bet, "game_category": bet.game_category, "country": bet.user_country, "device_type": bet.device_type, } Матеріалізовані представлення автоматично оновлюються та віддають агрегати для дашбордів за мілісекунди. Помилки ETL логуються та обробляються за retry-політикою.
Аналітичні запити: когорти та RTP
Когортний аналіз утримання:
SELECT registration_cohort, days_since_registration, count(DISTINCT user_id) AS active_users, sum(ggr) AS cohort_ggr FROM ( SELECT b.user_id, toStartOfWeek(u.registration_date) AS registration_cohort, dateDiff('day', u.registration_date, b.bet_time) AS days_since_registration, b.ggr FROM fact_bets b JOIN dim_users u ON b.user_id = u.user_id WHERE b.bet_time >= now() - INTERVAL 180 DAY ) GROUP BY registration_cohort, days_since_registration ORDER BY registration_cohort, days_since_registration; Аналіз RTP по іграх:
SELECT game_id, game_category, count() AS bet_count, sum(amount) AS total_wagered, sum(winnings) AS total_paid, sum(ggr) AS total_ggr, sum(winnings) / sum(amount) AS actual_rtp, countIf(ggr < 0) AS losing_rounds, countIf(ggr >= 0) AS winning_rounds FROM fact_bets WHERE bet_time BETWEEN now() - INTERVAL 60 DAY AND now() AND NOT is_free_bet GROUP BY game_id, game_category ORDER BY total_wagered DESC; Як виявити аномалії в реальному часі?
Запит для пошуку підозрілої активності:
SELECT user_id, count() AS bet_count, sum(winnings) / sum(amount) AS rtp, sum(ggr) AS user_ggr, max(winnings) AS max_single_win FROM fact_bets WHERE bet_time >= now() - INTERVAL 7 DAY GROUP BY user_id HAVING rtp > 1.5 AND bet_count > 50 ORDER BY rtp DESC LIMIT 100; Ми доповнюємо цей запит динамічним порогом на основі ковзної середньої RTP. В одному проєкті такий моніторинг допоміг виявити баг у смарт-контракті, через який група гравців отримувала RTP 1.8 — збиток $75 000 за квартал було усунуто за 2 дні.
Інструменти дашбордів: порівняння
| Інструмент | Тип метрик | Завантаження дашборду | Рекомендація |
|---|---|---|---|
| Apache Superset | Фінансові, когортні | 1-2 сек | Для складної аналітики та звітів |
| Grafana | Операційні, реалтайм | <1 сек | Для моніторингу в реальному часі |
| Metabase | Прості, самообслуговування | 2-4 сек | Для невеликих команд |
Що входить в систему аналітики
- Аудит поточних даних і вимог — аналіз джерел, структури, якості даних.
- Проєктування star schema та ETL — модель даних під ваші метрики.
- Розробка пайплайнів — збір, трансформація, завантаження з моніторингом.
- Матеріалізовані представлення — оптимізовані агрегати для швидких дашбордів.
- Дашборди — 3 набори: операційний (реалтайм), фінансовий (GGR/NGR), когортний (LTV, утримання).
- Документація — опис схеми, дашбордів, інструкція з додавання нових ігор.
- Навчання команди — 2-3 сесії по роботі з системою.
- 3 місяці підтримки — виправлення помилок, оптимізація запитів, додавання метрик.
Процес розробки аналітичної системи
- Аудит поточних даних і вимог — 1 тиждень.
- Проєктування star schema та ETL — 1-2 тижні.
- Розробка пайплайнів і матеріалізованих представлень — 2-3 тижні.
- Налаштування дашбордів (3 типи) — 1 тиждень.
- Тестування точності метрик і продуктивності — 3-4 дні.
- Навчання команди та передача документації — 2 дні.
- 3 місяці підтримки — доопрацювання, виправлення помилок, оптимізація.
Скільки часу займає впровадження?
Базовий пілот з GGR, NGR, RTP і простими дашбордами — від 2 тижнів. Повноцінна система з когортним аналізом, фрод-детекцією та інтеграцією всіх ігор — від 4 до 8 тижнів. Точні терміни оцінюємо індивідуально після збору вимог.
Зв'яжіться з нами для безкоштовної попередньої оцінки вашого проєкту. Замовте розробку системи аналітики — отримайте прозорі метрики та контроль над бізнесом.