Explain user identity stitching across devices and SDK roles

WHAT THIS TESTS: This tests whether you understand the difference between anonymous event attribution and authenticated user identity in distributed analytics pipelines. Interviewers want to see that you know identity stitching is not just a client-side tag but a backend merge problem involving out-of-order events, multiple devices, and distinct ID namespaces.

A GOOD ANSWER COVERS: A good answer hits four things in order. First, explain that anonymousId is a device or session-scoped identifier generated locally by the SDK, often stored in localStorage on web or device storage on mobile, and it persists until the user logs in or clears data. Second, describe that every pre-login event is sent with this anonymousId as the distinct_id so the backend can attribute the behavior to a temporary profile. Third, state that the identify call is fired at the moment of authentication, passing the canonical userId, which tells the backend to alias or merge the anonymous distinct_id into the authenticated user profile. Fourth, emphasize that the backend maintains a merge queue or identity graph to reconcile events that arrive out of order, such as a mobile event sent before the identify call from the web session, so the final user journey is complete.

COMMON WRONG ANSWERS: Common wrong answers include suggesting that a single cookie or shared storage solves cross-device tracking, which fails because iOS apps and web browsers do not share cookies. Another red flag is confusing the identify call with a user profile update; identify changes the identity namespace for event attribution, while profile updates set properties like email or plan tier. Candidates also stumble by claiming the frontend must rewrite old events after login, which is not how SDKs work; the merge happens server-side.

LIKELY FOLLOW-UPS: Interviewers often follow up by asking how you handle identity resets on logout, which requires calling reset to generate a new anonymousId and prevent leaking the previous user’s identity. They may ask about race conditions when two devices identify simultaneously, or how to handle server-side events where no anonymousId exists, in which case you should pass the authenticated userId directly.

ONE CONCRETE EXAMPLE: Imagine a user browses pricing on a laptop without logging in. The web SDK generates anonymousId abc123 and sends a Page View event with distinct_id abc123. Three hours later, the same user downloads the iOS app, receives anonymousId xyz789, and taps Sign Up. The app calls identify(user_42). Both the web Page View and the mobile Tap events now resolve to user_42 in the identity graph, even if the web session sends a late event after the merge.