Métricas duplicadas: o problema silencioso que mata confiança em BI

Tem uma cena que já vi se repetir 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 para o 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". O head de vendas abre a ferramenta de pipeline uma hora depois, vê R$ 4,31M e copia esse número para o deck.

Três números. Três definições. Zero alinhamento. Quando alguém finalmente pergunta "espera , qual deles é o certo?" o deck já está com o board.

Essa é a fonte mais comum de frustração de executivos com times de dados que eu encontro. E é, paradoxalmente, uma das mais fáceis de resolver, uma vez que as pessoas admitam que esse é o problema.

Como uma única métrica acaba duplicada

Métricas duplicadas raramente chegam num evento dramático. Elas se acumulam devagar por meio de decisões locais perfeitamente razoáveis:

• O CRM tem o próprio cálculo de "deals fechados no mês". Alguém montou um relatório em cima disso.
• Financeiro importa pagamentos do Stripe e reconhece receita num calendário diferente. Construiu o próprio Dashboard.
• O time de growth precisava de algo mais rápido do que esperar pelo warehouse, então plugou 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, constrói um Dashboard "harmonizado" com uma quarta definição.

Cada passo foi racional. O resultado agregado é caos. E ninguém acorda responsável por isso porque ninguém acorda dono da métrica, todos são donos 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 custo invisível, bem maior, aparece ao longo dos meses:

1. Paralisia decisória. Executivos param de confiar em qualquer número que não consigam reconferir pessoalmente, o que significa que param de usar Dashboards e voltam a pedir consultas avulsas para o time de dados.
2. Burnout do time de dados. As mesmas perguntas são re-respondidas toda semana porque ninguém confia na resposta anterior. Seus analistas mais caros gastam a semana reproduzindo conciliações em vez de construir coisa nova.
3. Decadência cultural. "Deixa eu conferir os números" vira um projeto de dois dias em vez de uma consulta de trinta segundos. A velocidade de decisão cai. O time de dados vira gargalo em vez de alavanca.

Um exercício de uma semana para expor as duplicatas

Eu rodo uma versão desse exercício com a maioria dos clientes no primeiro mês. É simples, é desconfortável, e quase sempre encontra 5–10 métricas duplicadas que ninguém sabia que estavam duplicadas.

Dia 1, listar todo Dashboard

Faça uma planilha com todo Dashboard, relatório e SQL recorrente em produção. Power BI, Looker, Metabase, Tableau, a página no Notion onde alguém tira screenshot de um número toda segunda, tudo.

Dias 2–3, extrair toda definição

Para os 20 Dashboards mais visualizados, anote as métricas que cada um expõe. Para cada métrica: qual o nome em português claro, qual o SQL por baixo, qual a tabela de origem.

Dia 4, agrupar por nome

Agrupe métricas pelo nome que uma pessoa não-técnica usaria. "Receita", "usuários ativos mensais", "taxa de churn", "valor em pipeline". Você normalmente vai encontrar 2–4 definições diferentes escondidas atrás de cada nome.

Dia 5, eleger a vencedora

Para cada grupo, decida a definição canônica. Não "a certa", "a que vamos usar". Documente num doc que mora ao lado do warehouse. Renomeie cada outra versão para "X (legacy CRM)", "X (visão de vendas)", etc., ou aposente.

A solução duradoura: uma camada semântica

Limpar as duplicatas existentes é um esforço pontual. Impedir que novas apareçam é o prêmio de verdade. O mecanismo é uma camada semântica, um lugar no seu stack onde cada métrica é definida exatamente uma vez e toda ferramenta downstream consome dali.

Concretamente, isso costuma significar 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 lê da mesma definição. Novos analistas continuam podendo escrever SQL, mas escrevem em cima da camada canônica, não contra tabelas cruas.

A camada semântica não torna duplicatas impossíveis. Ela as torna óbvias. Quando alguém a contorna, o desvio aparece no code review. É a única defesa sustentável que encontrei contra esse problema no longo prazo.