Um dashboard de tráfego construído sobre a planilha que já existia
- AI Product Builder
- Product Design
- UI/UX Design
- Growth com dados
Em vez de montar uma infraestrutura nova, usei a planilha que o time já mantinha como fonte, e construí em cima dela um dashboard que mostra o que pede ação primeiro. Eu desenhei e construí com IA.
Em resumo
O time de tráfego pago acompanhava gasto, cliques, checkouts e vendas em planilhas. Quem analisa precisa responder todo dia a mesma pergunta: o que está bom, o que está ruim e onde olhar primeiro. Na planilha, essa resposta existia, mas escondida em abas e fórmulas.
O Growth Dashboard UI é um app web em Google Apps Script que lê essas planilhas a cada 30 segundos, aplica as regras de cálculo que o time já usava e mostra tudo em sete telas: Geral, Funil, Campanhas, Criativos, Vendas, CRO e FCA. A escolha foi ficar na planilha: sem servidor, sem banco e sem outra ferramenta para manter.
Cada número aparece com contexto (meta, comparação com o período anterior ou estado), e a cor só entra quando diz algo: verde, laranja e vermelho para bom, no limite e ruim, sempre com ícone ou texto junto.
Meu papel
- Produto
- UX e jornada
- Growth com dados
- UI
- Construção com IA
Ferramentas
- Google Apps Script
- Google Sheets
- JavaScript
- clasp
- Claude
- Codex
- Quem usa (segundo o desenho do produto)
- Analista de dados e gestor de tráfego pago
- Prazo
- Desde out/2026, em evolução
- Tipo
- Ferramenta interna de análise de tráfego pago
- Natureza das telas
- Dados de exemplo nas imagens desta página
Resultados
0
DecisãoServidores ou bancos de dados novos
O app roda dentro do Google, sobre as planilhas que já existiam. Quem mantém o dado continua mantendo na planilha.
30 s
DesenhoIntervalo de atualização da tela
O painel consulta a planilha a cada 30 segundos, com cache de 25. Uma linha nova aparece em até cerca de 55 segundos.
45
MedidoTestes automáticos nas regras de cálculo
Rodam sem depender do Google, e cobrem fórmulas, vendas reais, reembolso e amostra mínima do funil.
O dado existia, a decisão é que demorava
As planilhas de tráfego já tinham gasto, impressões, cliques, visualizações da página e checkouts, vindos da Meta. Faltava uma leitura que dissesse onde olhar primeiro, sem abrir aba por aba.
Havia um problema mais fundo: o pixel da Meta atribuía venda errado. Contava como compra um boleto só impresso e uma venda de teste da própria equipe. Se o painel mostrasse esse número, ele decidiria em cima de uma venda que não aconteceu.
Os exemplos do pixel foram conferidos contra a exportação da plataforma de pagamento, em outubro de 2026.
Três decisões para não montar uma infraestrutura
Muitas vezes a resposta é uma estrutura mais robusta. Aqui, a pergunta foi outra: o que dá para fazer com o que já está de pé?
Três decisões saíram dela, nesta ordem: ficar na planilha, confiar na venda real e deixar a cor significar uma coisa só.
Ficar na planilha
O script do Google fica vinculado à planilha e só enxerga ela, com a menor permissão possível. Sem servidor, sem banco e sem migração: o dado novo entra onde o time já escrevia.
Venda vem do pagamento, não do pixel
Gasto, cliques e checkouts seguem da Meta. Vendas e faturamento passam a vir da plataforma de pagamento, ligadas ao anúncio pela UTM do checkout.
Cor é sinal, não enfeite
Base preto e branco. Verde, laranja e vermelho só onde há meta ou limite, e o estado nunca depende só da cor.
Cada tela responde uma pergunta
O dashboard foi desenhado para quem consulta todo dia, no computador. Em qualquer tela, a tarefa é a mesma, e todo número tem contexto: meta, variação contra o período anterior ou estado ao lado do valor.
Funil: o passo que mais perde
As etapas de impressão a venda aparecem em formato de funil, cada uma com a taxa e uma régua de referência de mercado.
A decisão por trás: A régua é referência, não meta: serve para dizer onde o funil está abaixo do esperado, e só entra no ranking passo com amostra mínima.
Campanhas: do total ao anúncio
A tela abre em cascata: campanha, conjuntos e anúncios com miniatura. Clicar na linha abre e fecha o nível.
A decisão por trás: Quem investiga um número ruim desce pelo caminho do dinheiro, sem trocar de tela nem perder o total de vista.
Criativos: ver o anúncio ao lado do número
Tabela ou cartões com a miniatura do arquivo do anúncio, filtros por estado, tipo e faixa, e ordenação padrão por checkouts.
A decisão por trás: Decidir qual criativo escalar ou pausar pede ver a peça junto com o resultado dela.
Vendas: do bruto ao que ficou
Faturamento bruto, líquido e retido, taxa de reembolso e um medidor de ROAS. Cada métrica tem um "?" que explica o cálculo.
A decisão por trás: Reembolso é pós-venda e não pode inflar ROAS nem lucro. Por isso as métricas de sucesso usam só o que foi retido.
CRO: onde o funil vaza e o que testar
Furos por etapa, ritmo dos últimos dias, backlog de testes ordenado por impacto e um simulador de funil com cinco alavancas.
A decisão por trás: Com poucas vendas, o "melhor anúncio" pode ser sorte. A tela marca "amostra pequena" em vez de apontar uma causa que o dado não sustenta.
O que assumi em troca da simplicidade
Ficar na planilha tem custo, e ele está registrado no projeto em vez de escondido.
Ainda não há medida registrada do efeito do painel no tempo de decisão. Os resultados desta página contam o que foi construído, não um ganho.
Quase em tempo real, não instantâneo.
O Apps Script não empurra dado para o navegador. O painel pergunta de novo a cada 30 segundos, e o cache existe para não estourar a cota do Google.
A base de vendas ainda é atualizada à mão.
O processo é exportar da plataforma de pagamento, tirar os dados pessoais e colar na base. É o ponto mais frágil e o próximo candidato a automação.
O painel depende da planilha e de quem o publicou.
Se a planilha muda de formato, o painel avisa. Se a pessoa que publicou perder o acesso, o app para: um risco aceito e documentado.
O que eu faço agora
Validar o fator de taxa sobre o gasto contra a cobrança real, automatizar a carga das vendas e medir quanto o painel encurta o caminho até a decisão.