Totais do mesmo período lado a lado, por canal.
| Canal | Investimento Soma do investimento em anúncios. |
Participação no investimento Percentual do investimento total alocado a este canal. |
Cliques Cliques reportados pela plataforma. Inclui cliques fraudulentos. |
Impressões Quantas vezes os anúncios foram exibidos. |
CTR Taxa de cliques: cliques ÷ impressões. |
CPC Custo por clique: investimento ÷ cliques. |
Engajamentos da plataforma* Reportado pela plataforma: Google = "Conversões" fracionárias (modeladas por atribuição); Meta = "Conversas de mensagens iniciadas". Nenhum dos dois equivale a um lead no CRM. |
Leads no CRM Leads captados no CRM. |
CPL Custo por lead: investimento ÷ leads no CRM. |
Taxa de conversão (leads/clique) Leads no CRM ÷ cliques. |
|---|
CPL aqui é sempre investimento ÷ leads reais no CRM. Nunca as "conversões" do Google Ads ou as "conversas de mensagens iniciadas" da Meta. Essas métricas de plataforma superestimam bastante os leads reais; usá-las subestimaria o CPL verdadeiro, de um jeito que poderia distorcer as decisões de orçamento de um gestor de tráfego.
Distribuição geográfica do investimento.
Como este dashboard foi construído: fonte dos dados e decisões de design.
O briefing deste exercício foi um projeto customizado, sem escopo, objetivos ou KPIs específicos definidos com antecedência.
Os dados de origem foram entregues como um link vivo para uma Google Sheet, não como um arquivo estático. O dashboard lê a planilha compartilhada diretamente a cada carregamento da página, nas quatro abas de origem (base_gads, base_meta-ads-geral, base_meta-ads-regiao, base_crm), sem arquivo exportado nem etapa manual de reexportação entre as duas partes.
A decisão foi construir uma solução customizada, conectada em tempo real à planilha, relativamente completa e cobrindo as métricas mais usadas, com foco em facilitar filtragem, navegação e interação. Essa foi a escolha mais adequada para este caso, em vez de partir direto para uma ferramenta de BI genérica. A construção contou com apoio de IA para ganhar agilidade.
A partir do escopo inicial, o projeto passou por rodadas sucessivas de refinamento, das quais resultaram:
O layout inteiro cabe em uma única tela, em todas as abas, por decisão deliberada. Foi pensado para funcionar como algo que um gestor de tráfego consulta operacionalmente, num relance entre uma decisão e outra, não como um relatório para rolar de cima a baixo.
A interface passou por várias rodadas de ajuste com base em feedback direto durante a construção: filtros de canal e período como controles visíveis e clicáveis em vez de escondidos atrás de um dropdown, e uma identidade visual alinhada à marca real da GoTraktor em vez de um template genérico.
O layout se adapta a diferentes tamanhos de tela e de janela em desktop e laptop. Breakpoints por altura e por largura ajustam espaçamento, tamanho dos gráficos e disposição dos elementos, como as grades de duas colunas do funil e da visão regional, que passam a uma coluna em janelas mais estreitas. A barra de abas rola horizontalmente quando necessário em telas de largura de tablet, e qualquer painel que não caiba por completo passa a rolar internamente. O dashboard não é otimizado para celular: não há breakpoint abaixo de 768px.
Alguns pontos deste dashboard envolvem decisões tomadas além do que os dados brutos informavam: