Como faço análise preditiva — do dado bruto ao dashboard acionável — com IA

O percurso inteiro, não apenas as partes

A maioria dos conteúdos sobre análise preditiva com IA foca em partes isoladas do processo: como treinar um modelo, como criar um dashboard bonito, como limpar dados. Faltam os conteúdos que mostram o percurso completo — do dado bruto ao insight que a liderança usa para tomar decisão.

Esse percurso completo é o que vou mostrar neste artigo. Não como um tutorial técnico de Python — há centenas desses disponíveis. Mas como o processo real que executo nos meus projetos: as decisões que tomo, os problemas que encontro, e como o framework que desenvolvi com base nas metodologias da Trilion me ajuda a navegar por cada etapa com consistência.

Vou usar um caso representativo ao longo do artigo: uma empresa de SaaS de gestão para clínicas de saúde, com 1.200 clientes ativos, que precisava prever quais clientes expandiriam o contrato nos próximos 90 dias para priorizar o esforço do time comercial.

Etapa 1 — Entendimento do problema de negócio

Todo projeto de análise preditiva começa com uma conversa de negócio, não com dados. A pergunta que faço antes de qualquer outra: 'Que decisão específica vai ser tomada de forma diferente porque você tem essa previsão?'

No caso da clínica de saúde, a resposta foi: 'Com a previsão de expansão, vou saber em quais contas o time comercial deve focar nos próximos 90 dias para maximizar o ARR. Hoje eles abordam contas aleatoriamente ou por intuição — quero que a abordagem seja guiada por dados.'

Essa resposta define tudo: o horizonte de previsão (90 dias), a variável alvo (expansão de contrato), e o uso final (priorização da carteira comercial). Com isso definido, sei exatamente que modelo construir e como avaliá-lo.

'O problema de negócio mal definido é o vilão número 1 dos projetos de IA que não geram resultado. Antes de qualquer dado, qualquer código, qualquer modelo — defina a decisão.' — Princípio central do framework da Trilion

Etapa 2 — Inventário e auditoria de dados

Antes de construir qualquer pipeline, faço um inventário completo dos dados disponíveis. Para o projeto da clínica:

Dados disponíveis:

• Tabelas do produto: eventos de uso, sessões, features utilizadas, usuários por conta
• CRM: histórico de interações, tamanho do contrato, data de renovação, contatos
• Financeiro: histórico de pagamentos, upgrades e downgrades passados
• Suporte: tickets por conta, CSAT, tempo de resolução

Dados ausentes que seriam valiosos:

• NPS por conta (não eram coletados sistematicamente)
• Informações sobre crescimento da clínica cliente (número de profissionais, faturamento)
• Dados de uso de módulos específicos — o produto registrava sessões, mas não ações dentro de módulos

Com esse inventário, defino o que vou usar, o que vou aproximar e o que vou ignorar. Tentar incluir dados que não existem ou que precisam de coleta manual é uma forma de travar o projeto antes de ele começar.

Etapa 3 — Construção do pipeline de dados

Com as fontes mapeadas, construo o pipeline de transformação em dbt. Para esse projeto, o pipeline tinha cinco camadas:

• Raw layer: dados brutos das fontes, sem transformação, apenas com versionamento de ingestão.
• Staging layer: limpeza básica — tipos de dados corretos, nulos tratados, duplicatas removidas.
• Intermediate layer: agregações por conta por semana — uso semanal, tickets abertos, interações de CS.
• Mart layer: dataset final de modelagem — uma linha por conta, com todas as features calculadas para o período de observação definido.
• Prediction layer: tabela onde as previsões do modelo serão escritas após cada run.

Uso dbt tests em cada camada para garantir integridade: verificações de unicidade de chaves, verificações de nulos em colunas críticas, verificações de ranges aceitáveis para métricas numéricas. Isso me protege de bugs silenciosos que contaminam o modelo sem que ninguém perceba.

Etapa 4 — Análise exploratória orientada a hipótese

A análise exploratória não é uma etapa livre — é uma etapa orientada por hipóteses de negócio. Antes de explorar os dados, listo de 5 a 10 hipóteses sobre o que provavelmente explica a expansão de contrato:

• 'Contas que ativam o módulo financeiro têm mais propensão a expandir porque percebem mais valor.'
• 'Contas com múltiplos usuários ativos têm mais propensão a expandir porque há mais dependência organizacional.'
• 'Contas que passaram por upgrade de plano nos últimos 12 meses têm mais propensão a um segundo upgrade.'

A análise exploratória então testa essas hipóteses com dados. Algumas são confirmadas, outras refutadas, e algumas revelam nuances inesperadas. Esse processo de hipótese-teste é o que torna a análise exploratória um exercício analítico e não uma jornada aleatória por gráficos.

O que encontrei no projeto da clínica

As hipóteses confirmadas pelos dados foram surpreendentes em alguns casos:

• O uso do módulo financeiro confirmou correlação forte com expansão — mas apenas quando ativado nos primeiros 30 dias. Após 30 dias, a correlação caia drasticamente.
• O número de usuários ativos foi o preditor mais forte de expansão — mais do que qualquer métrica financeira.
• Contas que haviam aberto tickets críticos nos últimos 60 dias e recebido resolução rápida tinham taxa de expansão maior do que contas sem tickets — o que sugeria que o suporte bem prestado criava lealdade.

'A análise exploratória bem feita revela os paradoxos dos dados — os padrões que contrarian a intuição de negócio. Esses paradoxos são frequentemente as descobertas mais valiosas de todo o projeto.' — Metodologia dos cases da Trilion

