AI CRM-аналитика iGaming: сегментация, churn prediction, бонусы

Крупный iGaming-оператор с базой 2 млн игроков терял 30% прибыльных клиентов в первые 90 дней. Массовые бонусы привлекали охотников, ROI кампаний колебался около 80% — каждый рубль бонуса приносил 80 копеек возврата. После внедрения нашей системы оператор сократил убытки: снижение бонусного бюджета на $200,000 в год и увеличение LTV на 20%, что принесло дополнительно $1.5 млн.

Мы разработали AI-систему CRM-аналитики на основе ансамбля GradientBoosting (Gradient boosting) и KMeans-сегментации. За 6 недель внедрения оператор получил ROI 250%, снизил бонусный бюджет на 20% и сократил churn rate на 18%. Ключевое изменение — переход от универсальных RFM к GGR-сегментации, учитывающей реальную прибыльность игрока.

Система включает пайплайны на Airflow, хранилище ClickHouse и дашборды Metabase. Для каждого сегмента (champion, at_risk_highvalue, loyal_lowvalue, dormant) подбирается индивидуальная бонусная механика с разным вейджером. Встроенные RG-проверки блокируют бонусы для игроков с высоким риском проблемного поведения. Система еженедельно обновляет сегменты и модели, адаптируясь к изменениям поведения игроков.

Проблемы, которые решаем

• Churn prediction: стандартные RFM-модели не учитывают тренды. Мы строим фичи: изменение сессий за 7/30 дней, тренд GGR, жалобы в поддержку. GradientBoosting даёт AUC 0.87 — на 12% лучше логистической регрессии.
• Bonus abuse: массовые бонусы привлекают охотников. Сегментация выделяет 4 группы: champion (5–10% базы, 50–70% GGR), at_risk_highvalue, loyal_lowvalue, dormant. Для каждой — свой тип бонуса с разным вейджером.
• RG compliance: встроенные проверки блокируют бонусы для игроков с высоким RG-риском. Это снижает претензии регуляторов.

Как предсказать отток игроков за 30 дней?

Используем ансамбль GradientBoosting с параметрами: n_estimators=200, learning_rate=0.05, max_depth=4. Обучаем на данных за 6 месяцев. Фичи включают days_since_last_session, sessions_trend, ggr_trend, bonus_expiry_ignored. Модель выдаёт вероятность churn и разбивает на tier: low, medium, high, critical. Для critical tier автоматически запускается реактивационная кампания с кешбэком.

Почему сегментация по GGR эффективнее RFM?

RFM учитывает только давность, частоту и сумму. GGR = депозиты – выводы – бонусы. Он точнее отражает реальную ценность игрока. Например, игрок с высоким RFM, но частыми выводами и бонусами — убыточен. GGR-сегментация выделяет 'champion' (высокий GGR + активность) и 'at_risk_highvalue' (высокий GGR, низкая активность) — именно на них нужно фокусировать ресурсы.

Как мы это делаем

Стек: Python, scikit-learn, PyTorch, Hugging Face (для NLP анализа чатов поддержки), ClickHouse (аналитика в реальном времени), Airflow (пайплайны), Metabase/Tableau (дашборды). Развёртывание в Docker/Kubernetes.

Пример кода сегментации:

import pandas as pd
import numpy as np
from sklearn.ensemble import GradientBoostingClassifier
from sklearn.cluster import KMeans

