Guide · Quality
The six data quality dimensions, and how to measure yours
Everyone agrees data quality matters and almost nobody can say what their current quality is. The gap is usually not effort — it is that “quality” is six different questions wearing one coat, and answering them separately turns an unwinnable conversation into six measurable ones.
The short answer
The six standard dimensions are completeness (is anything missing), accuracy (does it match reality), timeliness (is it current enough for the decision), consistency (do the systems agree), validity (does it conform to its own rules) and uniqueness (is anything duplicated). Five of the six can be measured with SQL you can write this afternoon. Accuracy cannot, which is why it is the one that gets quietly dropped.
Completeness
Are the values that should be there, there? Measured as the share of records with a populated value in the fields you have declared mandatory.
The trap is measuring it against every field rather than the ones that matter. A customer table where 4% of middle names are blank is fine; the same table where 4% of postcodes are blank is a distribution problem. Declare a small set of required fields per dataset — usually four to eight — and measure only those.
How to measure: count nulls and empty strings per required field, as a percentage of rows. Watch for the fake value: a blank that has been helpfully filled with "N/A", "Unknown", "0" or a 1900 date will pass a null check and fail the business.
Accuracy
Does the value correspond to the real thing it describes? This is the dimension people mean when they say quality, and the only one that cannot be established from inside the database, because the database is what is being questioned.
Measuring it needs a reference: a second source you trust more, an external register, or a sample checked by hand. Sampling is respectable and cheap. Pull fifty records, have someone who knows the domain verify them against the world, and record the error rate with the date and the sample size. That number, imperfect as it is, will be the most informative thing on your quality dashboard.
How to measure: against an authoritative source where one exists — Companies House for company names, a postcode file for addresses, the finance ledger for values. Otherwise a dated manual sample, repeated quarterly.
Timeliness
Is the data current enough for the decision being made on it? Note the second half: timeliness is relative to a use, so the same feed can be timely for a monthly board pack and useless for a next-day operational call.
The measurable version is latency against a stated expectation. Which means someone has to state the expectation, and that is the useful part of the exercise. "Updated daily" is not an expectation; "in the warehouse by 07:00 on working days" is.
How to measure: the age of the newest record at the moment of use, and the share of days the stated deadline was met. The second number is the one that finds the problem — a feed that is on time 96% of the time is a feed that is late once a month, and that is the day the board meets.
Consistency
Do the systems that hold the same fact agree with each other? The CRM says the account is active, the billing system says it churned in June, the support desk has it on a current contract.
This is the dimension that produces the meetings people hate, because each system is internally correct and there is no technical error to find. It is a reconciliation problem, and the fix is a decision about which system is authoritative for which attribute — see master data management without the platform.
How to measure: pick the three or four facts that appear in more than one system, join on the key, count the disagreements. Do this once and the number will be higher than anyone expected.
Validity
Does the value conform to the rules of its own field — the right format, the right range, a value from the permitted list? A date of birth in 2087 is invalid. A status of "Complete " with a trailing space is invalid if the permitted list says "Complete".
Validity is the cheapest dimension to measure and the most satisfying, because the failures are unambiguous and usually fixable at source. It is also the one most likely to reveal that two teams have been maintaining separate versions of the same status list.
How to measure: a rule per field — regex, range, or membership of a reference list — and a count of rows failing each. Twenty rules across your top ten datasets is a good first pass.
Uniqueness
Is anything in here twice? Exact duplicates are easy. The expensive kind are near-duplicates: the same customer as "Acme Ltd", "ACME Limited" and "Acme Ltd." with three different account numbers and three different credit limits.
How to measure: count exact duplicates on the business key, then run a fuzzy match on name and postcode and eyeball the top hundred pairs. Do not automate the merge on a first pass. Merging two customers who are genuinely different is a much worse outcome than leaving them separate.
Why a single quality score is usually a lie
Averaging six dimensions into one number destroys the only information you had. A dataset scoring 92% because completeness and validity are perfect while consistency is at 60% is not a 92% dataset — it is a dataset that will lose you an argument in a board meeting.
If you must publish one figure, publish it as the lowest of the six rather than the mean, and show the six underneath. A minimum is honest about where you will actually get hurt.
A first pass you can run this month
- Take the ten datasets that reach a customer, a regulator, a lender or the board.
- For each, agree the required fields (four to eight) and the validity rules (two or three).
- Write the completeness, validity and uniqueness queries. An afternoon, for all ten.
- Set a timeliness expectation as a clock time, not an adjective, and start recording whether it was met.
- Run one consistency check across the two systems that most often disagree.
- Sample fifty records from the single most important dataset and check them by hand for accuracy. Date the result.
That produces a baseline in about two days of work, entirely without tooling. The reason to do it before buying a quality tool is that the tool will ask you for the rules, and if you have not agreed them it will happily measure nothing at all, very fast.
Common questions
What are the six dimensions of data quality?
How do you measure data quality without buying a tool?
Which data quality dimension is hardest to measure?
Should we publish a single data quality score?
Where the product comes in
Quality measures sit on the dataset, not in a separate spreadsheet
Each dataset record in Lake On Rails carries its quality checks and its score alongside its owner, its tier and its history, so the number a decision-maker sees is attached to the thing it describes. The maturity score rolls the measures up, and it falls when they do.
The first step costs you nothing
Forty-five minutes with whoever runs your reporting
We tell you honestly whether this is worth doing at all, and roughly what it would take. If the answer is not yet, you will hear that. "Not for us" is a fine outcome, and a better one than a slow maybe.