Uma diretoria de Revenue vivia em 6 planilhas. Hoje decide em 30 segundos.

O contexto

A PagLeve (fictícia) é uma fintech de meios de pagamento pra pequenos negócios digitais. Microempreendedores que vendem por redes sociais e marketplaces e usam a plataforma pra gerar cobranças, receber vendas e gerir o caixa. O crescimento é operado por uma diretoria de Revenue com cinco frentes de aquisição e engajamento: Mídia Paga, Conteúdo e SEO, Influenciadores, Indicação (member get member) e CRM.

O funil de crescimento tem uma régua clara. Aquisição é o cadastro com a primeira cobrança gerada. Ativação é a primeira venda recebida. Cliente Qualificado, o "CQ", são duas vendas em até 7 dias contados da primeira venda, proxy de retenção futura. A north star da companhia é 1 milhão de transações por mês.

A dor da C-Level

A Diretora de Revenue começava todo dia com o mesmo ritual. Abria 6 ou mais planilhas e um dashboard de BI com páginas em manutenção pra montar, de cabeça, o diagnóstico do mês. Os sintomas se repetiam todo mês.

• Custos e metas viviam em planilhas, cada frente com um formato próprio: matriz de P&L com meses em colunas, uma aba nova de pacing por mês, abas narrativas por campanha. Nenhum padrão entre elas.
• Indicadores viviam no data warehouse, mas sem ligação com o custo. Era impossível responder se o gasto estava virando resultado sem trabalho manual.
• Cada frente media CAC com régua própria. Comparar eficiência entre frentes era um exercício de fé.
• Zero governança. Um erro de digitação numa planilha contaminava a leitura do mês inteiro, sem alerta, sem auditoria, sem backup.
• O dashboard de BI existente misturava visão estratégica com operacional. A diretora navegava tabelas de campanha pra achar um número de direção.

O custo real dessa dor era de 30 a 40 minutos diários de leitura fragmentada, decisões tomadas sobre dados sem confiabilidade verificável, e nenhuma visão comparável de contribuição por frente.

O que construí

Um produto de dados completo, do pipeline à interface.

Planilhas Google (custos/metas)        Data Warehouse (indicadores de funil)
        │                                        │
        ▼                                        │
  n8n — extração CRUA (4 workflows, diários)     │
  + auditoria via Drive API (quem/quando)        │
        ▼                                        ▼
┌──────────────────── BigQuery ────────────────────────┐
│  RAW (append-only, imutável, tudo STRING)            │
│    → PORTÃO DE VALIDAÇÃO (QA automático)             │
│        ├─ reprova → QUARENTENA (motivo linha a linha)│
│        └─ aprova → SILVER (parse SQL versionado)     │
│    → GOLD (pré-agregado, semáforos e YoY resolvidos) │
│  + auditoria · snapshots mensais · ajustes manuais   │
└──────────────────────┬───────────────────────────────┘
                       ▼
        Camada de leitura (API/conector)
                       ▼
   Dashboard executivo (React) — Cloud Run + IAP
   ESTRATÉGICO (diretoria) × TÁTICO (coordenações)
                       +
   Alertas automáticos no Slack (falha, atraso, desvio)

Três entregas em um projeto só: o dashboard executivo, o pipeline governado que o alimenta e o modelo de governança (contratos de dados, auditoria, resiliência) que mantém tudo confiável.

Descoberta e diagnóstico

Antes de desenhar qualquer coisa, auditei as fontes reais.

Mídia Paga ficou de fora dessa lista de planilhas problemáticas de propósito: o custo dela já vinha direto da API do Google e do Meta Ads, automatizado, sem planilha no meio. Os 4 workflows do n8n cobrem exatamente as 4 fontes de planilha que precisavam de extração.

O diagnóstico chegou a uma conclusão simples. O problema não era fazer um dashboard bonito. Era arquitetar a ponte entre dois mundos, planilhas vivas e warehouse, sem quebrar a rotina dos times e sem herdar a fragilidade das planilhas.

Princípios de arquitetura

As decisões que importam, na ordem em que as tomei.

