Métricas duplicadas: o problema silencioso que mata confiança em BI
Três Dashboards, três números de receita diferentes, um CFO bem ansioso. Por que isso acontece, o quanto custa e um exercício de uma semana para resolver.
Tem uma cena que já vi umas doze vezes: o CFO abre o Dashboard executivo antes da reunião de board, vê receita de R$ 4,2M e pede confirmação ao líder de BI. O líder de BI abre o próprio Dashboard, vê R$ 4,05M e pensa "tá perto, deve ser fuso horário". Uma hora depois o head de vendas abre a ferramenta de pipeline, vê R$ 4,31M e copia esse número pro deck.
Três números, três definições, nenhuma combinando. Quando alguém finalmente pergunta "peraí, qual deles é o certo?", o deck já está na mão do board.
É a maior fonte de frustração de executivo com time de dados que eu vejo. E, por ironia, uma das mais fáceis de resolver, assim que todo mundo admite que o problema é esse.
Como uma única métrica acaba duplicada
Métrica duplicada quase nunca nasce de um evento dramático. Vai se acumulando devagar, a cada decisão local perfeitamente razoável:
- O CRM tem o próprio cálculo de "deals fechados no mês". Alguém montou um relatório em cima dele.
- O Financeiro importa pagamentos do Stripe e reconhece a receita num calendário diferente. E montou o próprio Dashboard.
- O time de growth precisava de algo mais rápido do que esperar pelo warehouse e ligou o Looker direto numa réplica transacional do Postgres, com SQL próprio.
- O novo líder de BI chega, vê três números e monta um Dashboard "harmonizado" com uma quarta definição.
Cada passo foi racional. A soma é o caos. E ninguém se sente responsável, porque ninguém é dono da métrica: cada um é dono do próprio Dashboard.
O que isso de fato custa
O custo visível é a reunião desconfortável em que dois gráficos se contradizem. O invisível, que é bem maior, vai aparecendo ao longo dos meses:
- Paralisia na hora de decidir. O executivo para de confiar em qualquer número que ele mesmo não consiga reconferir, ou seja, larga os Dashboards e volta a pedir consulta avulsa pro time de dados.
- Burnout do time de dados. As mesmas perguntas voltam toda semana porque ninguém confiou na resposta da vez passada. Seus analistas mais caros passam a semana refazendo conciliação em vez de construir coisa nova.
- A cultura azeda. "Deixa eu conferir os números" vira um projeto de dois dias em vez de uma consulta de trinta segundos. A decisão fica mais lenta. O time de dados vira gargalo em vez de fazer o negócio andar.
Um exercício de uma semana para expor as duplicatas
Eu rodo uma versão desse exercício com quase todo cliente no primeiro mês. É simples, desconfortável, e quase sempre acha de 5 a 10 métricas duplicadas que ninguém imaginava que estavam duplicadas.
Dia 1, listar todo Dashboard
Monte uma planilha com todo Dashboard, relatório e SQL recorrente que está em produção. Power BI, Looker, Metabase, Tableau, a página do Notion onde alguém cola o print de um número toda segunda-feira, tudo.
Dias 2–3, extrair toda definição
Nos 20 Dashboards mais acessados, anote as métricas que cada um mostra. Para cada uma: o nome em português claro, o SQL por baixo e a tabela de origem.
Dia 4, agrupar por nome
Junte as métricas pelo nome que uma pessoa não-técnica usaria. "Receita", "usuários ativos mensais", "taxa de churn", "valor em pipeline". Quase sempre você acha de 2 a 4 definições diferentes escondidas atrás de cada nome.
Dia 5, eleger a vencedora
Para cada grupo, escolha a definição canônica. Não "a certa", e sim "a que a gente vai usar". Anote num doc que mora ao lado do warehouse. Renomeie cada uma das outras versões para "X (legado do CRM)", "X (visão de vendas)" e assim por diante, ou aposente de vez.
Já fiz essa auditoria dezenas de vezes. Sai mais rápido, e dá bem menos briga interna, quando quem conduz é alguém de fora do time. Um projeto de 1 a 2 semanas costuma revelar de 5 a 10 métricas duplicadas e te entrega um roadmap de fonte única da verdade.
Rodar esse exercício comigoA solução duradoura: uma camada semântica
Limpar as duplicatas que já existem é um esforço pontual. O ganho de verdade é impedir que novas apareçam. O mecanismo é uma camada semântica: um lugar no seu stack onde cada métrica é definida uma única vez e toda ferramenta downstream lê dali.
Na prática, isso costuma virar modelos de marts em dbt expondo fact tables e tabelas de métricas canônicas, mais uma metrics layer (dbt Semantic Layer, Cube, MetricFlow ou um wrapper fino seu) que garante que toda ferramenta de BI leia da mesma definição. Analista novo continua escrevendo SQL, mas escreve em cima da camada canônica, não direto nas tabelas cruas.
A camada semântica não impede que duplicatas aconteçam. Só deixa cada uma à vista. Quando alguém a contorna, o desvio aparece no code review. É a única defesa que se sustenta no longo prazo que eu achei pra esse problema.