A transit authority CRM lists the same rider under three slightly different names and phone formats. What data quality problem does this primarily represent?
Select an answer to reveal the explanation.
Short Explanation
Three 'different' riders who are really one person is like three library cards for the same borrower—operations get messy fast. Uniqueness fails when duplicates of the same entity pile up. Slight name and phone format drift is a classic duplicate-entity risk.
Full Explanation
Uniqueness requires that each real-world entity is represented once as intended in the system of record. A transit authority CRM listing the same rider under three slightly different names and phone formats primarily illustrates a uniqueness problem: one person appears as multiple records. Blaming only delayed nightly extracts as a timeliness problem does not explain why three near-duplicate identities coexist after loads complete. Calling parentheses versus dashes in phone numbers a validity problem may note a format inconsistency, but the core defect the stem highlights is multiple records for one rider, not a single malformed number. Adding a fourth blank address line as a completeness fix increases noise and does nothing to consolidate identity. Exam caveat: format variation often contributes to match failure, yet the dimension under test is uniqueness of the entity, not format polish alone. Operational check: run deterministic and probabilistic matching on name-phone keys, review near-duplicates with a steward threshold, merge or link under an approved survivorship rule, and prevent re-entry with search-before-create at the CRM. Civic customer-service teams should train agents to search existing rider IDs before opening a new account so fare and ADA accommodations stay attached to one person.