Data Quality Dimensions and Metrics: How to Measure Data Quality with a Scorecard

Data quality is measured by scoring a table against named dimensions, then tracking each score over time. The six most commonly used dimensions are completeness, uniqueness, timeliness, validity, accuracy and consistency. Five of them can be computed directly in SQL against the table itself. Accuracy cannot, because it requires an external source of truth, which is why most published data quality scores quietly leave it out.

That last point is the one worth carrying into your own program. It is easy to build a scorecard that produces a confident number every morning and still tells you nothing, and the usual reason is that it measures the five cheap dimensions and calls the result "data quality".

What are the 6 dimensions of data quality?

Here are the six, with the metric that actually computes each one. The formulas assume a single table with a load timestamp, which covers most warehouse cases.

Is there a standard list of data quality dimensions?

No, and this is worth knowing before somebody in a governance meeting insists there is.

The "six dimensions" almost every article repeats come from a single trade body paper: DAMA UK's The Six Primary Dimensions for Data Quality Assessment, published by its working group in October 2013. It is a good, practical paper and it deserves its influence. It is not a standard, and DAMA UK did not present it as one.

The actual international standard is ISO/IEC 25012, part of the SQuaRE family, and it does not define six characteristics. It defines fifteen, split into inherent and system-dependent views: accuracy, completeness, consistency, credibility, currentness, accessibility, compliance, confidentiality, efficiency, precision, traceability, understandability, availability, portability and recoverability. Several of those, availability, portability and recoverability in particular, are properties of the system holding the data rather than the data itself.

So when you see "the 7 dimensions of data quality" or a vendor page listing eight, nobody is wrong. They are drawing different lines around an unstandardized concept. The practical consequence: pick your dimension list once, write down the definition of each, and stop relitigating it. A team that measures four dimensions consistently for a year learns far more than one that spends that year debating whether integrity is distinct from consistency.

How do you measure data quality?

You turn each dimension into a query that returns a number between 0 and 1, run it on a schedule against a defined slice of rows, and store the result with a timestamp so you can see the trend. The scoring itself is not hard. The two decisions that make it useful or useless are the denominator and the threshold.

A completeness check over the whole table is the most common mistake in this whole exercise. If a table holds four years of history and last night's load arrived with 30% of its email addresses missing, a completeness score across all rows moves from 0.98 to 0.976 and no alert fires. Score the load window, not the table:

-- Completeness of a required column, scoped to yesterday's load
SELECT
  COUNT_IF(email IS NOT NULL AND email <> '') / NULLIF(COUNT(*), 0) AS completeness
FROM analytics.customers
WHERE loaded_at >= DATEADD(day, -1, CURRENT_TIMESTAMP());

Validity is the same shape with a rule instead of a null test, and it is where most real defects surface because a badly formed value passes a NOT NULL constraint happily:

-- Validity: does the value conform to its rule?
SELECT
  COUNT_IF(REGEXP_LIKE(email, '^[^@\\s]+@[^@\\s]+\\.[^@\\s]+$')) / NULLIF(COUNT(*), 0) AS valid_email_rate,
  COUNT_IF(order_total >= 0)                                    / NULLIF(COUNT(*), 0) AS valid_total_rate
FROM analytics.orders
WHERE loaded_at >= DATEADD(day, -1, CURRENT_TIMESTAMP());

Uniqueness is a duplicate rate on the business key, which is usually not the surrogate primary key. Note that on most cloud warehouses a declared PRIMARY KEY is metadata only and is not enforced, so the constraint being present tells you nothing:

-- Uniqueness on the business key
SELECT COUNT(DISTINCT order_reference) / NULLIF(COUNT(*), 0) AS uniqueness
FROM analytics.orders;

Timeliness is a lag against an SLA rather than a ratio, and it is the one metric most worth alerting on directly, because a stale table is wrong in a way no other check catches. If the pipeline did not run, every other score stays green on yesterday's data.

Why accuracy is the dimension nobody measures

Accuracy asks whether a record is correct about the real world. A customer's address can be complete, valid, unique, timely and consistent across every system you own, and still be the address they moved out of in 2023. No query against the warehouse can detect that, because the warehouse is not the thing being described.

Measuring accuracy honestly requires one of three things: a trusted reference dataset to join against, a sampled manual audit, or a feedback signal from the real world such as returned mail or failed payments. All three cost something, which is why accuracy is usually asserted rather than measured.

The pragmatic approach is to measure it on a sample, on the handful of fields where being wrong is expensive, and to accept a slow cadence. Auditing 300 sampled customer records a quarter against a reference source gives you a defensible accuracy estimate. Claiming 99.4% accuracy from a query that never left the database does not.

It also pays to look upstream, because accuracy is mostly lost before the data ever reaches the warehouse. A surprising amount of business data still arrives as a PDF or spreadsheet attached to an email and gets re-keyed by a person, and teams that pull those attachments into structured rows automatically remove an entire class of transcription error at the point it would otherwise be introduced. Fixing the intake is cheaper than detecting the defect six models downstream.

How do you build a data quality scorecard?

A scorecard rolls the individual metrics into one number per table so that non-engineers can read it. The rollup is where most scorecards go wrong, in a specific and predictable way: an unweighted average across ten checks produces a score that essentially never moves, because a single failing check shifts it by ten percent of its range and no one notices.

Two rules keep a scorecard alive:

• Weight by consequence, not by count. The completeness of the revenue field is not worth the same as the completeness of a middle name column.
• Let critical checks veto. If a check is genuinely critical, a failure should force the table's score to fail outright rather than being averaged away.

A workable structure looks like this:

Notice that the three veto checks are the three that are cheap to compute and unambiguous when they fail. That is not a coincidence. Reserve the veto for checks where a failure has exactly one interpretation.

What is a good data quality score?

There is no universal target, and any vendor quoting one is guessing about your business. A 99% completeness rate is excellent for free-text profile fields and unacceptable for a payment amount, where the only tolerable rate is 100%. Set the threshold per check from the cost of a defect getting through, then judge the program on the trend and on the time it takes to detect a regression, not on the absolute number.

The two measures that actually correlate with a healthier data platform are boring ones: how long a defect survives before someone notices it, and what fraction of defects are found by a check rather than by a person looking at a dashboard. A team that moves detection from three days to twenty minutes has improved more than a team whose composite score went from 0.94 to 0.97.

Which data quality metrics should you alert on?

Alert on the checks where a failure has a clear owner and a clear action. Everything else belongs on a dashboard that somebody reviews weekly. Freshness SLA breaches, row count collapses, and null rates on veto columns meet that bar. A validity score drifting from 0.997 to 0.994 does not, and paging someone for it is how a team learns to ignore the channel.

The harder problem, once alerting works, is knowing what a failure affects. A completeness check firing on a staging table means very little on its own, and means a great deal if that column feeds three finance dashboards. That is a lineage question rather than a metrics question: column-level lineage maps which downstream models and reports read the field that just failed, so a triage decision takes seconds instead of an afternoon of grep. It works the other direction too, letting you run impact analysis before a schema change ships rather than measuring the damage afterward.

Getting the checks running is the first step, and if you are choosing where they should live, our comparison of data quality tools covers the field, while automated data quality monitoring goes deeper on scheduling and alert routing. For a warehouse-specific walkthrough, Snowflake data quality checks shows the same metrics implemented natively, and data quality vs data integrity untangles two terms that governance documents routinely mix up.