1. Modelo híbrido. Defini a planilha como fonte da verdade do gasto e da meta (é onde o financeiro concilia) e o warehouse como fonte da verdade do funil. Não brigo com isso, eu integro as duas pontas.
2. Raw-first e ELT. Fiz o extrator (n8n) burro de propósito. Ele fotografa as planilhas como string crua, append-only. Toda a inteligência, parse, tipo, de-para, regra de negócio, vive em SQL versionado. Se a planilha muda, ajusto um arquivo SQL e reprocesso o histórico inteiro a partir do raw. Nada se perde.
3. Rotina quase intocada para os times. Os workflows absorvem o formato existente, com descoberta dinâmica de abas por regex e fingerprint de cabeçalho. A exigência de rotina mais pesada foi uma miniaba de resumo pra única fonte imparseável (o CRM); as demais frentes ganharam só um contrato leve de convenções (não renomear, número como número), detalhado mais abaixo.
4. Erro na origem nunca derruba o painel. Montei um portão de validação com checks técnicos (fórmulas quebradas, datas implausíveis, duplicidades) e de plausibilidade (total contra célula de controle, valor diário maior que 5 vezes a mediana de 60 dias). Carga suspeita vai pra quarentena, com motivo linha a linha. O painel segue no último dado válido (LKG), com um badge transparente de "dados em validação".
5. Auditoria de ponta a ponta. Cada carga registra, via Drive API, quem alterou a planilha, quando e qual revisão, exposto na página de metodologia do painel. Meses fechados ficam congelados. Alteração retroativa na origem não entra sozinha, gera alerta e aguarda aprovação.
6. Tudo que o front lê é gold pré-agregado. Uma linha por grão, com semáforo e YoY resolvidos no SQL. O front só pinta. Latência baixa, zero lógica duplicada.
7. Backup à prova de exclusão. Raw append-only, snapshots mensais congelados e time travel. Se a planilha for apagada ou movida, todo o histórico validado permanece no warehouse.

O modelo de dados (medalhão)

Convenção de nomes: <camada>_<fonte>_<domínio>_<grão> (brz_ / slv_ / gld_), tudo CREATE OR REPLACE idempotente e particionado por data.

A régua única de 8 indicadores

O contrato de métricas que tornou as frentes comparáveis pela primeira vez. Presente em toda página de frente, na mesma ordem.

1. Investimento (R$)
2. Aquisição
3. Ativação
4. Taxa de Ativação (Ativação dividido por Aquisição)
5. Cliente Qualificado
6. Taxa de CQ (CQ dividido por Ativação)
7. CAC-Ativação (Investimento dividido por Ativação)
8. CAC-CQ (Investimento dividido por CQ)

Com duas exceções conscientes, documentadas no modelo de dados, não escondidas na interface: a frente orgânica (Conteúdo e SEO) não exibe os itens 1, 7 e 8 (não tem investimento a comparar), e o CRM é tratado como reativação, então também fica de fora do CAC-Ativação e do CAC-CQ.

O produto: dashboard executivo

Separação estratégico e tático

O erro do dashboard anterior era misturar níveis de decisão. O novo produto separa isso de forma explícita.

• Home, visão estratégica da diretoria. O que a C-Level decide: pacing consolidado do mês com projeção de fechamento (run-rate), metas de investimento e de CQ com percentual de atingimento, tabela de contribuição por frente (percentual do budget × percentual do resultado × CAC-CQ, ordenada por contribuição), shares de investimento, ativação e CQ em donuts, gráfico de onde está o dinheiro contra onde está o resultado, alertas com "decisão requerida" em nível de diretoria (revisar meta, SLA de dados, mix entre frentes, nunca campanha ou canal) e insights do mês.
• Páginas de frente, visão tática da coordenação. A régua de 8 indicadores, pacing diário real contra plano (barras no formato que os times já conheciam), tendência YoY com linha de referência de crescimento da empresa, e blocos operacionais (campanhas, cupons, pacing detalhado) isolados em seções colapsáveis de diagnóstico operacional.
• Pulso diário, página tática de anomalias. Cada indicador por dia contra a mediana e a banda P25 a P75 dos últimos 60 dias. Sazonalidade, campanha ou problema de tracking saltam aos olhos.
• Metodologia. Glossário das réguas, linhagem (de onde vem cada número), saúde de medição por fonte, com última atualização e autor da última alteração.

Princípios de dataviz aplicados

• Visual primeiro. Toda tabela nasce como gráfico, com alternância entre gráfico e tabela e download em CSV.
• Caixinha "Como ler" sob cada gráfico. Uma ou duas linhas didáticas. Gráfico que precisa de manual não decide nada.
• Tom copiloto, sem julgamento. Nenhum texto usa "pior" ou "melhor". Sempre dado comparativo mais referência (por exemplo, "Taxa de Ativação em 12,4%, mês anterior 13,1%, LY 14,2%") mais decisão sugerida. O painel informa, quem julga é o piloto.
• Semáforos resolvidos no SQL, com faixas numéricas explícitas (90 a 110% é dentro do ritmo), nunca recalculados no front.
• Comparação com o ano anterior em todos os cards, com métricas invertidas tratadas (CAC menor é melhor) e a referência oficial de crescimento anual como linha em todos os gráficos de tendência.

