Analyse de la rétention des joueurs

La rétention est au cœur de l'économie du produit : plus le joueur reste actif, plus le LTV est élevé, plus le revenu et la planification sont stables. Ci-dessous, un cadre complet : des définitions correctes aux modèles de survie et au contour de la ré-activation.

1) Définitions et unités de compte

Unité : Joueur (user/master_id) - par défaut ; pour les tâches à court terme, disons « compte/appareil », mais enregistrez-le dans le passeport métrique.
Activité : critère de retour (≥1 session/ ≥1 taux/dépôt ≥1) - fixez.
Rétention Dn : proportion de cohortes revenant le nième jour après la date de référence.
Rolling/Bracket : Rolling D7 (pour n'importe lequel des jours 1 à 7) vs Exact D7 (précisément pour le 7e jour).
Churn (sortie) : absence d'activité pendant ≥T jours (p. ex. 14/30) ; spécifié comme la règle du produit.
Cohortes : par date d'inscription/premier dépôt/premier jeu - choisissez pour la tâche marketing/produit.

💡 Règle d'or : fixez à l'avance le déclencheur d'activité, la zone temporelle, la date de référence et la règle de sortie.

2) Analyse de base : cohortes et courbes de rappel

Cartes thermiques de cohorte : D1/D3/D7/D14/D30/D60 ; les diagonales sont comparables entre les sorties et les campagnes.
Courbes de survie : proportion d'actifs du jour 0 à N (curve survivale).
Géométrie de la courbe : « marches » des fêtes/sorties ; un « effondrement » précoce → des problèmes d'onbording, une « longue queue » → le noyau des fidèles.

Pseudo-SQL : cohorte D7

sql
WITH regs AS (
SELECT user_id, DATE_TRUNC('day', ts) AS cohort_day
FROM event_register
),
act AS (
SELECT user_id, DATE_TRUNC('day', ts) AS act_day
FROM event_activity
),
d7 AS (
SELECT r. cohort_day,
COUNT(DISTINCT r. user_id)              AS cohort_size,
COUNT(DISTINCT CASE WHEN a. act_day = r. cohort_day + INTERVAL '7 day'
THEN r. user_id END)       AS retained_d7
FROM regs r
LEFT JOIN act a ON a. user_id = r. user_id
GROUP BY 1
)
SELECT cohort_day, cohort_size,
retained_d7::decimal / NULLIF(cohort_size,0) AS cr_d7
FROM d7
ORDER BY cohort_day;

3) Survie et modèles hazard

Kaplan-Meier : évaluation non modale de la survie (S (t)) ; utile pour « enlever la forme » de la courbe et de la médiane de la vie.
Temps de panne Cox PH/accéléré : modèles explicites de l'influence des traits (pays, canal, plateforme, bonus, contenu) sur le hazard (risque de fuite).
Discrete-time hazard (logit par jour) : flexible pour les analyses de produits et les fiches de calendrier.
Événement « ré-activation » : modélisez séparément (competing risks) ou comme une transition dans une chaîne de Markov.

4) Modèles Markov et semi-parking

États : Nouveau → Active → Dormant → Churned → Reactivated.
Transitions : probabilités par période (jour/semaine).
Valeur : multipliez les probabilités de rester dans « Active » par chèque/fréquence moyen - recevez la contribution attendue à LTV.

5) ligament de rétention et LTV

LTV ≈ Σ (Retention_t × ARPU_t × d'actualisation).
Élasticité : augmentation de D7 par X p.p. → augmentation de LTV par Y % (données historiques/modèles).
Priorité : les améliorations affectant la rétention précoce (D1 à D7) sont presque toujours les plus rentables.

6) Segmentation de la rétention

Cohortes d'Onbording : première catégorie de contenu/jeu/modèle comportemental au jour 0.
Géo/plateforme/canal : différences UX et attentes ; ajuster pour le calendrier/jours fériés.
Comportement/valeur : RFM (Recency-Frequency-Monetary), risque de sortie, rentabilité.
Réponse aux stimuli : segments par uplift-réactions aux offers/notations.

7) Causalité et expériences

A/B : onbording, tutoriels, stratégies push ; la métrique principale est la rétention D7/D14/D30, guardrails - plaintes, temps de réponse, RG.
Quasi-expériences : DiD/contrôle synthétique lorsque la randomisation n'est pas possible (par exemple, décharges régionales).
Modèles Uplift : ciblent les gains de rendement plutôt que la probabilité d'activité ; évaluer Qini/AUUC.

8) Ré-activation : Déclencheurs et politiques

Signaux : baisse de fréquence, pas de dépôts N jours, chèque anormalement bas, onbording terminé sans 2ème session.

Table de décision (exemple)

Condition	Contexte	Action	Кулдаун	Guardrails
`risk_churn ≥ 0. 8` & `value_q ≥ 0. 8`	VIP	offer personnel L	7д	ROMI≥0
`no_session ≥ 7д` & `no_deposit ≥ 14д`	le segment de masse. push + e-mail « revenons à »...	5д	zhaloby≤Kh
`RG_risk ≥ τ`	Chacun	rausa/conseil RG	1д	FPR≤1%

