How do you approach user identity stitching across devices?

WHAT THIS TESTS: This question evaluates whether you understand cross-channel identity resolution as a data engineering problem rather than a simple SQL exercise. The interviewer wants to see if you can distinguish between device-level persistent identifiers and stable person-level identifiers, and how you bridge the gap when a user moves from anonymous browsing to authenticated states across web and mobile.

A GOOD ANSWER COVERS: First, emit a persistent anonymous ID on every device and channel, such as a cookie on web or a device ID in a native app, so that unauthenticated events are not lost. Second, define a single stable person ID namespace, like a hashed email or user UUID, that is present at login and shared across channels. Third, describe a rekeying process that retroactively and prospectively binds anonymous events to the person ID once authentication occurs, using either field-based stitching on a single dataset or graph-based stitching that leverages an identity graph. Fourth, acknowledge that if no link can be made, the system falls back to the persistent device ID so analysis remains possible at the device level. Fifth, mention privacy prerequisites, including obtaining user consent before merging authenticated and unauthenticated data, and note that the stitching process is case-sensitive.

COMMON WRONG ANSWERS: Treating stitching as a join or merge across multiple datasets is a major error; stitching operates on one event dataset at a time, while merging happens later in the connection configuration. Proposing to overwrite the raw identity field directly ignores that stitching uses the value as it exists in the data lake without transformation. Ignoring the unauthenticated gap by only tracking logged-in users destroys cross-channel attribution for the majority of top-of-funnel behavior. Overlooking compliance or case-sensitivity is another red flag that signals inexperience with production data pipelines.

LIKELY FOLLOW-UPS: The interviewer may ask how you would handle shared devices where multiple people log in, or how to set replay frequency and lookback windows for historical rekeying. They might also probe whether you would use deterministic matching only or allow probabilistic device graphs, and how you would validate that stitched attribution actually improved conversion accuracy.

ONE CONCRETE EXAMPLE: Imagine a user clicks a desktop ad and browses anonymously with cookie ID abc123. Later that day they log in on the same browser, emitting person ID user456. A stitching job with a 30-day lookback rekeys the earlier ad click to user456. Three days later, the same user opens the mobile app on a new device, initially seen as device ID xyz789, then logs in again as user456. Graph-based stitching resolves xyz789 to user456, so the mobile session is attributed to the original desktop ad. If the user had never logged in on mobile, those events would remain under xyz789 rather than being incorrectly merged.