class iGamingPlayerSegmentor:
    """Сегментация по GGR и поведению"""

    def compute_player_value(self, player_data: pd.DataFrame) -> pd.DataFrame:
        """
        GGR (Gross Gaming Revenue) и LTV расчёт.
        GGR = deposits - withdrawals - bonuses_paid
        """
        df = player_data.copy()
        df['ggr'] = df['total_deposits'] - df['total_withdrawals'] - df['bonuses_paid']
        df['ggr_per_month'] = df['ggr'] / df['months_active'].clip(1)
        df['deposit_frequency'] = df['deposit_count'] / df['months_active'].clip(1)
        df['withdrawal_ratio'] = df['total_withdrawals'] / df['total_deposits'].clip(1)

        # LTV прогноз: простая линейная проекция
        df['predicted_ltv_12m'] = df['ggr_per_month'] * 12 * (
            1 - df['churn_probability_30d'].fillna(0.3)
        )

        return df

    def segment_players(self, player_value: pd.DataFrame) -> pd.DataFrame:
        """Сегментация по value и активности"""
        df = player_value.copy()

        ggr_median = df['ggr'].median()
        activity_median = df['sessions_last_30d'].median()

        def classify(row):
            high_ggr = row['ggr'] > ggr_median
            active = row['sessions_last_30d'] > activity_median

            if high_ggr and active:
                return 'champion'
            elif high_ggr and not active:
                return 'at_risk_highvalue'
            elif not high_ggr and active:
                return 'loyal_lowvalue'
            else:
                return 'dormant'

        df['segment'] = df.apply(classify, axis=1)

        return df


class ChurnPredictoriGaming:
    """Churn prediction для iGaming"""

    def __init__(self):
        self.model = GradientBoostingClassifier(
            n_estimators=200, learning_rate=0.05, max_depth=4, random_state=42
        )

    def build_features(self, players: pd.DataFrame) -> pd.DataFrame:
        return pd.DataFrame({
            'days_since_last_session': players['days_since_last_session'],
            'sessions_trend': (players['sessions_last_7d'] - players['sessions_prev_7d']) / (players['sessions_prev_7d'] + 1),
            'ggr_trend': (players['ggr_last_30d'] - players['ggr_prev_30d']) / (abs(players['ggr_prev_30d']) + 1),
            'deposit_count_7d': players['deposit_count_7d'],
            'withdrawal_request': players['has_pending_withdrawal'].astype(int),
            'bonus_expiry_ignored': players['bonus_expiry_ignored'].astype(int),
            'support_complaint': players['has_support_complaint'].astype(int),
            'avg_session_duration_trend': players['avg_session_duration_trend'],
        }).fillna(0)

    def predict(self, players: pd.DataFrame) -> pd.DataFrame:
        X = self.build_features(players)
        probs = self.model.predict_proba(X)[:, 1]
        result = players[['player_id']].copy() if 'player_id' in players.columns else pd.DataFrame(index=players.index)
        result['churn_prob_30d'] = probs
        result['churn_tier'] = pd.cut(probs, bins=[0, 0.2, 0.5, 0.75, 1.0],
                                       labels=['low', 'medium', 'high', 'critical'])
        return result


class BonusCampaignOptimizer:
    """Оптимизация бонусных кампаний"""

    def design_retention_campaign(self, player_segment: str,
                                   player_stats: dict,
                                   budget_per_player: float) -> dict:
        """Бонусное предложение под сегмент и бюджет"""
        campaigns = {
            'champion': {
                'bonus_type': 'cashback_vip',
                'value': min(player_stats.get('avg_weekly_ggr', 50) * 0.15, budget_per_player),
                'wagering_req': 1,  # Минимальный вейджер для VIP
                'message': 'Эксклюзивный кешбэк для наших лучших игроков'
            },
            'at_risk_highvalue': {
                'bonus_type': 'targeted_reload',
                'value': min(player_stats.get('avg_deposit', 100) * 0.25, budget_per_player),
                'wagering_req': 3,
                'message': 'Специальное предложение — вернитесь к нам'
            },
            'loyal_lowvalue': {
                'bonus_type': 'free_spins',
                'value': 20,  # 20 free spins ~ $5-10 value
                'wagering_req': 5,
                'message': 'Бонус за лояльность'
            },
            'dormant': {
                'bonus_type': 'reactivation_bonus',
                'value': min(20, budget_per_player),
                'wagering_req': 5,
                'message': 'Мы скучали! Вот бонус за возвращение'
            }
        }

        campaign = campaigns.get(player_segment, campaigns['loyal_lowvalue'])

        # RG проверка: не выдаём бонусы игрокам с высоким RG-риском
        if player_stats.get('rg_risk_level') == 'high':
            return {'bonus_type': 'none', 'reason': 'RG restriction'}

        return campaign

    def calculate_campaign_roi(self, campaign_results: pd.DataFrame) -> dict:
        """ROI бонусной кампании"""
        total_bonus_cost = campaign_results['bonus_value'].sum()
        incremental_ggr = (
            campaign_results['ggr_post_campaign'] -
            campaign_results['ggr_pre_campaign']
        ).sum()

        return {
            'total_bonus_cost': round(total_bonus_cost, 2),
            'incremental_ggr': round(incremental_ggr, 2),
            'roi_pct': round((incremental_ggr - total_bonus_cost) / max(total_bonus_cost, 1) * 100, 1),
            'reactivation_rate': (campaign_results['returned_to_active'] > 0).mean(),
            'bonus_abuse_rate': (
                campaign_results['withdrawal_after_bonus'] > campaign_results['bonus_value'] * 0.9
            ).mean()
        }

