Início/ Cases/ Simulador de Orçamento Multicanal
Case study · Growth & Simulação

Quanto eu ativo se investir mais em cada canal? Agora tem uma tela que responde.

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.

Foodtech · marketplace de delivery Ferramenta interativa BigQuery · Chart.js
+18%
Aviso de confidencialidade. "Fominha" é uma empresa fictícia usada para descrever este projeto. O segmento é real e comum. Os números são ilustrativos e servem para explicar o método, não representam a operação real de nenhuma companhia. O que está aqui é a estrutura, a metodologia e o raciocínio, não dado proprietário de negócio.

Resumo em 30 segundos

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.

O contexto

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.

EtapaO que significa
AquisiçãoPrimeira busca por um restaurante no app. O sinal de que a pessoa chegou.
AtivaçãoPrimeiro pedido pago no checkout. A pessoa começou a usar de verdade.
EntregaPrimeiro pedido entregue. Na prática, quase todo pedido pago vira entrega, cancelamento é raro. É a etapa que confirma que a operação (restaurante + entregador) funcionou.
ICPDois 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).

A dor real da liderança

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.

O que eu construí

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.

Como cheguei nos números

Essa é a parte que deu mais trabalho e é a mais importante do case.

Passo 1: definir o funil e a régua de cada métrica

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.

Passo 2: montar as bases certas para cada canal

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.

Passo 3: escolher uma lente de tempo que bata com o oficial

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.

Passo 4: unificar seis canais numa lente única que soma o total real

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.

Passo 5: validar contra o número oficial, mês a mês

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.

Passo 6: medir a dupla contagem entre canais

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.

Arquitetura de dados

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 simulador por dentro

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.

Decisões difíceis (e por que tomei cada uma)

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.

Redesenho da comunicação para a liderança

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.

Resultado e impacto

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.

94%–99%
de cobertura do simulador frente ao número oficial da empresa, no mês fechado
6 canais
consolidados numa lente única, sem sobra e sem falta
~50%
dos clientes de influenciadores também creditados em mídia paga
~33%
dos clientes de indicação (MGM) também creditados em mídia paga

(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.

Aprendizados

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.

Stack de ferramentas

CamadaFerramentas
Data warehouseBigQuery
Modelagem de dadosSQL, arquitetura medallion (bronze, silver, gold), tabelas idempotentes e particionadas
Atribuição e eventosGA4, AppsFlyer, Google Tag Manager (server-side), identidade por UID único
Front-end da ferramentaHTML, CSS, JavaScript puro, Chart.js, tipografia Poppins
Validação e QACross-check contra dashboard oficial de BI, reconciliação mês a mês, QA de renderização automatizada
VersionamentoGit e GitHub
ProdutividadeDesenvolvimento assistido por IA (prototipagem, geração e revisão de SQL, documentação)

Estrutura do repositório

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

Sua liderança também discute orçamento por canal no achismo?

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 →