5 métricas de saúde dos seus dados que todo time deveria acompanhar todo mês

Arthur Frota

A maioria dos times de negócio descobre que tem problema de qualidade quando alguém da liderança questiona um número em uma reunião. Esse é o pior momento para descobrir: a decisão já estava sendo formada, e o número que deveria dar clareza passa a gerar mais dúvida 

Monitorar confiabilidade de dados não é projeto. É rotina de operação, como monitorar uptime de servidor ou taxa de erro de API. 

As cinco métricas abaixo cobrem os pontos de falha mais comuns em bases operacionais. Para cada uma: o que mede, como calcular, qual benchmark separa saudável de problemático e o que fazer quando o número está abaixo do mínimo.

1. Taxa de completude

O que mede: a proporção de campos obrigatórios preenchidos sobre o total de registros. Completude baixa significa que parte da base não tem as informações mínimas para ser usada em análise, e qualquer modelo de IA vai ou ignorar esses registros, ou imputar valores estimados sem avisar.

Como calcular:

Taxa de completude (%) = (registros sem valor nulo no campo / total de registros) × 100

Calcule por campo, não por tabela. Uma tabela pode ter 98% de completude geral e ainda ter um campo crítico com 60% de preenchimento. O número agregado esconde o problema.

Benchmark: campos de identificação como CPF, CNPJ, e-mail e código de produto devem atingir 99% ou mais. Campos críticos que alimentam análises e modelos de IA precisam estar acima de 95%. Campos secundários aceitam entre 80% e 90%.

O que fazer abaixo do mínimo: identifique se o campo ficou vazio por falha de entrada (formulário que não exige preenchimento), por migração mal feita (campo sem correspondência no sistema de origem) ou por processo que parou de atualizar. A causa define a solução: validação obrigatória na entrada, remapeamento de migração ou correção de pipeline. Nunca preencha campo vazio com valor padrão sem saber a causa.

2. Índice de duplicidade

O que mede: a proporção de registros duplicados nos campos de identificação única. Duplicidade distorce qualquer análise de volume, frequência e comportamento. Se a base tem 15% de clientes duplicados, toda análise de churn, recência e segmentação está errada na mesma proporção.

Como calcular:

Índice de duplicidade (%) = ((total de registros - registros únicos no campo-chave) / total de registros) × 100

Aplique nos campos que deveriam ser únicos: CPF, CNPJ, e-mail, código de produto, ID de pedido. Para cada campo-chave, agrupe por valor e conte grupos com mais de uma ocorrência.

Benchmark: o padrão para bases de clientes e contas é índice de duplicidade abaixo de 1% a 2%. Bases migradas de sistemas legados sem deduplicação chegam frequentemente a 10% a 20%. Acima de 2%, qualquer análise de volume e comportamento está comprometida o suficiente para gerar decisões erradas.

O que fazer abaixo do mínimo: diferencie duplicata exata (mesmo CPF, mesma grafia) de duplicata fuzzy (mesmo cliente, nome com variação). Duplicatas exatas são resolvíveis com agrupamento simples e regra de mesclagem. Duplicatas fuzzy exigem algoritmo de similaridade e revisão manual dos casos limítrofes. Implante validação de unicidade no ponto de entrada do dado para evitar novas duplicatas enquanto limpa as existentes.

3. Consistência entre sistemas

O que mede: a taxa de concordância para o mesmo campo crítico em sistemas diferentes. Se receita do mês aparece com valores diferentes no ERP e no CRM, há inconsistência. Se "cliente ativo" tem critério diferente em vendas e no financeiro, qualquer análise que cruze as duas fontes vai gerar resultado conflitante.

Como calcular:

Consistência (%) = (registros com valor idêntico em todos os sistemas onde o campo existe / total de registros comparados) × 100

Mapeie primeiro quais campos existem em mais de um sistema. Priorize campos que aparecem em análises cruzadas: receita, volume de pedidos, status de cliente, estoque disponível. Compare valores para o mesmo identificador (mesmo CPF, mesmo código de produto) entre sistemas.

Benchmark: para campos que alimentam análises e modelos de IA, o padrão é consistência acima de 95% entre sistemas. Para métricas financeiras e de desempenho operacional, 99%. Inconsistência abaixo desse limite precisa ser rastreada até a causa antes de qualquer uso analítico.

O que fazer abaixo do mínimo: antes de tentar resolver tecnicamente, resolva conceitualmente. Defina qual sistema é a fonte de verdade para cada campo crítico. Documente a definição que vale: o que conta como "receita líquida", qual critério define "cliente ativo", qual data delimita o período. Com a fonte de verdade definida, o problema técnico de sincronização tem endereço certo para ser resolvido.

4. Latência de atualização

O que mede: o tempo entre um evento acontecer no mundo real e esse evento estar disponível na base de dados para análise. Uma venda que acontece às 14h e aparece na base às 18h tem quatro horas de latência. Um cadastro de cliente atualizado ontem que ainda não chegou ao data warehouse tem latência de mais de um dia.

Como calcular:

Latência média (horas) = média de (timestamp de disponibilidade na base - timestamp do evento na fonte)

Para acompanhamento mensal, calcule o percentual de registros dentro da janela de atualização esperada para cada pipeline:

Aderência ao SLA de atualização (%) = (registros atualizados dentro da janela esperada / total de registros) × 100

