Coverage Metric

Coverage is measured at different levels of granularity within a data ecosystem.

• Table Coverage: The percentage of tables in a database or data warehouse that have at least one active data quality check.
• Column Coverage: The percentage of columns within a monitored table that are covered by specific validation rules (e.g., null checks, format validation).
• Pipeline Coverage: The percentage of data transformation jobs or workflows that have embedded quality gates.

High column coverage within critical tables is often more valuable than 100% table coverage with minimal checks.

Raw coverage percentage is insufficient without considering the density and criticality of checks.

• Check Density: The average number of quality checks (e.g., for freshness, validity, uniqueness) applied per covered asset. A table with ten checks has higher assurance than one with a single null check.
• Criticality Weighting: Coverage metrics should be weighted by business importance. A 90% coverage on mission-critical revenue tables is more significant than 100% coverage on low-impact reference data.

Effective coverage reporting segments metrics by data domain, pipeline tier (e.g., bronze, silver, gold), and service level objective (SLO) tier.

Achieving high coverage relies on automated profiling and rule inference, as manual configuration does not scale.

• Automated Profiling: Tools scan schema, statistical distributions, and data lineage to suggest relevant quality checks (e.g., detecting a column that should never be null).
• Declarative Rule Templates: Engineers define rules in code (e.g., using SQL or YAML) that are automatically applied to new columns matching a pattern.
• Coverage Gaps: The inverse of the coverage metric highlights unmonitored assets, which should be prioritized based on risk assessment and usage.

Coverage is a leading indicator for Data Service Level Objectives (SLOs). You cannot reliably meet an SLO for data freshness or accuracy without monitoring coverage of the underlying assets.

• Prerequisite for SLOs: A Data SLO like "99.9% of records in Table X are valid" requires a validity check to be in place—this is coverage.
• Error Budget Impact: Gaps in coverage increase the risk of undetected breaches consuming the data error budget.
• Progressive Enhancement: Teams often set incremental coverage targets (e.g., 70% → 90% → 95%) for critical pipelines as part of SLO adoption.

Coverage enables the measurement of core data quality dimensions.

• Completeness & Validity: A null rate or format validation check directly measures these dimensions, but only if coverage exists.
• Freshness & Latency: A timestamp-based freshness check must be configured on a table to measure these timeliness metrics.
• Drift Detection: Data drift and schema drift detection require baseline statistical profiles and schema snapshots, which are forms of coverage.

Coverage is the mechanism that operationalizes abstract quality dimensions into measurable metrics.

Coverage metrics are typically generated by data observability platforms or specialized data quality frameworks.

• Centralized Metadata Store: These tools maintain a catalog of assets, checks, and execution results to calculate coverage percentages.
• Programmatic APIs: Coverage can be queried via API to integrate with CI/CD pipelines, preventing deployment if coverage on modified assets falls below a threshold.
• Example Workflow: A pipeline adds a new column; a declarative rule for NOT NULL is automatically applied based on its name (user_id); coverage for that table's columns increases from 85% to 88%.

A core data quality dimension that measures the proportion of expected data values that are present and non-null. While coverage assesses if a data asset is monitored, completeness evaluates the data within it.

• Key Metric: Null Rate, which calculates the percentage of missing values.
• Example: A customer email column with a 5% null rate has a 95% completeness score.
• Relationship: High coverage ensures completeness checks are applied; poor completeness indicates a data issue within a covered asset.

An automated checkpoint within a data pipeline that evaluates metrics and can halt processing if thresholds are violated. Coverage metrics determine which assets pass through these gates.

• Function: Acts as a circuit breaker for bad data.
• Implementation: Often uses SQL assertions or library-based checks (e.g., Great Expectations, Soda Core).
• Process: A pipeline with 100% table coverage might have quality gates on freshness, row count, and key column validity before allowing data to propagate downstream.

A composite, business-facing score that synthesizes technical metrics—including coverage—to indicate the overall fitness-for-use of a data asset or pipeline.

• Composition: Often a weighted aggregate of coverage, freshness, accuracy, and volume stability scores.
• Purpose: Provides a single, interpretable gauge of data trustworthiness for non-technical stakeholders.
• Example: An asset with 100% coverage but failing freshness checks would have a moderate health index, signaling monitored but stale data.

A fundamental category used to characterize and measure data quality. Coverage is a dimension focused on the governance and observability process itself, rather than the intrinsic properties of the data.

• Intrinsic Dimensions: Accuracy, Completeness, Uniqueness (assess the data itself).
• Operational/Process Dimensions: Timeliness, Coverage (assess the pipeline and monitoring).
• Framework: The DAMA DMBOK lists six core dimensions; coverage is often added in modern observability frameworks to measure control scope.

A target level of reliability for a data product. Coverage metrics are prerequisites for defining and measuring SLOs, as you cannot guarantee the quality of unmonitored data.

• Relationship: A Data SLO for "99.9% freshness" is only meaningful for tables under freshness monitoring (i.e., within coverage scope).
• Error Budget: The allowable amount of SLO violation. Poor coverage can lead to undetected breaches consuming the error budget.
• Implementation: Teams often set SLOs like "95% of critical tables covered by validity checks."