Analisi della tenuta dei giocatori

Analisi dei giocatori

La tenuta è il cuore dell'economia del prodotto: più a lungo un giocatore rimane attivo, più alto è LTV, più stabile è il reddito e la pianificazione. Di seguito è riportato un wireframe completo che va dalle definizioni corrette ai modelli di sopravvivenza e al tracciato di re-attivazione.

1) Definizioni e unità di contabilità

Unità - Giocatore (user/master _ id) - Impostazione predefinita; per le attività a breve termine è possibile «account/dispositivo», ma fissarlo nel passaporto della metrica.
Attività: criteri di rientro (sessione /tasso di interesse/deposito ) - fissa.
La parte della coorte che è tornata al nono giorno dopo la data di riferimento.
Rolling/Bracket: Rolling D7 (in uno qualsiasi dei giorni 1-7) vs Exact D7 (esattamente il 7 ° giorno).
Churn (deflusso): assenza di attività di ≥T giorni (ad esempio 14/30); specifica la regola del prodotto.
Coorti: in base alla data di registrazione/primo deposito/primo gioco - scegli l'attività di marketing/prodotto.

2) Analisi di base: coorti e curve retensive

Quadri termici coorti: D1/D3/D7/D14/D30/D60; le diagonali sono paragonabili tra comunicati e campagne.
Curve di sopravvivenza: percentuale di attivi dal giorno 0 alla N (surval curve).
Geometria curva: «gradini» festività/rilascio; Un crollo precoce, un problema di onboarding, una lunga coda, un nucleo di leali.

Pseudonimo-SQL 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) Sopravvivenza e modelli hazard

Kaplan-Meier - Valutazione non singola di survival (S (t)) utile per «rimuovere» la curva e la mediana della vita.
Cox PH/Accelerated Failure Time: modelli di impatto dei segni spiegabili (paese, canale, piattaforma, bonus, contenuti) su hazard (rischio di deflusso).
Discrete-time hazard (logit giornaliero) - Flessibile per l'analisi dei prodotti e le fitte del calendario.
Evento re-attivazione - Modellare separatamente (componing risks) o come transizione nella catena Markov.

4) Modelli di marca e mezzo parcheggio

Stati: New → Active → Dormant → Churned → Reativated.
Transizioni: probabilità di periodo (giorno/settimana).
Valore: moltiplicare la probabilità di soggiorno in Active per un assegno/frequenza media - ottenere il contributo previsto per LTV.

5) Collegamento di contenimento e LTV

LTV (Retention _ t x ARPU _ t x Disc).
Elasticità: aumento del D7 per X p.p. e aumento del LTV per Y% (da dati/modelli storici).
Priorità: i miglioramenti che influiscono sulla ritenzione precoce (D1-D7) sono quasi sempre i più redditizi.

6) Segmentazione di contenimento

Coorti onboording: primo contenuto/categoria di gioco/modello comportamentale al giorno 0.
Geo/piattaforma/canale: differenze tra UX e aspettative; Regolate il calendario/festività.
Comportamento/valore: RFM (Recency-Frequency-Monetary), rischio di fuga, redditività.
Risposta agli incentivi: segmenti di risposta uplift agli offer/notificazioni.

7) Causalità ed esperimenti

A/B: onboarding, tutoriali, strategie dei pass; la metrica principale è D7/D14/D30 retensioni, guardrail - lamentele, tempo di risposta, RG.
Quoziente: Controllo diD/sintetico quando la randomizzazione non è possibile (ad esempio, scarichi regionali).
Modelli Uplift: target per aumentare il ritorno e non la probabilità di attività; valutare Qini/AUUC.

8) Re-attivazione: trigger e criteri

I segnali sono: calo della frequenza, nessun deposito N giorni, assegno anomalo basso, onboarding completato senza sessione 2.

Decision table (esempio)

Isteresi: diverse soglie di ingresso/uscita per i segnali per non «lampeggiare».
Canali: in-app, pozzo, e-mail, SMS, call center - con rate-limit e priorità.

9) Metriche di contenimento

D1/D7/D30 (Rolling/Exact), WAU/MAU, Stickiness (DAU/MAU).
Survival mediana/quantili; hazard sugli intervalli.
Reactivation rate (R30), Dormancy share.
ROMI re-attivazione, NNT (quanti contatti per 1 ritorno).
Fairness: differenze di metriche per paese/piattaforma; escludere i segni non validi dai criteri.

10) Dashboard di contenimento

Circuito termico coorte + linee di tendenza D1/D7/D30.
Grafica survival/hazard per segmenti.
Il vortice della vita precoce è che ho pagato un deposito.
Mappa delle azioni signal→resheniye→kanal→iskhod (conversion to return).
Guardrails: freschezza di dati, eventi di coverage, denunce, indicatori RG.

11) Dati e qualità

Eventi: schema canonico (UTC, versioni), idampotenza, deducibilità.
Identità: user/device/e-mail/telefono - ponti e record d'oro.
Finestre e TZ: archiviazione in UTC + viste locali un unico calendario delle feste.
Filtri: bot/QA/frode - Escludi dalla coorte e dalle attività.
Versioning delle metriche: «RET_D7_vN» con changelog.

12) Pseudo-SQL/piton-ricette

Rolling D30 per coorti

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 (sketch)

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 giornaliero)

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-target di contenimento

Zone: Persuadable (torneranno se siamo in contatto), Sure things (torneranno anche così), Lost cause, Do-not-disturb (contatto dannoso).
Metriche: uplift @ k, Qini/AUUC; criteri - Contatti top k per uplift per budget.
Guardrails: cap sulla frequenza dei contatti, RG/etica, spiegazione della causa del contatto.

14) Funzionamento operativo

SLO: aggiornamento del retro-dashbord alle 6:00; latency scansione del rischio 300 ms; Decision→Action ≤ 5 с.
Monitoraggio: spostamento delle curve sui segmenti, PSI sulla deriva dei segni, diradamento degli eventi.
Runibuki: calo D1 (onboording/release), calo D7 (contenuto/frequenza), guasti locali dei canali di comunicazione.

15) Errori frequenti

Miscelazione di unità (sessii↔polzovateli), TZ, finestre di attività.
Il confronto tra Rolling ed Exact è uguale.
Ignorare i bot/frode è un D1/D7 esagerato.
Conclusioni sulla correlazione senza verifica causale.
La mancanza di isteresi/cooldown ha causato la stanchezza dei contatti.
Nessun collegamento con LTV - ottimizziamo il CR, ma non il valore.

16) Foglio di assegno prima del lancio del circuito di contenimento

• Passaporto metriche (trigger attività, finestra, TZ, versione)
• Report di coorte e surval/hazard per segmenti
• Modelli di rischio di fuoriuscita e uplift, caps e garrails
• Piano A/B e/o quasi per gli interventi
• Dashboard freschezza/coverage/lamentele/RG
• Runibuki incidenti, isteresi e rate-limits in politica
• Collegamento di contenimento con LTV e ROMI; priorità per valore previsto

Totale

Le analisi di contenimento non sono solo «griffe di calore», ma un sistema controllato: definizioni corrette, modelli survival/hazard, connettività con il valore, interventi targati ed etici, valutazione rigorosa degli effetti e garrails operativi. Stai costruendo un ciclo dì Osservare, Capire, Decidere ", che aumenta stabilmente la LTV e riduce il deflusso.