Skip to content

Scenarios 01–06

1 — Two purposes, one score

Stem: address data is 96% complete. Marketing requires 95%; regulatory reporting requires 99.9%.
Primary problem / best answer: contextual fitness for purpose.
Leading KA: Data Quality Management.
Supporting: consumer requirements, thresholds, business risk.
Roles: consumers, Stewards, Data Owners.
Best action: maintain purpose-specific requirements/thresholds and report conformance by use.
Weaker: globally declare the data “high” or “low” quality from 96%; ignores context.
Changed fact: if both uses require 95%, the same data may satisfy both.
Source: pp. 424–428.


2 — Email target

Stem: missing customer emails reduce marketing revenue; 98% completeness is achievable and valuable.
Primary problem: critical data + measurable completeness target.
Supporting: business drivers, criticality, dimensions.
Roles: Marketing owner, Steward, DQ analyst.
Best action: classify email as critical for this use, define rule/threshold, measure, improve producing process.
Weaker: profile every field equally because “all data matters”; wastes priority.
Changed fact: if email has little material impact and another element drives regulatory risk, reprioritize.
Source: pp. 428–432.


3 — Valid but wrong

Stem: EMAIL_ADDRESS conforms to required syntax/domain but belongs to another customer.
Best answer: Accuracy failure; format validity may pass.
Supporting: Validity vs Accuracy.
Roles: Steward, process owner, DQ analyst.
Best action: verify against trusted source/reality and investigate incorrect association/root cause.
Weaker: tighten regex only; does not test truth/ownership.
Changed fact: if address also violates email format, validity fails too.
Source: pp. 430–432.


4 — Late or stale

Stem: feed arrives within five-minute commitment, but balance values are yesterday’s when intraday current values are required.
Best answer: Currency.
Supporting: Timeliness vs Currency.
Roles: consumer, process owner, DQ operations.
Best action: define/monitor currentness requirement and correct source/update process.
Weaker: call it timeliness because values are “old”; delivery itself met time requirement.
Changed fact: if values are current but feed arrives 20 minutes late → Timeliness.
Source: pp. 431–432.


5 — Order orphan

Stem: ORDER.CUSTOMER_ID is populated for every order, but 2% have no matching Customer.
Best answer: Integrity. Completeness of the field passes; referential relationship fails.
Supporting: Master Data.
Roles: system owner, Steward, DQ analyst.
Best action: enforce/monitor referential integrity and investigate source process creating orphans.
Weaker: treat it as simple completeness.
Changed fact: CUSTOMER_ID is null → Completeness.
Source: pp. 430–431.


6 — Duplicate customer

Stem: two customer records have different IDs but matching identity attributes and split one person’s services.
Best answer: Uniqueness / deduplication.
Supporting: Master Data.
Roles: MDM team, Steward, DQ analyst.
Best action: identity/duplicate rules, resolve records, correct upstream cause.
Weaker: only cross-system consistency test; duplicate identity is the deciding clue.
Changed fact: only one record exists but its address is wrong → Accuracy.
Source: pp. 431–432.

← Scenario Home · Scenarios 07–12 →