Análisis de retención de jugadores

Análisis de retención

La retención es el núcleo de la economía del producto: cuanto más tiempo permanezca activo el jugador, más alto será el LTV, más estables serán los ingresos y más previsible la planificación. A continuación, un marco completo: desde las definiciones correctas hasta los modelos de supervivencia y el contorno de re-activación.

1) Definiciones y unidades de contabilidad

Unidad: jugador (user/master_id) - predeterminado; para tareas a corto plazo, permitiremos «cuenta/dispositivo», pero fijarlo en el pasaporte métrico.
Actividad: criterio de devolución (≥1 sesión/tasa ≥1/depósito ≥1) - fijar.
Retiro Dn: la fracción de la cohorte que regresó el día n después de la fecha de referencia.
Rolling/Bracket: Rolling D7 (en cualquiera de los días 1-7) vs Nat D7 (precisamente el día 7).
Churn (salida): falta de actividad ≥T días (por ejemplo, 14/30); especificado como la regla de producto.
Cohortes: por fecha de registro/primer depósito/primer juego - elija bajo la tarea de marketing/producto.

💡 Regla de oro: fije de antemano el desencadenante de la actividad, la zona de tiempo, la fecha de referencia y la regla de salida.

2) Analítica básica: cohortes y retention-curvas

Tarjetas térmicas de cohorte: D1/D3/D7/D14/D30/D60; las diagonales son comparables entre lanzamientos y campañas.
Curvas de supervivencia: proporción de activos del día 0 al N (curve survival).
Geometría de curva: «pasos» de vacaciones/lanzamientos; el temprano «colapso» → problemas de onboarding, la «cola larga» → el núcleo de los leales.

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) Supervivencia y modelos hazard

Kaplan-Meier: evaluación de survival (S (t)) no modélica; útil para «quitar la forma» de la curva y la mediana de la vida.
Cox PH/Accelerated Failure Time: patrones explicables del impacto de los signos (país, canal, plataforma, bonos, contenido) en hazard (riesgo de salida).
Discrete-time hazard (logit por día): flexible para análisis de productos y calendario de fichas.
Evento de «re-activación»: modele por separado (risks de competición) o como una transición a los circuitos de Markov.

4) Modelos de Markov y Medio Parque

Estados: New → Active → Dormant → Churned → Reactivated.
Transiciones: probabilidades por período (día/semana).
Valor: Multiplique las probabilidades de estar en «Activo» por un cheque/frecuencia media - obtenga la contribución esperada a LTV.

5) Ligamento de retención y LTV

LTV ≈ Σ (Retention_t × ARPU_t × el descuento).
Elasticidad: ganancia de D7 en X p.p. → ganancia de LTV en Y% (a partir de datos/modelos históricos).
Priorización: las mejoras que afectan a la retención temprana (D1-D7) son casi siempre las más rentables.

6) Segmentación de retención

Cohortes de Onboarding: primer contenido/categoría de juego/patrón de comportamiento en el día 0.
Geo/plataforma/canal: diferencias de UX y expectativas; ajustar a calendario/vacaciones.
Comportamiento/valor: RFM (Recency-Frequency-Monetary), riesgo de salida, rentabilidad.
Respuesta a los estímulos: segmentos de respuesta uplift a offers/notificaciones.

7) Causalidad y experimentos

A/B: onboarding, toutorials, push-strategies; La métrica principal es D7/D14/D30 retencion, guardrails - quejas, tiempo de respuesta, RG.
Cuasiexperimentos: DiD/control sintético cuando la aleatorización no es posible (por ejemplo, dispares regionales).
Modelos de Uplift: dirigen la ganancia de retorno en lugar de la probabilidad de actividad; evaluar Qini/AUUC.

8) Re-activación: desencadenantes y política

Señales: caída de frecuencia, ningún depósito de N días, un cheque anormalmente bajo, un onboarding completo sin segunda sesión.

Tabla de decisión (ejemplo)

