Um framework de medicao antes de tocar no pipeline

A maioria dos projetos de dados comeca pelo pipeline. Alguem pede um dashboard, o time de dados abre o dbt, modela as tabelas e entrega. Duas semanas depois, a pergunta muda. O dashboard nao responde mais. Tres meses de trabalho jogados fora.

Esse artigo conta como um framework de medicao, definido antes de qualquer linha de SQL, salvou um projeto de churn de cair nessa armadilha.

O problema mal definido

O pedido inicial era simples: “precisamos entender nosso churn.” Mas churn pode significar coisas diferentes dependendo de quem pergunta.

• Produto queria saber em qual etapa do onboarding os usuarios desistiam.
• Financeiro queria a taxa de cancelamento mensal por cohort.
• CS queria prever quais contas estavam em risco.

Tres perguntas diferentes. Tres definicoes de churn. Se o time de dados tivesse comecado pelo pipeline, teria construido para uma dessas definicoes e descoberto tarde demais que as outras duas existiam.

O custo do retrabalho

Retrabalho em dados nao e so refazer SQL. E revalidar premissas, recalcular historicos, atualizar documentacao, retreinar stakeholders. Num projeto medio, cada iteracao custa de tres a seis semanas. Duas iteracoes e voce perdeu um trimestre.

Definicao antes de dbt

O framework de medicao inverte a ordem. Antes de abrir o editor, voce responde quatro perguntas:

1. Qual decisao essa metrica informa? Se ninguem vai tomar uma decisao diferente com base no numero, a metrica nao precisa existir.
2. Quem e o publico? Produto, financeiro e CS precisam de granularidades diferentes. Definir o publico evita o dashboard unico que nao serve ninguem.
3. Qual e a definicao operacional? “Churn” nao e uma definicao. “Usuario que nao fez login nos ultimos 30 dias e tinha pelo menos 3 sessoes no mes anterior” e.
4. Como vamos saber se esta funcionando? Toda metrica precisa de um meta ou baseline. Sem referencia, um numero e so um numero.

O canvas na pratica

Montamos um canvas de uma pagina com essas quatro perguntas para cada metrica. O time inteiro preencheu junto: dados, produto, CS e financeiro. Levou duas horas. Economizou tres meses.

O resultado foi um mapa de sete metricas, cada uma com dono, definicao, granularidade e meta. So entao abrimos o dbt.

A arquitetura que emergiu

Com as definicoes claras, a arquitetura praticamente se desenhou:

• Uma staging layer com eventos brutos, sem logica de negocio.
• Uma intermediate layer com as definicoes operacionais de cada metrica.
• Uma marts layer com as agregacoes por publico.

Cada camada mapeava diretamente para uma decisao do canvas. Nada de “vamos modelar tudo e ver o que sai.”

Validacao continua

O framework tambem definiu regras de validacao: se a taxa de churn mensal ultrapassar 15%, um alerta dispara. Nao porque 15% seja um numero magico, mas porque o canvas definiu que acima disso a decisao muda de “otimizar onboarding” para “investigar problema sistemico.”

O que mudou na decisao

Depois de tres meses rodando:

• Produto identificou que o churn de onboarding estava concentrado no dia 3, nao no dia 1 como assumiam. Mudaram o fluxo de ativacao.
• Financeiro descobriu que a taxa de cancelamento era estavel, mas o mix de planos estava mudando. O problema nao era retencao, era pricing.
• CS comecou a usar o score de risco para priorizar contatos proativos. A taxa de salvamento subiu 22%.

Nenhuma dessas decisoes teria emergido de um dashboard generico de churn. Emergiram porque as perguntas certas foram feitas antes da primeira linha de codigo.

Licoes para o proximo projeto

1. Comece pelo canvas, nao pelo pipeline.
2. Envolva todos os stakeholders na definicao. Duas horas de alinhamento valem tres meses de retrabalho evitado.
3. Cada metrica precisa de um dono e uma decisao associada.
4. Defina os thresholds de acao antes de ter os dados. Depois dos dados, vieses de ancoragem contaminam os limites.
5. Documente as definicoes operacionais no mesmo repositorio do codigo. Se a definicao esta num Confluence que ninguem le, ela nao existe.