The Dimensions of Data Quality

“The numbers are wrong”: this is the sentence that ruins trust in a dashboard. Behind it, the causes vary: a customer counted twice, yesterday’s sales not yet loaded, a mistyped postal code. To act, you first need to name the problem and measure it. The dimensions of data quality give this common vocabulary.

Quality depends on the use

Data is not good or bad in absolute terms: it is fit or unfit for a use. A customer file without phone numbers suits an emailing campaign, not a calling campaign. Before measuring, you therefore ask: who uses this data, for what, and what error would have consequences?

The six usual dimensions

Frameworks do not all list exactly the same dimensions, but these six come up everywhere:

Dimension	Question	Example of a defect
Completeness	Is the value filled in?	empty email
Validity	Does it respect the expected format or domain?	4-digit postal code, email without @
Accuracy	Does it match reality?	wrong address, well formed
Consistency	Is it compatible with other data?	“France” here, “FR” elsewhere; delivery date before the order
Uniqueness	Is each real-world object present only once?	same customer entered twice
Freshness (timeliness)	Is it recent enough for the use?	yesterday’s sales missing at 9 AM

Two frequent confusions:

• validity and accuracy: [email protected] is a valid email, but if it belongs to someone else, it is inaccurate. Validity is checked with a rule; accuracy often requires a reference source or human verification;
• uniqueness and technical duplicates: two identical rows are an obvious duplicate; two rows “Marie Dupont” and “M. Dupont” with the same email are the same customer, which is harder to detect.

Some teams add integrity (references point to existing objects), precision (a sufficient level of detail), or accessibility.

From requirement to measurable rule

A vague requirement (“customer data must be clean”) cannot be measured. You translate it into rules:

• Completeness: “email is filled in for at least 98% of active customers”;
• Validity: “the French postal code has exactly 5 digits”;
• Plausibility (a verifiable form of accuracy): “the date of birth is in the past and after 1900”;
• Uniqueness: “no email is shared by two active customers”;
• Freshness: “the previous day’s sales are available every day at 7 AM”.

Each rule has a threshold (100% is not always realistic or necessary) and an owner.

Computing an indicator

A quality indicator is a simple ratio: compliant rows / checked rows. Mind the denominator: the validity of an email is computed on the emails that are filled in, otherwise you mix completeness and validity.

SELECT
  100.0 * COUNT(email) / COUNT(*)                                AS pct_email_renseigne,
  100.0 * SUM(CASE WHEN email LIKE '%_@_%' THEN 1 ELSE 0 END)
        / COUNT(email)                                          AS pct_email_valide
FROM clients;

In SQL, COUNT(column) ignores NULLs: this is handy for completeness. Watch out for empty strings, which are not NULL: depending on the source, a missing email can be '', NULL, or 'n/a'.

Tracking quality over time

A one-off measurement is not enough: you compute the indicators at every load and record them. A chart of the trend shows whether quality is degrading (new version of a form, new source) and whether corrective actions work. Transformation tools (dbt tests) and specialized tools (Great Expectations, Soda, or the quality features of cloud platforms) automate these checks. But the choice of rules and thresholds remains a business decision, made with the users of the data.