A/B-тесты правил начисления очков

Начисление очков — сердце любой геймификации. От того, как именно считаются очки, зависит поведение игроков, структура участия и экономика (ARPPU, бонус-косты). Ниже — практический рецепт, как валидно протестировать новое правило очков и убедиться, что рост метрик реален, а не артефакт.

1) Что именно тестируем

Примеры правил:

По сумме ставок: 1 очко за каждые €1 ставки.
По мультипликатору win/bet: очки = ⌊множитель×k⌋, с капом за ставку.
Гибрид: очки за оборот + буст за «серии» (N спинов подряд), капы по минуте/часу.
Миссии: фикс-очков за выполнение задач (T1…Tn) с нарастающей сложностью.

Гипотеза (пример): «Модель “мультипликатор + кап” повысит participation_net и completion rate без ухудшения Net ARPPU (после призов/бонусов)».

2) Экспериментальная единица и рандомизация

Единица: пользователь (не сессия, не устройство).

Распределение: статический хэш (user_id → bucket) с фиксированными солями; доли 50/50 или 33/33/33 для A/B/C.

Стратификация (рекомендуется): payer-status (новые платящие/повторно платящие/неплатящие), платформа, гео.

Sticky-assignment: пользователь всегда видит одно и то же правило в течение теста.

Проверка SRM (Sample Ratio Mismatch): ежедневно сверяйте фактические доли групп с ожидаемыми (хи-квадрат). SRM — сигнал утечки трафика, ошибочной фильтрации, багов.

3) Метрики и «воронка очков»

Активность и участие

Reach: доля, кто увидел ивент.

Participation_gross: вступили / eligible.

Participation_net: начали прогресс / eligible.

Completion: завершили / начали.

Качество и деньги

ΔDAU/WAU и stickiness (DAU/WAU).

Avg Bets per Session, Avg Bet Size.

ARPPU (net) = ARPPU − (Prize + Bonus Cost per payer).

Avg Deposit, Paying Share.

Net Uplift: (доп. выручка) − (призы+бонусы+операционные+фрод-утечки).

Гардерейлы

Жалобы/техподдержка на 1 000 юзеров, отказы по KYC, аномальные паттерны ставок, RG-флаги (лимиты, самоисключение).

4) Длительность, сезонность и новизна

Минимум 2 полных бизнеса-цикла (например, 2 недели, чтобы захватить выходные).

Учтите novelty-effect: всплеск первых 48–72 ч. Фиксируйте и анализируйте фазами (D0–D2, D3–D7, D8+).

Не пересекать с крупными промо, либо планировать «равный шум» по группам.

5) Мощность и объём выборки (пример расчёта)

Цель: обнаружить разницу Δ по средней «очков на пользователя» (или Net ARPPU).

Формула для двухвыборочного t-теста (поровну в группах):

[
n_{\text{на группу}} = \frac{2,(z_{1-\alpha/2}+z_{1-\beta})^2,\sigma^2}{\Delta^2}
]

Пример: хотим поймать Δ = 5 очков, σ = 120, α = 0,05 (двусторонний), мощность 80% (β=0,2).

(z_{1-α/2}=1{,}96), (z_{1-β}=0{,}84) → сумма 2,8 → квадрат 7,84.

(\sigma^2 = 14,400).

(n = \frac{2 \times 7{,}84 \times 14,400}{25} \approx \frac{225,792}{25} \approx 9,032) на группу.

💡 Итог: ~9 100 пользователей на группу (с запасом на отбраковку и антифрод).

6) Снижение дисперсии: делаем тест «дешевле»

CUPED: регрессионная корректировка на предтестовые ковариаты (например, очки/ставки за прошедшую неделю).

Ковариаты: payer-флаг, лог-трансформы оборота, активность, платформа, гео.

Кластеризация ошибок: на уровне пользователя (повторные сессии внутри).

7) Интерференция и «проливы»

Правило очков может влиять не только на участников теста:

Социальное сравнение (лидерборд общий) → «spillover».
Общие джекпоты/совместные миссии → кросс-эффект.

Решения:

Раздельные лидерборды по группам или скрытая нормализация очков.
Кластерная рандомизация по кластерам трафика/гео (дороже, но чище).
Пер-протокол (ITT) + чувствительные анализы.

8) Антифрод и капы правил

Любые изменения очков стимулируют оптимизацию: микроставки, ботоводство, «фермы очков».

Минимальные защиты:

Кап очков в минуту/час/сутки и за одну ставку.
Минимальная волатильность ставок (запрет «идеальных» последовательностей).
Детекция headless/повторяющихся fingerprints, прокси.
Отложенная верификация крупных призов + KYC.
Аналитика: сравнивайте «очков/ставок» и «очков/мин» распределения, ищите хвосты.

9) События и схема данных (минимум)

События:

`session_start {user_id, ts, platform}`
`event_view {user_id, event_id, ts}`
`event_join {user_id, event_id, ts}`
`points_awarded {user_id, event_id, rule_id, amount, source, ts}`
`mission_progress {user_id, mission_id, step, value, ts}`
`mission_complete {user_id, mission_id, ts}`
`bet {user_id, game_id, bet, win, ts}`
`deposit {user_id, amount, ts}`

Справочники:

`rules {rule_id, name, params, caps_minute, caps_hour, caps_day, version}`
`assignments {user_id, test_id, group, assigned_at}`

10) SQL-скетчи для анализа

SRM-проверка (распределение по группам):

sql
SELECT group, COUNT() AS users
FROM assignments
WHERE test_id =:test
GROUP BY group;
-- далее хи-квадрат против ожидаемых долей

