Blog

O gráfico é a parte fácil. O difícil é concordar sobre “o que estamos medindo” e “o que vamos fazer quando o número mudar”.

Se você já viveu isso, vai reconhecer o cenário: alguém pede “um dashboard” e, em poucos dias, o time está discutindo cores, tipos de gráfico e filtros… sem ter alinhado a coisa mais importante: qual decisão esse painel precisa destravar.

O resultado costuma ser um dashboard cheio de números, mas sem rotina de uso — o famoso “dashboard que ninguém usa”.

Neste artigo, eu vou te mostrar um passo a passo simples (e bem prático) para definir métricas úteis antes de pedir gráficos. O conteúdo serve tanto para Looker quanto para Metabase (e, na prática, funciona para qualquer ferramenta de BI).

O que você vai ver aqui

• Por que dashboards “morrem” (mesmo com dados corretos)
• Métricas de negócio vs métricas de vaidade (com exemplos)
• Um método simples para sair do “achismo”: Objetivo → Perguntas → Métricas
• Checklist para definir uma métrica de forma inequívoca
• Como organizar a primeira versão do dashboard (sem exagero)
• Periodicidade, donos e rituais: quem usa, quando usa e para quê
• Dicas práticas para implementar isso no Looker e no Metabase

1) O erro nº 1: pedir gráfico antes de definir a pergunta

Um dashboard não deveria começar com “quero um gráfico de X”. Ele deveria começar com perguntas do tipo:

• “Estamos melhorando ou piorando?”
• “Onde está o gargalo?”
• “Qual canal está trazendo clientes com mais qualidade?”
• “O que eu devo priorizar esta semana?”

Se você não consegue listar as perguntas, qualquer painel vira um mural de números.

Uma forma de evitar isso é obrigar todo pedido de dashboard a responder 4 coisas, em uma frase:

1. Para quem é esse painel? (diretoria, operação, comercial, suporte…)
2. Qual decisão ele precisa destravar? (aprovar orçamento, priorizar backlog, ajustar campanha…)
3. Com que frequência alguém vai olhar isso? (diário, semanal, mensal)
4. Qual ação esperamos tomar com base no dado?

Se o pedido não responde isso, o mais provável é que o painel vire um “PDF bonito” e pare de ser usado.

2) KPI não é qualquer métrica (e isso muda tudo)

“Métrica” é qualquer medida. “KPI” é a métrica que comprova progresso em direção a um objetivo.

Exemplo simples:

• Métrica: “visitas no site”.
• KPI: “taxa de conversão de cadastro” (se o objetivo é aumentar base de usuários).

A diferença parece pequena, mas ela evita que você se perca em números que não mudam nada.

3) Métricas de negócio vs métricas de vaidade

Métricas de vaidade são aquelas que “soam bem”, mas não ajudam a decidir o que fazer amanhã.

Exemplos comuns em apps e plataformas:

• “Downloads totais” (sem ligar isso a ativação/retorno)
• “Pageviews”
• “Quantidade de seguidores”
• “Número total de cadastros” (sem olhar qualidade e retenção)

Isso não quer dizer que são inúteis para sempre. Significa que, sozinhas, elas não orientam ação.

Uma regra prática: se a métrica cresce e mesmo assim o negócio não melhora (receita, retenção, eficiência, satisfação), ela é um alerta de vaidade.

Tabela: exemplos rápidos (bom para alinhar no kickoff)

Se o objetivo é…	Métrica de vaidade (risco)	Métrica mais acionável (melhor)
Crescer base	Cadastros totais	Taxa de ativação (cadastros que completam 1ª ação de valor)
Melhorar vendas	Visitas na home	Conversão por etapa (checkout, pagamento aprovado)
Reduzir churn	Usuários cadastrados	Retenção por coorte (D7/D30)
Melhorar suporte	Tickets abertos	Tempo de 1ª resposta + resolução e motivos recorrentes
Melhorar marketing	Impressões	CAC por canal + LTV estimado (quando aplicável)

4) Um método simples para definir métricas: Objetivo → Perguntas → Métricas

Quando a discussão está confusa (“qual KPI é melhor?”), use um método bem direto:

1. Defina o objetivo.
2. Escreva as perguntas que, se respondidas, mostram se o objetivo está sendo atingido.
3. Só então escolha as métricas que respondem cada pergunta.

Isso evita “métrica sem dono” e “métrica sem propósito”.

Exemplo prático (app com compra/assinatura)

Objetivo: aumentar receita recorrente sem aumentar o volume de suporte.

Perguntas:

• Onde o usuário abandona o fluxo de compra?
• Quantos clientes entram em reembolso/cancelamento e por quê?
• Quais planos geram mais chamados?