Hystérésis : différents seuils d'entrée/sortie pour les signaux afin de ne pas « clignoter ».
Canaux : in-app, push, e-mail, SMS, centre d'appels - avec rate-limit et priorités.

9) Métriques de rétention

D1/D7/D30 (Rolling/Exact), WAU/MAU, Stickiness (DAU/MAU).
Survie médiane/quantifiée ; hazard à intervalles.
Reactivation rate (R30), Dormancy share.
ROMI ré-activation, NNT (combien de contacts pour 1 retour).
Fairness : différences de métriques par pays/plate-forme ; exclure les signes non valides des stratégies.

10) Dashboards de retenue

Cohorte calorifique + lignes de tendances D1/D7/D30.
Graphiques de survival/hazard par segments.
Vortex tôt dans la vie : install→reg→KYC→1 -je igra→1 un dépôt.
Plan d'action : signal→resheniye→kanal→iskhod (conversion to return).
Guardrails : fraîcheur des données, coverage des événements, plaintes, indicateurs RG.

11) Données et qualité

Evénements : schéma canonique (UTC, versions), idempotence, dedup.
Identités : user/device/e-mail/téléphone - ponts et disque d'or.
Fenêtres et TZ : Stockage dans UTC + vues locales ; un calendrier unique des fêtes.
Filtres : bots/QA/fred - exclure de la cohorte et des activités.
Versioner les métriques : 'RET _ D7 _ vN' avec changelog.

12) Pseudo-SQL/recettes de python

Rolling D30 par cohortes

sql
WITH base AS (
SELECT user_id, DATE_TRUNC('day', MIN(ts)) AS cohort_day
FROM event_register GROUP BY 1
),
act AS (
SELECT user_id, DATE_TRUNC('day', ts) AS d
FROM event_activity
),
roll30 AS (
SELECT b. cohort_day,
COUNT(DISTINCT b. user_id)                              AS cohort_size,
COUNT(DISTINCT CASE WHEN a. d BETWEEN b. cohort_day AND b. cohort_day + INTERVAL '30 day'
THEN b. user_id END)                      AS any_1_30
FROM base b LEFT JOIN act a ON a. user_id = b. user_id
GROUP BY 1
)
SELECT cohort_day, any_1_30::decimal/cohort_size AS rolling_d30
FROM roll30;

Kaplan-Meier (croquis)

python t_i - time to outflow or censorship; e_i - event indicator
S(t) = Π_{t_i ≤ t} (1 - d_i / n_i)

Discrete-hazard (logit par jour)

python
For each user, create records before the event/censorship by day:
target = 1 if there was an outflow on that day; characteristics: calendar, activity, promo, etc.
Training logistic regression/GBM; forecast p_t - probability of outflow on day t.

13) Uplift-ciblage de maintien

Zones : Persuadables (retour si nous sommes en contact), Sure things (retour et ainsi de suite), Lost causses, Do-not-disturb (contact nuisible).
Métriques : uplift @ k, Qini/AUUC ; politique - nous sommes en contact avec le top k sur uplift sous le budget.
Guardrails : cap sur la fréquence des contacts, RG/éthique, explication de la cause du contact.

14) Exploitation opérationnelle

SLO : mise à jour du dashboard de rappel ≤ 06:00 lok. ; Évaluation du risque en latitude ≤ 300 ms ; Decision→Action ≤ 5 с.
Surveillance : décalage des courbes par segments, dérive PSI des caractéristiques, « rupture des événements ».
Runibooks : chute D1 (onbording/release), chute D7 (contenu/fréquence), défaillances locales des canaux de communication.

15) Erreurs fréquentes

Mélange d'unités (sessii↔polzovateli), TZ, fenêtres d'activité.
Comparaison des indicateurs Rolling et Exact à égalité.
Ignorer les bots/frods → surestimés D1/D7.
Conclusions sur la corrélation sans vérification causale.
L'absence de l'hysteresis/kouldaounov → la fatigue des contacts.
Pas de ligament avec LTV - nous optimisons le CR, mais pas la valeur.

16) Chèque avant de libérer le circuit de rétention

Passeport métrique (déclencheur d'activité, fenêtre, TZ, version)
Rapports de cohorte et survival/hazard par segment
Modèles de risque de sortie et d'uplift, caps et guardrails
Plan d'intervention A/B et/ou quasi-expériences
Dashboards de fraîcheur/coverage/plaintes/RG
Runibooks incidents, hystérésis et rate-limits en politique
Lien de rétention avec LTV et ROMI ; priorité à la valeur attendue

Résultat

L'analyse de rétention n'est pas seulement une « carte thermique des cohortes », mais un système contrôlé : définitions correctes, modèles de survie/hazard, lien avec la valeur, interventions ciblées et éthiques, évaluation rigoureuse de l'effet et guardrails opérationnels. Vous construisez un cycle « observez → comprenez → décidez → agissez → apprenez » qui augmente régulièrement la LTV et réduit les sorties.

Analyse de la rétention des joueurs