Help understand if the first screen user see 24 are unauthenticated and the next screen unauthenticated users see it's 48 how is this possible? Could the number be inflated because of refresh and being assigned a new device ID is that even possible what could explain why the same device ID is not persistent across both events or page load events
Hi event, Please stand by as I search the Mixpanel knowledge base for an AI-powered answer. I normally take about 15 seconds or so. In case AI cannot answer your question, feel free to reach out to Mixpanel support at mixpanel.com/get-support. If you have follow-up questions for this thread, please tag me again with your question: @kapa.ai <follow-up question> 👋
Feel free to ask a follow-up question once I've answered by mentioning me with @kapa.ai
Yes, it is possible for the number of unauthenticated users to increase between two screens (e.g., 24 on the first screen and 48 on the next) due to issues with device ID persistence. Here are some reasons this can happen, based on Mixpanel documentation: 1. Device ID Not Persistent Across Events:
If the $device_id is not being stored and reused consistently (for example, if it is regenerated on every page load or refresh), the same user could be counted as a new anonymous user each time. This would inflate your unauthenticated user counts, as each refresh or navigation could create a new device ID and thus a new "user" in Mixpanel’s eyes. This is a common implementation issue and can explain why the same device ID is not persistent across both events or page loads Client-side Identity Management.2. Calling .reset() Unnecessarily:
If your implementation calls .reset() too frequently (for example, on every page load or refresh), this will clear the local storage and generate a new $device_id for the session. This should only be done when there is a definite intent to change the user on the same device (e.g., a new user signing up or logging in), not on every navigation or refresh Client-side Identity Management.3. Anonymous User Tracking:
For unauthenticated users, Mixpanel relies on the $device_id to persistently identify the user across events. If this ID is not stored in a persistent way (e.g., in local storage or cookies), or if your app is in a context where storage is cleared (incognito mode, privacy settings, etc.), the same user may be assigned a new device ID on each screen, leading to inflated counts Server-side Identity Management.Best Practices to Avoid This Issue:
- Ensure that the $device_id is generated once and persists across the user’s session and navigation.
- Only call .reset() when a user logs out or there is a clear user change.
- QA your ID management implementation to confirm that the same anonymous user retains the same device ID across screens and events Best Practices.Summary:
Yes, the number can be inflated if the device ID is not persistent, such as when it is regenerated on refresh or page load. This is a common cause for seeing more unauthenticated users on subsequent screens than on the first screen.
If you need to debug further, compare the device IDs across events to see if they are changing unexpectedly, and review your implementation to ensure device IDs are being handled correctly.
kapa.ai is still learning and improving, please let me know how I did by reacting below.
ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
Let me check the knowledge base for you again. One moment! 📚
The knowledge sources do not explicitly mention VPN usage as a reason for a new device ID being generated upon page refresh. According to Mixpanel documentation, the persistence of the device ID ($device_id) depends on how it is stored (e.g., in local storage or cookies) and how your implementation manages it. Common causes for a new device ID include clearing local storage, calling .reset(), or not persisting the ID correctly between sessions or page loads. There is no direct reference to VPNs affecting device ID generation in the provided documentation Client-side Identity Management.If you are experiencing new device IDs on refresh, it is more likely related to storage or implementation issues rather than VPN usage.
kapa.ai is still learning and improving, please let me know how I did by reacting below.
ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
Let me check the knowledge base for you again. One moment! 📚
For unauthenticated users, Mixpanel relies on the $device_id to identify users across events. The client-side SDKs (such as JavaScript) automatically generate a $device_id and store it in the browser’s local storage or cookies. This allows Mixpanel to persistently identify the same anonymous user across page views and sessions, as long as the storage is not cleared and .reset() is not called.If you do not use cookies or local storage for unauthenticated users, the $device_id cannot persist between page loads or sessions. This means a new device ID will be generated each time, causing Mixpanel to treat each visit as a new anonymous user. This can inflate your unauthenticated user counts and break the continuity of user journeys Client-side Identity Management.Summary:
- For authenticated users, you can use cookies to persist their user ID.
- For unauthenticated users, Mixpanel’s SDKs use local storage or cookies to persist the $device_id.
- If you do not persist the $device_id (e.g., by not using cookies or local storage), each page load will generate a new device ID, and Mixpanel will treat each as a new user.This is why it’s important to allow Mixpanel to use local storage or cookies for anonymous user tracking, even if you use cookies for authenticated users.
kapa.ai is still learning and improving, please let me know how I did by reacting below.
ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
Let me check the knowledge base for you again. One moment! 📚
The persistence of the $device_id for unauthenticated users is managed automatically by Mixpanel’s SDKs, which store it in local storage or cookies. If you observe that sometimes the device ID persists across pages and other times it does not, the following factors—based on Mixpanel documentation—could explain this behavior: 1. Local Storage or Cookie Clearing:
If the browser’s local storage or cookies are cleared (manually by the user, by browser settings, or by privacy extensions), the stored $device_id will be lost. On the next page load, Mixpanel will generate a new device ID, treating the user as new Client-side Identity Management.2. Calling .reset():
If your implementation calls .reset() (intentionally or unintentionally), this will clear the local storage and generate a new $device_id. This should only be done when a user logs out or there is a clear intent to change users on the same device. Calling .reset() at other times (such as on every page load) will cause the device ID to not persist Client-side Identity Management.3. Incognito/Private Browsing Modes:
In incognito or private browsing modes, local storage and cookies are often not persisted between pages or are cleared when the session ends, leading to new device IDs being generated.4. Implementation Issues:
If your site or app is set up in a way that prevents Mixpanel from accessing or persisting local storage or cookies (for example, due to restrictive Content Security Policies, JavaScript errors, or custom code that interferes with storage), the device ID may not persist as expected.Summary:
The most common reasons for inconsistent persistence of the device ID are clearing of local storage/cookies, calling .reset() at the wrong time, or browser privacy features. Ensuring that your implementation allows Mixpanel to store and access local storage or cookies, and only calls .reset() when appropriate, will help maintain consistent device ID persistence Best Practices.
kapa.ai is still learning and improving, please let me know how I did by reacting below.
ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
