Data Quality Dimensions: The 6 That Matter, With Examples

Data quality dimensions are the standard categories teams use to describe what "good data" means, so that a vague complaint like "the numbers look wrong" becomes a measurable defect. The six most widely used are completeness, accuracy, consistency, timeliness, validity, and uniqueness. Each one maps to a different failure mode, each is measured differently, and only some of them can be checked automatically. Getting the split right is what separates a data quality program that catches real incidents from one that produces a dashboard nobody opens.

What are the 6 data quality dimensions?

The six dimensions are completeness (is the data there), accuracy (does it match reality), consistency (does it agree with itself across systems), timeliness (did it arrive when it should have), validity (does it conform to the rules and formats it is supposed to), and uniqueness (is each real-world thing represented once). They come out of the DAMA data management body of knowledge and its UK chapter work on assessing data quality, and they have become the common vocabulary across vendors, auditors, and internal data teams.

That last column is the one worth staring at. Four of the six can be monitored continuously by software with no human input beyond a connection. Consistency needs somebody to state the rule. Accuracy usually cannot be measured at all without a reference you trust more than the data itself, which is why so many data quality programs quietly stop at "the pipeline ran."

Completeness: is the data actually there?

Completeness asks whether the values and records you expected are present. It shows up in two forms, and teams often only monitor one of them. Column completeness is the familiar one: what percentage of rows have a non-null value in a field that should always be populated. Record completeness is the one that hurts more: did you get all the rows at all. A customer table that arrives with 400,000 rows instead of the usual 1.2 million is fully "complete" at the column level and catastrophically incomplete at the record level.

Measure column completeness as non-null count divided by total rows, per column, tracked over time rather than as a single threshold. A field that is normally 3 percent null and is suddenly 30 percent null is a real incident even though 70 percent is not obviously "bad." For record completeness, watch row counts against their own history and account for seasonality: a B2B dataset that always dips on weekends should not page anyone at 6am on Saturday.

Accuracy: does the data match reality?

Accuracy is whether a value correctly describes the thing it claims to describe. A customer address that is well formed, present, unique, and current is still inaccurate if the customer moved last year. This is the dimension people mean when they say "the data is wrong," and it is also the hardest one to measure, because to check accuracy you need a source you trust more than the data you are checking.

In practice teams measure accuracy in three ways. They sample and verify manually against a known-good source, which is expensive but honest. They reconcile against an authoritative system, for example checking revenue in the warehouse against the finance system of record. Or they use external reference data, such as address validation or a business registry. If none of those are available, be candid that you are not measuring accuracy, rather than reporting a proxy as if it were the real thing. Most published "data quality scores" are really completeness and validity scores wearing an accuracy label.

Consistency: does the data agree with itself?

Consistency asks whether the same fact is represented the same way everywhere it appears. Order counts in the finance mart should tie to order counts in the operations mart. A customer marked churned in the CRM should not have an active subscription in billing. Line item totals should sum to the invoice header total. None of these require knowing the truth, only that two representations agree, which is why consistency is measurable when accuracy is not.

These are business rules, and they have to be written by someone who understands the business. That is genuinely different work from statistical monitoring, and it is why most mature teams end up running a testing framework alongside a monitoring platform rather than choosing between them. The framework encodes the handful of reconciliations that matter. The platform watches everything else. If you are weighing that split, our comparison of data quality tools breaks the market into the five categories and explains which failures each one actually catches.

Timeliness: did it arrive when it should have?

Timeliness is whether data is available when it is needed, and it is the dimension that causes the most visible damage per incident. A table that has not refreshed since Thursday feeds a Monday board deck with stale numbers, and every downstream consumer sees a plausible dashboard with no warning that it is three days old. Nothing is null, nothing is invalid, nothing is duplicated. The data is just old.

Measure it as time since the last successful load compared with the expected interval, per table, with the expectation learned from history rather than set by hand. Hand-set freshness thresholds are the classic maintenance trap: someone sets six hours, the pipeline moves to hourly, and the alert is now six hours late forever. Freshness monitoring is the single highest-value automated check most teams can turn on, which is why it is the first of the 5 pillars of data observability.

Validity: does it conform to the rules?

Validity asks whether a value conforms to its defined format, type, range, or allowed set. A date of 2026-13-45, a US state code of "ZZ", an order status outside the seven you support, a percentage of 340, an email with no at sign: all invalid, regardless of whether they are accurate. Validity is cheap to check and worth checking, because invalid values usually indicate an upstream change rather than a one-off typo.

