Data Quality Scorecard
Score data quality based on completeness, accuracy, and consistency rules. Enter values for instant results with step-by-step formulas.
Formula
DQI = (Coverage% × 0.4) + (Reliability% × 0.6)
The Data Quality Index (DQI) balances two opposing forces: Coverage (are we testing enough tables?) and Reliability (are those tests actually passing?). High coverage with high failures is bad. Low coverage with zero failures is also bad (blind spots).
Worked Examples
Example 1: Startup Pipeline
Problem:10 Tables, 2 Covered (20%), 0 Failures
Solution:Coverage 20%, Reliability 100%. DQI = (20*0.4) + (100*0.6) = 68 (Fair).
Result:68/100 (Blind Spots)
Example 2: Mature Enterprise
Problem:100 Tables, 90 Covered (90%), 10 Critical Failures / 500 Rules
Solution:Coverage 90%. Failures impact ~6%. Reliability ~94%. DQI = (90*0.4) + (94*0.6) = 92.4.
Result:92.4/100 (Excellent)
Frequently Asked Questions
What is Data Quality Coverage?
The percentage of your data assets (tables, streams, dashboards) that have at least one automated quality check (e.g., null check, uniqueness, freshness).
What counts as a 'Critical' failure?
A failure that breaks downstream consumers—e.g., NULLs in a Primary Key, duplicate IDs, or data not arriving on time (Freshness SLA breach).
How many rules should I have per table?
Quality over quantity. Start with the 'Big 3': Freshness, Volume (row count), and Schema. Then add semantic rules (e.g., 'Order Total > 0'). 3-5 rules per critical table is a good baseline.
What is Data Observability?
The ability to understand the health of your data system by monitoring metrics like Freshness, Distribution, Volume, Schema, and Lineage. It's 'APM for Data'.
Does this replace unit testing?
No. Unit tests check logic *transformation*. Data quality tests check the *state* of the data in production. You need both.
What is 'Reliability Engineering' for Data?
Applying DevOps principles to data. Setting SLIs (Service Level Indicators) and SLOs (Objectives) for data quality and pipeline uptime.
Is my data stored or sent to a server?
No. All calculations run entirely in your browser using JavaScript. No data you enter is ever transmitted to any server or stored anywhere. Your inputs remain completely private.
Background & Theory
The 6 Dimensions of Data Quality
- Accuracy: Does it reflect reality?
- Completeness: Is all the data there? (No gaps).
- Consistency: Is it the same across systems?
- Timeliness: Is it available when needed? (Freshness).
- Validity: Does it follow the format rules? (Regex).
- Uniqueness: Are there duplicates?
Building a Scorecard
A single "Good/Bad" metric is hard for data. This calculator splits it into Coverage (Breadth) and Reliability (Depth). This prevents the "Gaming the system" problem where a team has 100% reliability because they only test 1 table.
Practical Tips
- Start with Critical Assets: Don't try to test all 500 tables. Identify the 20 "Gold" tables that power the CEO's dashboard.
- Monitor Volume Anomalies: Sudden drops (partial loads) or spikes (duplicates) in row counts are the easiest way to catch issues.
- Differentiate Freshness: A daily report table being 1 hour late is a failure. A real-time stream being 1 hour late is a catastrophe. Set dynamic thresholds.
History
The "Garbage In, Garbage Out" Era
In traditional warehousing (1990s), data quality was handled by strict schema constraints (ETL). If data didn't fit the type, the load failed. This protected quality but killed agility. Analysts waited weeks for simple columns.
The ELT & Data Lake Shift
With Hadoop and Cloud Warehouses (2010s), we moved to ELT (Extract, Load, Transform). We loaded raw data first and transformed later. This increased speed but created "Data Swamps"—massive repositories of untested, unreliable, and duplicated data.
Data Reliability Engineering (2020s)
Inspired by SRE (Site Reliability Engineering) in software, the data world adopted "Data Observability." Tools like Great Expectations and Monte Carlo normalized the idea of "Data Contracts" and continuous testing in production. Data Quality is no longer a one-time audit; it's a continuous operational metric.
Common Misconceptions
- Myth: "The data source is responsible for quality." Reality: The pipeline owner owns the quality delivered to the business. Defensive coding is required.
- Myth: "We fix it in the BI layer." Reality: Fixing data in Tableau/Looker creates technical debt and inconsistent logic across reports. Fix it upstream.