How do you approach user identity stitching across devices?

WHAT THIS TESTS: Your ability to design a data pipeline that resolves user identity across sessions and devices. It assesses your knowledge of identifier types, event processing, and the trade-offs between data completeness, cost, and privacy. The interviewer is looking for a system-level answer that details the 'how', not just a conceptual overview.

A GOOD ANSWER COVERS: Four key stages in order. First, establish a persistent anonymous identifier for each platform (e.g., a first-party cookie ID for web, an IDFV or UUID for mobile). Second, define the 'stitch event' – typically a successful login or registration – which emits a record containing both the anonymous ID and the canonical, stable user_id. Third, describe the asynchronous backend stitching process. This is often a batch job (e.g., running daily on Spark) that takes new stitch events, performs a lookback (e.g., 90 days) on the raw event store, and re-keys all events matching the anonymous ID with the canonical user_id. Fourth, explain how this creates a 'person-level' view, allowing attribution across channels and devices that have been linked to the same user_id. Mentioning graph-based vs. field-based stitching is a senior-level bonus.

COMMON WRONG ANSWERS: A junior answer just says 'you link the cookie to the user ID.' A senior candidate must describe the mechanism. Red flags include: focusing on third-party cookies (obsolete); failing to mention the backend processing and its computational cost (the lookback is expensive); ignoring cross-device linking (only solving for one browser); and, critically, omitting any discussion of privacy regulations like GDPR/CCPA, which govern how this data can be collected and used. Another miss is confusing stitching (enriching one dataset) with merging (combining multiple datasets).

LIKELY FOLLOW-UPS: 'How would you handle a 90-day lookback for 100 million daily active users? What's the computational cost?' 'What happens if a user uses a shared device and multiple people log in? How do you resolve identity conflicts?' 'How does your design change under strict privacy regulations like GDPR?'

ONE CONCRETE EXAMPLE: A user visits our e-commerce site on their laptop, generating anonymous events with cookie_id=ABC. They browse for 3 days. On day 4, they log in as user_id=123. A 'stitch event' {cookie_id: ABC, user_id: 123} is sent to a Kafka topic. A nightly Spark job reads this event. It then queries our data lake (e.g., S3 with Parquet files) for all events from the last 90 days where cookie_id=ABC. It finds thousands of events and writes new, enriched versions of them to a separate 'stitched events' table, now with user_id=123 populated. The next week, the same user logs in on our mobile app (device_id=XYZ), linking user_id=123 to that device ID as well. Now, analysis on the 'stitched events' table can track the full journey for user_id=123 across both devices.