Impact of Not Tracking Users in Unique vs Total Count Reports
What happens if you do not track users when you filter reports by uniques vs total counts, etc.?
What happens if you do not track users when you filter reports by uniques vs total counts, etc.?
Hi Gabe, 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
If you do not track users (i.e., you do not send a unique identifier such as $distinct_id with your events), Mixpanel cannot accurately calculate metrics that rely on user identification, such as "uniques" (unique users), DAU/WAU/MAU, or any user-based breakdowns. - Filtering by Uniques: When you filter or measure by uniques, Mixpanel counts the number of unique users who performed an event. Without user tracking, all events may appear as coming from anonymous or the same user, leading to inaccurate or misleading unique user counts. For example, if every event is missing a unique identifier, Mixpanel may undercount or overcount unique users, depending on how it handles anonymous events in your implementation. This affects metrics like DAU, WAU, MAU, and any report where you want to know "how many users did X" rather than "how many times X happened" see: Users in Insights.- Filtering by Totals: When you filter or measure by totals, Mixpanel simply counts the total number of events, regardless of who performed them. In this case, not tracking users does not affect the event count, but you lose the ability to segment or analyze by user, cohort, or any user property.- Other Impacts: Not tracking users also prevents you from using features like funnels with unique user conversion rates, retention analysis, cohort analysis, and any breakdowns or filters based on user properties. Many advanced Mixpanel features depend on user identification to provide meaningful insights.In summary, not tracking users severely limits the accuracy and usefulness of any report or analysis that relies on unique user identification. For event totals, you can still get raw counts, but you lose all user-level granularity and insight.For more details on how Mixpanel calculates uniques and totals, see the documentation on Users in Insights and Funnels Counting Methods.
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! 📚
What you’re observing is expected behavior in Mixpanel if events are being sent with different distinct_id values for the same person (such as during testing from different browsers, devices, or after clearing cookies). In Mixpanel, each unique distinct_id is treated as a separate user unless you implement identity management and merge those IDs.- Users without profiles: Not every distinct_id will have a user profile. Profiles are only created when you explicitly set user properties (using the Engage API or profile updates). So, you may see events from users (distinct_ids) that do not have associated profiles. - Truly unique users: Mixpanel considers each distinct_id as a unique user. If you generate new distinct_ids (e.g., by clearing cookies or using incognito mode), Mixpanel will count each as a separate user—even if it’s actually you testing multiple times. This is why you see your own testing events under different distinct_id event streams. - Merging identities: To ensure that all activity from the same real-world user is attributed to a single user in Mixpanel, you need to implement identity management (ID Merge). This involves calling identify() with a consistent user ID at login/registration, so Mixpanel can merge anonymous and known IDs into a single identity cluster. Without this, the same person can appear as multiple users in your reports Identity Management Overview.In summary, unless you are merging IDs, Mixpanel will treat each distinct_id as a unique user, which can lead to overcounting of users—especially during testing or if users access your product from multiple devices or after clearing cookies Identity Management in Mixpanel.
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! 📚
Yes, you can implement user identification and retroactively merge anonymous IDs with known user IDs in Mixpanel, but the exact approach depends on which ID management system your project uses: Original ID Merge or Simplified ID Merge.
Retroactive Merging
- Original ID Merge:
You can retroactively merge anonymous and known user IDs by calling .identify(<user_id> ) when the user logs in or registers. This triggers a $identify event that links the anonymous $device_id (used as the distinct_id before login) with the known user ID. All previous events tracked with the anonymous ID will be merged into the same identity cluster as the user ID, so future queries treat them as a single user. This works even if the user has multiple anonymous sessions across devices, as long as you call .identify() with the same user ID on each device Identifying Users (Original) - Example User Flows.- Simplified ID Merge:
With the Simplified API, you simply call .identify(<user_id> ) at login/registration, and send at least one event after this call. Mixpanel will automatically merge the anonymous $device_id with the $user_id and retroactively update previous events to associate them with the user. This is the most straightforward approach and is recommended for new projects Identifying Users (Simplified) - Client-side Identity Management.
Most Simple Implementation
For the most simple implementation (especially with the Simplified ID Merge API): 1. Call .identify(<user_id> ) when a user signs up or logs in, passing in your unique user identifier (e.g., database ID).
2. Send at least one event after the .identify() call to trigger the merge.
3. Call .reset() when a user logs out to clear the local identity and prevent merging different users on the same device.This ensures that all anonymous activity is merged with the user’s profile once they are identified, and is the recommended best practice Identifying Users (Simplified) - Client-side Identity Management.Note:
- If you are using the Original API, the process is similar, but the merge is triggered by the $identify event.
- You cannot merge two different $user_ids together in the Simplified API; only anonymous IDs can be merged into a single user ID Identifying Users (Simplified) - FAQ.Summary:
Implementing .identify() at login/registration and .reset() at logout is the simplest and most effective way to ensure user identities are merged retroactively and accurately in Mixpanel.For more details and step-by-step flows, see Identifying Users (Simplified) - Example User Flows and Identity Management in Action.
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! 📚
If you are currently on the Original ID Merge API and have not yet implemented user identification, you should consider the following before switching to the Simplified ID Merge API:
Can You Switch?
- You cannot switch an existing project (with data) from Original to Simplified API. To use the Simplified API, you must create a new, empty Mixpanel project and enable Simplified ID Merge before sending any data. There is no way to convert an existing project with data to the Simplified API due to backend architectural differences Deciding to Migrate Identity Merge APIs.
Should You Switch?
- Simplified ID Merge is generally recommended for new projects because it is easier to implement and maintain. It only requires you to send $user_id and $device_id properties for identity merging, and does not require special events like $identify, $merge, or $create_alias. It also removes the 500 ID cluster limit present in the Original API Identity Merge APIs.
- However, Simplified ID Merge only supports one $user_id per identity cluster. If you need to support multiple user IDs per user (e.g., both email and phone number as IDs), you should stay on the Original API Considerations when Migrating.
Does Switching Affect Anything Besides User Implementation?
- The main difference between the APIs is how user identity is managed and merged. Other Mixpanel features (event tracking, reporting, etc.) remain the same, but the way you implement user identification and merging will change. Simplified API removes the need for special identity events and makes merging more straightforward, but with the limitation of only one $user_id per cluster Identity Merge APIs.Summary:
If you want a simpler, more robust identity management system and do not need multiple user IDs per user, it is best to start a new project with the Simplified API before implementing users. If you have requirements that are only supported by the Original API, you should stay on it.> You cannot change the ID Merge API version for a project that already contains data. You must create a new project to use the Simplified API Identity Merge APIs.
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! 📚
Mixpanel strongly recommends not using PII (such as phone numbers or email addresses) as user identifiers. Instead, you should use an internal, unique, and unchanging ID (such as a database-generated account or user ID) to identify users and link their events. This approach protects user privacy and makes your implementation more robust, especially if users can change their phone numbers or emails in the future. If you use PII as an identifier and a user changes their phone number, Mixpanel will treat the new number as a new user, which can fragment your data and analytics Identifying Users (Simplified) - FAQ.If your system has accounts with multiple profiles or partner profiles, you can: - Use the account ID as the primary identifier for account-level analysis. - Use a unique, non-PII user ID for each profile to track individual user activity. - If you need to analyze at both the account and user/profile level, you can use Mixpanel’s group analytics to associate events with both user and account IDs.Summary: - Do not use PII (like phone numbers) as the main user identifier. - Use internal, unique, and stable IDs for both users and accounts. - You can store PII as a user property (for internal reference), but not as the identifier used for event tracking or identity merging.This approach is both a best practice for privacy and ensures your Mixpanel data remains accurate and useful as your users’ information changes Protecting User Data Identifying Users (Simplified) - FAQ.
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.