GH GambleHub

Analyse de cohorte

Analyse de cohorte

L'analyse de cohorte regroupe les objets (généralement les utilisateurs) par événement de démarrage unique et compare comment et combien de temps ils restent actifs et précieux. Cette approche sépare l'effet du temps dans le système (saisons, actions) de l'effet de l'âge de la cohorte (jours depuis le début).

1) Définitions de base

Cohorte (cohort) : beaucoup de joueurs réunis par l'événement « naissance » - inscription, premier dépôt, premier jeu, premier achat.
Axe du calendrier : dates réelles (2025-10-01,...).
Axe d'âge de la cohorte (cohort age) : jours/semaines à compter de la « naissance » (D0, D1,...).
Métriques de rétention : D1/D7/D30 (Exact et Rolling), WAU/MAU, Stick....( DAU/MAU).
Monétisation : ARPU/ARPPU, LTV cumulatif (sur D7/D30/D90).
Unité de compte : Utilisateur (user/master_id) - enregistrer dans le passeport.

💡 Règle d'or : enregistrer à l'avance l'événement de naissance, TZ, la fenêtre d'activité et d'exclusion (bots/QA/fred).

2) Les espèces de cohortes et quand les choisir

Acquisitions-cohortes : par date d'inscription/première visite - évaluation des canaux d'attraction et d'onbording.
Activité/Monetization-cohorte : sur le premier dépôt/achat - évaluation early-monetization et promo.
Feature-cohortes : Selon la première utilisation de la catégorie fichi/jeu, l'effet des sorties.
Cohortes Behavior : selon le modèle RFM/départ (p. ex. « mobile de nuit »).

3) Axes et grilles : Comment regarder la matrice

Matrice des cohortes : lignes - cohortes (calendrier), colonnes - âge (D0... D90).
Saisonnalité : comparer les diagonales (même jour civil) pour séparer les effets saisonniers.
Normalisation : métriques relatives (CR, parts) + cumulatives (LTV), montrer les deux.

4) Passeport de cohorte et métriques (template)

COHORT: `REG_DAY``FIRST_DEPOSIT_WEEK`
Axe d'âge : jour (D), horizons D1/D7/D30/D90.
Activité : ≥1 session ou pari ≥1 (fixer).
Exceptions : bots/frod/QA/doublons.
Segments par défaut : pays, plateforme, canal, catégorie de contenu, segment de prix.
Métriques : CR, Rolling/Retaction, LTV cumulatif, ARPU/ARPPU, % payant.
Version : 'COHORT _ RET _ v3', propriétaires, date de révision.

5) Pseudo-SQL : matrice de rétention (Exact Dn)

sql
WITH regs 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 act_day
FROM event_activity
),
ages AS (
SELECT r. user_id, r. cohort_day, a. act_day,
(a. act_day - r. cohort_day) AS age_days
FROM regs r
JOIN act a ON a. user_id = r. user_id
),
exact AS (
SELECT cohort_day,
age_days,
COUNT(DISTINCT user_id) AS users_active
FROM ages
GROUP BY 1,2
),
coh_size AS (
SELECT cohort_day, COUNT(DISTINCT user_id) AS cohort_size
FROM regs GROUP BY 1
)
SELECT e. cohort_day,
e. age_days,
e. users_active::decimal / NULLIF(c. cohort_size,0) AS exact_retention
FROM exact e
JOIN coh_size c USING (cohort_day)
WHERE age_days IN (1,7,30,90)
ORDER BY cohort_day, age_days;

Rolling Dn (activité au jour 1... n)

sql
WITH days AS (... as above...),
roll AS (
SELECT cohort_day,
CASE WHEN age_days BETWEEN 1 AND 7 THEN 7
WHEN age_days BETWEEN 1 AND 30 THEN 30 END AS bucket,
COUNT(DISTINCT user_id) AS any_active
FROM days
WHERE age_days BETWEEN 1 AND 30
GROUP BY 1,2
)
SELECT r. cohort_day, r. bucket AS Dn,
r. any_active::decimal / s. cohort_size AS rolling_retention
FROM roll r
JOIN (SELECT cohort_day, COUNT(DISTINCT user_id) cohort_size FROM regs GROUP BY 1) s USING (cohort_day)
ORDER BY cohort_day, Dn;

6) LTV de cohorte et monétisation

LTV cumulatif (Dn) : montant du revenu par utilisateur de la cohorte par Dn.
ARPU/ARPPU : revenu par utilisateur/par payeur selon Dn.
% payant : part avec paiement ≥1 à Dn.

sql
WITH reg AS (
SELECT user_id, DATE_TRUNC('day', MIN(ts)) AS cohort_day
FROM event_register GROUP BY 1
),
pay AS (
SELECT user_id, amount, DATE_TRUNC('day', ts) AS pay_day
FROM fact_payments
),
ltv AS (
SELECT r. cohort_day,
(pay_day - r. cohort_day) AS age_days,
SUM(amount) AS rev
FROM reg r JOIN pay p USING (user_id)
WHERE pay_day >= r. cohort_day
GROUP BY 1,2
),
cum AS (
SELECT cohort_day, age_days,
SUM(rev) OVER (PARTITION BY cohort_day ORDER BY age_days ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS rev_cum
FROM ltv
)
SELECT c. cohort_day, c. age_days,
c. rev_cum::decimal / NULLIF(sz. cohort_size,0) AS ltv_per_user
FROM cum c
JOIN (SELECT cohort_day, COUNT(DISTINCT user_id) cohort_size FROM reg GROUP BY 1) sz USING (cohort_day)
WHERE age_days IN (7,30,90)
ORDER BY cohort_day, age_days;

7) Survival/hazard pour tenir

