Métriques de gamification : DAU/WAU, participation, taux complet
La gamification ne fonctionne que lorsque son effet est confirmé par des chiffres. Voici l'analyse système de trois métriques de base, sans lesquelles il est impossible de gérer les missions, les événements et les récompenses : DAU/WAU, le taux de participation (participation) et le taux de complétion (achèvement).
1) DAU/WAU et « autocollant »
Définitions
DAU (Daily Active Users) est le nombre d'utilisateurs uniques avec une action ciblée en 24 heures (login, lancement du client, pari/spin, exécution des missions, etc.).
WAU (Weekly Active Users) sont des utilisateurs uniques avec une action ciblée au cours des 7 derniers jours.
DAU/WAU (Stick....) est la proportion de « actifs quotidiens » parmi les « hebdomadaires ».
[
\text{DAU/WAU} = \frac{\text{DAU}}{\text{WAU}} \quad (0\ldots1)
]Comment interpréter
0,15-0,25 est un autocollant « sain » de base pour les produits de divertissement avec un modèle non régulier.
0,25-0,35 est un bon niveau avec des missions régulières et une entrée facile.
Important : évaluer en coupe les segments (débutants, ré-activés, payants, mid-core, haute valeur). Le chiffre global masque facilement les problèmes.
Distorsions fréquentes
L'inflation est due aux jours de bonus. L'événement « hype » unique soulèvera le DAU, mais n'améliorera pas la tendance du DAU/WAU à l'horizon de 4 à 8 semaines.
Fausse multiactivité. Comptes de bottes/dupliqués. Déduplication obligatoire des signaux device-fingerprint + KYC.
Changement de « cible ». Si vous changez la règle « qui est considéré comme actif », fixez la date et construisez la métrique 2. 0».
2) Taux de participation (niveau de participation)
Définition
Proportion d'utilisateurs qui sont entrés dans le cycle de gamification (événement/mission/tournoi) parmi le public cible.
Formules de base :[
\text{Participation (gross)}=\frac{# \text{users_with_event_open}}{# \text{eligible_audience}}
][
\text{Participation (net)}=\frac{# \text{users_started_progress}}{# \text{eligible_audience}}
]Gross est tous ceux qui ont vu l'animateur et qui ont appuyé sur « participer ».
Net - ceux qui ont vraiment commencé l'exécution (par exemple, fait les premiers X points/spins/étapes de quête).
La bonne « dénomination »
« Eligible audience » à l'avance : par exemple, tous les utilisateurs actifs ≥1 fois au cours des 14 derniers jours et entrant dans la géo/règles.
Considérez séparément les communications reach (push, in-app, email). Faible participation, souvent = faible reach.
Normes et repères
Net participation 12-25 % pour les événements légers de masse.
5-12 % pour les évents « hardcore » avec seuil d'entrée (dépôt/niveau).
30 % + est atteint en micro-sprints pour les segments chauds (D1-D7 débutants, re-engagés).
3) Taux de complétion (achèvement)
Définition
Proportion de participants ayant terminé une mission/chaîne/événement.
[
\text{Completion Rate}=\frac{# \text{users_completed}}{# \text{users_started}}
]Variétés
Per-task completion - achèvement des étapes spécifiques de la chaîne (T1, T2,...).
Full-chain completion - achèvement de toute la règle.
Time-bounded completion - terminez jusqu'à la date limite.
Interprétation
Les normes dépendent de la longueur et du « prix » des tâches.
Simple mission solitaire : 60-85 %.
Chaîne de 3 à 5 étapes : 35 à 60 %.
Longue quête 7-10 étapes : 18-35 %.
Réduire la complétion dans les étapes tardives n'est pas toujours mauvais. Il peut s'agir d'un vortex de monétisation/complexité conscient. Il est important que Net Uplift reste positif et RG métrique - dans la zone verte.
4) Combinaison de métriques : « Vu → commencé → terminé »
Construisez un seul entonnoir :1. Reach : ils ont vu l'événement.
2. Participation (gross/net) : entrée/départ.
3. Progression : proportion de ceux qui atteignent les T1/T2/.../Tn (avec timing).
4. Complétion : terminé.
5. Value: ΔDAU/WAU, ΔRetention, ΔARPPU, ΔAvg Deposit, Bonus Cost%, Net Uplift.
Cela permet de capter les « fuites » : faible reach, barrières d'entrée, surchauffe de la complexité des étapes 2 à 3, échecs UX (mauvaise visibilité des progrès).
5) Analytique : segmentation et cohortes
Coupes recommandées :- Stage : Nouveaux D0-D7 retournés par les R7-R30, P30 permanents.
- Monetization : non payants, nouveaux payeurs (NPP), re-payants (RPP), haute valeur.
- Channel/Geo/Platform : web/iOS/Android, pays/réglementation.
- Contenu : type de mission (XP, dos, dépôt), volatilité des jeux, seuils.
Pour chaque groupe, fixez DAU/WAU, participation, complétion, ARPPU, Bonus Cost per Active - avant/pendant/après l'événement (D-window, W-window).
6) Conception expérimentale : nous prouvons l'incrément
Contrôle Holdout : une partie du public ne voit pas l'event (ou voit le « vide »).
Invitation randomisée : distribution aléatoire des invitations, nous enregistrons reach.
Geo/Channel Split : si le rand est interdit - matching soigné.
Fenêtre de mesure : effet « pendant » et tail post-événement (7-14 jours).
Métriques finales : Δ DAU/WAU, Δ Participation/Complétion, Δ ARPPU (net of bonus), Retraite D7/D30, Net Uplift.
7) DWH/événements : schéma de données minimum
Événements (exemple) :- `session_start {user_id, ts, platform}`
- `mission_view {user_id, mission_id, ts}`
- `mission_join {user_id, mission_id, ts}`
- `mission_progress {user_id, mission_id, step, value, ts}`
- `mission_complete {user_id, mission_id, ts}`
- `purchase/deposit {user_id, amount, ts}`
- `spin/bet {user_id, game_id, bet, win, ts}`
- `missions {mission_id, type, start_at, end_at, rules, segment, min_requirement, reward_type}`
- `users {user_id, geo, platform, signup_at, payer_flag, segments}`
8) Exemples de calculs (sketches SQL)
DAU pour la date d :sql
SELECT DATE(ts) AS d, COUNT(DISTINCT user_id) AS dau
FROM session_start
WHERE DATE(ts) =:d
GROUP BY 1;sql
SELECT COUNT(DISTINCT user_id) AS wau
FROM session_start
WHERE ts >=:d - INTERVAL '6 day' AND ts <:d + INTERVAL '1 day';sql
WITH dau AS (
SELECT COUNT(DISTINCT user_id) AS dau
FROM session_start
WHERE DATE(ts) =:d
), wau AS (
SELECT COUNT(DISTINCT user_id) AS wau
FROM session_start
WHERE ts >=:d - INTERVAL '6 day' AND ts <:d + INTERVAL '1 day'
)
SELECT dau::float / NULLIF(wau,0) AS dau_wau FROM dau, wau;sql
WITH elig AS (
SELECT user_id
FROM users
WHERE last_active_at >=:d - INTERVAL '14 day'
), started AS (
SELECT DISTINCT user_id
FROM mission_progress
WHERE mission_id =:m AND ts BETWEEN:start AND:end
)
SELECT COUNT(DISTINCT s. user_id)::float / NULLIF(COUNT(DISTINCT e. user_id),0) AS participation_net
FROM elig e
LEFT JOIN started s ON s. user_id = e. user_id;sql
WITH started AS (
SELECT DISTINCT user_id
FROM mission_progress
WHERE mission_id =:m AND ts BETWEEN:start AND:end
), completed AS (
SELECT DISTINCT user_id
FROM mission_complete
WHERE mission_id =:m AND ts BETWEEN:start AND:end
)
SELECT COUNT(DISTINCT c. user_id)::float / NULLIF(COUNT(DISTINCT s. user_id),0) AS completion_rate
FROM started s
LEFT JOIN completed c USING (user_id);9) Conception affectant la participation et la complétion
Visibilité : bannières au-dessus de la « ligne de pliage », badge sur l'icône « Mission », barre de progression sur l'écran d'accueil.
Clarté des règles : 1 écran = 1 objectif clé, exemples « comment marquer X points ».
Micro-récompenses sur le chemin : les luth-drops pour T1/T2/T3 → soutiennent la motivation.
Seuil d'entrée : ne surestimez pas les exigences à la première étape ; Compliquez-le à mesure que vous progressez.
Délais : sprints courts (2-24 h) pour les segments chauds, arcs hebdomadaires - pour les masses.
Indices dynamiques : « Il reste 120 points ≈ 8 rounds de 15 ».
10) Anti-distorsion et qualité des données
Déduplication : drapeaux device-fingerprint + KYC pour lutter contre le multi-accounting.
Anomalies : surtensions sans progrès → tracking ; completion> démarré → dupliqué.
Geler le schéma : toute modification des règles de l'entreprise - uniquement par le biais de la version des métriques.
Débogage temporel : stockez 'event _ time' et 'ingest _ time' ; les déplacements des fuseaux horaires sont une cause fréquente de « trous ».
11) Dashboard : que montrer quotidiennement
1. Autocollant : DAU, WAU, DAU/WAU (tendance 8 semaines, médiane par segment).
2. Entonnoir eventa : Reach → Participation gross/net → T1/T2/... → Completion.
3. Qualité : pannes (bounce), temps moyen avant la T1/T2, erreurs de suivi.
4. Valeur : Δ ARPPU (net of bonus), Δ Avg Deposit, Bonus Cost %, Net Uplift.
5. Segments : coupe par étape/geo/platform/payer-status.
6. Alertie : chute de participation> X p.p., échec du complétion à l'étape, déviation du DAU/WAU par rapport au modèle saisonnier.
12) Erreurs fréquentes
Compter la participation sur « toute la base » en ignorant les filtres éligibles.
Empêcher gross et net participation de tirer des conclusions « sur la moyenne ».
Optimiser uniquement le complétion, en surestimant la complexité et en coupant l'implication.
Il est aveugle de se réjouir de la croissance du DAU sans vérifier si l'autocollant (DAU/WAU) et le post-effet ont augmenté.
Ignorer la valeur des bonus/prix en interprétant mal la Δ ARPPU.
13) Chèque de lancement et d'évaluation
- Les événements et les dénominateurs sont définis.
- Règles commerciales fixées pour le DAU/WAU/participation/complétion (v1. 0).
- Configuré holdout/rand pour incrémenter.
- Dashboard en coupes de segments, plates-formes, géo.
- Alerts de qualité et contrôle antifrod.
- Évaluation finale : Δ DAU/WAU, Δ Participation/Complétion, Δ ARPPU (net), Net Uplift, post-effet 7-14 jours.
Le DAU/WAU montre l'habitude et le « collant » du produit, la participation - la capacité de l'event à impliquer le public cible, et le complétion - la qualité de l'équilibre de la complexité et de la récompense. Comptez-les selon des règles uniques, stockez les versions, vérifiez l'incrément et le prix de la croissance. La gamification sera alors un outil prévisionnel, pas une loterie.
