A qualidade de um indicador depende de decisões tomadas antes de desenhar o gráfico: qual evento será contado, qual é a unidade de cada registro, quais situações ficam de fora e até quando os dados estão completos. Um dashboard confiável precisa tornar essas decisões verificáveis. Para isso, o time deve definir o significado da métrica, conferir os registros que a alimentam e informar ao leitor quando uma condição necessária não foi atendida.
Esse trabalho envolve pessoas de negócio, engenharia e análise. Um campo preenchido pode conter uma classificação errada; uma soma correta pode reunir valores de moedas diferentes; uma atualização recente pode carregar apenas parte do período. A aparência regular do painel não permite distinguir esses problemas. É preciso acompanhar a informação desde sua origem até a decisão que ela sustenta.
Considere, ao longo do artigo, uma operação de vendas fictícia. A liderança quer acompanhar pedidos pagos, valores recebidos e devoluções. Os números apresentados são didáticos, não resultados de uma empresa. O objetivo é mostrar como definir controles e interpretar divergências, sem depender de uma ferramenta específica de BI ou de uma arquitetura particular de processamento.
Escreva o significado antes de escolher a visualização
Comece pela decisão: o que alguém fará depois de consultar o indicador? Dimensionar atendimento, acompanhar recebimentos e avaliar uma campanha exigem recortes diferentes. Se o pedido for apenas “mostrar vendas”, devolva uma definição concreta para discussão. No caso fictício, “pedidos com pagamento confirmado no dia” responde a uma pergunta operacional; “valor de pagamentos confirmados, descontadas devoluções registradas” responde a outra. Nenhum desses nomes deve ser automaticamente apresentado como receita contábil.
A definição precisa especificar evento, unidade, período e tratamento das exceções. Para contar pedidos pagos, decida se o evento relevante é a primeira confirmação de pagamento ou cada parcela recebida. Para somar valores, registre moeda, descontos, taxas e devoluções. Quando existir mais de uma interpretação legítima, mantenha métricas distintas, com nomes que permitam ao leitor reconhecer a diferença.
Uma ficha curta ajuda a transformar a conversa em critério executável. Ela deve permitir que uma pessoa reconstrua um exemplo sem entrevistar o autor do relatório. O preenchimento também revela lacunas: se ninguém sabe dizer o que ocorre com um pagamento confirmado perto da meia-noite, falta uma regra temporal antes de faltar um gráfico.
| Campo da definição | Exemplo didático | Dúvida que precisa ser resolvida |
|---|---|---|
| Evento | Primeira confirmação do pagamento | Uma confirmação repetida cria outro evento? |
| Unidade | Pedido identificado na organização | O identificador é único entre lojas? |
| Período | Dia do evento em um fuso definido | Como tratar registros recebidos com atraso? |
| Valor | Montante confirmado em reais | Taxas e devoluções estão incluídas? |
| Exclusões | Pedidos de teste identificados | Quem mantém a classificação de teste? |
| Responsável pela definição | Área que aprova o significado | Quem decide uma mudança de regra? |
| Responsável pelo controle | Equipe que acompanha e encaminha a falha | Quem investiga a origem e verifica a correção? |
Escolha uma amostra pequena de registros e calcule o resultado esperado com as áreas interessadas. Inclua um pedido normal, um cancelado, um parcelado e um devolvido. Se as pessoas discordarem, registre a diferença como decisão pendente. Resolver o desacordo dentro de uma consulta SQL, sem explicitar a escolha, apenas transfere uma decisão de negócio para quem implementou o relatório.
O Government Data Quality Framework trata qualidade como adequação ao uso e recomenda direcionar melhorias para os dados que mais importam. Isso sustenta a escolha de começar pela finalidade do indicador. A ficha acima é uma proposta editorial de aplicação desse princípio; não é um formulário obrigatório definido pela fonte.
Fixe a unidade dos registros e confira as relações
A granularidade indica o que uma linha representa. Uma tabela pode registrar pedidos; outra, itens; outra, tentativas de pagamento. Todas podem estar corretas e ainda assim produzir um resultado errado quando combinadas. Antes de juntar conjuntos, descreva as cardinalidades esperadas: um pedido tem vários itens, mas o indicador de pedidos pagos deve contá-lo uma única vez.
Imagine um pedido de R$ 300 com três itens. Ao juntar o total do pedido com suas três linhas de item e somar a coluna de total, uma consulta ingênua obtém R$ 900. A multiplicação vem da relação entre tabelas. Aplicar uma remoção indiscriminada de duplicados pode ocultar o sintoma e descartar repetições legítimas. A correção começa pela unidade que a medida pretende representar.
Escolha o nível de agregação antes da junção ou utilize uma regra que preserve a cardinalidade adequada ao caso. Confira a quantidade de registros e os totais antes e depois de cada transformação relevante. Se uma junção aumentar o número de pedidos distintos, deve existir uma explicação compatível com o desenho. Confira também quantas linhas cada pedido gera: a contagem de pedidos distintos pode permanecer igual enquanto o total financeiro é multiplicado. Uma relação declarada como “um para um” também merece teste: a documentação não impede que a origem passe a enviar duas versões do mesmo registro.
Identificadores exigem escopo explícito. O pedido 123 da loja A e o pedido 123 da loja B podem ser objetos diferentes. Um controle de unicidade baseado apenas no número curto produziria uma colisão artificial. Da mesma forma, o identificador do evento pode ser adequado para deduplicar uma entrega, enquanto o identificador do pedido serve à contagem do negócio. Confundir essas duas funções altera o resultado.
Quando uma dimensão contém histórico, como a região comercial de um cliente, defina qual versão vale para o indicador. A região atual e a região na data da venda respondem a perguntas diferentes. Usar a primeira reclassifica o passado sempre que o cadastro muda. Usar a segunda exige conseguir localizar a versão correspondente ao evento. A decisão deve aparecer na definição e em exemplos de aceite.
Transforme dimensões de qualidade em regras úteis
Um catálogo de testes ajuda quando cada regra representa uma consequência conhecida. “Não nulo”, “único” e “valor permitido” são verificações claras, mas insuficientes para provar que um indicador descreve a realidade. Uma data no formato correto pode estar no mês errado. Um cliente existente pode ter sido associado ao pedido de outra pessoa. A validade estrutural e a correspondência com o fato precisam de evidências diferentes.
Escolha os controles por campo, população e finalidade. No caso fictício, a ausência de identificador de pedido impede uma contagem confiável. A ausência de canal de aquisição limita uma análise por canal, mas não invalida automaticamente o total de pagamentos. Essa distinção evita tanto bloquear tudo por um detalhe secundário quanto liberar um número cuja base essencial está incompleta.
Para cada regra, registre condição esperada, escopo, forma de detectar violação, tratamento e responsável. Um limiar percentual precisa indicar seu denominador. “Completude de 96%” é ambíguo sem saber se a base contém todos os pedidos, somente pagos ou apenas os recebidos naquela execução. O indicador de qualidade também precisa ter significado estável.
| Controle | Pergunta verificável | Limite da evidência |
|---|---|---|
| Unicidade | Existe mais de um registro para a chave definida? | Não prova que a chave representa o evento correto. |
| Completude | Os campos necessários estão presentes na população esperada? | Pode ignorar registros que nunca chegaram. |
| Validade | Valores respeitam formato, domínio e intervalo acordados? | Um valor permitido ainda pode estar incorreto. |
| Integridade | As referências encontram os objetos esperados? | A existência da referência não comprova a associação. |
| Reconciliação | Contagens e valores fecham com uma referência independente? | Duas saídas do mesmo erro podem concordar. |
No exemplo, 30 de 800 pedidos pagos não têm canal identificado. A completude desse campo é de 770 divididos por 800, ou 96,25%. O painel deve mostrar a parcela desconhecida e o limite da análise por canal. Não distribua os 30 registros proporcionalmente entre canais sem uma hipótese explícita: isso produziria uma classificação estimada, que precisaria ser apresentada e avaliada como tal.
Diferencie dado atrasado, período parcial e valor zero
O horário de execução do relatório não informa sozinho a atualidade do conteúdo. Uma carga concluída às 9h pode ter lido dados cujo último evento disponível é das 6h. Também pode ter processado a loja A até as 8h50 e a loja B apenas até as 7h. Exibir “atualizado às 9h” sem o período coberto induz o leitor a comparar conjuntos diferentes.
Registre pelo menos os tempos que alteram a interpretação: ocorrência do evento, chegada à plataforma e disponibilização da versão consumida. A precisão necessária depende da decisão. Um relatório mensal fechado admite uma política diferente de um painel usado para interromper uma campanha durante o dia. Defina o compromisso com o consumidor antes de escolher o indicador de atraso.
O maior horário de evento observado também não prova completude. Um evento recente pode ter chegado enquanto vários anteriores continuam ausentes. Quando a origem fornece um fechamento, sequência ou total de controle, use essa evidência para delimitar a cobertura. Quando não fornece, declare a limitação e acompanhe sinais complementares, como volume por origem, atrasos conhecidos e comparação com períodos equivalentes.
No caso fictício, a loja B interrompeu o envio. O valor zero de pagamentos dessa loja pode significar ausência real de vendas ou falha de coleta. Enquanto a origem não for reconciliada, a interface deve representar o estado como indisponível ou incompleto. Mostrar zero e adicionar um aviso discreto distante do gráfico não resolve a ambiguidade para quem exporta ou fotografa apenas o indicador.
Dados tardios exigem uma política de revisão. Determine quando um período permanece aberto, como correções alteram números já exibidos e quando o fechamento é considerado definitivo para aquele uso. Um painel operacional pode reprocessar o dia anterior; um relatório distribuído precisa identificar a nova versão. A regra deve permitir reconhecer uma correção sem confundi-la com mudança real no comportamento do negócio.
Coloque controles onde a violação pode ser contida
Algumas regras devem ser garantidas na gravação; outras dependem de informações que só estão disponíveis mais adiante. Um identificador obrigatório costuma ser melhor protegido antes de o registro circular. Já a reconciliação entre o sistema de pedidos e o provedor de pagamentos exige comparar conjuntos, períodos e situações que não cabem em uma validação local de um formulário.
A documentação de restrições do PostgreSQL 18 mostra como NOT NULL, UNIQUE, CHECK e chaves estrangeiras restringem dados persistidos. Ela também explica que uma expressão CHECK aceita resultado nulo, exigindo uma restrição própria para proibir nulos. Esses mecanismos protegem condições declaradas no banco; seu desenho não substitui a definição semântica do indicador.
Depois das transformações, confira propriedades do conjunto que será entregue. A documentação de data tests do dbt descreve testes que procuram registros que violam uma afirmação, incluindo unicidade, ausência de nulos e relações. O mesmo princípio pode ser aplicado em outra ferramenta: um teste precisa ter um conjunto de falhas identificável e um resultado que o fluxo saiba tratar.
Decida o efeito da falha. Uma violação na chave que sustenta o total pode impedir a publicação da nova versão, mantendo a última versão válida com sua data visível. Uma ausência de classificação secundária pode permitir divulgação parcial com a categoria “desconhecido”. Uma quebra de contrato ampla pode exigir suspender somente os indicadores afetados. O tratamento depende do uso e precisa ser definido antes do incidente.
Evite apagar registros problemáticos para fazer o teste passar. Uma quarentena deve preservar identificação, motivo, origem e possibilidade de correção. Também precisa expor a parcela excluída da saída. Sem essa informação, o dado publicado parece completo enquanto parte da operação desapareceu. Limites de acesso e retenção devem acompanhar a evidência de falha, especialmente quando os registros contêm informações pessoais.
Reconcilie um exemplo de ponta a ponta
O conjunto didático reúne pagamentos confirmados entre 1 e 31 de outubro de 2026, no fuso America/Sao_Paulo, com corte de conhecimento em 6 de novembro às 12h. Consideramos as devoluções vinculadas conhecidas nesse corte, inclusive as registradas depois de outubro. Trata-se de uma coorte de pagamentos ajustada por devoluções, sem representar o fluxo financeiro daquele mês. Existem 800 pedidos distintos com pagamento confirmado, somando R$ 160.000. Uma entrega repetida inclui dez confirmações adicionais de R$ 200 cada. A tabela recebida contém 810 linhas e a soma ingênua chega a R$ 162.000. O erro de R$ 2.000 aparece porque a mesma confirmação entrou duas vezes no conjunto considerado pelo indicador.
Depois de identificar as dez repetições pela chave de evento definida no contrato, a soma retorna a R$ 160.000. Há também doze devoluções de R$ 100, vinculadas a pagamentos do conjunto. Se a métrica escolhida desconta essas devoluções, o valor ajustado é R$ 158.800. Esse total usa uma definição didática de pagamentos menos devoluções; não representa uma classificação contábil de receita.
| Etapa do exemplo | Registros ou eventos | Valor considerado |
|---|---|---|
| Confirmações recebidas | 810 linhas, incluindo dez repetições | R$ 162.000 |
| Confirmações distintas | 800 pedidos, uma confirmação por pedido neste caso | R$ 160.000 |
| Devoluções vinculadas | 12 devoluções de R$ 100 | R$ 1.200 |
| Indicador ajustado | Confirmações distintas menos devoluções | R$ 158.800 |
A contagem e o valor oferecem verificações complementares. Um conjunto pode manter 800 linhas e alterar o montante de um pagamento. Também pode manter o total financeiro e trocar as atribuições entre lojas. Por isso, escolha pontos de reconciliação que representem o risco: contagem por entidade, soma por moeda, cobertura por origem e amostra de relações relevantes. Nenhuma soma geral comprova todas essas propriedades.
Use uma referência com independência suficiente para revelar a falha investigada. Comparar duas visualizações construídas sobre a mesma tabela transformada verifica consistência entre apresentações, mas pode repetir o mesmo erro de origem. No exemplo, a confirmação operacional dos pagamentos e o registro das devoluções oferecem evidências adicionais. Divergências precisam de uma lista de itens conciliáveis, não apenas de um percentual agregado.
Verifique o detector e defina quem resolve
Um teste que sempre retorna sucesso precisa ser desafiado. Prepare exemplos pequenos com uma violação conhecida: um identificador repetido, uma referência ausente, uma data fora do intervalo e uma origem sem atualização. Confira se cada caso é detectado e se o alerta chega a quem consegue agir. Preserve também exemplos válidos para evitar regras que rejeitam situações legítimas.
Esse exercício verifica o controle, não demonstra qualidade universal da base. Uma consulta que detecta duplicidade de chave pode funcionar perfeitamente e não descobrir uma duplicidade de negócio representada por duas chaves diferentes. Ao revisar incidentes, pergunte qual propriedade faltou observar e se há informação suficiente para transformá-la em uma regra verificável.
O alerta precisa identificar indicador afetado, população, período, regra violada e impacto conhecido. Informe uma amostra segura ou referências para investigação, sem copiar toda a base na notificação. O responsável pelo significado decide se o uso permanece aceitável; quem mantém a origem investiga o registro; a equipe de dados verifica propagação e correção. Uma única pessoa pode acumular papéis, desde que a decisão não fique sem dono.
Priorize pelo uso comprometido. Uma falha em um atributo descritivo de baixa utilização pode esperar a próxima rotina. A suspeita de duplicidade em valores apresentados para uma decisão imediata exige contenção antes da investigação completa. Registre a justificativa da prioridade, o prazo de reavaliação e quem deve ser informado quando a versão corrigida estiver disponível.
Investigue o significado dos registros que passam nos testes
A aprovação estrutural deve ser complementada por uma leitura de casos. Escolha registros com variações relevantes: lojas distintas, pedidos parcelados, devoluções parciais e alterações próximas do fechamento. Compare o que o painel representa com documentos ou eventos operacionais autorizados. O objetivo é localizar interpretações que uma lista de valores permitidos não consegue examinar.
Uma amostra escolhida por conveniência pode esconder justamente os casos difíceis. Se a equipe sempre abre pedidos simples e recentes, terá pouca evidência sobre correções antigas ou operações incomuns. Separe uma amostra exploratória, usada para procurar erros, de uma amostra desenhada para estimar sua frequência. A primeira ajuda a descobrir mecanismos de falha; sua composição não permite extrapolar automaticamente uma taxa para toda a população.
Considere uma devolução parcial registrada no mês seguinte à confirmação. O total do mês original muda se a regra realoca a devolução para o período do pagamento. Permanece igual se o indicador contabiliza devoluções no momento em que ocorreram. Cada interpretação tem utilidade para uma pergunta específica. O caso de aceite deve explicitar o resultado em ambos os períodos para impedir que a mesma política seja aplicada de formas diferentes por dois relatórios.
O mesmo vale para valores monetários e arredondamento. Se uma plataforma divide um valor entre itens, parcelas ou centros de custo, documente em que etapa arredonda e quem recebe a diferença residual. Um centavo repetido em muitas linhas pode produzir divergência material na reconciliação. Não ajuste o total final com uma constante para eliminar a diferença: localize a regra que gerou a distribuição e preserve sua explicação.
Os limites de tolerância devem corresponder ao mecanismo observado. Uma tolerância de centavos por documento não equivale a uma margem percentual sobre qualquer volume. Se a divergência aceitável depende do número de itens e da regra de arredondamento, essa relação precisa estar documentada. Uma tolerância ampla adicionada depois de uma falha pode normalizar um defeito sem resolver sua causa.
Compare também as permissões dos consumidores. Dois usuários podem obter totais diferentes porque enxergam populações diferentes, mesmo usando a mesma medida. Teste o indicador com os perfis relevantes e apresente o escopo visível. Quando a liderança compara uma exportação regional com o consolidado, deve conseguir distinguir diferença de acesso, diferença de filtro e problema de dados.
Por fim, examine se o próprio tratamento de erros cria um viés. Excluir registros sem endereço, por exemplo, pode reduzir desproporcionalmente a presença de uma região ou de um canal. A decisão de publicar apenas a parcela válida precisa apresentar o tamanho e a distribuição da exclusão. Isso permite avaliar se o conjunto restante ainda atende à pergunta original, em vez de presumir que qualquer redução da base mantém sua representatividade.
Mantenha o histórico quando a regra mudar
O significado de um indicador evolui. Uma empresa pode passar a considerar uma nova forma de pagamento ou separar uma operação anteriormente agrupada. Antes de alterar a consulta, compare o resultado das duas definições sobre o mesmo conjunto. Essa comparação torna visível quanto da diferença vem da regra e quanto vem dos eventos observados.
Registre vigência, autor da decisão, motivo e tratamento do passado. Recalcular o histórico pode ser necessário para manter comparabilidade, mas também altera números já utilizados. Manter o passado sob a regra antiga exige sinalizar a quebra da série. A escolha depende da pergunta do relatório; nenhuma das duas estratégias deve ocorrer silenciosamente.
O Data Quality Vocabulary do W3C, publicado como nota de grupo de trabalho, propõe representar medições e informações de qualidade para apoiar a avaliação do consumidor. Ele não define um selo universal de qualidade. A ideia útil para este caso é preservar contexto junto da medição: regra, conjunto avaliado, momento e evidência precisam continuar associados.
Na entrega, coloque perto do indicador a definição resumida, o período coberto e o estado de qualidade. Disponibilize detalhes para quem investiga, incluindo versão e limitações conhecidas. Uma pessoa que abre apenas uma exportação também precisa reconhecer a data e o alcance do conteúdo. O formato pode mudar; as condições de interpretação devem acompanhar o número.
Para começar, escolha um indicador que já orienta uma decisão relevante. Feche sua definição com os consumidores, reconstrua uma amostra e registre as relações que podem multiplicar ou excluir registros. Implante os controles que detectam essas falhas e simule um caso de erro. O trabalho está verificável quando o time consegue mostrar de onde veio o valor, qual período ele representa e o que acontecerá se uma dessas condições deixar de valer.
Fontes
- Government Data Quality Framework — GOV.UK. Finalidade e abordagem orientada ao uso; publicação de 3 de dezembro de 2020.
- PostgreSQL 18 — Constraints. Condições garantidas por restrições e tratamento de valores nulos em
CHECK. - dbt — Add data tests to your DAG. Testes de dados que retornam registros em violação; documentação consultada em 6 de novembro de 2026.
- W3C — Data Quality Vocabulary. Nota de grupo de trabalho sobre representação de medições e metadados de qualidade.
