Análise de linha

A análise de grupo agrupa os objetos (normalmente usuários) em um único evento de início e compara o tempo e o tempo em que eles permanecem ativos e valiosos. Esta abordagem separa o efeito do tempo no sistema (estações, promoções) do efeito da idade do cômodo (dias a partir do início).

1) Definições básicas

Côrtes (cohort): muitos jogadores combinados pelo evento de «nascimento» - inscrição, primeiro depósito, primeiro jogo, primeira compra.
Eixo do calendário (calendar time): datas reais (2025-10-01,...).
Eixo da idade da banda (cohort age): dias/semanas desde o «nascimento» (D0, D1,...).
Métricas de retenção: D1/D7/D30 (Exact e Rolling), WAU/MAU, Stickiness (DAU/MAU).
Monetização: ARPU/ARPU, LTV cumulativa (em D7/D30/D90).
Unidade de contabilidade: usuário (user/master _ id) - Anote no passaporte.

💡 Regra de ouro: verifique previamente o evento de nascimento, TZ, janela de atividade e exclusão (bots/QA/frod).

2) Tipos de cômodos e quando escolhê-los

Acquisition-cômodos: por data de check-in/primeira visita - avaliação de canais de atração e onboarding.
Activation/Monetização-cômodos: primeiro depósito/compra - avaliação early-monetização e promoção.
Feições: pela primeira vez que os fichas/jogos são usados - efeito de lançamento.
Côrtes Behavior: RFM/pattern de partida (por exemplo, «celulares noturnos»).

3) Eixos e grades: como ver a matriz

Matriz de cômodos: linhas - cômodos (calendário), colunas - idade (D0... D90).
Sazonalidade: compare as diagonais (o mesmo dia do calendário) para separar os efeitos sazonais.
Normalização: métricas relativas (CR, participações) + cumulativas (LTV), mostre ambas.

4) Passaporte de linha e métricas (template)

COHORT: `REG_DAY`	`FIRST_DEPOSIT_WEEK`
Eixo da idade: dia (D), horizontes D1/D7/D30/D90.
Atividade: ≥1 sessão ou taxa ≥1 (fixar).
Exceções: bots/frod/QA/duplicados.
Os segmentos padrão são país, plataforma, canal, categoria de conteúdo, segmento de preços.
Métricas: CR, Rolling/Exact retence, LTV cumulativo, ARPU/ARPU,% pagantes.
Versão de 'COHORT _ RET _ v3', proprietários, data de revisão.

5) Pseudo-SQL: matriz de retenção (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 (atividade em 1... n dia)

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 cômico e monetização

LTV cumulativo (DN): soma o rendimento por utilizador da linha para Dn.
ARPU/ARPU: renda por usuário/por pagante Dn.
% dos pagantes: participação com pagamento ≥1 para 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 para retenção

Kaplan-Méier: Uma curva de sobrevivência não unificada (S (t)) - uma proporção de «descongelados».
Modelos Hazard (Soh/logit-em-dias): efeitos dos sinais (canal, país, plataforma, bónus, conteúdo) sobre o risco de fuga.
Prática: Construindo KM por segmentos, depois explicando a diferença do modelo hazard.

8) Sazonalidade, TZ e calendário

TZ: Guarde eventos em UTC, analise no TZ local do mercado; sejam consistentes.
Calendário: feriados/salários/jogos/lançamentos - como bandeiras; compara-as semanas semelhantes.
Janela deslizante: para cômodos semanais/mensais - múltiplo de festas e períodos relatórios.

9) Segmentação e atribuição

Segmentos: canal de atração, plataforma/OS, geo, primeiro conteúdo, preço/limite, método de pagamento.
Atribuição de cômodo: «quem trouxe» o usuário - fixe o algoritmo (last não-direto, data-driven).
LTV Pesagem: compare não apenas CR, mas também LTV (D30/D90) por canais/segmentos.

10) Visualização

Marca térmica da matriz de cômodos (CR/LTV).
Linhas de tendência D1/D7/D30 no calendário.
Gráficos de Survival/Hazard.
Bridge «o que mudou a LTV para D30»: contribuição de pagantes, frequência, cheque médio.

11) Experimentos e causalidade

A/B: onboarding, tutoriais, paywall, offs. A métrica principal é D7/D30 retence e LTV (D30).
Quasiexportadores: DiD/controle sintético para escoamento de mercados.
Modelos Uplift: meta aumento de retorno para a ativação (Qini/AUUC, uplift @ k).

12) Exploração e produção

Versionização: «RET_D7_vN», «LTV_D30_vN»; changelog quando muda a definição de atividade/moeda.
SLO frescura: cômodos diários - pronto até às 06:00 lock; liga de dados ≤ 1 h.
Qualidade: eventos de coveragem, proporção de duplicados, proporção de bots/frod fora dos cômodos.
Acesso: RLS/CLS, camuflagem PII; exportar são apenas máquinas.
Runbooks: queda D1 (onboarding), D7 (conteúdo), camada de eventos/identidade.

13) Erros frequentes (anti-pattern)

Mistura de eixos, comparando diferentes idades de cômodos em diferentes estações sem alterações.
Rolling vs Exact: Interpretado como a mesma coisa.
Mistura de unidades: sessões no denominador, usuários no numérico.
Agregação «média»: em vez de somar números/denominadores.
Omissão TZ/calendário: deslocamento D1 nos limites dias/feriados.
Não há filtro de bots/frod/QA.
Restarte não contabilizado: contas split/merge sem pontes de identidade.

14) Folha de cheque antes de publicar o relatório de grupo

Definidos evento de nascimento, unidade, TZ, janelas de atividade
Bots/frod/QA excluídos; identidades combinadas (golden record)
Foram construídas matrizes CR (Exact/Rolling) e LTV para D7/D30/D90
Levar em conta o calendário/feriado; segmentos por canal/plataforma/geo
Adicionados os gráficos survival/hazard e bridge LTV
São documentadas versões de métricas e algoritmo de atribuição
Configurado SLO de frescura, monitoramento de coverage/duplicados/erros
Pronto runbooks para as baixas D1/D7 e os eventos

Resultado

As análises de linha são dois eixos e disciplina: «momento de nascimento» fixo, janelas corretas e TZ, matrizes de retenção e LTV, segmentação e verificação de causa. Esta abordagem não só ajuda a observar as curvas, mas também a tomar decisões: onde consertar a linha, quais canais de escala, quais conteúdos e offs mantêm os jogadores por mais tempo e aumentam a LTV.

Análise de linha