Tests A/B des règles de notation

L'attribution de points est le cœur de toute gamification. La façon dont les points sont considérés dépend du comportement des joueurs, de la structure de la participation et de l'économie (ARPPU, bonus-kosts). Voici une recette pratique pour tester la nouvelle règle des lunettes et s'assurer que la croissance des métriques est réelle, pas un artefact.

1) Exactement ce que nous testons

Exemples de règles :

Pour le montant des paris : 1 point pour chaque €1 pari.
Par multiplicateur win/bet : points = multiplicateur ⌊ × k ⌋, avec capuche par mise.
Hybride : points par tour + bouffon par « série » (N spins consécutifs), caps par minute/heure.
Missions : fix points pour l'exécution des tâches (T1...Tn) avec une complexité croissante.

Hypothèse (exemple) : « Le modèle « multiplicateur + cap » augmentera le taux de participation_net et de complétion sans détérioration de Net ARPPU (après prix/bonus) « .

2) Unité expérimentale et randomisation

Unité : utilisateur (pas de session, pas d'appareil).

Distribution : hachage statique (user_id → bucket) avec sels fixes ; parts 50/50 ou 33/33/33 pour A/B/C.

Stratification (recommandé) : payer-status (nouveaux payeurs/reverseurs/non payants), plate-forme, géo.

Sticky-assignment : l'utilisateur voit toujours la même règle pendant le test.

Vérification SRM (Sample Ratio Mismatch) : vérifiez quotidiennement les fractions réelles des groupes avec celles attendues (chi-carré). SRM est un signal de fuite de trafic, de filtrage erroné, de bugs.

3) Métriques et « vortex de lunettes »

Activité et participation

Reach : la part qui a vu l'évènement.

Participation_gross : Entrez/eligible.

Participation_net : ont commencé le progrès/eligible.

Complétion : terminé/commencé.

Qualité et argent

Δ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 : (chiffre d'affaires) − (prix + bonus + opérations + fuites frod).

Gardereila

Plaintes/support technique pour 1 000 USER, refus de KYC, modèles de paris anormaux, drapeaux RG (limites, auto-exclusion).

4) Durée, saisonnalité et nouveauté

Minimum de 2 cycles d'affaires complets (par exemple, 2 semaines pour capturer le week-end).

Tenez compte de l'effet novelty : sursaut des premiers 48-72 h. Fixez et analysez en phases (D0-D2, D3-D7, D8 +).

Ne pas croiser avec les gros promos ou planifier un « bruit égal » par groupe.

5) Puissance et volume de l'échantillon (exemple de calcul)

Objectif : détecter la différence de Δ en moyenne « points par utilisateur » (ou Net ARPPU).

Formule pour le test T à deux sélections (également dans les groupes) :

[
n_{\text{na groupe}} =\frac {2, (z_{1-\alpha/2}+z_{1-\beta}) ^ 2 ,\sigma ^ 2} {\Delta ^ 2}
]

Exemple : on veut attraper un Δ = 5 points, un σ = 120, un α = 0,05 (double face), une puissance de 80 % (β = 0,2).

(z_{1-α/2}=1{,}96), (z_{1-β}=0{,}84) → somme de 2,8 → carrés 7,84.

(\sigma^2 = 14,400).

(n =\frac {2\times 7 {,} 84\times 14.400} {25 }\approx\frac {225.792} {25 }\approx 9.032) par groupe.

💡 Résultat : ~ 9 100 utilisateurs par groupe (avec une marge de rejet et antifrod).

6) Réduction de la variance : rendre le test « moins cher »

CUPED : ajustement de régression pour les covariables pré-testées (p. ex. points/paris au cours de la semaine écoulée).

Covariables : drapeau payeur, transformations logiques, activité, plateforme, géo.

Clustering d'erreurs : au niveau de l'utilisateur (sessions répétées à l'intérieur).

7) Interférence et « détroits »

La règle des points ne peut pas seulement affecter les participants au test :

Comparaison sociale (leader général) → « spillover ».
Jackpots communs/missions conjointes → effet croisé.

