Analiza retenției jucătorului
Analiza retenției jucătorului
Retenția este nucleul economiei de produs: cu cât un jucător rămâne activ mai mult, cu atât LTV este mai mare, cu atât venitul este mai stabil și planificarea este mai previzibilă. Mai jos este un cadru complet: de la definiții corecte la modele de supraviețuire și circuitul de reactivare.
1) Definiții și unități contabile
Unitate: player (user/master_id) - implicit; pentru sarcini pe termen scurt, este permis un „cont/dispozitiv”, dar înregistrați acest lucru în pașaportul metric.
Activitate: criteriu retur (≥1 sesiune/rata ≥1/depozit ≥1) - înregistrare.
Reținerea Dn: proporția cohortei care revine în ziua n după data de referință.
Rolling/Suport: Rolling D7 (în oricare din zilele 1-7) vs Exact D7 (în ziua 7).
Churn: fără activitate timp de ≥T zile (de exemplu, 14/30); este specificată ca regulă a produsului.
Cohorte: până la data înregistrării/primei depuneri/primului joc - alegeți pentru activitatea de marketing/produs.
2) Analiza de bază: cohorte și curbe de retenție
Hărți termice ale cohortei: D1/D3/D7/D14/D30/D60; diagonalele sunt comparabile între lansări și campanii.
Curbe de supraviețuire: proporția de active din ziua 0 până la N (curba de supraviețuire).
Geometria curbei: „pașii” sărbătorilor/eliberărilor; „colapsul” timpuriu → problemele de îmbarcare, „coada lungă” → miezul loial.
Pseudo-SQL: Cohorta 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) Modele de supraviețuire și de pericol
Kaplan-Meier: scor de supravieţuire non-model (S (t)); util pentru „decuparea formei” curbei și a mediei de viață.
Cox PH/Timp de eșec accelerat: modele explicative ale influenței caracteristicilor (țară, canal, platformă, bonusuri, conținut) asupra pericolului (risc de ieșire).
Pericol discret (log by day): flexibil pentru analiza produselor și caracteristicile calendarului.
Re-activare eveniment-Model separat (riscuri concurente) sau ca o tranziție într-un lanț Markov.
4) modele Markov și semi-Markov
Noul activ adormit reactivat.
Tranziții: probabilități pe perioadă (zi/săptămână).
Valoare: multiplicați probabilitățile de ședere în „Activ” cu verificarea medie/frecvență - obțineți contribuția așteptată la LTV.
5) retenție pachet și LTV
LTV ( reducere).
Elasticitate: Creșterea D7 cu X pp → LTV cu Y% (de la date/modele istorice).
Prioritizarea: Îmbunătățirile care afectează retenția timpurie (D1-D7) sunt aproape întotdeauna cele mai profitabile.
6) Segmentarea retenției
Cohorte onboarding: prima categorie de conținut/joc/model comportamental în ziua 0.
Geo/platformă/canal: diferențe între UX și așteptări; ajustați pentru calendar/sărbători.
Comportament/valoare: RFM (Recency-Frequency-Monetary), risc de ieșire, profitabilitate.
Răspuns la stimulente: segmente privind reacția la oferte/notificări.
7) Cauzalitate și experimente
A/B: onboarding, tutoriale, strategii push; metrică principală - retenție D7/D14/D30, parapete - reclamații, timp de răspuns, RG.
Cvasi-experimente: DiD/control sintetic atunci când randomizarea nu este posibilă (de ex. lovituri regionale).
Modele Uplift: câștiguri de retur țintă, nu probabilități de activitate; evaluează Qini/AUUC.
8) Reactivare: declanșatoare și politică
Semnale: cădere de frecvență, fără depuneri N zile, verificare anormal de scăzută, finalizat la bord fără a doua sesiune.
Tabelul de decizii (exemplu)
Histerezis: diferite praguri de intrare/ieșire pentru semnale, astfel încât să nu „clipi”.
Canale: in-app, push, e-mail, SMS, call center - cu rate-limită și priorități.
9) Valori de retenție
D1/D7/D30 (Rolling/Exact), WAU/MAU, Stickiness (DA/MAU).
Mediana de supravieţuire/cantităţi; pericol la intervale de timp.
Rata de reactivare (R30), cota de adormire.
Reactivare ROMI, NNT (câte contacte pe 1 retur).
Corectitudine: diferențe metrice pe țară/platformă; Excludeți caracteristicile nevalide din politici.
10) Tablouri de bord de retenție
Cohorta hartă de căldură + linii de trend D1/D7/D30.
Grafice de supraviețuire/hazard pe segment.
Pâlnie de viață timpurie: install→reg→KYC→1 igra→1-lea depozit.
Hartă acțiune: signal→resheniye→kanal→iskhod (conversie în retur).
Guardrails: prospețimea datelor, acoperirea evenimentelor, reclamații, indicatori RG.
11) Date și calitate
Evenimente: schemă canonică (UTC, versiuni), idempotență, deadup.
Identități: utilizator/dispozitiv/e-mail/telefon - poduri și intrare de aur.
Windows și TZ: stocarea în UTC + vederi locale; calendar unic de sărbători.
Filtre: boți/QA/fraudă - excluderea din cohortă și activități.
Versioning metrics: 'RET _ D7 _ vN' with changelog.
12) Rețete Pseudo-SQL/python
D30 de rulare prin cohortă
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 (schiță)
python t_i - time to outflow or censorship; e_i - event indicator
S(t) = Π_{t_i ≤ t} (1 - d_i / n_i)
Pericol discret (jurnal cu zi)
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) Reținerea țintirii ascendente
Zone: Persuadables (se va întoarce dacă vom contacta), Sigur lucruri (se va întoarce și așa), Cauze pierdute, Do-nu-deranjez (contact dăunează).
Valori: uplift @ k, Qini/AUUC; politică - contactăm vârful k prin ridicarea bugetului.
Guardrails: capac pe frecvența de contact, RG/etică, explicabilitatea cauzei contactului.
14) Operațiune operațională
SLO: actualizare placa de retenție ≤ 06:00 blocare.; latența scorului de risc ≤ 300 ms; Decision→Action ≤ 5 с.
Monitorizare: schimburi de curbe pe segmente, PSI de drift feature, „event break”.
Runibooks: D1 drop (onboarding/release), D7 drop (conținut/frecvență), eșecuri locale canal de comunicare.
15) Erori frecvente
Amestecarea unităților (sessii↔polzovateli), TZ, ferestre de activitate.
Compararea indicatorilor Rolling și Exact ca egal.
Ignorarea roboților/fraudei → D1/D7 umflate.
Concluzii privind corelarea fără validare cauzală.
Fără histerezis/răcire → oboseală de contact.
Nu există nicio legătură cu LTV - optimizăm CR, dar nu și valoarea.
16) Lista de verificare a buclei de păstrare înainte de eliberare
- Pașaport metric (activity trigger, window, TZ, version)
- Rapoarte de cohortă și supraviețuire/pericol pe segment
- Outflow și modelele de risc de ridicare, kapas și canale de parapete
- Planul A/B și/sau cvasi-experimente pentru intervenții
- Prospețime/acoperire/reclamații/tablouri de bord RG
- Runybooks incidente, isterezis și rate-limite în politică
- Pachetul de retenție cu LTV și ROMI; prioritizarea după valoarea preconizată
Total
Analiza retenției nu este doar o „hartă termică a cohortelor”, ci un sistem gestionat: definiții corecte, modele de supraviețuire/hazard, asociere cu valoarea, intervenții direcționate și etice, evaluare riguroasă a efectelor și parapete operaționale. Construiți un ciclu „ceas înțelegeți decideți acționați” care crește în mod constant LTV și reduce fluxul.