How to Measure Data Quality: KPIs, Thresholds and Dashboards

Why Measuring Data Quality Isn't Optional

Without metrics, data quality is a conversation of opinions. Engineering thinks the data is fine. The business thinks it's bad. Leadership doesn't know who to believe. Nobody is right or wrong because nobody has measured anything.

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

Furthermore, in the context of the AI Act, quality measurement stops being a best practice and becomes a documentable obligation. Article 10 of the Regulation requires that training data for high-risk AI systems be relevant, representative, and as error-free as possible, with evidence of the analyses performed. Without recorded metrics, that evidence doesn't exist.

The 7 Fundamental Data Quality KPIs

There are dozens of possible metrics, but seven cover 90% of real-world 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 a value in mandatory fields. It's the most basic metric and the most frequently ignored. A mandatory field with 15% nulls isn't a minor technical problem: it's an unreliable data source for any analysis depending 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 reflect reality. It's the hardest dimension to measure automatically because it requires a source of truth to validate against. In practice, it's approximated by validating against master reference tables or defined business rules.

Formula: (Records valid 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 a million records means 20,000 customers receiving double communications, generating double cost, and contaminating any behavioral or segmentation analysis.

Formula: (Duplicate records / Total records) × 100

Reference threshold: < 0.5%.

4. Consistency Rate

Measures what percentage of records contain no contradictions between fields in the same record or across related tables. A customer with country "ES" and phone prefix "+1" is an inconsistent record. So is a cancellation date earlier than the signup date.

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. An incorrectly formatted tax ID, a six-digit postal code, or a February 30th date are validity problems an automated test can catch 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 until it's available in the consuming system. Correct data arriving 48 hours late is useless for the decisions that depended on it. This metric is especially critical for operational domains like inventory, pricing, or availability.

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

7. Overall Data Quality Index (DQI)

The weighted average of all the above dimensions, adapting each one's weight according to its importance for the specific domain. It's the KPI communicated to leadership and the one that lets you compare domains and track evolution over time.

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

How to Set Thresholds: The Most Common Mistake

The most common mistake in data quality programs is setting thresholds without business input. The technical team decides 95% completeness is acceptable, implements it as an alert, and six months later the sales team discovers that 5% of incomplete records are exactly the highest-value customers, who haven't received any communications since the system was implemented.

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

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

• What decisions depend on this data? — identify the real use case.
• What happens if the data fails? — quantify the business impact.
• What confidence level do you need to operate? — 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 nobody defends under 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.
• Who receives the alert and the maximum response time.
• The remediation process and incident closure criteria.

Without all four elements, the SLA doesn't work. The most common failure mode is having a threshold and an alert but no clear owner: the alert arrives, nobody knows who should 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 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 as the ingestion tool, these validations are configured as transformation rules in the loading process.

At Transformation (Pipeline)

Tests integrated into dbt models, Great Expectations rules, or Soda checks that run automatically on every pipeline execution. If a test fails, the pipeline stops or fires an alert depending on the configured criticality level. Each run's results 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 showing 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 to Show and to Whom

A data quality dashboard isn't a technical pipeline monitoring dashboard. It's a management tool that different roles use with different goals. The design must reflect that difference:

The most common design mistake is building a single dashboard with all metrics for all roles. 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 underlying data model, adapted to each role, are infinitely more effective.

What Tools to Use for Measuring and Visualizing

La elección de herramienta depende del stack. Estas son las combinaciones más efectivas según el entorno:

For a deeper look at data quality management tools and how they fit into the governance framework, see Data Quality Management: What It Is, How to Measure It and Why the AI Act Cares.

Adoption Metrics for the Quality System Itself

There's a set of metrics many data quality programs forget: metrics about the quality system itself. Without them, you don't know if the program actually works or just exists on paper.

• Rule coverage: what percentage of data assets have 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 reopen within the next 30 days. A high rate indicates you're remediating the symptom, not the root cause.
• 90-day DQI evolution: the trend matters more than the point-in-time value. A 94% DQI that's been climbing for three months is better than a 97% one that's been dropping 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 occurs or exactly how to remediate it within each organization's specific context.

The Customers domain's duplicate rate is 3.2%. The dashboard shows that. 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 solution isn't technical at first: it's defining the business rule for what makes two records the same customer, agreeing on it across the teams feeding the CRM, and only then implementing deduplication. That definition and agreement process is the governance work no tool automates.

Conclusion: Measuring Is the First Step, Not the Last

Implementing data quality KPIs doesn't fix quality problems: it makes them visible. Visibility is a 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 through improvement cycles that don't close in weeks.

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

Checklist: Data Quality Measurement System

• The 7 fundamental KPIs defined per critical domain.
• Thresholds formally agreed with Data Owners, not unilaterally decided by the technical team.
• Data SLAs documented with threshold, frequency, owner, and remediation process.
• Measurement at the three pipeline points: ingestion, transformation, and consumption.
• Quality-as-code tests integrated into the CI/CD process (dbt, Soda, Great Expectations).
• Results from each run stored and accessible for historical analysis.
• 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 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 indicator 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%, validity ≥ 99.5%, and an overall DQI ≥ 95%. For high-risk AI training data, 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 dbt tests, Soda, or Great Expectations results are the most common combinations. With Snowflake and dbt, test results are sent to a table in Snowflake and visualized in Power BI with no extra 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. Alerts should fire in real time when the threshold is breached, not at the next reporting cycle.

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

The threshold is the minimum acceptable value of a metric. The SLA is the formal agreement establishing that threshold, the measurement frequency, the alert process, and the maximum remediation time. A threshold without an SLA is just a number nobody defends under time pressure.