SaaS Revenue Intelligence: Do Lead ao Churn

Por /

A Importância de Modelar Problemas em Ciência de Dados: Do Zero ao Dashboard Estratégico

Muitos aspirantes a dados sabem fazer gráficos coloridos e escrever linhas de código, mas poucos sabem realmente modelar o problema. No mundo real, os dados não chegam prontos; eles precisam ser arquitetados para responder a perguntas de negócio.

Neste post, vou mostrar como construí um projeto de Revenue Ops (Operações de Receita), saindo da geração de dados brutos até a tomada de decisão estratégica. Veremos como a Ciência de Dados vai muito além da ferramenta: ela é sobre entender a lógica por trás dos números.

O Erro de “Muitos para Muitos” em Marketing e Vendas

Um dos desafios mais comuns em projetos de Análise de Dados é unir fontes com granularidades diferentes. Imagine o cenário:

  • O time de Marketing olha para Leads (cada pessoa é uma linha).
  • O time Financeiro olha para Transações (cada pagamento é uma linha).

Se tentarmos ligar essas duas tabelas diretamente no Power BI ou SQL, criamos um relacionamento “Muitos para Muitos”. Isso gera duplicidade de valores, erros de soma e dashboards lentos. O Power BI, por exemplo, muitas vezes bloqueia esse tipo de relação ou gera resultados ambíguos.

A Solução: Tabela Dimensão (dCliente)

Para resolver isso, utilizei o conceito de Modelagem Estrela (Star Schema). A solução foi criar uma tabela central, chamada dCliente (Dimensão Cliente).

Esta tabela funciona como uma “ponte”. Ela contém apenas IDs únicos de clientes. Assim, o filtro flui da seguinte maneira:

  1. A dCliente filtra a tabela de Marketing (para sabermos a origem do lead).
  2. A dCliente filtra a tabela Financeira (para somarmos o LTV).

Essa estrutura garante integridade na modelagem de problemas e performance no cálculo dos KPIs.

Trecho Relevante do Script Python

Antes de analisar, precisei agir como Engenheiro de Dados. Utilizei Python para gerar uma base de dados sintética que simulasse problemas reais, como clientes que cancelam o serviço (Churn).

Abaixo, apresento um trecho crucial do script onde implementei a lógica de Churn. Note como o código não apenas “para” de gerar pagamentos, mas registra explicitamente o evento de cancelamento, o que é vital para a análise posterior.

# Trecho do código referente à lógica de Churn e Geração de Transações

while data_pagamento <= DATA_FIM and ativo:
    meses_ativo += 1
    
    # Lógica de Churn: 5% de chance de cancelar após o primeiro mês
    if random.random() < 0.05 and meses_ativo > 1:
        ativo = False
        # Registramos o evento de Churn explicitamente para o BI
        transacoes.append({
            'id_transacao': f'TRX-{random.randint(100000, 999999)}',
            'id_cliente': id_cliente,
            'data_pagamento': data_pagamento, # Data do cancelamento
            'valor': 0, 
            'plano': plano_atual,
            'tipo_transacao': 'Churn' 
        })
        break
        
    # Geração da transação recorrente (pagamento normal)
    transacoes.append({
        'id_transacao': f'TRX-{random.randint(100000, 999999)}',
        'id_cliente': id_cliente,
        'data_pagamento': data_pagamento,
        'valor': valor_atual,
        'plano': plano_atual,
        'tipo_transacao': 'Recorrente' if meses_ativo > 1 else 'Nova Venda'
    })
    
    data_pagamento += relativedelta(months=1)

Análise do Gráfico de Barras: CAC vs LTV

Com os dados modelados e tratados, chegamos ao coração da Ciência de Dados: a geração de valor.

O gráfico abaixo compara duas métricas fundamentais para qualquer empresa SaaS:

  1. CAC (Custo de Aquisição de Cliente): Quanto gastamos para trazer um cliente.
  2. LTV (Lifetime Value): Quanto esse cliente gastou conosco ao longo da vida.

A Regra de Ouro: A barra do LTV (Retorno) deve ser sempre significativamente maior que a barra do CAC (Custo).

Ao analisar o gráfico, identificamos um insight crítico: o canal LinkedIn apresentava um CAC altíssimo com um LTV baixo. Em contrapartida, canais como Orgânico e Indicação traziam lucro quase puro. Essa visualização permite que o gestor corte gastos ineficientes imediatamente.

Traduzindo Dados em Decisões

Este projeto reforça que dados sem contexto são apenas números em uma tela. O verdadeiro papel do Cientista de Dados não é apenas escrever código ou criar visuais bonitos, mas sim traduzir essa complexidade técnica em tomada de decisão clara.

Ao modelar o problema corretamente desde a origem (Python) até a visualização (Power BI), conseguimos transformar terabytes de “ruído” em uma estratégia de negócios clara: pausar investimentos no LinkedIn e focar no crescimento orgânico.

É essa visão holística — da engenharia à estratégia — que define uma Análise de Dados de alto impacto.

Gostou deste estudo de caso? Confira o código completo e o arquivo do dashboard no meu GitHub e vamos nos conectar no LinkedIn.

Rolar para cima