How to measure data quality: KPIs, thresholds and dashboards

Why measuring data quality is not optional

Without metrics, data quality is a conversation of opinions. The engineering team thinks the data is fine. The business team thinks it's bad. Management doesn't know who to believe. No one is right or wrong because no one has measured anything.

With metrics, the conversation changes: the completeness rate of the Customer domain is 91% this week, below the 99% threshold agreed with the commercial team, and there are 847 records with the EMAIL field empty that block next Monday's renewal campaign. That's an actionable conversation.

Moreover, in the context of the AI Act, quality measurement ceases to be a good practice and becomes a documentable obligation. Article 10 of the Regulation requires that training data for high-risk AI systems be relevant, representative and free from errors as far as possible, with evidence of the analyses performed. Without recorded metrics, that evidence does not exist.

The 7 fundamental data quality KPIs

There are dozens of possible metrics, but seven cover 90% of real use cases. These are the ones that should be in any quality dashboard that aims to be useful for the business and auditable for the regulator:

1. Completeness rate

Measures what percentage of records have values in mandatory fields. It is the most basic metric and the most frequently ignored. A mandatory field with 15% nulls is not a minor technical problem: it is an unreliable data source for any analysis that depends on that field.

Formula: (Records without nulls in mandatory fields / Total records) × 100

Reference threshold: ≥ 99% for key fields. ≥ 95% for relevant business fields.

2. Accuracy rate

Measures what percentage of values correctly reflects reality. It is the hardest dimension to measure automatically because it requires a source of truth to compare against. In practice it is approximated by validating against master reference tables or through defined business rules.

Formula: (Valid records against source / Total records) × 100

Reference threshold: ≥ 98%.

3. Duplicate rate

Measures what percentage of records are duplicated. A 2% duplicate rate in a customer table with one million records is 20,000 customers receiving double communications, generating double cost and contaminating any behaviour or segmentation analysis.

Formula: (Duplicate records / Total records) × 100

Reference threshold: < 0.5%.

4. Consistency rate

Measures what percentage of records do not contain contradictions between fields of the same record or between related tables. A customer with country "ES" and telephone prefix "+1" is an inconsistent record. A cancellation date earlier than the creation date is also inconsistent.

Formula: (Records without contradictions / Total records) × 100

Reference threshold: ≥ 99%.

5. Format validity rate

Measures what percentage of values comply with defined format, range and domain rules. A tax ID with incorrect format, a postcode of six digits or a date 30/02 are validity problems that an automated test can detect in milliseconds.

Formula: (Records with correct format / Total records) × 100

Reference threshold: ≥ 99.5%.

6. Update latency

Measures the time from when data changes in the source system to when it is available in the consumption system. Correct data that arrives with 48 hours delay is useless data for the decisions that depended on it. This metric is especially critical in operational domains like inventory, pricing or availability.

Metric: Average delay time relative to the agreed SLA per domain.

7. Overall Quality Index (DQI)

The weighted average of all the above dimensions, adapting the weight of each according to the importance for the specific domain. It is the KPI communicated to management and the one that allows comparing domains with each other and tracking evolution over time.

Reference threshold: ≥ 95% as a general objective. Domains with AI training data should aim for ≥ 98%.

How to define thresholds: the most frequent mistake

The most frequent mistake in data quality programmes is defining thresholds without business input. The technical team decides that 95% completeness is acceptable, implements it as an alert and six months later the commercial team discovers that that 5% of incomplete records are exactly the highest-value customers, who have been missing communications since the system was implemented.

The correct process is the inverse: the business defines what impact each percentage point of non-compliance has, and from that the threshold is established. If an incomplete email field blocks a campaign with an estimated ROI of €50,000, the completeness threshold for that field should be 99.9%, not 95%.

Data SLAs: the difference between a threshold and a commitment

A quality threshold without a formal SLA is a number that no one defends when there is time pressure. A data SLA is a documented agreement between the data team and the business area that establishes four elements:

• The quality threshold per dimension and field.
• The measurement frequency and alert system.
• The person responsible for receiving the alert and the maximum response time.
• The remediation process and the incident closure criteria.

The quality dashboard: what it should show and to whom

A data quality dashboard is not a technical pipeline monitoring dashboard. It is a management tool that different profiles use with different objectives. The design must reflect this difference: