How do you create a 'golden record' for customers?

WHAT THIS TESTS: This question assesses your ability to handle a complex data strategy problem, not just a technical one. The interviewer is looking for a senior mindset that balances business needs, data governance, and technical implementation. They are testing your understanding of Master Data Management (MDM) as an ongoing discipline, not a one-time cleanup script. Can you architect a durable system and process for ensuring data quality and consistency across an enterprise?

A GOOD ANSWER COVERS: A strong answer is structured as a multi-phase project. First, Discovery and Governance: Identify all data sources (CRM, billing, support), define key stakeholders from each domain, and form a governance council to make decisions. The goal here is to get business alignment on what a 'customer' is and who owns which piece of data. Second, Rule Definition: Establish concrete, deterministic rules for matching and merging. Matching rules define how to identify the same customer across systems (e.g., normalized email OR phone number). Merge rules define precedence for conflicting attributes (e.g., use the address from the billing system, but the name from the CRM). Third, Technical Implementation: Design and build the pipeline. This involves extracting data from sources, applying the matching and merging rules, and storing the resulting 'golden record' in a master database. This master record should have a unique, persistent ID that is propagated back to source systems if possible. Fourth, Stewardship and Iteration: Define a process for ongoing data stewardship, handling new data sources, and monitoring data quality metrics over time. This is a continuous process, not a one-off project.

COMMON WRONG ANSWERS: A major red flag is jumping straight into a technical solution like, "I'd write a Python script to pull from APIs and deduplicate in Pandas." This ignores 90% of the problem. Other weak answers treat this as a simple ETL task, failing to mention stakeholder involvement, rule negotiation, or long-term governance. Another mistake is assuming a perfect, universal key exists across all systems; the core of the problem is that one doesn't.

LIKELY FOLLOW-UPS: Expect questions like: "How would you handle fuzzy matching for names like 'Bob' vs 'Robert'?" (Discuss phonetic algorithms like Soundex, distance metrics like Levenshtein, or ML models). "What if business stakeholders disagree on the merge rules?" (Refer back to the governance council, use data to show the impact of each choice, or start with the most conservative, agreed-upon rules). "How would you measure the success of this project?" (KPIs like percentage of records matched, reduction in bounced marketing emails, or fewer customer support tickets due to identity issues).

ONE CONCRETE EXAMPLE: For a company with 1M customers fragmented across a Salesforce CRM, a Stripe billing system, and a Zendesk support tool, the first step is analysis. We might find 1.5M total records, suggesting significant duplication. A good rule set could be: match on normalized email. For merging, trust Stripe for the legal name and address, Salesforce for the sales contact owner, and Zendesk for the most recent support interaction timestamp. Implementing this could consolidate records down to 1.1M golden records, improving marketing campaign ROI by 10% by reducing duplicate sends and increasing personalization accuracy.