The Data Quality Metrics That Actually Matter

Search for data quality metrics and you'll find the same list everywhere: completeness rate, accuracy rate, consistency rate, and so on, each expressed as a percentage. Those numbers are worth tracking. They're just not sufficient by themselves, because a dashboard full of clean-looking percentages doesn't tell you whether the data that actually drives decisions is trustworthy. Here's how I think about it in two layers.

The core metrics, and how to actually calculate them

• Completeness rate. Percentage of required fields that are populated, where "required" is defined per use case, not applied as one blanket rule across every table.
• Accuracy rate. Percentage of records that match a trusted reference or ground truth. Harder to measure than the others when no clean reference exists, and often approximated through reconciliation against a second, independently sourced dataset.
• Consistency rate. Percentage of records that agree across systems for the same real-world entity. This is the metric behind the "same customer in three systems" problem.
• Timeliness, or freshness. The lag between when data was generated and when it's actually available to use, measured against a defined expectation, not against a vague sense of "recent enough."
• Validity rate. Percentage of records that pass their format and rule checks, structurally correct even before you get to whether the value itself is accurate.
• Uniqueness rate. Percentage of records that represent a distinct real-world entity, with no duplicates inflating counts.

The operational metrics most lists leave out

These are less commonly discussed and often more useful, because they measure whether your quality process itself is working, not just the state of one dataset:

• Real pipeline success rate. Not just whether the job exited without an error, but whether the output actually passed validation. A job that "succeeded" while silently producing wrong output should not count as a success. This is the gap covered in how to catch a pipeline failing silently.
• Mean time to detect. How long between something breaking and someone actually noticing. A short time to detect means your monitoring is doing its job. A long one means issues are being found by business users instead of by the system built to catch them.
• Mean time to resolve. Once detected, how long until it's actually fixed. This is where ownership gaps show up clearly, since issues without a clear owner tend to sit unresolved far longer.
• Check coverage. The percentage of critical datasets that actually have automated validation in place. Most organizations have never measured this, and the honest number is usually lower than expected.

Choosing which ones matter for your organization

Not every metric deserves the same attention everywhere. The right approach is the same one that applies to defining data quality in the first place: track the dimensions and datasets that actually affect a real decision, not every metric uniformly across everything you have. A completeness score on a rarely used archival table isn't worth the same attention as a consistency score on the customer data your revenue reporting depends on.

A dashboard full of quality percentages that nobody looks at is worse than having no dashboard at all, because it creates a false sense that quality is being monitored. Metrics only do their job when someone owns them and something actually happens when they slip.