In Amplitude, why should a web app call reset() when a user logs out?

## The identity model underneath the question Amplitude does not have one identifier; it has two inputs and one derived key. Every event carries a `device_id` (generated by the SDK and persisted in browser storage) and, once the user is known, a `user_id` you supply through `setUserId` or on the event payload. Amplitude resolves the pair onto an internal **Amplitude ID**, which is the thing charts actually count as a user. The resolution rules are what make the logout question interesting: - A device seen for the first time with no user id gets an anonymous Amplitude ID of its own. - When that device later sends a `user_id` that Amplitude has not associated with anyone, the anonymous history on the device is **merged into that user**. This is the good case: the visitor who browsed for a week before signing up keeps their pre-signup events, so the acquisition funnel is measurable. - Once the association exists, events from that device with no `user_id` continue to resolve to that user, because the device is already mapped. That last rule is the trap. Logging out in your application is a state change in *your* code; unless you tell the SDK, nothing about the browser's device id has changed. ## What goes wrong without reset() User A logs out on a shared laptop. User B sits down and browses anonymously before logging in. Every event B generates in that anonymous window still carries A's device id, so it resolves to A. The damage is quiet but broad: - **Inflated activity and retention for A.** A looks like a power user who came back; retention curves and active-user counts absorb someone else's behaviour. - **Broken funnels.** A conversion path gets steps performed by two different humans, which produces conversion rates that are not describing any real person's journey. - **Polluted behavioural cohorts.** If those cohorts sync outward to marketing or lifecycle tools, the wrong person receives the campaign — the error escapes analytics and reaches customers. - **Irreversible merges.** Amplitude's identity merges cannot be unpicked after the fact. There is no supported "split these two users back apart" operation, so this is not a bug you clean up; it is one you stop repeating and then live with in historical data. Kiosks, call-centre workstations, family tablets, demo laptops and shared support accounts are where this shows up worst, because the same device serves many people per day. ## What reset() actually does `amplitude.reset()` in the Browser SDK does two things together: it clears the stored user id, and it generates a **new device id**. Both halves matter. Clearing only the user id — for example by calling `setUserId` with an empty value — leaves the old device id in place and therefore leaves the association intact, which is the subtly-wrong fix candidates often propose. The new device id is what actually severs the link. Call it as part of the logout routine, alongside clearing your own session storage, and call it *before* any post-logout page view is tracked so the redirect to the marketing page does not land on the previous user. ## The mirror-image mistake Calling `reset()` at login is worse than useless. The whole value of Amplitude's anonymous-to-known merge is that the pre-signup journey — landing page, pricing page, trial start — stays attached to the person who eventually converted. Reset immediately before or after `setUserId` throws that history away by minting a new device id, and the acquisition funnel becomes unmeasurable from the first anonymous step. The correct login sequence is simply to call `setUserId` with the identifier; the merge happens because the device was already anonymous. ## Server-side and multi-surface complications Events sent from your backend have no browser storage and therefore no device id unless you supply one. If server events carry only a `user_id`, they resolve to that user, which is usually fine — but they cannot participate in the anonymous merge, so a signup completed server-side will not stitch the visitor's earlier anonymous browsing unless you propagate the client's device id into the backend call. Teams that instrument the same funnel across web, mobile and server need one deliberate rule for which identifier travels where. ## How to answer this in an interview State the mechanism (device id and user id resolve to an Amplitude ID), then the specific consequence at logout (the device stays mapped, so the next visitor is counted as the previous user), then the fix (`reset()` clears the user id and issues a new device id), then the two boundaries: merges are irreversible, and resetting at login destroys the stitching you actually want. Mentioning shared devices and kiosks shows you have thought about where the failure is common rather than theoretical.