Solutions :

Des leaders séparés par groupe ou une normalisation cachée des lunettes.
Randomisation en grappe par grappes de trafic/géo (plus cher mais plus propre).
Protocole Per (ITT) + analyses sensibles.

8) Antifrode et caps de règles

Tous les changements de lunettes stimulent l'optimisation : micropointes, bot, « fermes de lunettes ».

Protection minimale :

Cape points par minute/heure/jour et pour une mise.
Volatilité minimale des taux (interdiction des séquences « idéales »).
Détection headless/fingerprints répétitifs, proxy.
Vérification différée des grands prix + KYC.
Analyse : comparer « points/paris » et « points/min » de la distribution, chercher les queues.

9) Événements et schéma de données (minimum)

Événements :

`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}`

Manuels :

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

10) sketches SQL pour l'analyse

Vérification SRM (répartition par groupe) :

sql
SELECT group, COUNT() AS users
FROM assignments
WHERE test_id =:test
GROUP BY group;
-- ensuite hi-carré contre les parts attendues

Participation/Complétion par groupe :

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 et coût des prix/bonus :

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 (exemple) :

sql
-- pre_value : points/recettes avant le test ; valeur : pendant le test
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) Effets privés et hétérogénéité

Vérifiez les effets HET :

Débutants vs core, low-value vs high-value, différentes plates-formes/geo.
Parfois, la nouvelle formule de lunettes « allume » mid-core sans changer les baleines est le bon résultat.
Faites l'enregistrement préalable des segments pour ne pas attraper le « p-hacking ».

12) Pièges fréquents

1. Un leader commun pour tous les groupes → l'interférence.

2. Modifier la structure des prix pendant le test → incomparable.

3. La gamme de lunettes micro-paris → non-valides uplift.

4. SRM et « filtres flottants » dans ETL → des notes décalées.

5. S'appuyer sur l'ARPPU "sans déduction des prix/bonus.

6. Stop précoce en raison de fluctuations sans statistiques séquentielles correctes.

13) Fréquence Bayes vs et solutions successives

Cadre : vous pouvez utiliser l'approche bayésienne (différence de métriques post-période, probabilité « B est meilleur que A »), en particulier lors de la surveillance dans le temps.

Attention : les bandits pour les règles de lunettes sont appropriés après l'uplift confirmé - pendant la phase d'exploitation, pas sur la validation primaire.

14) Jeu responsable et conformité

Règles transparentes et capes : le joueur doit comprendre comment gagner des points.

Limites d'activité et de dépôt, « pauses » et conseils RG.

Pas de « pénalités » cachées pour le style de jeu.

15) Mini case (synthétique)

Contexte : event hebdomadaire, A = « points pour €1 pari », B = « points par multiplicateur win/bet, cap = 50/pari ».

Taille : 2 × 10 000 utilisateurs, stratification par statut payeur. SRM - oc.

Résultats :

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 €) avec Prix + Bonus per payer ≈ 6,4 € (inchangé).
Plaintes/1k : aucun changement ; drapeaux frod ↓0,3 p.p. aux frais des kaps.
Conclusion : la règle B est gagnante ; nous mettons à l'échelle avec la « longue queue » des prix et nous gardons les capes.

16) Chèque de lancement A/B par lunettes

Unité = utilisateur, sticky-assignment, stratification.
Leaders séparés/normalisation pour supprimer l'interférence.
Caps clairs sur lunettes, signaux antibot, KYC aux grands lauréats.
Préenregistrement des hypothèses et des métriques (primary/secondary/guardrails).
Plan de capacité et de durée, saisonnalité prise en compte.
CUPED/covariables connectés, pipline SRM-alerts.
Дашборд «Reach → Participation → Progress → Completion → Value».
Rapport : incrément dans l'argent après les prix/bonus, queue post-effet.

La règle du score est un levier de comportement. Conçu correctement, le test A/B (sans SRM, avec antifraude et covariables) vous permet d'augmenter en toute sécurité votre participation, complétion et Net ARPPU, tout en préservant la confiance des joueurs et l'économie des campagnes.