Benchmark: para tabelas de primeiro nível que alimentam decisões operacionais e modelos em produção, o padrão é aderência ao SLA acima de 99% dentro de uma janela de 24 horas. Para dados cadastrais usados em segmentação mensal, a janela pode ser mais longa, mas precisa estar definida e monitorada. O ponto crítico: um sistema que responde em milissegundos mas retorna dado de horas atrás não é rápido, é rápido em estar errado.

O que fazer abaixo do mínimo: identifique onde a latência está sendo introduzida no pipeline. Cada etapa de transformação, cada carga em batch, cada sincronização agendada adiciona latência. Pipelines com muitas etapas acumulam atraso em cada uma. Se a causa é processamento batch onde streaming seria adequado, avalie a mudança. Se a causa é pipeline frágil que falha silenciosamente e fica sem executar, implante alertas de ausência de execução antes de alertas de erro.

5. Taxa de erro em campo crítico

O que mede: a proporção de registros que violam as regras de validade definidas para campos críticos. Data de entrega anterior à data do pedido. Valor de receita negativo onde não deveria ser. CEP fora do padrão. Código de produto com caracteres não permitidos. Cada um é uma entrada inválida que vai distorcer qualquer análise que use aquele campo.

Como calcular:

Taxa de erro (%) = (registros que violam pelo menos uma regra de validade do campo / total de registros) × 100

Defina as regras de validade antes de calcular: intervalo numérico aceitável, formato obrigatório, lista de valores permitidos, relações lógicas entre campos (data de entrega posterior à data de pedido, margem bruta entre -100% e 100%). Sem regra definida, não há como calcular o erro.

Benchmark: para campos críticos que alimentam análises de negócio e modelos de IA, o padrão é taxa de erro abaixo de 2%. Para dados financeiros e transacionais, abaixo de 1%. Uma taxa de 2% que parece pequena em relatório estático se propaga como viés sistemático quando um modelo processa milhões de registros com aquele campo.

O que fazer abaixo do mínimo: aplique a validação no ponto de entrada do dado, não só na auditoria posterior. Regra aplicada apenas depois que o dado já está na base corrige o histórico mas não impede novos problemas. Para os registros inválidos existentes: corrija o que tem fonte de verdade disponível para cruzamento, marque como incerto o que não tem, e nunca substitua por valor padrão sem documentar a decisão.

Como usar essas métricas no mês a mês

Cinco métricas são gerenciáveis. Vinte não são. O erro mais comum é instrumentar tudo de uma vez e depois não agir porque não há dono claro para cada alerta.

A sequência que funciona: comece por completude e índice de duplicidade, porque quebram análises com mais frequência e são as mais simples de medir. Adicione latência de atualização assim que os primeiros dois estiverem estáveis. Inclua consistência entre sistemas e taxa de erro em campo crítico quando o time tiver capacidade de agir sobre os alertas gerados.

Para cada métrica, defina antes de monitorar: qual tabela, qual campo, qual janela de tempo, qual threshold dispara ação e quem é o responsável por corrigir quando o número fica abaixo do mínimo. Equipes que monitoram qualidade de dados como disciplina de produto, com donos definidos e thresholds explícitos, detectam problemas em média em 12 minutos. Equipes sem monitoramento automatizado levam em média 47 minutos, e a maior parte do dano à confiança nos dados acontece nessa janela de tempo em que ninguém sabe que há problema.

O objetivo não é ter todas as métricas verdes. É saber, em qualquer momento, qual está amarela, por quê, e quem está resolvendo.

Perguntas frequentes

Com que frequência devo calcular essas métricas? Depende da métrica e da criticidade da base. Latência de atualização e taxa de erro em campo crítico devem ser monitoradas continuamente em tabelas de primeiro nível. Completude, duplicidade e consistência entre sistemas têm variação mais lenta e se beneficiam de verificação diária ou semanal, com revisão de tendência mensal. O que importa é a tendência ao longo do tempo: uma métrica estável em 93% é menos preocupante do que uma que estava em 98% e caiu para 93% no último mês.

Preciso de ferramenta específica para calcular essas métricas? Não para começar. Completude, duplicidade e taxa de erro em campo crítico são calculáveis com SQL básico em qualquer banco de dados. Consistência entre sistemas exige acesso às duas bases para comparação, mas o cálculo continua sendo SQL. Latência de atualização exige que a base registre timestamps de entrada e de evento de origem. A partir daí, o próximo passo é automatizar essas verificações para que rodem sozinhas em intervalos definidos, e configurar um aviso automático para o time sempre que algum número ficar abaixo do mínimo aceitável. Em vez de alguém precisar lembrar de checar, o sistema avisa quando há problema. 

Como definir o threshold certo para cada base? O threshold não é universal: depende do caso de uso. Uma análise de tendência mensal tolera latência de horas. Um modelo de recomendação em produção pode precisar de atualização a cada 15 minutos. Comece pelos benchmarks gerais descritos neste post e ajuste de acordo com o risco da decisão que cada base suporta. A pergunta prática: se esse dado estiver nesse estado por 24 horas sem que ninguém saiba, qual é o pior que pode acontecer?

O que fazer quando várias métricas estão ruins ao mesmo tempo? Priorize pela consequência para o negócio, não pela facilidade de correção. Completude e duplicidade em bases de clientes impactam diretamente análises de receita e comportamento. Inconsistência entre sistemas impacta diretamente confiança da liderança nos números. Comece pelo que está causando mais dano visível, documente o estado de cada métrica antes de corrigir e acompanhe a evolução para não criar o problema em outro campo enquanto corrige o primeiro.

Fontes de referência