How do you approach user identity stitching?

WHAT THIS TESTS: This question tests your ability to think about data systems holistically. The interviewer is evaluating your understanding of the business goal (cross-channel attribution), the data architecture (event pipelines, data lake), the core logic (identity mapping), and critical non-functional requirements (privacy, data governance). They are looking for a systems thinker who understands that stitching is a complex data engineering process, not just a simple database query.

A GOOD ANSWER COVERS: First, the goal and identifiers. State that the objective is to create a single customer view for cross-channel analysis. Differentiate between anonymous identifiers (e.g., first-party cookie ID, mobile device ID) and a persistent, known person ID (e.g., a hashed user ID or email established post-authentication).

Second, the stitching process. Describe the core logic of creating an identity graph or mapping table. When a user authenticates, you associate their current anonymous ID with their known person ID. This link allows a process to 'rekey' or backfill historical events from that anonymous ID, replacing it with the now-known person ID.

Third, the system architecture. Explain that this requires a central event data lake or warehouse where raw, unstitched events from all sources (web, mobile, CRM, call center) are ingested. The stitching process runs against this dataset to produce a new, stitched dataset for analysis.

Fourth, key constraints. Acknowledge that a non-negotiable first step is ensuring compliance with all applicable laws and regulations like GDPR and CCPA, which requires obtaining end-user permissions. Also, mention data quality issues like case-sensitivity (e.g., 'user@a.com' vs 'User@a.com') that can break the process.

COMMON WRONG ANSWERS: Focusing only on web cookies, ignoring mobile device IDs and other channels. Describing a simple database join without mentioning the temporal, backfilling aspect of the process. Completely ignoring privacy, consent, and legal requirements, which is a major red flag for a senior role. Confusing stitching (enriching a single event dataset) with merging multiple datasets; stitching prepares a dataset for later merging.

LIKELY FOLLOW-UPS: How would you handle a user with multiple authenticated accounts, like a personal and work login? What lookback window would you use for backfilling events, and what are the cost implications? How do you handle graph corrections, such as when two profiles are mistakenly merged? Can you describe the difference between field-based and graph-based stitching?

ONE CONCRETE EXAMPLE: A user visits your site on a laptop, generating anonymous cookie ID 'ABC-123' and views 3 pages. The next day, they open your mobile app, generating device ID 'XYZ-789'. Later, on the laptop, they log in with user ID '_usr_99'. At this moment, you create a link: 'ABC-123' -> '_usr_99'. A stitching process runs and rekeys the previous 3 page views, changing their identifier from 'ABC-123' to '_usr_99'. When they log in on mobile, you link 'XYZ-789' -> '_usr_99'. Now, an analyst can query for '_usr_99' and see a single journey across both devices.