How to Actually Measure Data Quality (Instead of Just Saying Your Data Is "Bad")

"Our data is bad" is one of the most common sentences we hear in a first meeting, and one of the least useful. It is a feeling, not a diagnosis. It tells us nothing about which systems, which fields, which time windows, or which decisions are actually affected. And because it is not measured, it never gets fixed — it just gets repeated, quarter after quarter, in slightly more frustrated tones.

Data quality is measurable. It has dimensions, each with a concrete test behind it. Once a company can score its data instead of just distrusting it, quality work stops being a vague cultural aspiration and becomes a project with a backlog, an owner, and a completion date.

1. 1Completeness: What percentage of required fields are actually populated? A customer record missing an industry tag or a deal missing a close date is not a minor gap — it is a hole in every report that segments by that field.
2. 2Accuracy: Does the value match reality? This is the hardest to test automatically, but proxy checks work — email formats, phone number patterns, values outside plausible ranges, duplicate customer IDs with conflicting details.
3. 3Consistency: Does the same entity look the same across systems? We routinely find a client named one way in the CRM, another way in the accounting system, and a third way in the support platform — and no reliable key joining the three.
4. 4Timeliness: How stale is the data by the time someone uses it? A dashboard refreshed nightly that feeds a same-day operational decision is a timeliness failure even if every value in it is technically correct.
5. 5Uniqueness: How many duplicate records exist, and how much do they distort totals? Duplicate lead records alone have inflated pipeline reporting by more than 15% in more than one organization we have audited.

The organizations that improve their data quality do one thing differently from the ones that stay stuck: they route quality failures into the same backlog discipline they already use for engineering work. A completeness failure on a required field becomes a ticket, assigned to whoever owns that data entry point, with a due date. A duplicate detection job runs weekly and produces a merge queue, not just an alert nobody reads.

This is where business intelligence consulting engagements often go wrong when they focus purely on the dashboard layer. A beautifully designed dashboard built on top of a 23%-failure-rate dataset is not an improvement — it is a more convincing way to present an unreliable number. Quality work has to happen upstream of visualization, not alongside it as an afterthought.

Pick the three tables or objects that feed your most important recurring report — usually revenue, pipeline, or operational throughput. Score each of the five dimensions above on just those three tables. Do not attempt an organization-wide quality audit on day one; it will stall under its own scope before it produces anything usable.

• Run automated checks weekly, not quarterly — quality decays continuously, and quarterly checks let problems compound silently for months.
• Assign an owner to each data source, not just to the dashboard that consumes it. Dashboards do not create bad data; unowned entry points do.
• Report the quality score itself to leadership alongside the metrics it supports, so trust in a number is never assumed — it is demonstrated.