Data Quality Metrics and KPIs: What to Track

If you only track how many tables have a test, you will celebrate coverage while finance still disputes revenue numbers. Data platform leaders need two layers of measurement: asset-level data quality dimensions that say whether a table is fit for use today, and program-level KPIs that say whether the quality operating model is actually improving.

TL;DR

  • Split asset health metrics from program KPIs so neither layer creates false confidence.
  • Start with freshness, completeness, validity, and test pass rates on tier-1 assets.
  • Add ownership, documentation, and time-to-detect/resolve so governance progress is visible.
  • Cap alert volume; optimize for actionable failures, not maximum test count.

Article Contents

Separate quality metrics from program KPIs

Gartner estimates that poor data quality costs organizations an average of $12.9 million per year, and that 59% of organizations do not measure data quality. Measurement is the first intervention, but the shape of the measurement matters.

A quality metric answers a local question about an asset or pipeline: Did last night's load arrive within SLA? What share of `customer_id` values are null? Did uniqueness hold on the natural key? A KPI answers an organizational question: What share of tier-1 assets have an owner? What is the mean time to resolve failed tests? Are we reducing repeat incidents on the same tables?

Mixing the layers is how teams get stuck. A rising test count looks like progress while the same five tables keep breaking. A documentation KPI looks green while freshness SLAs silently slip. Track both, and review them on different cadences: asset metrics daily or per-run, program KPIs weekly or monthly.

This split also clarifies tooling. Data quality tests and profilers feed the asset layer. Metadata KPIs for documentation, ownership, and tiering feed the program layer. Collate and OpenMetadata expose both so you are not stitching warehouse dashboards to a separate governance spreadsheet.

Asset-level metrics that map to dimensions

Freshness, completeness, and validity first

Most production pain shows up in three signals. Freshness is time since last successful update versus the agreed SLA for that asset. Completeness is null rates or missing required fields on columns consumers treat as mandatory. Validity is conformance to formats, enums, ranges, and referential rules.

Instrument these as executable checks, not as monthly manual audits. Define thresholds with the consuming team, not only with the platform team. A marketing null rate that is fine for funnel exploration may be unacceptable for billing. Publish the threshold next to the asset so consumers know what "green" means.

Test pass rate is the rollup. Track it per asset, per domain, and for the tier-1 cohort. A global pass rate that mixes unused staging tables with revenue facts hides risk. Prefer cohort views that mirror how the business feels pain.

Consistency and uniqueness where joins and keys matter

Add uniqueness when duplicate keys create double counting. Add consistency when the same entity is represented differently across systems that later join. These metrics are more expensive to design because they need shared definitions, but they catch the failures that single-table null checks miss.

Where joins are critical, track row-count and key-overlap expectations between producer and consumer tables. Contract assertions help here: data contracts can encode the quality expectations that must stay green for a data product to be considered compliant.

Program KPIs that prove the operating model works

Program KPIs tell you whether data quality management is becoming muscle memory or remaining a side project.

Ownership coverage: percentage of tier-1 assets with an accountable owner and backup. Documentation coverage: percentage with usable descriptions for the asset and critical columns. Tiering coverage: percentage labeled by criticality so incident routing and review intensity can differ. OpenMetadata's insights model is built around these adoption goals, including percentage or absolute targets over a timeframe.

Operational KPIs matter just as much. Mean time to detect (MTTD) is the lag between a bad load and a failed check or alert. Mean time to resolve (MTTR) is the lag from failure to fix, waiver with expiry, or accepted rule change. Repeat-incident rate tells you whether fixes are lasting. Open failure count by domain shows whether backlog is concentrated or systemic.

If ownership and documentation climb while MTTD and MTTR stay flat, you improved catalog hygiene without improving reliability. If pass rates climb while ownership stays empty, you automated checks nobody will answer.

How Collate and OpenMetadata surface both layers

On the asset layer, Collate runs and stores data quality tests, profiler signals, and alerts beside the tables people already search. For teams that need domain-specific measures, the custom metrics and alerts path lets you express business rules in SQL instead of waiting for a generic test type.

On the program layer, metadata KPIs make documentation, ownership, and tiering targets visible as organizational goals rather than tribal knowledge. Pair that with data observability so volume, schema, and freshness anomalies appear even when a static weekly score still looks fine.

The data quality demo is a useful reference for how these signals appear together in the product UI while you design your first executive scorecard.

A starter scorecard you can run this quarter

Keep the first scorecard small enough that leaders will actually read it.

Asset cohort (tier-1 only): freshness SLA adherence, critical-column null rate, uniqueness check pass rate, overall test pass rate, open failures older than seven days.

Program: ownership coverage, documentation coverage on tier-1, MTTD, MTTR, repeat failures on the same asset within thirty days.

Review weekly with domain owners for open failures. Review monthly with platform leadership for KPI trends. Resist adding more charts until these move for a full quarter. A thin data quality framework that people use beats a dense dashboard that people ignore.

Avoid vanity coverage and alert noise

Coverage percentage is a supporting metric, not the north star. Prefer "share of revenue-critical tables with owners and failing-fast checks" over "share of all cataloged tables with any test." The second number is easy to game with shallow checks.

Alert volume is a leading indicator of program health. If every minor variance pages the same channel, responders mute the channel and true incidents go quiet. Bundle related cases into suites, route by domain, and require that every alert name the owner and the consumer impact.

Finally, publish definitions beside the numbers. If two teams disagree about what freshness means, your KPI is theater. Align the metric dictionary the same way you align the business glossary: one definition, linked to the assets it governs, enforced by the same data quality tools that run the checks.

Track what consumers feel first, then what the catalog can prove. That is the difference between metrics that decorate a slide and KPIs that change how data ships.

Frequently asked questions

What is the difference between a data quality metric and a KPI? A metric describes asset or pipeline health, such as freshness lag or null rate. A KPI describes program performance, such as ownership coverage or mean time to resolve. You need both layers.

How many metrics should a platform team track? Start with a short tier-1 scorecard: freshness SLA adherence, critical null rates, uniqueness where keys matter, test pass rate, ownership coverage, MTTD, and MTTR. Add metrics only when a decision changes because of them.

Should every table use the same scorecard? No. Tier and domain should change thresholds and review intensity. Revenue facts need tighter freshness and uniqueness than exploratory sandbox tables.

How do metadata adoption KPIs relate to data quality? Ownership and documentation KPIs do not prove row correctness, but they prove someone can answer a failure. Without owners, quality metrics become orphaned dashboards.

What is a healthy test pass rate? There is no universal number. Track pass rate for the tier-1 cohort and trend it with open failures older than seven days. A high global pass rate that mixes unused tables can hide critical risk.

How often should quality dashboards refresh? Asset metrics should update with pipeline runs or at least daily for critical loads. Program KPIs can refresh weekly for operating reviews and monthly for leadership. Match cadence to the decision the chart supports.

Ready for trusted intelligence?
See how Collate helps teams work smarter with trusted data