Processo de produto

Construí o protótipo numa ferramenta de AI app building (Lovable), com dados mock estruturados exatamente como as tabelas gold. Isso permitiu validar telas, indicadores e leitura com a C-Level antes de investir no pipeline. Foram 5 iterações guiadas por feedback real, incluindo duas correções de rota valiosas.

1. "Realocar budget por canal não é decisão da diretora, é da coordenação." Isso levou a uma reescrita completa dos alertas para o nível de decisão correto e à criação da hierarquia estratégico e tático.
2. "Não diga 'pior' ou 'melhor', traga o dado e a referência. Quem julga sou eu." Isso levou a uma revisão de todo o copy para o tom copiloto.

Essas iterações custaram horas no protótipo. Teriam custado semanas se descobertas depois do pipeline pronto.

Governança e resiliência

O que mantém a confiança no dado, mecanismo por mecanismo.

Fechei um contrato de dados de uma página por planilha com cada coordenação: 7 pedidos mínimos (não renomear abas, não renomear colunas chave, números como número em vez de formato local com vírgula, não misturar subtotal com detalhe na mesma coluna, cabeçalho em uma linha só, SLA de preenchimento D-1, avisar antes de reestruturar) em troca de um incentivo concreto, a página tática da própria frente, alertas automáticos e o fim da cobrança manual de atualização.

Segurança e hospedagem

• Protótipo. Autenticação Google restrita ao domínio corporativo, mais allowlist gerida em painel admin (papéis viewer e admin, admin fixo), com tela de "solicite acesso" pra quem está fora da lista.
• Produção (arquitetura definida). Código em repositório privado no GitHub (2FA, branch protection, secret scanning, zero credencial no código), deploy contínuo no Cloud Run (--no-allow-unauthenticated, escala a zero), Identity-Aware Proxy na frente (o Google barra contas fora do domínio na infraestrutura, antes de 1 byte do app carregar), allowlist do app como segunda camada de controle fino, dados via service account com escopo mínimo (leitura no dataset), segredos no Secret Manager.
• Racional de custo. A ferramenta de prototipagem cobrava por créditos de edição. A stack final (GitHub, Cloud Run, IAP) roda o mesmo app por cerca de R$ 0 a 15 por mês, com CI/CD e auditabilidade de TI.

Resultados e impacto

Números ilustrativos, com ordens de grandeza reais.

O ganho estrutural mais importante foi outro: a pergunta da diretora mudou. Antes era "quanto gastamos?", o que exigia caça manual. Hoje é "o gasto está virando cliente qualificado no ritmo da meta, e onde eu realoco?". Essa segunda pergunta é respondida em 30 segundos, com dado auditado. Não foi a única vez que precisei transformar planilha e achismo em ferramenta de decisão: no case do Simulador de Orçamento Multicanal, o problema era outro (canal de aquisição, não custo consolidado), mas a régua foi a mesma, validar contra o número oficial antes de qualquer decisão.

Stack e competências

As ferramentas e as competências que sustentaram o projeto de ponta a ponta.

Do lado técnico, apliquei analytics engineering (ELT raw-first, modelagem medalhão) e data governance (auditoria, contratos de dados, LGPD by design). Do lado de produto, usei product thinking (protótipo antes do pipeline, iteração com C-Level) e dataviz estratégico (hierarquia decisória, tom copiloto, visual primeiro). E do lado de infraestrutura, montei uma arquitetura cloud com custo próximo de zero e conduzi a gestão de stakeholders, com contratos com coordenações em troca de disciplina de dado.

Lições aprendidas

Protótipo com mock estruturado como o modelo final é o atalho mais barato que existe. Consegui 5 iterações de produto antes de escrever uma linha de pipeline.

A decisão de UX mais valiosa foi de hierarquia, não de estilo visual. Separar o que é decisão de diretoria do que é diagnóstico de coordenação evitou o erro mais comum: dashboard que falha por misturar nível de decisão, não por gráfico feio.

Extrator burro mais SQL inteligente vence parser esperto. Planilha viva muda todo mês. SQL versionado com raw imutável absorve qualquer mudança sem perder histórico.

Tom importa. Trocar "pior movimento" por "ponto de observação mais referência" mudou a relação da C-Level com o painel, de fonte de ansiedade para copiloto.

Governança se vende com incentivo, não com imposição. Os times aceitaram o contrato de dados porque ganharam algo visível em troca.