Um simulador que parte do mês real, recalcula a composição de aquisição por canal na hora, e fechou entre 94% e 99% do número oficial da empresa.
A liderança de Growth e Revenue queria responder uma pergunta simples. Se colocasse mais investimento em um canal, quantos clientes isso traria, ativaria e reteria, e por qual canal.
Ninguém conseguia responder com confiança. Os números de cada canal vinham de planilhas de planejamento, não do realizado. E a atribuição contava o mesmo cliente em mais de um canal, inflando tudo.
Construí um simulador que parte do mês real, deixa a liderança mexer nas alavancas de investimento e recalcula a composição de aquisição por canal na hora. Por trás dele, montei o pipeline de dados, resolvi a lente de atribuição e validei tudo contra o número oficial da empresa.
O resultado ficou dentro de 94% a 99% do número oficial e virou a base de conversa de planejamento entre Growth, Revenue e a liderança.
A Fominha é uma foodtech. O produto é um marketplace de delivery que conecta restaurantes a clientes que pedem comida pelo app. O cliente entra no app, escolhe um restaurante, faz o primeiro pedido e recebe a entrega. Quanto mais ele pede, mais valor ele gera.
O funil de crescimento tem quatro degraus.
| Etapa | O que significa |
|---|---|
| Aquisição | Primeira busca por um restaurante no app. O sinal de que a pessoa chegou. |
| Ativação | Primeiro pedido pago no checkout. A pessoa começou a usar de verdade. |
| Entrega | Primeiro pedido entregue. Na prática, quase todo pedido pago vira entrega, cancelamento é raro. É a etapa que confirma que a operação (restaurante + entregador) funcionou. |
| ICP | Dois pedidos em até sete dias. Pedir de novo tão rápido, sem cupom de primeira compra pra puxar, é o sinal mais barato de recompra que dá pra medir cedo. |
A aquisição vem de seis frentes: mídia paga, influenciadores, indicação entre clientes (member get member), conteúdo e SEO, parcerias, e um grupo grande de clientes que chega sem canal identificado (orgânico e direto).
O time de Revenue precisava planejar quanto investir em cada canal para bater a meta de crescimento. A liderança de Growth precisava defender prioridade de investimento com números.
Três problemas travavam essa conversa.
O primeiro era de fonte. O volume por canal saía da planilha de orçamento, que só tinha dinheiro planejado, não o volume que cada time entregava de fato. Alguns canais nem apareciam na planilha.
O segundo era de atribuição. A empresa contava o mesmo cliente em mais de um canal. Se alguém clicava num anúncio pago e também usava um cupom de influenciador, ele entrava nos dois. A soma dos canais ficava maior que o número real de clientes.
O terceiro era de simulação. Não existia um lugar onde a liderança pudesse mexer numa alavanca, por exemplo subir o investimento em mídia paga, e ver o efeito na aquisição, na ativação e na retenção, canal por canal.
Sem isso, o planejamento virava achismo. E achismo não sobrevive numa reunião de meta.
Uma ferramenta web, leve, que roda no navegador e pode ser embarcada num portal interno.
Ela tem cinco telas. Um simulador, onde a liderança ajusta investimento e custo por cliente e vê o resultado recalcular. Uma composição por mês, que mostra a participação de cada canal ao longo do tempo. Uma evolução por canal, com volumes, custo por cliente e qualidade. Um glossário que explica cada métrica em linguagem simples. E uma ficha técnica, onde ficam as fórmulas, as consultas e a validação, para quem quiser auditar.
Por baixo, um pipeline de dados que consolida a atribuição de seis canais numa lente única e reconcilia com o número oficial da empresa.
Essa é a parte que deu mais trabalho e é a mais importante do case.
Antes de qualquer consulta, fechei com a liderança o que conta como aquisição, ativação, entrega e ICP. Parece óbvio, mas metade dos problemas de dado nasce de gente medindo a mesma palavra de jeito diferente. A régua de entrega, por exemplo, ficou sendo o pedido efetivamente entregue ao cliente, com cancelamento nulo e data de entrega preenchida. Sem essa definição escrita, cada dashboard mostrava um número.
Cada canal tem uma origem de dado diferente, e forçar todos na mesma fonte quebra a leitura. Ficou assim.
Mídia paga, conteúdo e SEO, e o grupo orgânico e direto saem da atribuição de first-touch, cruzando o comportamento de web e app por UID único. É a fonte que diz de onde o cliente veio na primeira vez.
Influenciadores e indicação (MGM) saem do uso de cupom. Um cliente é de influência quando a primeira entrega dele usou um cupom de influenciador. Um cliente é de MGM quando entrou como convidado por indicação.
Parcerias entra como um valor médio fixo, porque o rastreamento próprio ainda estava em maturação.
O orçamento de cada frente vem do plano oficial de Revenue. Retenção (CRM) fica de fora, porque é outra caixa.
Aqui teve uma reviravolta boa. Minha primeira versão contava tudo por coorte de aquisição, ou seja, agrupava o cliente pelo mês em que ele chegou. Faz sentido para calcular custo de aquisição, mas não batia com o dashboard oficial.
O motivo era simples quando parei para olhar. O dashboard oficial conta por período, pela data em que o evento aconteceu. Clientes que chegaram em abril e ativaram em maio apareciam em maio no oficial e em abril na minha coorte. Nos meses recentes, a diferença explodia, porque uma coorte nova ainda não tinha amadurecido.
Troquei a lente para base período, contando cada indicador pela data do evento. A distância para o oficial caiu de dois dígitos para menos de 6% no mês fechado.
O pedido da liderança era claro. A soma dos canais tinha que fechar com o total oficial do mês. Para isso, cada cliente precisa cair em um único balde.
Montei uma partição por canal onde cada cliente é atribuído a uma frente só. A soma das seis frentes passou a reproduzir o total oficial de ativações. Isso deu à liderança algo que ela não tinha: um total confiável, quebrado por canal, sem sobra e sem falta.
Não adianta construir bonito e não bater. Comparei o total do simulador com o número oficial da empresa, mês a mês. Fechou em torno de 94% a 99% no mês de referência. A pequena diferença que sobra são pedidos feitos por vias fora da atribuição de growth, como parceiros com totem ou app white-label integrado via API. Deixei isso explícito na ficha técnica, porque esconder gap é pior que mostrar.
Aqui veio o achado que mudou a conversa. A liderança suspeitava de dupla contagem e queria descontá-la do grupo orgânico. Fui atrás do dado.
O que os números mostraram: cerca de metade dos clientes de influenciadores e cerca de um terço dos de indicação também eram creditados em mídia paga. A sobreposição com o orgânico era mínima, na casa de poucos por cento.
Descontar do orgânico não resolveria nada. A dupla contagem morava entre influência, indicação e mídia paga. Levei isso de volta para a liderança com o dado na mão, e a decisão de como tratar virou uma conversa informada, não um palpite.
Usei uma arquitetura em camadas, no estilo medallion.
A camada bronze guarda o dado cru, do jeito que sai da fonte, sem tratamento. A camada silver limpa, padroniza e resolve identidade por UID. A camada gold entrega a visão de negócio, já particionada por canal e por período, pronta para consumo.
Cada tabela roda de forma idempotente e é reprocessável. Se um mês fecha errado, eu reprocesso sem quebrar histórico. A ferramenta consome só a camada gold, então o front nunca fala direto com dado sujo.
FONTES DATA WAREHOUSE (BigQuery) CONSUMO
──────────────────── ────────────────────────────── ──────────────
GA4 / AppsFlyer ─┐ bronze (dados crus) Simulador (app web)
(first-touch web/app) │ ─▶ silver (identidade por UID, ├─ simulador
│ canal resolvido) ├─ composição por mês
Cupons (influência, ─┤ ─▶ gold (partição por canal, ├─ evolução por canal
indicação / MGM) │ base período) └─ ficha técnica
│ ┌ validação contra dashboard oficial
Plano de Revenue ─┘ └ análise de dupla contagem
O modelo é direto de explicar, o que foi proposital. A liderança precisa entender o caminho.
Você define o investimento e o custo por cliente ativado de cada canal pago. A ferramenta calcula quantos clientes aquele investimento ativa. A partir da ativação, ela estima quantos chegaram (aquisição) e quantos viraram recorrentes (ICP), usando as taxas de conversão medidas no mês de referência.
Os canais orgânicos não têm investimento, então entram direto pelo volume de ativação.
Um detalhe que fez diferença. No estado inicial, sem ninguém mexer, a ferramenta reproduz o mês real com precisão, usando os valores medidos. Só quando alguém edita um campo é que ela recalcula. Isso evita um problema clássico de simulador, que é o número base já sair errado por arredondamento de taxa. O ponto de partida é sempre a realidade.
A projeção não parte da ideia ingênua de que gastar mais gera pedidos na mesma proporção. Na prática, o gasto sozinho explica pouco do volume. Ancorei a projeção em três coisas que se mostraram estáveis mês a mês: a participação de cada canal, o custo por cliente de cada canal, e as taxas de conversão do funil.
Coorte contra período. Escolhi período para bater com o oficial, mesmo sabendo que coorte é melhor para custo de aquisição puro. Deixei a coorte documentada como visão secundária.
First-touch contra cupom. Para influência e indicação, o dado dos times vem do cupom, que conta mais gente do que o first-touch. Mantive o cupom nesses dois canais, porque é o número que a operação usa e reconhece, e validei que ele bate com o gráfico oficial dos times.
Mostrar o gap em vez de esconder. O simulador não fecha 100% com o oficial. Podia ter forçado o encaixe jogando a diferença num canal qualquer. Não fiz isso. Mostrei a cobertura real e expliquei a origem da diferença. Confiança se constrói com transparência, e a liderança precisa confiar na ferramenta para decidir com ela.
Não inventar dado. Em vários pontos faltava um número. A tentação é derivar por proporção e seguir. Preferi rodar a consulta e trazer o dado medido, mesmo que custasse mais uma rodada. O único lugar onde deixei um valor derivado, marquei como derivado, na cara.
A primeira versão era tecnicamente correta e ilegível para quem decide. Cheia de termo de banco de dados, sigla e jargão.
Reescrevi tudo pensando em quem vai olhar por dois minutos numa reunião. Tirei o jargão das telas principais e joguei o detalhe técnico para uma aba separada, para quem quiser auditar. Renomeei as métricas para linguagem de negócio, com uma glosa curta explicando cada uma. Troquei "não atribuído" por "orgânico e direto", que diz a mesma coisa de um jeito que não soa como erro.
Cada canal ganhou uma linha explicando de onde vem o número, em uma frase. Cupom para influência e indicação. Valor médio fixo para parcerias. Atribuição de web e app por UID para o resto.
A régua que usei: se a liderança não entende em dez segundos, o texto está errado. Não a liderança.
A ferramenta virou a base de conversa de planejamento entre Growth, Revenue e a liderança. A pergunta de quanto investir e o que esperar passou a ter uma tela para responder, com número que bate com o oficial.
O total por canal ficou reconciliado com o número oficial, entre 94% e 99% no mês fechado, com a diferença explicada.
(números representativos, anonimizados)
O achado de dupla contagem mudou uma decisão. A liderança ia mexer no lugar errado, o orgânico. O dado mostrou que o ajuste certo era entre mídia paga, influência e indicação.
A leitura ficou acessível. Quem decide passou a usar a ferramenta sem precisar de tradução técnica.
Definição de métrica é metade do projeto. Escrever a régua antes de consultar economizou semanas de retrabalho.
A lente de tempo muda tudo. Coorte e período respondem perguntas diferentes e não são intercambiáveis. Escolher a errada faz o número não bater, e ninguém confia.
Validar contra a fonte oficial é inegociável. Um simulador bonito que não bate com o dashboard da empresa morre na primeira reunião.
Comunicação é parte da ferramenta, não enfeite. A versão tecnicamente correta que ninguém entende não gera decisão. A versão clara e auditável gera. Vi o mesmo princípio valer numa escala maior no case do Revenue Command Center, onde um painel executivo inteiro só ganhou confiança da liderança depois de auditoria e validação de ponta a ponta.
| Camada | Ferramentas |
|---|---|
| Data warehouse | BigQuery |
| Modelagem de dados | SQL, arquitetura medallion (bronze, silver, gold), tabelas idempotentes e particionadas |
| Atribuição e eventos | GA4, AppsFlyer, Google Tag Manager (server-side), identidade por UID único |
| Front-end da ferramenta | HTML, CSS, JavaScript puro, Chart.js, tipografia Poppins |
| Validação e QA | Cross-check contra dashboard oficial de BI, reconciliação mês a mês, QA de renderização automatizada |
| Versionamento | Git e GitHub |
| Produtividade | Desenvolvimento assistido por IA (prototipagem, geração e revisão de SQL, documentação) |
simulador-orcamento-multicanal/
├── README.md # visão geral, print e link da ferramenta
├── docs/
│ ├── case-study.md # este documento
│ ├── ferramenta.html # o simulador (standalone, roda no navegador)
│ └── screenshots/ # capturas das cinco telas
├── sql/
│ ├── 01_particao_periodo_por_canal.sql # lente única, base período, seis canais
│ ├── 02_influencia_cupom.sql # funil de influência por uso de cupom
│ ├── 03_mgm_convidados.sql # funil de indicação (convidados)
│ ├── 04_sobreposicao_canais.sql # análise de dupla contagem (multi-touch)
│ └── 05_validacao_oficial.sql # reconciliação contra o número oficial
├── data/
│ └── amostra_anonimizada.csv # amostra fictícia; dados reais não versionados
└── LICENSE
30 minutos, de graça. Entro nas suas plataformas e mostro se o número que vocês usam pra decidir bate com o real.
Quero meu diagnóstico grátis →