A customer email bounces. A prescription arrives at the wrong dose. Two systems show two different balances for the same account. Every one of these starts with the same question nobody asked in time: was the underlying data actually any good?
That question has an answer, and it is not a feeling. Data quality dimensions are the specific, measurable characteristics you check to find out whether a dataset is fit for the job you are asking it to do. Accuracy, completeness, consistency, timeliness, validity and uniqueness turn up in nearly every framework you will encounter, and between them they cover most of what goes wrong with data in practice. This guide walks through what each one means, where organisations actually feel the pain, how to measure them, and how to work out which ones deserve your attention first.
Why data quality dimensions matter
You cannot fix what you cannot measure, and "the data looks a bit off" is not a measurement. Data quality dimensions give you specific, named attributes to check instead, so two people looking at the same dataset arrive at the same verdict rather than a shrug and a guess. Without that shared language, quality becomes whatever the loudest person in the meeting says it is.
What poor data actually costs
Gartner puts the average cost of poor data quality at somewhere around $12.9 million a year for a typical organisation, and separate estimates suggest bad data eats into a meaningful slice of revenue once you add up the wasted hours behind it. Those numbers rarely show up as one dramatic incident. They show up as a support team correcting the same wrong address for the third time, a marketing campaign that lands in a spam folder because half the list is duplicated, and a finance team burning a Friday afternoon reconciling two numbers that should have matched from the start.
We have sat in enough of these post-mortems to know the pattern. It is rarely one catastrophic failure. It is a record from three years ago that nobody flagged, sitting quietly in a join that a dozen reports now depend on.
Why this matters even more for AI
A model trained on inaccurate data produces confident, wrong answers, and it does so at scale. Machine learning needs complete records to find real patterns rather than noise. Natural language systems need consistent formatting to extract anything reliable from text fields. Recommendation engines quietly degrade when duplicate customer records split one person's behaviour across two profiles. None of this shows up as an error message. It shows up as an AI pilot that technically works and never gets adopted, because the outputs do not quite match what people on the ground already know to be true. If you are weighing up whether your data is ready for an AI project, our AI and ML data readiness checklist is a reasonable place to start before you commit budget.
The six core dimensions explained
Most frameworks in use today trace back to research by Richard Wang and Diane Strong, published in 1996, which set out a structured way to think about data quality from the perspective of the people actually using the data rather than the people storing it. Three decades on, the six dimensions they popularised are still the ones you will meet first in any serious data quality programme.
Accuracy, completeness and consistency
Accuracy is how closely a record matches reality. A customer's address is accurate when it is the address they actually live at, not merely a well-formatted string that looks like an address. Checking it properly means comparing against a trusted source, whether that is a postal database, a bank verification step, or the customer themselves confirming the details.
Completeness is whether the fields you need actually hold values. A patient record missing an allergy field is not incomplete because it looks sparse. It is incomplete because a doctor cannot safely prescribe without that information, even if every other field is filled in perfectly. Completeness is always relative to what the record needs to do, not to how full it looks on a screen.
Consistency is whether the same fact agrees with itself across every place it is stored. If your CRM holds one phone number for a customer and your billing system holds another, you have a consistency problem, and it is usually a sign that two systems update independently with no reconciliation step between them.
Timeliness, validity and uniqueness
Timeliness is whether data is available when you need it and reflects the current state of the world. Yesterday's stock price is completely accurate and completely useless to a trader deciding what to do this morning. Timeliness is the dimension people underrate most, because a dataset can pass every other check and still be wrong simply by being late.
Validity is whether data conforms to the rules you have defined for it: an email address contains an @ symbol, a postcode matches a real postal pattern, a date falls in a range that makes sense. Validity checks are usually the cheapest to automate, which makes them a sensible first line of defence even though they will not catch everything on their own.
Uniqueness is the absence of duplicates. Two records for the same patient is not a minor inconvenience. It is a risk, because whichever record a clinician happens to open is missing whatever sits in the other one. In a CRM the stakes are lower but the effect is similar: split history, confused reporting, and a customer who gets the same marketing email twice in one morning.
Between them, these six give you a fair first pass at almost any dataset:
- Accuracy: percentage of records that match a trusted, independent source
- Completeness: percentage of required fields that hold a value
- Consistency: percentage of matching fields that agree across systems
- Timeliness: average age of a record measured against the freshness your use case needs
- Validity: percentage of values that pass their defined format or range rules
- Uniqueness: percentage of records with no duplicate elsewhere in the dataset
Extended dimensions for specific contexts
The core six cover most of what goes wrong, but not all of it, and some industries need a wider net. Integrity checks whether the relationships between pieces of data survive as information moves through your systems, so an order still points to a real customer after three system migrations rather than a customer ID that no longer resolves to anyone. Auditability matters most in regulated environments, where you need to prove not just that a number is right but that you can trace exactly how it got there. This overlaps heavily with data lineage, and the two are worth tackling together rather than separately.
Relevance is a quieter dimension, and an easy one to skip. It asks whether a dataset actually supports the decision someone is trying to make, rather than just existing and being technically correct. A manufacturer tracking integrity might find that a supplier ID still resolves correctly after a system migration, yet the linked contract terms point to a version that was superseded two years ago; the record passes every technical check while still being useless to whoever pulls it up to settle a dispute. Banks and healthcare providers also tend to formalise accessibility and security as quality dimensions in their own right, because data that is perfectly accurate but unreachable by the people who need it, or reachable by people who should not have it, has failed a real test even if every other number checks out fine.
Data quality dimensions in practice
Definitions only get you so far. Seeing how the dimensions interact in a real setting is usually what makes them click.
Healthcare patient records
A hospital needs several dimensions working together just to keep a patient safe through one admission. Completeness catches the missing allergy field before it causes a reaction. Accuracy is what stands between a correct dosage and a decimal-point error that turns a safe prescription into a dangerous one. Uniqueness is what stops a patient's history splitting across two records, because a surgeon who only sees half a history is operating with half the information.
E-commerce customer data
Retailers live or die on a narrower but still demanding set. Accuracy in a delivery address is the difference between a parcel arriving and a parcel getting returned, refunded, and never trusted again. Completeness in contact details is what lets you actually warn a customer about a delay instead of leaving them guessing. Consistency between the website, the checkout system, and the warehouse stops product codes drifting apart, which is exactly how a customer ends up with the wrong item in the box.
Financial transaction processing
Banks lean hardest on timeliness and accuracy, and for good reason. Fraud detection only works if transaction data arrives close to real time. A suspicious pattern spotted a day late is a suspicious pattern that already cost someone money. A single wrong digit in an account number sends funds to a stranger and triggers a recovery process that costs far more than getting the digit right the first time would have done. Uniqueness stops a customer being charged twice for one purchase, and validity rules catch transaction amounts that fall outside anything plausible before they corrupt a report further downstream.
A record can be accurate and complete and still get someone hurt if it is not there when the decision gets made.
Which dimensions matter most for your use case
Treating all six dimensions as equally important is a good way to spend a lot of effort and fix very little. Real-time fraud detection lives and dies on timeliness, because a perfectly accurate record that arrives an hour late has already missed its window. Regulatory reporting cares most about accuracy and completeness, since a gap or an error there becomes a compliance finding rather than a minor inconvenience. Customer segmentation is mostly a consistency problem: get that wrong and the same person receives three different versions of the same email because three systems each think they know who they are.
Matching your effort to what the business actually needs, rather than chasing a perfect score across every dimension, is the difference between a data quality programme that pays for itself and one that quietly runs out of budget by year two.
The dimensions also trade off against each other more often than the frameworks admit. Pushing for perfect accuracy on a field usually means slower ingestion, because every value gets checked against a trusted source before it lands, and that extra step can quietly undermine timeliness for a use case where speed was the actual requirement. A fraud team that insists on validating every transaction against three external sources before flagging it has traded the one dimension it needed most for a level of accuracy nobody asked for. Know which dimension you are optimising for before you tune the others up.
Where data quality programmes go wrong
The dimensions themselves are simple. Most programmes that stall do so for reasons that have nothing to do with the framework and everything to do with how it gets applied.
The most common mistake is treating every dataset the same way. Measuring all six dimensions against every table in the warehouse burns weeks of engineering time on datasets nobody downstream actually depends on, while the one dataset that genuinely matters sits unmeasured because it was not first in the queue. Prioritise by business impact, not by which team shouts loudest or which dataset happens to be easiest to profile.
The second is chasing a perfect score. Ninety-nine per cent completeness on an optional field that half your customers deliberately leave blank is not a problem worth solving. A validation rule tightened past the point where it reflects reality just generates false alerts that your team learns to ignore, and once people start ignoring alerts, the whole monitoring system stops earning its keep.
The third is skipping ownership. A dimension score with nobody responsible for acting on it is a number on a dashboard, not a quality programme. Every dataset you measure needs someone whose job includes fixing what the measurement finds, and that person needs the authority and the time to actually do it, not just a line in their job description.
The fourth, and the one we see most often at Shipshape Data, is buying a tool before understanding the problem. Data quality platforms are good at running checks once you know what to check and why. They are much worse at telling you which datasets matter or what "good enough" looks like for your business, and teams that skip that groundwork end up with an expensive dashboard nobody trusts.
Measuring and monitoring data quality dimensions
Scores only mean something once you can compare them over time, which is why measurement has to be quantitative from day one rather than a periodic gut check.
Establish a baseline
Before you improve anything, run profiling against your priority datasets and write down where you actually stand, with a timestamp and a note on how each score was calculated. A customer database showing 87% accuracy, 94% completeness and 78% uniqueness today is not a verdict on the team. It is a starting line. Without it, you have no way to prove the next six months of work did anything at all.
Automate the checks that can be automated
Manual spot-checks do not scale and go stale within weeks. Set up validation rules that run as data enters your systems or moves between them: format checks on email and postcode fields, range checks on numerical values, referential checks that confirm a foreign key actually points to something real, and fuzzy matching to catch duplicates that differ by a misplaced initial or an extra space. Alert when a score drops below the threshold you defined for that dataset. When accuracy on a critical field slips under 90%, the system should tell someone before a customer does.
Put the numbers somewhere people will actually see them
A dashboard nobody opens is just an expensive spreadsheet. Show trend lines per dimension, not just a snapshot, so a slow decline is visible long before it becomes a crisis. Split the view by dataset or business unit so the people responsible for a number are the ones who see it move. The goal is not a pretty chart. It is a team that notices a problem on a Tuesday instead of hearing about it from a customer on a Friday.
Getting started
You do not need to instrument every field in the business before you get value from this. Pick one dataset that genuinely matters, measure it against two or three dimensions that map to a real business problem, and get a working baseline before you try to scale the approach anywhere else. Momentum from one clean win does more for a data quality programme than a perfect framework nobody has tested yet.
Building the pipelines, monitoring and governance that keep those scores healthy is exactly the kind of work we do at Shipshape Data. If your team is weighing up where your data foundation actually stands before an AI project or a compliance deadline forces the question, talk to us and we will help you find out.