Etapa 5 — Engenharia de features

Com as hipóteses testadas, construo o conjunto de features para o modelo. Para o projeto da clínica, as features que desenvolvi:

• Dias até a data de renovação do contrato
• Número de usuários ativos no último mês dividido pelo total de licenças
• Trend de sessões semanais nas últimas 6 semanas (slope da regressão linear)
• Indicador binário: módulo financeiro ativado nos primeiros 30 dias
• Número de features core usadas regularmente (pelo menos uma vez por semana)
• Dias desde o último ticket crítico
• Resolução do último ticket crítico: rápida (menos de 4 horas), média (4-24 horas) ou lenta (mais de 24 horas)
• Histórico de upgrades anteriores: quantos upgrades a conta já fez
• Tamanho atual do contrato em reais — MRR da conta
• Segmento da clínica: especialidade médica (ortopedia, dermatologia, etc.) — algumas especialidades tinham propensão de expansão muito diferente

Etapa 6 — Treinamento, seleção e validação do modelo

Para esse problema — classificação binária (vai expandir / não vai expandir) com dados tabulares — testo quatro modelos:

• Logistic Regression com regularização L2 (baseline)
• Random Forest
• LightGBM
• Ensemble dos três via soft voting

Uso validação temporal: treino nos dados de clientes históricos e valido na coorte mais recente que ainda não foi usada para treino. Isso simula o ambiente de produção e evita data leakage.

No projeto da clínica, o LightGBM superou os demais com AUC-ROC de 0.84 e Precision@top20% de 71% — ou seja, das 20% de contas com maior score, 71% de fato expandiram no período de validação. Para o uso de priorização de carteira, esse é o número que importa: quando o time comercial trabalha as contas do topo da lista, qual é a taxa de acerto?

Etapa 7 — Interpretabilidade e validação com stakeholders

Antes de colocar qualquer modelo em produção, apresento os resultados para os stakeholders com foco em interpretabilidade. Uso SHAP para mostrar os principais fatores de expansão por conta e globalmente.

Essa apresentação tem dois objetivos:

• Validação de negócio: os fatores que o modelo identificou fazem sentido para quem conhece os clientes? Se o modelo diz que 'número de usuários ativos' é o fator mais importante e o time de CS concorda — ótimo. Se o modelo aponta um fator que parece contraintuitivo, investigo antes de colocar em produção.
• Geração de confiança: times que entendem por que o modelo recomenda o que recomenda adotam o modelo. Times que recebem apenas o score de 0 a 100 sem contexto não confiam e não usam.

Etapa 8 — Construção do dashboard acionável

O dashboard de expansão que construí no Power BI para o projeto da clínica tem três visões principais:

Visão 1 — Ranking de oportunidades: lista das 20% de contas com maior score de expansão, com o MRR atual, o MRR potencial estimado após expansão, e os três principais fatores que estão elevando o score de cada conta. O comercial vê imediatamente em quem focar e por quê.

Visão 2 — Mapa de saúde por segmento: distribuição do score de expansão por especialidade médica, tamanho de contrato e região. Ajuda o gestor comercial a identificar padrões por segmento e ajustar estratégia.

Visão 3 — Performance do modelo: métricas de calibração atualizadas semanalmente — o modelo continua acertando? A distribuição de scores está estável? Isso é para mim e para o time de dados, não para o comercial.

'Um dashboard acionável não é um dashboard com muitas informações — é um dashboard que leva o usuário direto para a próxima ação. Cada visão deve ter uma ação associada.' — Diretriz de design da Trilion

Etapa 9 — Deploy e monitoramento

O modelo vai para produção containerizado, com pipeline de retraining agendado para toda segunda-feira com os dados da semana anterior. O dashboard atualiza automaticamente após o retraining.

Monitoro três coisas semanalmente:

• Data drift: a distribuição das features está mudando? Se o comportamento dos clientes mudar drasticamente (como num lançamento de nova feature ou mudança de preço), o modelo pode degradar.
• Performance de negócio: das contas que o time comercial abordou com base no modelo, quantas expandiram? Esse é o ROI real.
• Feedback do time: o time comercial está encontrando padrões que o modelo não captura? Esse feedback vira feature nova no próximo retraining.

Resultados do projeto

Nos seis meses após o deploy do modelo e do dashboard no projeto da clínica:

• Taxa de conversão de abordagem comercial para expansão aumentou de 14% para 31% — o time passou a abordar as contas certas no momento certo.
• ARR médio das expansões aumentou 22% porque o modelo priorizava contas com maior potencial de expansão, não apenas as mais propensas a qualquer tipo de expansão.
• O ciclo de venda de expansão reduziu em 18 dias porque o modelo identificava contas já prontas para a conversa, eliminando o tempo de warm-up.

Conclusão

Análise preditiva de verdade não é sobre o modelo mais sofisticado — é sobre o processo mais completo. Do entendimento do problema ao dashboard acionável, cada etapa tem seu papel e sua complexidade específica.

O framework de nove etapas que compartilhei aqui — desenvolvido e refinado com base nas práticas da Trilion e em projetos reais — é o que garante que o resultado final não seja apenas um modelo tecnicamente correto, mas uma ferramenta que a liderança usa para tomar decisões melhores.

Se você quer ver esse processo aplicado ao seu contexto, o próximo passo é explorar o exemplo prático que preparamos.

Ver Exemplo Prático da Trilion — acesse o case completo de análise preditiva com código Python, estrutura dbt, modelo calibrado e dashboard Power BI. Disponível com documentação detalhada de cada etapa do processo.