Call mixpanel.reset() immediately after logout completes and before any new page renders. This clears the persisted distinct_id and super properties and generates a fresh anonymous ID, so the next person on that browser is not folded into the previous user's profile.
Why this happens
Mixpanel persists distinct_id (and any registered super properties) in browser storage so identity survives reloads and new sessions - correct behavior while someone is logged in, but a data-integrity problem at logout. If you do not clear it, the next person who logs in on the same browser, or even continues browsing anonymously, keeps sending events under the previous person's distinct_id until identify() is called again.
That means some of person B's pre-login activity gets attributed to person A's profile - especially damaging on shared or public devices, and in QA/demo environments where several team members log in and out of the same browser session.
Fix it
- Add
mixpanel.reset()to your logout handler, after the logout API call succeeds and before redirecting. - Do not call reset() on every page load "just in case" - it also clears super properties you may want to persist across an anonymous session, so scope it strictly to the logout event.
- If your app supports switching accounts without a full logout, treat that the same way: reset() then identify() the new account.
- In single-page apps, confirm reset() runs before any route change fires a new pageview event, so the pageview right after logout does not still carry the old distinct_id.
How to verify it worked
After triggering logout in a test session, run mixpanel.get_distinct_id() in the console - it should return a new, different ID than the one active during the logged-in session. In Live View, confirm the next tracked event after logout appears under a new, unlinked anonymous profile rather than continuing to attach to the previous user's profile.