The measure is straightforward: percent of values passing the rule. The judgment call is which rules to write. A useful heuristic is to write validity rules only where an invalid value would silently produce a wrong answer rather than an obvious error. A malformed date that makes a job crash does not need a rule, because you will find out. A currency field that starts arriving in cents instead of dollars passes every type check and quietly multiplies your revenue by 100, and that is exactly where a range or distribution check earns its keep.

Uniqueness: is each thing represented once?

Uniqueness asks whether a single real-world entity appears exactly once. Duplicates inflate counts, double-count revenue, and send the same customer two of everything. They usually come from a small number of predictable causes: a pipeline retry that reloaded a batch, a join that fanned out because the join key was not as unique as assumed, or two source systems that both created a record for the same entity with slightly different spellings.

Measure it as duplicate records on an agreed business key divided by total records. The hard part is agreeing the key, and it is genuinely hard when the same customer exists as "Acme Corp", "Acme Corporation", and "ACME Corp. Inc" across three systems. That fuzzy version of the problem is entity resolution and it is a different discipline from monitoring. The version worth automating is the exact-key one, which catches the retry and the fan-out, and those are the two that cause most real duplicate incidents. The same failure mode shows up all over operational systems, not just analytics, which is why teams that automate accounts payable processing spend so much effort on duplicate invoice detection before anything reaches the ledger.

How do you measure data quality dimensions?

Pick a small number of tables that matter, define one measure per dimension for each, compute them on a schedule, and track them over time rather than against a fixed pass mark. The trend is the signal. A completeness figure of 94 percent means nothing on its own and means a lot if it was 99 percent every day for six months.

Do them in this order, because it front-loads the value:

1. Timeliness on every table that feeds something a human looks at. Cheapest to compute, highest damage when it fails, and it needs no business knowledge.
2. Completeness at both row-count and column level, with the expected range learned from history.
3. Uniqueness on the primary business key of your core entities: customers, orders, transactions.
4. Validity on the fields where an invalid value would go unnoticed rather than crash something.
5. Consistency on the two or three reconciliations that finance or operations already care about.
6. Accuracy last, and only where you genuinely have a reference source. If you do not, say so.

Once you have the measures, the reporting question is separate. Composite "data quality scores" that blend all six into one number are popular with executives and nearly useless to engineers, because a score of 92 does not tell you what to fix. If you want the formulas and the traps inside each calculation, we covered those in detail in our guide to data quality metrics.

Are there only 6 data quality dimensions?

No, and this trips people up when they compare two frameworks and get different lists. Six is the most common working set, but DAMA and various regulators define more, and you will regularly see integrity, currency, precision, relevance, accessibility, conformity, and reasonableness added. Some of these are genuinely distinct. Integrity, meaning referential integrity across related tables, is really a specific form of consistency. Currency, meaning how up to date a value is, overlaps heavily with timeliness.

The number matters far less than the coverage. If your framework catches missing data, late data, malformed data, duplicated data, contradictory data, and wrong data, you have the space covered whatever you call the categories. Adding a seventh and eighth dimension to a program where nobody has yet turned on freshness monitoring is a way of looking busy.

Which dimensions can a tool monitor without me writing rules?

Completeness, timeliness, and uniqueness on a known key can all be monitored with no rules written, because each has an obvious statistical baseline: null rate, load interval, and duplicate rate all have a normal for a given table that software can learn from history. Distribution shifts, which cut across accuracy and validity, can also be detected without rules by watching how a column's values move over time. Validity rules and consistency reconciliations both need a human to state the rule, because no amount of history tells a machine that an order total must equal the sum of its lines.

That division is the practical reason data teams end up with two things rather than one. Automated monitoring covers the dimensions with learnable baselines across every table, including the hundreds nobody had time to write tests for. A testing framework covers the handful of business rules that only a person can state. Dataobservability does the first half: it connects read-only to Snowflake, BigQuery, Databricks, or Redshift, profiles your tables, and monitors freshness, volume, schema, and distribution automatically, with column-level lineage so an alert arrives with its downstream impact attached. Pricing is on the page, from 99 dollars a month, and setup is a read-only connection.

Where to start this week

Take your ten most-used tables. Turn on freshness and row-count monitoring on all ten, which needs no business input and will probably surface something within a fortnight. Agree the business key on your three core entities and check for duplicates. Write validity rules only for the fields where a bad value would slip through silently. Then, and only then, have the conversation about accuracy and what reference source you would need to measure it honestly. Six dimensions is a useful map. Four of them you can have running before the end of the week.