Data quality metrics are useful when they describe whether data is fit for a specific process or decision and lead to owned remediation. A single completeness percentage cannot represent identity, transaction and historical integrity.
Define the data object, rule, population, time and consequence. Measure dimensions such as completeness, validity, uniqueness, consistency, accuracy and timeliness separately, then pair them with control totals and exception ageing.
Begin with fitness for use
Name the business event or decision: pay an employee, ship an order, contact a customer, migrate an account or report a balance. Identify fields and relationships that determine whether it can proceed safely.
Different uses tolerate different gaps. An optional marketing attribute and a payroll bank identifier should not share one target.
Define six dimensions
| Dimension | Example formula | Limitation |
|---|---|---|
| Completeness | required values present / required values expected | present can still be wrong |
| Validity | values passing rule / values tested | rule may not reflect reality |
| Uniqueness | nonduplicate entities / entities tested | matching has uncertainty |
| Consistency | agreeing cross-field/source values / comparisons | both sources may be wrong |
| Timeliness | records current by decision deadline / records due | deadline varies by use |
| Accuracy | verified correct values / sampled values | needs trusted reference or observation |
Write the metric card
Include object, population, formula, exclusions, source, frequency, threshold, owner, remediation route and action when failed. Version the definition.
Give an example record that passes and one that fails. This prevents teams interpreting the same label differently.
Use control totals
For migration and integration, compare counts and material amounts by meaningful segment before and after movement. Include accepted, rejected, duplicate and pending records.
Grand totals can let errors cancel. Reconcile by entity, period, location, status or transaction type according to risk.
Measure relationships
Check orphan records, invalid references, impossible state order and broken hierarchy. A complete order row is unusable when its customer or item cannot be resolved.
Define referential rules across systems and preserve identifiers during migration.
Sample accuracy responsibly
Choose a sample that covers value, risk, source and difficult variants. Compare with an authoritative document, observation or subject expert. Record method and confidence.
Do not extrapolate a tiny convenient sample without disclosing limits. Increase focus where defects cluster.
Track exception ageing
Measure defects opened, resolved, reopened and ageing by cause and owner. A stable defect rate can hide a growing unresolved backlog.
Prioritise by consequence, not only count. One wrong bank record may matter more than many missing optional tags.
Distinguish source and transformation defects
Trace whether the value was wrong at entry, mapped incorrectly, transformed by a rule, truncated, duplicated or delayed. Fix the earliest owned cause.
Correction in the target alone may be overwritten by the next load. Feed valid changes back through the authoritative process.
Set thresholds and stop rules
Use thresholds based on risk and operating capacity. Some defects can be accepted with a dated action; others block migration or release. Name the decision authority.
Monitor guardrails after go-live because users and interfaces create new patterns not present in test data.
Profile before setting targets
Measure current distributions, patterns, nulls, duplicates and relationships before committing to a target. Separate known legitimate variants from defects. A target chosen without a baseline can be impossible, trivial or harmful.
Profile by source and time because one clean system can hide another with concentrated risk. Retain the query or rule so the baseline is reproducible.
Use metrics through migration rehearsals
Run the same definition at source, transformed stage and target. Track exceptions by reason and disposition. Compare not only the final score but which records changed status.
A rising completeness score can come from default values that remove nulls without creating truth. Sample business use after load.
Build a remediation ledger
For each material defect, record object, rule, records affected, first cause, owner, correction method, control preventing recurrence and verification. Separate one-time cleanup from source-process change.
Keep before values or a reversible transformation where risk warrants it. Bulk fixes need peer review and reconciliation.
Publish quality with decision context
Show the relevant metric beside the report or process it affects, with freshness and known limitations. A separate quality dashboard may be useful to stewards but should not let decision users overlook a failed control.
When a threshold is breached, state whether use is blocked, qualified or allowed. This turns quality from a technical score into an operating rule.
Prevent metric gaming
Completeness can rise when teams insert placeholders; uniqueness can rise after unsafe merges; timeliness can improve by closing records early. Pair metrics and sample outcomes.
Use measures to improve systems and processes, not punish people for surfacing defects.
Operate the quality loop
Review decision-critical metrics, investigate causes, assign remediation, verify correction and change capture or interface controls. Retire metrics that no longer guide action.
Data quality improves when definitions, authority and remediation are part of delivery—not when a dashboard merely reports a score.
After release, compare quality incidents with the original project thresholds and update the control plan. New users, volumes and interfaces can create defects the migration rehearsal never contained.