Faut-il vraiment déployer cette nouvelle version de l'application ?
Contexte
Analyse de données sur un jeu mobile hyper-casual. Deux builds sont déployées en parallèle : la v10.2 (référence) et la v11.0 (rollout progressif). Objectif : déterminer si la nouvelle build est saine, ou s'il faut mettre en pause le rollout 100%.
Deux angles d'analyse :
- Angle Produit / Publishing — v11.0 est-elle meilleure, équivalente, ou pire que v10.2 ? Focus sur la rétention et l'engagement.
- Angle Game Design — si v11.0 sous-performe, pourquoi ? Le problème est-il global, ou concentré sur un niveau spécifique ?
Données
Deux extraits préagrégés couvrant les 90 derniers jours d'installations Android. Ci-dessous les 5 premières lignes de chaque table, pour montrer le grain réel des données.
user_activity — activité quotidienne par cohorte
~85K lignes. Une ligne par date d'install × version × pays × réseau × package × jour de cohorte. Les KPIs de rétention, sessions et temps de jeu se calculent sur cette table.
| d_install_date | s_app_name | s_app_version | s_os | s_country | s_acquisition_network | s_installing_pckg_group | i_cohort_groups | f_playtime | i_active_users | i_count_sessions |
|---|---|---|---|---|---|---|---|---|---|---|
| 2026-02-02 | Wonders Kingdom | 10.2 | android | BR | AppLovin | com.android.vending | 0 | 105410.2 | 42 | 116 |
| 2026-02-02 | Wonders Kingdom | 10.2 | android | BR | AppLovin | com.android.vending | 1 | 64774.0 | 25 | 66 |
| 2026-02-02 | Wonders Kingdom | 10.2 | android | BR | AppLovin | com.android.vending | 2 | 46151.4 | 13 | 44 |
| 2026-02-02 | Wonders Kingdom | 10.2 | android | BR | AppLovin | com.android.vending | 3 | 10524.5 | 8 | 16 |
| 2026-02-02 | Wonders Kingdom | 10.2 | android | BR | AppLovin | com.android.vending | 4 | 26027.9 | 8 | 25 |
progression — funnel niveau par niveau par cohorte
~530K lignes. Même grain, plus i_level : démarrages, complétions, échecs et temps de jeu pour chaque niveau. Le fail rate et le temps de jeu par niveau viennent d'ici.
| d_install_date | s_app_name | s_app_version | s_os | s_country | s_acquisition_network | s_installing_pckg_group | i_cohort_groups | i_level | i_level_started | i_level_completed | i_level_failed | i_users | f_play_time |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2026-02-02 | Wonders Kingdom | 10.2 | android | BR | AppLovin | com.android.vending | 0 | 1 | 43 | 41 | 2 | 42 | 8151.4 |
| 2026-02-02 | Wonders Kingdom | 10.2 | android | BR | AppLovin | com.android.vending | 0 | 2 | 44 | 40 | 4 | 40 | 8306.7 |
| 2026-02-02 | Wonders Kingdom | 10.2 | android | BR | AppLovin | com.android.vending | 0 | 3 | 33 | 33 | 0 | 33 | 4650.9 |
| 2026-02-02 | Wonders Kingdom | 10.2 | android | BR | AppLovin | com.android.vending | 0 | 4 | 26 | 23 | 3 | 23 | 2850.0 |
| 2026-02-02 | Wonders Kingdom | 10.2 | android | BR | AppLovin | com.android.vending | 0 | 5 | 12 | 11 | 1 | 11 | 1728.7 |
Métriques clés
v10.2 vs v11.0
v10.2 en bleu foncé, v11.0 en rouge.
La v11.0 sous-performe sur toutes les métriques clés : la rétention perd 4 à 6 points à chaque jalon (D1, D3, D7), et l'engagement s'effondre — –13% de sessions par utilisateur et –28% de temps de jeu. Le détail des métriques suit ci-dessous.
Méthodologie
- Stack : Python + DuckDB pour l'agrégation SQL, Matplotlib/Seaborn pour la viz.
- Cohortes : une cohorte est le groupe d'utilisateurs ayant installé l'application le même jour (
d_install_date), avec la même version d'app, le même pays, le même réseau d'acquisition et le même package d'installation — cette combinaison de colonnes définit une cohorte, et chaque ligne appartient à une. - Rétention :
SUM(active_DN) / SUM(d0_users). Le dénominateur D0 est dynamique : seuls les segments ayant encore une activité au jour N entrent au numérateur et au dénominateur, pour éviter de diluer la rétention par des cohortes déjà mortes. - Taux d'échec :
SUM(i_level_failed) / SUM(i_level_started)par version × niveau. - Engagement :
SUM(sessions) / SUM(active_users)etSUM(playtime) / SUM(active_users). - Fenêtre d'observation : tous les KPIs sont calculés sur les jours 0 à 7 après l'installation —
i_cohort_groups BETWEEN 0 AND 7, où D0 est le jour d'install et D7 sept jours plus tard.
Rétention
Rétention globale D0–D7
Part des utilisateurs actifs à chaque jour de cohorte.
La chute est continue depuis le D1 — pas un drop isolé mais une dégradation systémique, qui suggère un problème structurel de la build plutôt qu'un bug ponctuel.
Focus US vs Global
Rétention : US (pointillés) vs Global (plein)
Vérifier si la régression est géographique ou globale.
Les US sont le premier marché, et suivent la même tendance que le global. Pas de disparité régionale marquée — le problème n'est pas géographique. Si dégradation il y a, elle est liée à la build elle-même, pas à un mix d'acquisition.
Engagement
Engagement global par utilisateur (D0–D7)
Sessions ouvertes par utilisateur actif et temps de jeu cumulé par utilisateur.
Sessions par utilisateur
Temps de jeu par utilisateur
Chaque utilisateur v11.0 ouvre 13% de sessions en moins (2.29 vs 2.64) et accumule 28% de temps de jeu en moins (31 min vs 44 min). La baisse d'engagement indique soit que les utilisateurs se sont ennuyés, soit qu'ils ont été découragés par le niveau de difficulté.
Sessions & temps de jeu par jour de cohorte
Engagement journalier par utilisateur (D0–D7)
Évolution jour par jour — pour voir si la chute s'installe à un moment précis.
Sessions / user / jour
Temps de jeu / user / jour
La chute d'engagement est là dès le D0 (jour d'installation) et reste constante jour après jour — les users v11.0 ouvrent moins de sessions et jouent moins chaque jour, pas seulement au fil du temps.
Focus US vs Global
Engagement : US vs Global
Comparaison directe des deux régions par build.
Sessions / user
Temps de jeu / user
Taux d'échec par niveau
Taux d'échec par niveau (Global)
Part des tentatives échouées sur le total des tentatives à chaque niveau (1–30).
Marqueur vertical au niveau 7 — point de divergence critique entre les deux builds.
Le Niveau 7 est le point de divergence critique. Taux d'échec : 14.2% (v10.2) → 60.4% (v11.0) — soit +46 pp et un taux 4.2× plus élevé. C'est le seul niveau avec une telle cassure — et il intervient tôt dans le funnel, juste après l'onboarding. Les niveaux 1 à 6 sont quasi identiques entre les builds ; à partir de L8, la pénalité de fail rate reste dans la fourchette +8 à +18 pp jusqu'à L20+. Conclusion : la v11.0 a globalement durci la difficulté, avec un spike catastrophique au L7.
Top 10 des écarts de difficulté (v11.0 − v10.2)
| Niveau | Fail rate v10.2 | Fail rate v11.0 | Écart (pp) |
|---|---|---|---|
| Level 7 | 14.2% | 60.4% | +46.1 pp |
| Level 27 | 52.5% | 70.8% | +18.3 pp |
| Level 29 | 60.0% | 71.4% | +11.5 pp |
| Level 23 | 43.6% | 54.7% | +11.1 pp |
| Level 24 | 44.5% | 53.5% | +9.0 pp |
| Level 10 | 19.7% | 28.6% | +8.9 pp |
| Level 18 | 33.2% | 42.1% | +8.9 pp |
| Level 14 | 24.3% | 32.9% | +8.6 pp |
| Level 13 | 22.9% | 31.4% | +8.4 pp |
| Level 21 | 39.3% | 47.7% | +8.4 pp |
Niveau 7 domine largement (+46 pp) — seul point de divergence critique. Les 9 autres niveaux cumulent +8 à +18 pp.
Focus US vs Global
Taux d'échec : US (pointillés) vs Global (plein)
Vérifier si la dégradation de difficulté se retrouve à l'identique aux US.
Les US suivent la tendance globale partout jusqu'au L20, avec une volatilité plus forte après — cohérent avec un échantillon US plus réduit. Le spike du L7 est présent partout, ce qui confirme un problème de design du niveau, pas un mix d'acquisition.
Temps de jeu par niveau
Temps de jeu moyen par utilisateur et par niveau (Global)
Temps passé par utilisateur actif, par niveau — pour identifier où le playtime se perd.
Le temps de jeu par niveau reste globalement constant dans les deux builds. Les spikes marquent les niveaux plus difficiles (les users réessayent, donc chaque niveau prend plus de temps) : le spike du L7 en v11.0 reflète son taux d'échec de 60%, et les spikes L27–L29 montrent que la difficulté monte sur les derniers niveaux. La différence est la forme : la v10.2 progresse régulièrement à mesure que les niveaux avancent, tandis que la v11.0 saute irrégulièrement — suivant sa courbe de difficulté plus heurtée.
Recommandations
Équipe Publishing
- Mettre en pause le rollout 100% de v11.0 — elle sous-performe sur tous les KPIs (rétention D1/D3/D7, engagement).
- Attendre un fix pour le Niveau 7, puis lancer un A/B test avant de repousser le rollout.
- Re-exécuter l'analyse post-fix pour confirmer l'amélioration des métriques clés (D1, D3 surtout, signaux de rollout les plus fiables).
Équipe Game Design
- Restaurer le Niveau 7 à sa version v10.2 — c'est la cause racine principale de la chute de rétention.
- Rééquilibrer la courbe de difficulté sur L8–L20+ : la progression des niveaux doit être une ligne fluide plutôt que des à-coups de difficulté allant de +8 à +18 pp. La progression de difficulté idéale à intégrer dans chaque niveau doit être réévaluée.