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) Міні-кейс (синтетичний)

Контекст: тижневий івент, А = «очки за €1 ставки», В = «очки по мультиплікатору 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, зберігаючи довіру гравців і економіку кампаній.