Análise de retenção de jogadores

A retenção é o centro da economia do produto: quanto mais tempo o jogador permanecer ativo, maior a LTV, mais estável o rendimento e previsível o planejamento. Abaixo, o esqueleto completo, desde definições corretas até modelos de sobrevivência e caminhos de ré-ativação.

1) Definições e unidades de contabilidade

Unidade: jogador (user/master _ id) - padrão; para tarefas de curta duração, digamos «conta/dispositivo», mas registrem-no no passaporte da métrica.
Atividade: critério de retorno (sessão ≥1/taxa ≥1/depósito ≥1) - fixe.
Retenshn Dn, uma parte da banda que regressou ao nono dia após a data de referência.
Rolling/Bracket: Rolling D7 (em qualquer dia 1-7) vs Exact D7 (exatamente no dia 7).
Churn: falta de atividade de ≥T dias (por exemplo, 14/30); especifica a regra do produto.
Côrtes: pela data de inscrição/primeiro depósito/primeiro jogo - escolha sob a tarefa de marketing/produto.

💡 Regra de ouro: fixe previamente o desencadeador de atividade, a zona de tempo, a data de referência e a regra de saída.

2) Analista básico: cômodos e curvas retenciosas

Telas de calor: D1/D3/D7/D14/D30/D60; as diagonais são comparáveis entre lançamentos e campanhas.
Curvas de sobrevivência: proporção de ativos do dia 0 a N (curve survival).
Geometria da curva: «degraus» de festas/lançamentos; «colapso» precoce → problemas de segurança, «cauda longa» → núcleo de leais.

Pseudo-SQL: cômodo 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) Sobrevivência e modelos hazard

Kaplan-Méier: avaliação não unificada de survival (S (t)); útil para «remover a forma» da curva e medianos da vida.
Cox PH/Acelerated Failure Time: Modelos explicáveis de impacto de sinais (país, canal, plataforma, bônus, conteúdo) em hazard (risco de fuga).
Discrete-time hazard (logit por dia): flexível para analistas de alimentos e fichas de calendário.
Evento «re-ativação»: modele separadamente (composto risks) ou como passar para a cadeia Markov.

4) Modelos de Marco e Meio Estacionamento

Estados: New → Action → Dormant → Churned → Reativated.
Transições: probabilidades por período (dia/semana).
Valor: multiplique a probabilidade de permanência no Ativo em um cheque/frequência médio - recebendo o aporte esperado para a LTV.

5) Retenção e LTV

LTV .
Elasticidade: aumento de D7 em X p.p. → aumento de LTV em Y% (a partir de dados históricos/modelos).
Priorização: melhorias que afetam a retenção precoce (D1-D7) são quase sempre as mais rentáveis.

6) Segmentação de retenção

Conboarding: primeiro conteúdo/categoria de jogo/modelo comportamental no dia 0.
Geo/plataforma/canal: diferenças entre UX e expectativas; ajuste para calendário/feriado.
Comportamento/valor: RFM (Recency-Frequency-Monetary), risco de fuga, lucratividade.
Resposta a estímulos: segmentos de resposta uplift a offs/notificações.

7) Causalidade e experimentação

A/B: onboarding, tutoriais, estratégias; A métrica principal é D7/D14/D30 retenss, guardrails - queixas, tempo de resposta, RG.
Quasiexportadores: Controle diD/sintético quando a randomização não é possível (por exemplo, saques regionais).
Modelos Uplift: metas de aumento de retorno em vez de probabilidade de atividade; avalie Qini/AUUC.

8) Re-ativação: desencadeadores e políticas

Sinais: queda da frequência, falta de depósito N dias, cheque anormalmente baixo, pagamento concluído sem 2ª sessão.

Resolução de tabela (exemplo)

Condição	Contexto	Ação	Cooldown	Guardrails
`risk_churn ≥ 0. 8` & `value_q ≥ 0. 8`	VIP	pessoal off L	7d	ROMI≥0
`no_session ≥ 7д` & `no_deposit ≥ 14д`	massas-segm. «Voltemos ao»...	5d	zhaloby≤Kh
`RG_risk ≥ τ`	qualquer um	rausa/conselho RG	1d	FPR≤1%

Histeresis: diferentes liminares de entrada/saída para sinais para não «piscar».
Canais: in-app, push, e-mail, SMS, call center - com rate-limit e prioridades.

9) Métricas de retenção

D1/D7/D30 (Rolling/Exact), WAU/MAU, Stickiness (DAU/MAU).
Survival mediana/quantili; hazard em intervalos.
Reactivation rate (R30), Dormancy share.
ROMI e ativação, NNT (quantos contatos por 1 retorno).
Fairness: diferenças de métricas por país/plataforma; exclua os sinais inaceitáveis das políticas.

10) Dashboards retenção

Marca de calor + linhas de tendência D1/D7/D30.
O Survival/hazard gráficos por segmento.
Vórtice da vida precoce, eu o depósito.
Mapa de ação: signal→resheniye→kanal→iskhod (conversion to return).
Guardrails: dados recentes, eventos coverage, queixas, indicadores RG.

11) Dados e qualidade

Eventos: esquema canônico (UTC, versões), idempotidade, dedução.
Identidade: user/device/e-mail/telefone - pontes e gravação de ouro.
Janelas e TZ: armazenamento em UTC + visualizações locais; um calendário único de feriados.
Filtros: bots/QA/frod - Excluam-no da conectividade e da actividade.
Versionização de métricas: 'RET_D7_vN' com changelog.

12) Pseudo-SQL/piton-receitas

Rolling D30 sobre cômodos

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-Méier (esboço)

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

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-meta de retenção

Zonas: Persuadáveis (voltarão se estivermos em contato), Sure things (voltarão assim), Lost causes, Do-not-disturb (contato prejudicado).
Métricas: uplift @ k, Qini/AUUC; política - contato top k sobre uplift para o orçamento.
Guardrails: cap na frequência de contatos, RG/ética, explicação da causa do contato.

14) Operação operacional

SLO: Atualização do Retensn Dashbord ≤ 06:00; latency screen de risco ≤ 300 ms; Decision→Action ≤ 5 с.
Monitoramento: deslocamento de curvas por segmento, PSI à deriva de sinais, «penhasco de eventos».
Runibuki: queda D1 (onboarding/lançamento), queda D7 (conteúdo/frequência), falhas locais nos canais de comunicação.

15) Erros frequentes

Mistura de unidades (sessii↔polzovateli), TZ, janelas de atividade.
Comparando os indicadores Rolling e Exact como iguais.
Ignorar bots/frod → D1/D7 exagerados.
Conclusões sobre correlação sem verificação causal.
Falta de histerese/cooldowns → fadiga de contatos.
Sem ligação com LTV - otimizar CR, mas não valor.

16) Folha de cheque antes do lançamento do circuito de retenção

Passaporte de métricas (desencadear atividade, janela, TZ, versão)
Relatórios de grupo e survival/hazard por segmento
Modelos de risco de saída e uplift, caps e canais
Plano A/B e/ou quociente para intervenções
Dashboards de frescura/coverage/queixas/RG
Runibuki incidentes, histerese e rate-limits na política
Vínculo de retenção com LTV e ROMI; priorização de acordo com o valor esperado

Resultado

A análise de retenção não é apenas uma «caixa de calor», mas um sistema controlado: definições corretas, modelos de survival/hazard, conexão com o valor, intervenções targadas e éticas, avaliação rigorosa do efeito e guichês operacionais. Você está construindo um ciclo de «observar → entender → decidir → agir → aprender» que aumenta a LTV de forma estável e reduz a retração.

Análise de retenção de jogadores