Kaplan-Meier : Courbe de survie non modulaire (S (t)) - Proportion non « dégelée ».
Modèles Hazard (Soh/logit-par-jour) : impact des signes (canal, pays, plateforme, bonus, contenu) sur le risque de fuite.
Pratique : nous construisons KM par segments, puis nous expliquons la différence par le modèle hazard.

8) Saisonnalité, TZ et calendrier

TZ : Stocker les événements dans UTC, analyser dans le marché local TZ ; soyez cohérent.
Calendrier : vacances/salaires/matchs/communiqués - comme drapeaux ; comparer les cohortes de semaines similaires.
Fenêtre glissante : pour les cohortes hebdomadaires/mensuelles - multiple des jours fériés et des périodes de déclaration.

9) Segmentation et attribution

Segments : canal d'attraction, plateforme/OS, géo, premier contenu, prix/limites, méthode de paiement.
Attribution de cohorte : « qui a amené » l'utilisateur - fixez l'algorithme (dernier non direct, data-driven).
pondération LTV : comparer non seulement le CR, mais aussi le LTV (D30/D90) par canal/segment.

10) Visualisation

La carte thermique de la matrice de cohorte (CR/LTV).
Les lignes de tendance D1/D7/D30 selon le calendrier.
Graphiques Survival/Hazard.
Bridge « ce qui a changé LTV en D30 » : contribution des payeurs, fréquence, chèque moyen.

11) Expérimentation et causalité

A/B : onbording, tutoriels, paywall, offers. La métrique principale est la D7/D30 de rétention et LTV (D30).
Quasi-expériences : DiD/contrôle synthétique à jeter sur les marchés.
Modèle Uplift : Ciblez le gain de retour en ré-activation (Qini/AUUC, uplift @ k).

12) Exploitation et governance

Versioning : 'RET _ D7 _ vN', 'LTV _ D30 _ vN' ; changelog lorsque vous changez de définition d'activité/monnaie.
SLO de fraîcheur : cohortes quotidiennes - prêt jusqu'à 06:00 lok. ; Une bande de données ≤ 1 h.
Qualité : coverage des événements, proportion de doublons, proportion de bots/frondes en dehors des cohortes.
Accès : RLS/CLS, masquage PII ; les exportations ne sont que des agrégats.
Runbooks : chute D1 (onbording), D7 (contenu), chute d'événements/identités.

13) Erreurs fréquentes (anti-modèles)

Mélange des axes : Comparez les âges des cohortes à différentes saisons sans les modifier.
Rolling vs Exact : Interprété comme la même chose.
Mélange d'unités : sessions dans le dénominateur, utilisateurs dans le numérateur.
Agrégation des « moyennes » : au lieu de résumer les nombres/dénominateurs.
Ignorer TZ/calendrier : décalage D1 aux limites des jours/jours fériés.
Aucun filtre bot/frod/QA.
Restarts non comptabilisés : split/merge comptes sans ponts identitaires.

14) Chèque avant la publication du rapport de cohorte

  • Événement de naissance défini, unité, TZ, fenêtres d'activité
  • Les bots/frod/QA sont exclus ; identités compilées (golden record)
  • Les matrices CR (Exact/Rolling) et LTV à D7/D30/D90 ont été construites
  • Calendrier/jours fériés pris en compte ; segments par canal/plateforme/géo
  • Ajout de graphiques survival/hazard et bridge LTV
  • Versions documentées des métriques et algorithme d'attribution
  • Personnalisé SLO fraîcheur, coverage surveillance/duplicata/erreurs
  • Prêt runbooks sur les chutes de D1/D7 et les falaises d'événements

Résultat

L'analyse de cohorte est deux axes et une discipline : le « moment de naissance » fixe, les fenêtres correctes et les TZ, les matrices de rétention et les LTV, la segmentation et la vérification causale des changements. Cette approche aide non seulement à observer les courbes, mais aussi à prendre des décisions : où réparer l'onbording, quels canaux mettre à l'échelle, quel contenu et quels offers gardent les joueurs plus longtemps et augmentent la LTV.

Contact

Prendre contact

Contactez-nous pour toute question ou demande d’assistance.Nous sommes toujours prêts à vous aider !

Telegram
@Gamble_GC
Commencer l’intégration

L’Email est obligatoire. Telegram ou WhatsApp — optionnels.

Votre nom optionnel
Email optionnel
Objet optionnel
Message optionnel
Telegram optionnel
@
Si vous indiquez Telegram — nous vous répondrons aussi là-bas.
WhatsApp optionnel
Format : +code pays et numéro (ex. +33XXXXXXXXX).

En cliquant sur ce bouton, vous acceptez le traitement de vos données.