Um guia prático sobre métricas essenciais para Product Data Managers
A indústria de dados vende complexidade como sofisticação.
Dashboards com quarenta e sete indicadores, scorecards multinível, matrizes de maturidade com cinco dimensões e quinze subdimensões — toda essa arquitetura existe para cumprir uma função que ninguém admite: evitar a pergunta que importa. “Esse dado está sendo usado para decidir alguma coisa?”
Começar com métricas não exige framework. Não exige plataforma enterprise. Não exige governança estabelecida. Exige uma coisa que a indústria trata como herezia: honestidade sobre o que você ainda não sabe responder. A primeira métrica cabe num post-it. É uma pergunta simples: “Quantas vezes esse relatório foi aberto essa semana?”, “Alguém tomou uma decisão diferente por causa do que viu nesse dashboard?”, “Se esse pipeline parasse hoje, quem sentiria falta?”. O Product Data Manager que espera maturidade para começar a medir está confundindo ferramenta com curiosidade.
A Mentira Estrutural
Existe uma narrativa que circula em reuniões de planejamento: quando o data warehouse estiver consolidado, quando a governança estiver estabelecida, aí sim começamos a medir de verdade. Essa narrativa é confortável porque adia a responsabilidade, transforma métrica em projeto de infraestrutura com budget e stakeholders, mas sem a pergunta original.
Zhamak Dehghani (fundadora do Data Mesh) escreveu sobre data mesh não como arquitetura técnica, mas como reorganização de responsabilidade. “Data as a product” não começa com tecnologia, começa com uma pergunta que soa ingênua até você tentar responder: quem é o consumidor e o que ele precisa? A realidade é outra: dados nascem órfãos, coletados porque “pode ser útil”, armazenados porque storage é barato. O catálogo não é resposta, é um cemitério organizado.
Métricas não nascem de plataformas, nascem de ignorância confessada. O ato de medir começa no momento em que você admite que não sabe algo que precisa saber, não no momento em que compra uma ferramenta que promete saber por você.
A Pergunta que Ninguém Faz
Todo dado tem um propósito definido no backlog, pelo menos é o que dizem as user stories: “Como analista de marketing, quero acessar dados de conversão por canal para otimizar alocação de budget.” Soa perfeito, soa intencional. Na prática, o dado é extraído, transformado, carregado, documentado (às vezes), catalogado (se sobrar tempo) e esquecido. O analista de marketing acessou três vezes na primeira semana, depois parou, e ninguém perguntou por quê. Ninguém mediu o abandono. O pipeline continua rodando, custa dinheiro, e ninguém sabe para quê.
O custo não é de armazenamento, storage é barato. O custo é de atenção desviada. Cada métrica sem pergunta correspondente é ruído que mascara sinal. Cada dashboard que ninguém abre ocupa espaço mental de quem precisa tomar decisão e não sabe onde olhar. A métrica mais simples que existe é esta: quantas pessoas usaram esse dado nos últimos trinta dias? Não é sofisticada, não aparece em nenhum framework de maturidade, mas responde a pergunta que nenhum scorecard responde: isso importa?
Quando comecei a trabalhar com dados, passei meses construindo pipelines elaboradas. Dados de três sistemas diferentes, enriquecidos com fontes externas, transformados em modelos semânticos que qualquer analista poderia usar. Fiquei orgulhoso, até que perguntei, casualmente, quantas vezes o modelo tinha sido consultado: zero. Não foi um problema de qualidade ou de performance, foi um problema de pergunta. Ninguém tinha me dito o que precisava saber, e eu tinha construído a resposta para uma pergunta que ninguém fez.
A Ilusão da Qualidade Perfeita
Existe uma crença que paralisa mais do que qualquer limitação técnica: a ideia de que preciso de noventa e nove vírgula nove por cento de accuracy antes de confiar nos dados. Essa crença transforma métrica em refém. O Product Data Manager fica preso num loop de validação infinita — testa, encontra anomalia, corrige, testa de novo — enquanto o negócio toma decisões no escuro. Decisão não espera perfeição, decisão acontece agora, com o dado disponível, imperfeito, incompleto e, mesmo assim, necessário.
Freshness é contextual. Essa é a verdade que ninguém quer ouvir porque destrói a ideia de padrão universal. Um dado de vendas de ontem serve perfeitamente para planejamento trimestral, mas um dado de detecção de fraude de cinco minutos atrás já é inútil. O framework de SLIs e SLOs — popularizado por engenheiros como Martin Kleppmann — resolve isso não com perfeição, mas com acordo explícito. Não é sobre o dado ser perfeito, é sobre o dado ser bom o suficiente para a decisão que precisa ser tomada. E isso precisa estar escrito, negociado e medido.
A busca por perfeição é a forma mais elegante de procrastinação na engenharia de dados. Disfarça-se de rigor, mas rigor sem prazo de entrega é apenas medo. O dado bom o suficiente para a decisão de hoje nunca chega porque o padrão é impecável para a decisão hipotética de amanhã. E amanhã, quando chega, o padrão mudou. Existe um padrão silencioso: a equipe de dados define métricas de qualidade sem consultar quem consome os dados, estabelece thresholds tecnicamente corretos mas desconectados da realidade. O dado atende todas as métricas e ainda assim é inútil, porque a métrica certa mede adequação ao propósito, não perfeição técnica.
Um relatório de churn com noventa e cinco por cento de completude é mais valioso que um relatório impecável que chega duas semanas depois. A diferença não é técnica, é temporal. E temporalidade é uma dimensão que frameworks de qualidade raramente capturam com a devida urgência.
O Contágio do Time-to-Insight
Entre o dado disponível e a decisão tomada existe um abismo chamado tempo para entender. O data product está no catálogo, tem documentação, schema definido e lineage rastreável, mas o analista leva quarenta minutos para entender o campo, duas horas para montar a query e mais uma hora para validar se o resultado faz sentido. Time-to-insight mede o tempo de compreensão humana, não o tempo de execução da query. Quase ninguém mede.
Query count é a métrica favorita de quem quer parecer produtivo. Dez mil queries por mês soa como adoção, mas podem ser dez mil tentativas frustradas de entender o mesmo dado, ou dez mil execuções de um relatório que ninguém lê. Decision velocity é a métrica que dói: mede quanto tempo leva para uma decisão ser tomada antes e depois do data product. Uma empresa onde a alocação de budget levava três semanas e passou a levar três dias tem uma métrica que importa. O resto é ruído.
Existe algo perturbador em observar equipes celebrando adoption rate enquanto o negócio opera por instinto. O dashboard tem mil usuários ativos, as pipelines processam terabytes, e as decisões continuam sendo tomadas na sala de reunião por quem fala mais alto. A métrica de adoção sem métrica de impacto é teatro, uma performance de produtividade. É o equivalente corporativo de organizar a estante por cor — parece que algo foi feito, mas ninguém leu nada.
A Adoção que Não Aparece no Log
DAU e MAU são métricas legítimas para responder quantas pessoas interagiram com o produto, mas não respondem à pergunta que o Product Data Manager precisa fazer: quantas pessoas mudaram o curso de ação por causa do que viram? Usuário ativo não é usuário que decide. Alguém pode abrir o dashboard todos os dias por ritual e continuar tomando as mesmas decisões de sempre. Isso é hábito, não é valor.
O framework de Input-Output Efficiency Matrix coloca isso em termos brutais: esforço de engenharia versus impacto mensurável. Quando você plota seus data products nessa matriz, a imagem é desconfortável. Produtos de alto esforço e baixo impacto — os queridinhos técnicos — contrastam com dashboards simples que o diretor usa toda manhã para decidir a produção. A matriz revela que valor e complexidade muitas vezes caminham em direções opostas.
Não sei se existe resposta para por que gravitamos para a complexidade. Talvez porque o visível seja mais fácil de elogiar do que o invisível. Ninguém aplaude uma métrica que cabe numa frase, mas todos admiram uma pipeline que processa quarenta fontes em tempo real. A pergunta que ninguém faz é: qual dos dois gerou mais decisões diferentes? Há ainda o abandono silencioso: o usuário que parou de usar sem reclamar porque “encontreu outro jeito” — geralmente uma planilha local e desatualizada. O produto não falhou tecnicamente, falhou em reter relevância.
A Economia Invisível do Custo por Decisão
Todo data product tem um custo oculto de manutenção, suporte e incidentes que consomem horas de engenharia. O TCO (Total Cost of Ownership) revela o número que ninguém quer ver: um produto que custa cinquenta mil reais e gera duas decisões mensuráveis tem um custo por decisão de vinte e cinco mil reais. Não é errado, é apenas honesto. E honestidade é desconfortável.
A fórmula de ROI é ignorada em quase toda equipe de dados não por incompetência, mas porque responder exige admitir que projetos de seis meses não geraram valor mensurável. Existe uma pergunta ainda mais incômoda: quanto custa não ter essa métrica? Quanto custa decidir no escuro? Essa pergunta inverte a equação e transforma custo em risco, uma linguagem que executivos entendem. Mas a resposta pode ser “nada”, e admitir que o dado não está influenciando o decisor é um espelho que poucos querem encarar.
A Governança como Performance
Governança de dados é tratada como checklist de compliance, burocracia disfarçada de controle. Mas governança real é a diferença entre um dado que todo mundo usa e um dado que ninguém confia. O framework DATSIS define seis princípios para data products: Discoverable, Addressable, Trustworthy, Self-describing, Interoperable, Secure. Soa acadêmico até você descobrir que “Discoverable” não significa que o dado existe, mas que pode ser encontrado por quem precisa sem pedir ajuda.
O framework VAULTIS — estratégia do Departamento de Defesa dos Estados Unidos — adiciona a camada “Linked”, o princípio que mais revela. Dados conectados via lineage, não apenas tecnicamente, mas semanticamente: o que esse número representa e que decisão ele já embasou. O dado sem lineage é um órfão genealógico. Ninguém assume responsabilidade por ele e, quando o número dá errado, a pergunta “quem é responsável?” morre no silêncio da arquitetura.
O DPDS (Data Product Descriptor Specification) propõe que o descriptor seja um contrato, não uma documentação. Um documento declarativo que define o que esperar e o que sustentar. Não é burocracia, é a anatomia da confiança.
A Verdade Incômoda
Todas as métricas sofisticadas falham pelo mesmo motivo: evitam a pergunta primitiva. North Star, funis de adoção, scorecards de qualidade — tudo é secundário à pergunta que antecede o framework: o que você precisa saber que ainda não sabe? O Product Data Manager eficaz é aquele que faz a pergunta que ninguém queria ouvir. “Se desligássemos esse pipeline amanhã, alguém perceberia?”
Dehghani escreveu que data mesh é uma abordagem sociotécnica. A arquitetura é secundária à responsabilidade. Métricas são ferramentas de pergunta, perguntas cristalizadas em números. Quando você mede time-to-insight, está perguntando “quanto tempo leva para entender?”. A curiosidade não se compra, não se implementa e não se governa. Ou existe, ou não existe.
O Que Permanece Não-Dito
Não há um guia para o framework perfeito porque perfeição é estática e métrica é movimento. Alguém, agora, está apresentando quarenta e sete KPIs com confiança. Ninguém mentiu, os dados são precisos e as pipelines rodam perfeitamente. E o negócio continua operando como se nada disso existisse. A métrica mais importante é aquela que você ainda não teve coragem de perguntar, porque a resposta pode ser que nada do que você construiu importa.
E continua rodando.