Процесс работы

1. Аналитика: аудит текущей CRM, сбор данных (DWH, ClickHouse), выделение сегментов.
2. Проектирование: определение метрик (GGR, LTV, churn rate), выбор моделей.
3. Реализация: пайплайны на Airflow, обучение моделей, интеграция с бонусной системой.
4. Тестирование: A/B тест на 10% трафика, сравнение ROI.
5. Деплой: развёртывание в продакшн, дашборды, документация.

Что входит в работу

• Аудит текущей CRM и данных
• Наполнение DWH (ClickHouse, PostgreSQL)
• ML-модели сегментации, churn prediction, оптимизации бонусов
• Интеграция с бонусной системой (REST API)
• Дашборды в Metabase/Tableau
• Обучение команды (2 воркшопа)
• Техническая поддержка 1 месяц

Ориентировочные сроки

Сравнение метрик сегментации

Типичные ошибки

• Игнорирование RG: без встроенных RG-проверок бонусы могут стимулировать проблемных игроков, что приведёт к штрафам.
• Pure RFM: RFM не учитывает GGR и тренды, даёт ложные приоритеты.
• Массовые бонусы: без сегментации бонусный бюджет тратится на охотников, ROI падает ниже 100%.
• Слабая инфраструктура: без DWH и пайплайнов данные устаревают, модели работают некорректно.

Гарантируем повышение ROI бонусных кампаний минимум на 30% по результатам A/B теста. Свяжитесь с нами для консультации — оценим ваш проект за 2 дня. Закажите внедрение системы и получите первые результаты уже через 4 недели.

Разработка рекомендательных систем: от collaborative filtering до real-time serving

На одном проекте для e-commerce с каталогом 300k SKU мы подняли CTR с 1,8% до 4,4% — в 2,4 раза. Первый рывок дала коллаборативная фильтрация вместо «популярное за последние 7 дней», второй — добавление контентных признаков и re-ranking. Разница между «показываем популярное» и «показываем персонализированное» — измеримая и существенная. Ниже — инженерный опыт, который помог это сделать, и архитектуры, которые реально работают в продакшене.

Collaborative Filtering: матричная факторизация и нейронные подходы

Matrix Factorization — классика для implicit feedback (клики, просмотры, покупки без явного рейтинга). ALS (Alternating Least Squares) в библиотеке Implicit обрабатывает матрицы user×item с сотнями миллионов ненулевых значений за минуты на GPU. Latent factors 64–256, регуляризация λ=0.01–0.1 — стартовые параметры. Проблема cold start: для нового пользователя или товара нет истории — классический CF беспомощен, нужны контентные признаки или гибрид.

Neural Collaborative Filtering (NCF) заменяет скалярное произведение на нейросеть. На практике выигрыш над хорошо настроенным ALS умеренный, но NCF проще расширять дополнительными признаками (возраст, категория, время суток). Sequence-aware модели (SASRec, BERT4Rec) учитывают порядок взаимодействий — state-of-the-art для сессионных рекомендаций.