Métricas:

• Conversão por etapa do funil (produto → checkout → pagamento aprovado)
• Taxa de cancelamento (por coorte e por motivo)
• Tickets por 100 clientes ativos (e top motivos)

Perceba: não tem “gráfico bonito” aqui. Tem decisão.

5) Checklist para definir uma métrica sem ambiguidade

A maior causa de briga em dashboard é simples: duas pessoas “medem a mesma coisa” de maneiras diferentes.

Para evitar isso, defina cada KPI usando um checklist. Você pode copiar e colar este modelo:

Modelo de definição (use como “ficha de métrica”)

Campo	Preencha assim
Nome	Curto e sem abreviações confusas (ex.: “Taxa de ativação D1”)
Objetivo relacionado	Qual objetivo de negócio ela suporta
Definição em 1 frase	O que ela mede, sem jargão
Fórmula	Numerador/denominador, filtros e exclusões
Fonte de dados	Eventos/tabelas (ex.: purchase_success, users)
Granularidade	Por dia, semana, mês? Por usuário, pedido, sessão?
Dimensões	Por canal, plataforma, plano, região, versão do app…
Janela e fuso	Ex.: “D7”, “mensal”; fuso horário (importa muito)
Atualização	Tempo real, a cada 1h, 1x/dia
Dono	Quem responde pela métrica (produto, financeiro, ops…)
Ação esperada	O que fazemos se subir/baixar? Qual playbook?
Observações	Ex.: atrasos, dados incompletos, limitações

Se uma métrica não tem “ação esperada”, ela tende a virar um enfeite.

6) Como montar o primeiro dashboard sem exagerar

Uma boa primeira versão geralmente cabe em uma tela.

Sugestão de estrutura:

1. Linha 1 (KPIs principais): 3 a 7 números com tendência e comparação (ex.: vs semana anterior).
2. Linha 2 (drivers): o que explica o KPI (ex.: conversão por etapa, canais, planos).
3. Linha 3 (diagnóstico): listas e detalhes (ex.: top erros, top motivos, cohort).

Se você começa com 20 gráficos, o usuário não sabe por onde olhar — e não volta.

Dica prática: sempre mostre contexto

Evite números “soltos”. Prefira:

• tendência (últimos 7/30/90 dias),
• comparação (semana anterior, mesmo período do mês anterior),
• e um “intervalo normal” (quando existir).

Assim, o painel ajuda a responder “isso é bom ou ruim?”.

7) Periodicidade e quem consome: sem isso, ninguém usa

Dashboards viram hábito quando entram em rituais.

Exemplos que funcionam bem:

• Diário (operação): erros, fila, SLAs, incidentes, conversão do dia.
• Semanal (produto/negócio): crescimento, conversão, retenção, receita.
• Mensal (diretoria): KPIs principais, tendências, metas, grandes causas.

E, importante: defina um dono do painel. Se ninguém é dono, ninguém mantém.

8) Implementando no Looker: onde “morar” a verdade da métrica

No Looker, a disciplina central é: defina dimensões e medidas no modelo, e não em cada dashboard.

Isso ajuda porque:

• padroniza cálculo (evita “5 receitas diferentes”),
• facilita governança,
• e dá mais confiança para as áreas consumirem o mesmo número.

Na prática, isso significa modelar bem (LookML), revisar definições e versionar mudanças.

9) Implementando no Metabase: modelos, métricas e organização

No Metabase, vale adotar duas práticas para não virar “cada um faz do seu jeito”:

1. Models: crie modelos como “tabelas prontas para pergunta” (camadas mais simples para o time explorar).
2. Metrics: salve cálculos oficiais (ex.: receita, pedidos, taxa de conversão) para serem reutilizados.

E organize tudo em Collections (pastas) por área/tema, com permissões claras (quem pode editar vs quem só vê).

10) Como evitar “dashboard que ninguém usa” (na prática)

Use este mini-checklist antes de publicar um painel:

• Existe um dono do dashboard?
• O painel responde 3 a 5 perguntas claras?
• Todo KPI tem definição e fórmula documentadas?
• Existe uma rotina (reunião/ritual) onde ele será usado?
• O painel mostra tendência e comparação (não só o número do dia)?
• O dashboard tem no máximo 1 objetivo por página?

Se a resposta for “não” para metade, reduza o escopo e publique menor.

Fechando

Dashboards dão certo quando você trata métricas como produto:

• com definição,
• dono,
• rotina,
• e iteração.

Se você fizer isso, o gráfico deixa de ser decoração e vira ferramenta de decisão.