Data Quality Monitoring: Schema Drift, Null Rates, Freshness SLAs, and Anomaly Detection for Analytics

Analytics consumers (PMs, finance) assume tables are correct, complete, and timely. Data quality monitoring makes violations visible before they pollute dashboards and A/B reads.

Interviews expect a layered story: contract tests at ingest, transformation assertions in dbt, SLA monitors on job completion, statistical anomaly detection on row counts and key metrics.

The key insight is that data quality is not one check, it is a defense-in-depth system. Schema contracts prevent malformed payloads from entering the lake, transformation tests catch logic regressions, and freshness/volume monitors catch silent operational failures that still pass SQL syntax. Teams that rely on only one layer usually discover incidents from executives before monitors fire, which is exactly what high-quality analytics engineering is meant to prevent.

Freshness: max(event_ts) - now() threshold per table tier — gold tables tighter than staging.

Volume: Day-over-day row count z-score or EWMA band — catches silent WHERE clause bugs.

Null rate: null_fraction(user_id) alert if exceeds rolling baseline — SDK bug classic.

Uniqueness: Primary key duplicates after dedupe — join explosion signal.

Accepted values: Enum domain shrink/expansion — mobile OS version mapping errors.

In production, every check should include three fields: owner, severity, and runbook URL. Without these, alerting devolves into Slack noise with no clear resolution path. Another practical pattern is seasonality-aware baselines (weekday/weekend profiles) for volume and null rates; static thresholds create alert fatigue and are eventually ignored.

Strong interview answers also include a post-incident loop: after each P0, add one preventive contract or monitor that would have caught it earlier. This closes the reliability feedback loop and demonstrates systems thinking beyond one-off debugging.