Note
Data quality needs an owner, not only a score
Why useful quality monitoring connects each signal with impact, context, and a resolution path.
- Data Quality
- Analytics Operations
- Root-Cause Analysis
A data quality score can summarize a large set of checks. It can also conceal the information people need to act.
A 94% score does not say which six percent failed, whether the failure affects a critical decision, who understands the source, or whether the condition is new. Without that context, monitoring becomes a display of concern rather than a route to resolution.
A check needs operational metadata
For each rule, record more than pass or fail:
- the business purpose of the data;
- the rule owner and technical owner;
- evaluation grain and schedule;
- severity and acceptable threshold;
- affected scope and representative examples;
- first occurrence, persistence, and latest result;
- the next investigation step.
Ownership does not mean one person must fix every issue. It means there is a clear starting point for triage and a person accountable for the rule’s meaning.
Failure rate is not impact
A widespread formatting inconsistency may be inconvenient but harmless. One incorrect record may materially affect an executive total or a customer outcome.
Prioritization should therefore combine technical severity with business context: criticality of the data product, affected volume, persistence, downstream dependencies, and whether a decision is blocked.
Show the path, not only the status
A useful monitoring view lets a user move from domain health to a specific rule, then to run history and a safe sample of failures. It should show freshness and definition changes so a user does not interpret a pipeline delay or revised rule as a sudden deterioration in source quality.
Sensitive fields need not be exposed to make diagnostics useful. Carefully selected identifiers, categories, timestamps, and reason codes can provide enough evidence to reproduce the condition while respecting access boundaries.
Close the loop with verification
An issue is not resolved merely because a change was deployed. The next evaluation should confirm that the affected population recovered and that the correction did not create a new failure elsewhere.
Good data quality monitoring supports a loop: detect, understand, assign, correct, verify, and learn. The score can remain—but it should be the doorway to that process, not the destination.