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%.

The conversation with the business to define thresholds follows this structure:

• What decisions depend on this data? — identify the real use case.
• What happens if the data fails? — quantify the impact in business terms.
• What level of confidence do you need to operate with? — define the minimum acceptable threshold.
• How quickly do you need to know? — define the measurement frequency and alert SLA.

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.

Without all four elements, the SLA doesn't work. The most frequent failure case is having a threshold and an alert but no clear owner: the alert arrives, nobody knows who's supposed to act, and the problem persists until someone catches it in production.

Technical implementation: where to measure in the pipeline

Quality should be measured at three points in the pipeline, not just one:

At ingestion (source)

Validations at the data's entry point: forms, APIs, upload files. The goal is to reject or flag incorrect data before it contaminates the system. In environments using Airbyte or Fivetran for ingestion, these validations are configured as transformation rules in the load process.

At transformation (pipeline)

Tests built into dbt models, Great Expectations rules or Soda checks that run automatically on every pipeline run. If a test fails, the pipeline stops or emits an alert depending on the configured criticality level. Results from every run are stored and feed the quality dashboard.

At consumption (Data Warehouse / semantic layer)

Validated views in Snowflake or BigQuery that only expose records meeting the defined quality thresholds. In Power BI, calculated metrics show the percentage of valid data in real time alongside the business figure. The analyst sees the number and also sees the confidence level of the data behind that number.

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:

The most frequent design mistake is building a single dashboard with every metric for every profile. The result is a panel nobody uses because it's too technical for the business and too incomplete for the technical team. Three distinct views of the same data model, adapted to each profile, are infinitely more effective.

Which tools to use to measure and visualise

The choice of tool depends on the stack. These are the most effective combinations by environment:

For a deeper look at data quality management tools and how they fit into the governance framework, see the article Data quality management: what it is, how to measure it and why it matters to the AI Act.

Metrics for the quality system itself

There's a set of metrics many data quality programmes forget: metrics about the quality system itself. Without them, you don't know whether the programme actually works or simply exists on paper.

• Rule coverage: what percentage of data assets has at least one quality rule defined.
• Average incident resolution time: from detection to closure. If it systematically exceeds the agreed SLA, the remediation process isn't working.
• Recurrence rate: what percentage of closed incidents reopens within the following 30 days. A high rate indicates the symptom is being remediated, not the root cause.
• 90-day DQI trend: the trend matters more than the point-in-time value. A 94% DQI that's been rising for three months is better than a 97% that's been falling for two.

The question the dashboard doesn't answer

A well-built data quality dashboard answers how much, where and with what trend. What it doesn't answer is why the problem happens or exactly how to remediate it in each organisation's specific context.

The Customer domain's duplicate rate is 3.2%. That's what the dashboard shows. But if that 3.2% comes from an integration with a legacy CRM that generates different IDs for the same customer depending on the entry channel, the fix isn't a technical one in the first instance: it's defining the business rule for what makes two records the same customer, agreeing it between the teams that feed the CRM, and only then implementing deduplication. That process of definition and agreement is the governance work no tool automates.

Conclusion: measuring is the first step, not the last

Implementing data quality KPIs doesn't solve quality problems: it makes them visible. Visibility is the necessary condition for improvement, but it isn't sufficient. What turns measurement into real improvement is having owners with the mandate to act on what the dashboard shows, defined remediation processes, and the patience to work in improvement cycles that don't close in weeks.

To understand how to structure the roles that manage data quality, see the article Roles and Responsibilities of a Data Governance Team.

Checklist: a data quality measurement system

• The 7 fundamental KPIs defined per critical domain.
• Thresholds formally agreed with Data Owners, not decided unilaterally by the technical team.
• Data SLAs documented with threshold, frequency, owner and remediation process.
• Measurement at all three points of the pipeline: ingestion, transformation and consumption.
• Quality tests as code integrated into the CI/CD process (dbt, Soda, Great Expectations).
• Results from every run stored and accessible for historical tracking.
• Dashboard with three distinct views: Data Steward, Data Owner and leadership.
• Automatic alerts configured with a clear recipient and response SLA.
• Adoption metrics for the system itself: coverage, resolution time and recurrence.
• Quarterly threshold review with the business areas.

Frequently asked questions

What are the most important KPIs for measuring data quality?

The seven fundamental KPIs are: completeness rate, accuracy rate, duplicate rate, consistency rate, format validity rate, update latency and the overall Data Quality Index (DQI). The DQI is the weighted average of all of them and the one communicated to leadership.

What data quality threshold is acceptable?

Thresholds depend on the domain and use case. As a general reference: completeness ≥ 99%, accuracy ≥ 98%, duplicates < 0.5%, consistency ≥ 99%, format validity ≥ 99.5% and an overall DQI ≥ 95%. For training data feeding high-risk AI systems, the AI Act requires stricter, explicitly documented thresholds.

What tool should I use to build a data quality dashboard?

Power BI or Tableau connected to the results of dbt tests, Soda or Great Expectations are the most common combinations. If the stack is Snowflake with dbt, test results can be sent to a metadata table in Snowflake and visualised directly in Power BI with no additional infrastructure.

How often should I measure data quality?

Monitoring should be continuous and automatic on every pipeline run. Reporting can be daily for Data Stewards, weekly for Data Owners and monthly for leadership. Alert thresholds should trigger in real time when the defined threshold is breached, not on the next reporting cycle.

What's the difference between a data SLA and a quality threshold?

The quality threshold is the minimum acceptable value of a metric (e.g. completeness ≥ 99%). The data SLA is the formal agreement with the business that establishes that threshold, the measurement frequency, the alert process and the maximum remediation time. A threshold without an SLA is just a number; an SLA without a threshold is an empty promise.