Row-Count Anomaly vs. Address Quality Regression
Helios Financial's customer hub ingests 12 million records daily from Salesforce, three regional POS systems, and a legacy AS/400 extract. Data quality rules run in PowerCenter and Informatica Data Quality: address validation via AddressDoctor, email format, a fuzzy duplicate rule on name and address, and a completeness rule on tax ID. Current scorecard: 9.4% German address validation failures (up from 2.1% last quarter), 6.2% duplicate rate, 11% missing tax ID for the German entity, and 3% email format failures. On Tuesday, Data Observability raised a row-count anomaly: the POS Japan feed delivered 41% fewer rows than the 30-day median, yet the load job reported success and no SLA breach fired because the threshold was set on total rows, not per feed. The data steward is on leave and the CFO's month-end dashboard refreshes in 36 hours.
1. What is your triage order and what do you do first?
Read the worked answer
The 41% feed drop outranks every quality score, because missing rows invalidate the metrics computed on them and cannot be recovered after the CFO refresh.
Sequence: (1) confirm the drop is real - query the POS Japan source counts by business date, compare file arrival counts and sizes against the 30-day median, and check whether the watermark or timestamp filter crossed a time-zone or month boundary; (2) confirm whether a partial load committed to the target and whether a backfill is possible before the refresh; (3) explain the false success - the job succeeded because it read what was there, so the missing signal is upstream file completeness, not job status; (4) only then return to the quality scorecard.
The German address regression can run in parallel with a second analyst, but it is a visible, explainable, slowly-moving metric rather than an unrecoverable gap. Triage by blast radius, not by which number looks worst. Communicate the known gap to the CFO's team before the refresh, even if the fix is a labeled partial dataset.
2. How do you determine whether the German address failures come from the rule configuration or from upstream data?
Read the worked answer
Build a fixed benchmark first. Take 1,000 records with known-good and known-bad addresses, run them through the current AddressDoctor configuration, and re-run through the configuration from before the regression. If results differ, the change is in rules or reference data; if identical, the change is upstream. This one test prevents weeks of speculation.
If config: check the reference data version and any recent deployment, the country-specific rule set, language and script settings, and whether the process mode changed.
If data: examine the source extract for a remapped country field, character encoding (UTF-8 versus ISO-8859-1 umlauts), street and house number reordering, or a new third-party feed. Segment the failures by source system and creation date - clustering by source or by date points straight at the cause.
Also distinguish status: 'unvalidated' usually signals configuration, reference data, or missing fields; 'invalid' usually signals bad input values. That distinction alone often resolves the question before you touch a rule.
3. How should alerting be redesigned so a feed-level drop is caught and alert fatigue is avoided?
Read the worked answer
Replace the single static threshold on total rows with per-feed checks, because a 41% drop in one of five feeds can hide inside a healthy aggregate.
Each feed gets: a day-of-week-aware dynamic volume baseline (median plus or minus three median absolute deviations), a freshness check on maximum event timestamp, a file-completeness check on arrival count and size, a schema-drift check, and distribution checks such as null rate on critical columns. Add absolute floors for feeds where any shortfall is unacceptable, and suppress expected variation during documented holiday windows.
Route alerts by owner and severity so the on-call analyst sees the two that matter rather than forty. Track alert precision - the proportion of alerts that led to real incidents - and retire rules that never fire true. Include a 'success but empty' rule, since Tuesday's failure was exactly that: the job completed and nobody asked whether the input was complete.