Análise de dados quase nunca é aquilo que os cursos desenham: uma linha reta que começa numa planilha e termina num gráfico bonito. Na prática é um ciclo — etapas encadeadas, com voltas frequentes a fases anteriores, cujo objetivo não é produzir um gráfico, mas produzir uma decisão defensável.
Neste post percorro as oito etapas desse ciclo: o que caracteriza cada uma, o erro típico que se comete nela, e o critério que permite dizer “esta etapa está concluída”. No fim, mostro como os frameworks clássicos — CRISP-DM, KDD, SEMMA, OSEMN — dizem quase as mesmas coisas com nomes diferentes.
1. O ciclo, em uma figura
O ciclo de vida organiza o trabalho analítico em etapas com entradas, saídas e critérios de qualidade definidos. A propriedade mais importante dele é a que a figura tenta deixar explícita: isso não é uma esteira.
As três setas tracejadas não são enfeite nem sinal de projeto malfeito. São o comportamento normal do trabalho analítico: descobertas feitas na exploração reformulam a pergunta original, e o que se observa em produção alimenta a iteração seguinte.
Regra prática de esforço Em projetos reais, a distribuição típica de tempo é aproximadamente: 10% definição do problema, 15% coleta, 40–50% preparação e limpeza, 10% exploração, 10% modelagem e 15% comunicação e implantação.
A etapa mais cara é a menos glamourosa — e é ela que determina a qualidade de todo o resto.
2. Definição do problema
Nenhuma técnica compensa uma pergunta mal formulada. Esta etapa converte uma demanda vaga (“queremos entender o churn”) em uma pergunta analítica respondível, com escopo, unidade de análise e critério de sucesso explícitos.
- Entrada: demanda de negócio, contexto do domínio, restrições de prazo e de dados.
- Saída: pergunta operacionalizada, hipóteses, métricas de sucesso, definição da população e do horizonte temporal.
Quatro perguntas precisam de resposta antes de escrever a primeira linha de código:
- Qual decisão será tomada com base neste resultado? Se nenhuma, o projeto é opcional.
- Qual é a unidade de análise — cliente, transação, sessão, mês?
- O que se pretende: descrever (o que aconteceu), diagnosticar (por quê), prever (o que vai acontecer) ou prescrever (o que fazer)?
- Qual seria um resultado inconveniente, e ele ainda assim seria aceito?
A quarta é a que mais gente pula, e é a que separa análise de encomenda. Se a resposta é “não”, o que se está pedindo não é uma análise.
Armadilha típica: confundir uma métrica com o conceito que ela representa. “Engajamento” não é “número de cliques”; escolher o proxy errado aqui contamina irreversivelmente todas as etapas seguintes — e o pior é que nada nas etapas seguintes vai acusar o erro.
3. Coleta e aquisição dos dados
Aqui se reúne o material bruto: bancos transacionais, data warehouses, APIs, arquivos de terceiros, web scraping, instrumentação de produto, pesquisas e experimentos desenhados.
A distinção que mais importa:
- Dados primários são gerados para responder à sua pergunta (experimentos, questionários) — caros, mas alinhados ao problema.
- Dados secundários já existem (logs, sistemas internos, bases públicas) — baratos, mas coletados para outro propósito, o que introduz vieses silenciosos.
Três cuidados centrais:
- Representatividade. O mecanismo que gerou os dados também decide quem não está neles. Sobreviventes, respondentes e usuários ativos raramente representam a população de interesse.
- Rastreabilidade. Registre origem, data de extração, query utilizada e versão da base. Análise sem procedência não é reproduzível — e, seis meses depois, ninguém lembra de qual snapshot saiu aquele número.
- Conformidade. Base legal para o tratamento, minimização de dados pessoais, anonimização quando possível (LGPD/GDPR).
4. Preparação, limpeza e transformação
A etapa mais longa, e por larga margem. Dados brutos praticamente nunca estão em condição de análise. O objetivo é chegar a um conjunto tidy: cada linha uma observação, cada coluna uma variável, cada célula um valor.
| Problema | Tratamento usual |
|---|---|
| Dados faltantes | Diagnosticar o mecanismo (MCAR, MAR, MNAR) antes de decidir; descarte, imputação simples ou múltipla. Nunca imputar sem registrar o que foi imputado. |
| Duplicatas | Definir a chave que identifica uma observação única; deduplicar por regra explícita, não por intuição. |
| Inconsistências de tipo e formato | Padronizar datas, unidades, codificação de texto e categorias escritas de formas diferentes ("SP", "S.P.", "São Paulo"). |
| Outliers | Separar erro de medição de valor legítimo extremo. O segundo caso costuma ser o mais informativo do conjunto. |
| Escalas e distribuições | Padronização, normalização, transformações (log, Box–Cox) quando o método posterior exigir. |
| Variáveis derivadas | Feature engineering: razões, defasagens, agregações por janela, codificação de categóricas. |
MCAR, MAR, MNAR: por que o mecanismo decide tudo
A primeira linha da tabela merece um parágrafo próprio, porque é o item que mais silenciosamente invalida análises. As três siglas são a tipologia de Donald Rubin (1976) para mecanismos de dados faltantes, e a ideia central é que o que importa não é quanto falta — é por que falta.
Os três mecanismos
- MCAR (missing completely at random) — a ausência não depende de nada: nem do valor que faltou, nem de qualquer variável observada. O equipamento do laboratório queimou numa terça e as amostras daquele dia se perderam. Os dados presentes são uma amostra aleatória simples dos completos.
- MAR (missing at random) — a ausência depende apenas do que você observou. Renda falta mais em questionários de jovens; se a idade está registrada, então dentro de cada faixa etária a ausência não depende da renda em si. O nome é infeliz: não é “aleatório”, é aleatório condicionalmente ao observado.
- MNAR (missing not at random) — a ausência depende do próprio valor que não foi observado. Renda falta mais entre quem ganha muito: a probabilidade de responder é função justamente do número que você não tem.
A consequência prática de cada um é diferente, e é aqui que a escolha do tratamento se decide:
| Mecanismo | Descartar os incompletos é válido? | Imputação resolve? | Dá para testar nos dados? |
|---|---|---|---|
| MCAR | Sim — perde-se poder, não validade | Desnecessária, mas recupera poder | Parcialmente (teste de Little) |
| MAR | Não — enviesa | Sim, se o modelo de imputação incluir as variáveis que explicam a ausência | Não |
| MNAR | Não — enviesa | Não | Não |
Sob MAR, imputar renda sem usar a idade não salva ninguém: a garantia vale para o modelo que contém a variável responsável pela ausência, não para qualquer imputação. E sob MNAR, nenhum método que use só os dados observados corrige o problema — resta modelar o próprio mecanismo de ausência (modelos de seleção de Heckman, pattern-mixture models) ou, mais honestamente, fazer análise de sensibilidade: mostrar como a conclusão muda sob hipóteses alternativas sobre os faltantes.
O ponto que a maioria dos textos omite:
MAR versus MNAR é indecidível a partir dos dados Não existe teste. Por definição, distinguir os dois exigiria conhecer os valores que faltam — e, se você os conhecesse, não haveria problema algum.
Ou seja: MAR é sempre uma suposição, nunca uma constatação. É por isso que a tabela diz “diagnosticar o mecanismo antes de decidir”: o diagnóstico é substantivo, não estatístico. Ele vem de entender como o dado foi coletado — quem respondeu, quem desistiu, o que o sistema deixou de gravar e por quê. É a mesma lógica de representatividade da etapa anterior: o mecanismo que gerou os dados também decide quem não está neles.
Daí vem a segunda frase daquela célula — nunca imputar sem registrar o que foi imputado. Um valor imputado carrega incerteza que um valor medido não carrega. Se ele circula sem marcação, a validação (etapa 6) vai medir precisão sobre números inventados, e não terá como saber disso.
Vazamento de informação (data leakage) Qualquer transformação que use estatísticas do conjunto completo (média, desvio, categorias) precisa ser ajustada apenas no conjunto de treino e depois aplicada aos demais.
Padronizar antes de dividir os dados é o erro mais comum e o mais difícil de detectar — ele produz métricas otimistas que desabam em produção, e nada no relatório denuncia o problema.
5. Análise exploratória (EDA)
Antes de modelar, é preciso conhecer os dados. A EDA é deliberadamente aberta: busca estrutura, padrões, anomalias e relações, e serve tanto para gerar hipóteses quanto para verificar os pressupostos das técnicas que virão.
- Univariada: distribuições, medidas de tendência central e dispersão, assimetria, contagens por categoria.
- Bivariada: correlações, tabelas cruzadas, comparações entre grupos, gráficos de dispersão.
- Multivariada: interações, redução de dimensionalidade, agrupamentos, estrutura temporal e espacial.
Visualização não é enfeite: é o instrumento principal desta etapa. O quarteto de Anscombe e o Datasaurus Dozen mostram conjuntos com médias, variâncias e correlações idênticas e formatos radicalmente diferentes. Resumos numéricos escondem; gráficos revelam.
Armadilha típica: p-hacking por exploração — testar dezenas de relações e reportar apenas as significativas. A EDA gera hipóteses; ela não as confirma. Confirmação exige dados que não foram usados para formulá-las.
6. Modelagem e inferência
Aqui a pergunta é formalizada em um modelo. A escolha decorre diretamente do objetivo definido na etapa 1 — não do que está na moda:
| Objetivo | Pergunta | Abordagens típicas |
|---|---|---|
| Descritivo | O que aconteceu? | Estatística descritiva, segmentação, agrupamento, séries históricas. |
| Inferencial | O padrão observado se sustenta na população? | Intervalos de confiança, testes de hipótese, modelos lineares e generalizados, métodos bayesianos. |
| Preditivo | O que deve acontecer? | Regressão, árvores e ensembles, redes neurais, modelos de séries temporais. |
| Causal | O que acontece se intervirmos? | Experimentos aleatorizados, diferenças-em-diferenças, variáveis instrumentais, escore de propensão. |
Predição não é causalidade Um modelo pode prever muito bem usando variáveis que não causam nada — consumo de sorvete prevê afogamentos. Para responder “o que fazer”, predição de alta acurácia é insuficiente: é necessário um desenho de identificação causal.
Um bom relato de modelagem sempre inclui três coisas: os pressupostos assumidos, a estratégia de validação e o modelo mais simples que serve de linha de base. Um modelo complexo que não supera a média histórica não justifica a própria complexidade.
7. Validação e interpretação
Etapa de contraprova. Um resultado só vale se sobrevive a tentativas honestas de derrubá-lo.
- Validação estatística: verificação de pressupostos, análise de resíduos, validação cruzada, avaliação em conjunto de teste intocado e — quando há dimensão temporal — validação out-of-time.
- Análise de sensibilidade: os resultados mudam sob outras escolhas razoáveis de limpeza, especificação ou período?
- Métricas adequadas ao problema: acurácia é enganosa em bases desbalanceadas; a escolha entre precisão, revocação, AUC, calibração ou custo esperado deve refletir o custo real dos erros.
- Significância prática: um efeito estatisticamente significativo pode ser irrelevante em magnitude. Reporte o tamanho do efeito, não apenas o valor-p.
- Equidade e viés: o desempenho se mantém entre subgrupos? Modelos treinados em dados históricos herdam desigualdades históricas.
8. Comunicação dos resultados
Análise que não é compreendida não gera decisão. A comunicação deve ser construída para o público, não para o analista.
- Estrutura: conclusão primeiro, depois evidência, depois método. O detalhe técnico vai para o apêndice.
- Honestidade sobre incerteza: apresente intervalos, não apenas pontos; declare limitações e o que os dados não permitem afirmar.
- Visualização responsável: eixos não truncados de forma enganosa, escalas comparáveis, elementos decorativos ausentes.
- Recomendação acionável: vincule cada conclusão à decisão que ela informa e ao seu grau de confiança.
9. Implantação e monitoramento
Quando o resultado alimenta um processo recorrente — um dashboard, um escore em produção, uma regra automatizada — o ciclo não termina na entrega.
- Operacionalização: versionamento de código, dados e modelo; pipelines reprodutíveis; testes automatizados sobre os dados de entrada.
- Monitoramento de desempenho: as métricas de validação se mantêm com dados novos?
- Data drift e concept drift: a distribuição das variáveis muda; a relação entre variáveis e alvo também. Um modelo estável em um mundo instável degrada silenciosamente.
- Ciclos de realimentação: um modelo que influencia o comportamento que ele prevê altera os próprios dados que o alimentam.
- Critério de reciclagem: defina antes da implantação o gatilho de retreinamento ou de aposentadoria do modelo.
10. Os frameworks clássicos, lado a lado
Diferentes tradições nomeiam as mesmas etapas de formas distintas. Vale conhecer a correspondência para não se perder quando alguém disser “estamos na fase de Modify”.
| Este ciclo | CRISP-DM | KDD | SEMMA | OSEMN |
|---|---|---|---|---|
| 1. Problema | Entendimento do negócio | — | — | — |
| 2. Coleta | Entendimento dos dados | Seleção | Sample | Obtain |
| 3. Preparação | Preparação dos dados | Pré-processamento e transformação | Modify | Scrub |
| 4. Exploração | Entendimento dos dados | — | Explore | Explore |
| 5. Modelagem | Modelagem | Mineração de dados | Model | Model |
| 6. Validação | Avaliação | Interpretação / avaliação | Assess | — |
| 7. Comunicação | Implantação | Consolidação do conhecimento | — | iNterpret |
| 8. Monitoramento | Implantação | — | — | — |
- CRISP-DM (1999) permanece o mais usado na indústria por ser explicitamente iterativo e por começar no negócio, não nos dados.
- KDD é o mais antigo e enfatiza a descoberta de conhecimento.
- SEMMA, de origem SAS, foca no ciclo técnico de modelagem e omite tanto o enquadramento do problema quanto a implantação.
- OSEMN é um mnemônico prático, popular em ciência de dados.
Nenhum deles substitui o julgamento: são mapas, não trilhos. Repare nos travessões da tabela — as lacunas dizem mais sobre cada framework do que os preenchimentos.
11. Por que o ciclo é iterativo
Três retornos são tão frequentes que devem ser previstos no cronograma, não tratados como imprevisto:
- Exploração → Definição do problema. A EDA revela que a pergunta original não é respondível com os dados existentes, ou que a pergunta interessante é outra.
- Validação → Preparação. Resíduos com estrutura, desempenho instável entre subgrupos ou vazamento detectado obrigam a revisar a construção das variáveis.
- Monitoramento → Novo ciclo. A degradação em produção é informação nova sobre o fenômeno, e inicia a próxima iteração com uma pergunta melhor.
Tratar essas voltas como fracasso leva a escondê-las. Tratá-las como parte do processo é o que distingue análise madura de análise apressada.
12. Lista de verificação: quando uma etapa está concluída
Uma etapa está concluída quando…
- Problema: a pergunta cabe em uma frase e a decisão que ela informa está nomeada.
- Coleta: a origem de cada campo é rastreável e o mecanismo de seleção da amostra é conhecido.
- Preparação: toda transformação está em código executável, e o conjunto se reconstrói do bruto sem intervenção manual.
- Exploração: você consegue descrever a distribuição de cada variável relevante e explicar cada anomalia encontrada.
- Modelagem: existe uma linha de base simples e o modelo escolhido a supera de forma mensurável.
- Validação: o desempenho foi medido em dados nunca usados para ajustar nada, e é estável sob escolhas alternativas razoáveis.
- Comunicação: o público consegue reproduzir a conclusão e enunciar as limitações com suas próprias palavras.
- Implantação: há métrica monitorada, alerta configurado e critério de retreinamento definido.
“Todos os modelos estão errados; alguns são úteis.” — George E. P. Box
O ciclo existe para maximizar a segunda parte da frase.
Comentários