Participation/Completion по группам:

sql
WITH eligible AS (
SELECT user_id FROM users
WHERE last_active_at >=:start - INTERVAL '14 day'
), joined AS (
SELECT DISTINCT user_id FROM event_join
WHERE event_id =:event AND ts BETWEEN:start AND:end
), started AS (
SELECT DISTINCT user_id FROM mission_progress
WHERE ts BETWEEN:start AND:end AND mission_id IN (:missions)
), completed AS (
SELECT DISTINCT user_id FROM mission_complete
WHERE ts BETWEEN:start AND:end AND mission_id IN (:missions)
)
SELECT a.group,  COUNT(DISTINCT j.user_id)::float/COUNT(DISTINCT e.user_id) AS participation_gross,  COUNT(DISTINCT s.user_id)::float/COUNT(DISTINCT e.user_id) AS participation_net,  COUNT(DISTINCT c.user_id)::float/NULLIF(COUNT(DISTINCT s.user_id),0) AS completion
FROM eligible e
JOIN assignments a USING (user_id)
LEFT JOIN joined j USING (user_id)
LEFT JOIN started s USING (user_id)
LEFT JOIN completed c USING (user_id)
WHERE a.test_id =:test
GROUP BY a.group;

Net ARPPU и стоимость призов/бонусов:

sql
WITH payors AS (
SELECT DISTINCT user_id FROM payments
WHERE ts BETWEEN:start AND:end
), rev AS (
SELECT user_id, SUM(ggr) AS ggr
FROM revenue
WHERE ts BETWEEN:start AND:end
GROUP BY user_id
), costs AS (
SELECT user_id, SUM(prize + bonus) AS cost
FROM promo_costs
WHERE ts BETWEEN:start AND:end
GROUP BY user_id
)
SELECT a.group,  AVG(COALESCE(r.ggr,0) - COALESCE(c.cost,0)) FILTER (WHERE p.user_id IS NOT NULL) AS net_arppu
FROM assignments a
LEFT JOIN payors p USING (user_id)
LEFT JOIN rev r USING (user_id)
LEFT JOIN costs c USING (user_id)
WHERE a.test_id =:test
GROUP BY a.group;

CUPED (пример):

sql
-- pre_value: очки/выручка до теста; value: во время теста
SELECT group,    AVG(value - theta pre_value) AS cuped_mean
FROM (
SELECT a.group, x.user_id, x.value, x.pre_value,     (SELECT COVAR_SAMP(value, pre_value)/VAR_SAMP(pre_value)
FROM x) AS theta
FROM assignments a
JOIN x ON x.user_id = a.user_id
WHERE a.test_id =:test
) t
GROUP BY group;

11) Частные эффекты и гетерогенность

Проверяйте HET-эффекты:

Новички vs core, low-value vs high-value, разные платформы/гео.
Иногда новая формула очков «зажигает» mid-core без изменения китов — это нужный исход.
Делайте пред-регистрацию сегментов, чтобы не ловить «p-hacking».

12) Частые ловушки

1. Общий лидерборд для всех групп → интерференция.

2. Изменение структуры призов во время теста → несравнимость.

3. Фарм очков микроставками → невалидный uplift.

4. SRM и «плавающие фильтры» в ETL → смещённые оценки.

5. Опора на «нагрязную» ARPPU без вычета призов/бонусов.

6. Ранний стоп из-за флюктуаций без корректной последовательной статистики.

13) Байес vs частота и последовательные решения

Фреймворк: можно использовать байесовский подход (постериорная разница метрик, вероятность «B лучше A»), особенно при мониторинге во времени.

Осторожно: бэндиты для правил очков уместны после подтверждённого uplift — на этапе эксплуатации, не на первичной валидации.

14) Ответственная игра и комплаенс

Прозрачные правила и капы: игрок должен понимать, как зарабатывает очки.

Лимиты активности и депозитов, «паузы» и RG-подсказки.

Никаких скрытых «штрафов» за стиль игры.

15) Мини-кейс (синтетический)

Контекст: недельный ивент, A=«очки за €1 ставки», B=«очки по мультипликатору win/bet, кап=50/ставку».

Размер: 2×10 000 пользователей, стратификация по payer-статусу. SRM — ок.

Результаты:

Participation_net: A 17,3% → B 22,1% (+4,8 п.п.).
Completion: A 38,9% → B 44,0% (+5,1 п.п.).
Net ARPPU: A €41,2 → B €43,5 (+€2,3) при Prize+Bonus per payer ≈ €6,4 (не изменился).
Жалобы/1k: без изменений; фрод-флаги ↓0,3 п.п. за счёт капов.
Вывод: правило B — победитель; масштабируем с «длинным хвостом» призов и сохраняем капы.

16) Чек-лист запуска A/B по очкам

Единица = пользователь, sticky-assignment, стратификация.
Раздельные лидерборды/нормализация, чтобы убрать интерференцию.
Чёткие капы на очки, антибот-сигналы, KYC крупным призёрам.
Пререгистрация гипотез и метрик (primary/secondary/guardrails).
План мощности и длительности, сезонность учтена.
CUPED/ковариаты подключены, пайплайн SRM-алертов.
Дашборд «Reach → Participation → Progress → Completion → Value».
Отчёт: инкремент в деньгах после призов/бонусов, хвост post-effect.

Правило начисления очков — это рычаг поведения. Корректно спроектированный A/B-тест (без SRM, с антифродом и ковариатами) позволяет безопасно увеличить участие, completion и Net ARPPU, сохраняя доверие игроков и экономику кампаний.