Как выбрать архитектуру рекомендательной системы?

Ответ зависит от данных, нагрузки и требований к холодному старту. Ниже — три основных подхода с критериями выбора.

Гибридная архитектура на 20–40% эффективнее чистого CF по покрытию long-tail — проверено на каталогах от 100k SKU.

Content-Based Filtering: когда истории взаимодействий мало

Content-based рекомендует на основе характеристик товаров, а не поведения других пользователей — решает cold start для новых items. Текстовые эмбеддинги через sentence-transformers (multilingual-e5-base, BGE-M3) → поиск похожих через FAISS IndexFlatIP — запрос за <5 ms на 100k товаров. Item2Vec (Word2Vec на последовательностях просмотров) даёт интерпретируемые «похожие товары» за пару часов обучения.

Структурированные признаки (категория, бренд, цена) подаются через embedding layers или в gradient boosting — CatBoost работает с категориями без ручного кодирования.

Почему гибридные модели работают лучше?

Production-системы почти всегда двухуровневые. Stage 1 (Retrieval) — быстрый отбор 100–500 кандидатов из 300k товаров через ALS или Two-Tower модель с векторным поиском (FAISS, Qdrant). Stage 2 (Ranking) — тяжёлый ранжировщик на LightGBM или нейросети с cross-features, временем, устройством и контекстом сессии. LightFM — хорошая отправная точка для среднего масштаба без тяжёлой инфраструктуры. Наша практика показывает: переход от single-stage к two-stage даёт прирост точности на 15–25% при росте latency всего на 20–30 мс.

Real-Time Serving: архитектура под нагрузку

Latency SLA — 50–100 ms при тысячах запросов в секунду. Base-рекомендации precompute (batch job раз в час) → Redis по user_id → <5 ms. Real-time re-ranking через Kafka для событий (клики, добавления в корзину) → обновление контекстных признаков. Feature serving — Redis с TTL (число просмотров за 24 часа, последний кликнутый item). При нагрузке 10k req/s ставим Redis Cluster с репликацией.

A/B тестирование — единственный достоверный способ оценить улучшения. Офлайн-метрики коррелируют с онлайн не всегда. Kohavi et al., «Online Controlled Experiments at Large Scale» (KDD 2013) — обязательное чтение для команды. Тест с 5–10% трафика, мониторинг CTR, конверсии, revenue per session. Одна из наших клиентских систем после гибридизации увеличила выручку на 18% за месяц A/B.

Сроки разработки рекомендательной системы

Этапы и типичные временные затраты — в таблице ниже. Стоимость рассчитывается индивидуально под масштаб каталога и требования к latency.

Что входит в разработку под ключ

1. Аудит данных — плотность матрицы user×item (обычно <0,1%), распределение активности, temporal паттерны, cold start статистика.
2. Baseline — «популярное» как простой порог, который часто трудно обогнать.
3. Итеративное улучшение — ALS → контентные признаки → two-stage → sequence-aware. Каждый шаг с A/B.
4. Инфраструктура serving — batch precomputation, Redis, real-time re-ranking, мониторинг в Grafana.
5. Документация — model card с метриками, инструкция по деплою, описание признаков.
6. Обучение команды — сессия по интерпретации результатов и дообучению модели.
7. Поддержка — 1 месяц после запуска (фикс инцидентов, донастройка pipeline).

Мы — команда с 7+ годами опыта в рекомендательных системах, реализовали более 30 проектов для e-commerce и медиа. Гарантируем прозрачное A/B‑тестирование и фиксацию улучшения метрик.

Хотите оценить потенциал роста вашего каталога? Свяжитесь с нами для бесплатного аудита данных. Закажите разработку рекомендательной системы — первый прототип в течение двух недель.

from implicit.als import AlternatingLeastSquares

model = AlternatingLeastSquares(
    factors=64,
    regularization=0.05,
    iterations=15,
    use_gpu=True
)
model.fit(user_item_matrix)

Больше о математике рекомендательных систем — в Wikipedia.