Condición	Contexto	Acción	Kuldaun	Guardrails
`risk_churn ≥ 0. 8` & `value_q ≥ 0. 8`	VIP	offer personal L	7д	ROMI≥0
`no_session ≥ 7д` & `no_deposit ≥ 14д`	El segmento de masas. push + e-mail «volvamos a»...	5д	zhaloby≤Kh
`RG_risk ≥ τ`	Cualquiera	rausa/consejo de RG	1д	FPR≤1%

Histéresis: diferentes umbrales de entrada/salida para que las señales no «parpadeen».
Canales: in-app, push, e-mail, SMS, call center - con rate-limit y prioridades.

9) Métricas de retención

D1/D7/D30 (Rolling/Exact), WAU/MAU, Stickiness (DAU/MAU).
Survival mediana/cuantili; hazard en intervalos.
Reactivation rate (R30), Dormancy share.
ROMI de re-activación, NNT (cuántos contactos por 1 retorno).
Fairness: diferencias de métricas por país/plataforma; excluir los signos no válidos de las directivas.

10) Dashboards de retención

Carta de calor de cohorte + líneas de tendencias D1/D7/D30.
Survival/hazard gráficos por segmento.
Embudo de la vida temprana: install→reg→KYC→1 -I igra→1 - depósito.
Mapa de acciones: signal→resheniye→kanal→iskhod (conversion to return).
Guardrails: frescura de datos, eventos de coverage, quejas, indicadores RG.

11) Datos y calidad

Eventos: esquema canónico (UTC, versiones), idempotencia, dedoup.
Identidades: usuario/dispositivo/e-mail/teléfono - puentes y disco de oro.
Ventanas y TZ: almacenamiento en vistas UTC + locales; un calendario único de vacaciones.
Filtros: bots/QA/frod - excluir de la cohorte y las actividades.
Versificación de métricas: 'RET _ D7 _ vN' con changelog.

12) Pseudo-SQL/recetas para pitones

Rolling D30 por cohorte

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

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 por día)

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-targeting de la retención

Zonas: Persuadibles (volverán si estamos en contacto), Sure things (volverán y así), Cauces perdidos, Do-not-disturb (el contacto perjudica).
Métricas: uplift @ k, Qini/AUUC; política - Contactamos a la parte superior k por uplift bajo presupuesto.
Guardrails: cap sobre frecuencia de contacto, RG/ética, explicabilidad de la causa de contacto.

14) Operación operativa

SLO: actualización de retransmisión ≤ 06:00 lock.; latency puntuación de riesgo ≤ 300 ms; Decision→Action ≤ 5 с.
Monitoreo: turnos de curvas por segmentos, PSI de deriva de rasgos, «acantilado de eventos».
Runibooks: caída D1 (onboarding/release), caída D7 (contenido/frecuencia), fallas locales de los canales de comunicación.

15) Errores frecuentes

Mezcla de unidades (sessii↔polzovateli), TZ, ventanas de actividad.
Comparación de los resultados de Rolling y Exact como iguales.
Ignorar los bots/frod → D1/D7 inflados.
Conclusiones de correlación sin verificación causal.
La ausencia de histéresis/couldowns → la fatiga de los contactos.
No hay ligamento con LTV - optimizar CR, pero no el valor.

16) Lista de verificación antes de la liberación del contorno de retención

Métricas de pasaporte (activador de actividad, ventana, TZ, versión)
Informes de cohorte y survival/hazard por segmentos
Modelos de riesgo de salida y uplift, capas y guardrails de canales
Plan A/B y/o cuasiexperimentos para intervenciones
Dashboards frescura/coverage/quejas/RG
Las rúnicas de incidentes, histéresis y rate-limits en la política
Unión de retención con LTV y ROMI; priorizar el valor esperado

Resultado

El análisis de retención no es solo una «tarjeta térmica de cohorte», sino un sistema manejable: definiciones correctas, modelos survival/hazard, relación con el valor, intervenciones dirigidas y éticas, evaluación rigurosa del efecto y guardrails operativos. Construyes un ciclo de «observa → entiende → decide → actúa → aprende» que aumenta de forma constante el LTV y reduce las salidas.

Análisis de retención de jugadores