how does mixpanel show funnels? what is the linking identifier that allows to club ONE user's funnel? Is it distinctID or anything else? What happens in case of multiple distinct IDs for ONE actual users?
How Mixpanel Funnels Work & the Linking Identifier
The Core Identifier: distinct_id
Mixpanel uses distinct_id as the primary linking identifier to track a single user through a funnel. [Identity Management Overview]
"Funnels report - Distinct IDs are used to follow a user through a conversion journey. If a user tracks events with inconsistent Distinct IDs between steps, they will be counted as a drop-off."
So if all funnel steps share the same distinct_id, Mixpanel counts that as one user converting through the funnel.
-------------------------
What Happens with Multiple distinct_ids for One Real User?
This is where ID Merge comes in. A single real user can generate multiple distinct_ids (e.g., anonymous device ID before login, user ID after login, different device IDs across devices). Without ID Merge, Mixpanel would treat these as separate users and show incorrect drop-offs in funnels.
With ID Merge, Mixpanel groups multiple identifiers into an identity cluster, and all events from any ID in that cluster are attributed to the same user. [Identity Management Overview]
How the cluster is formed:
Simplified API: When an event contains both $device_id and $user_id for the first time, a mapping is created linking them. The canonical distinct_id is always set to the $user_id. [Identifying Users (Simplified)]
Original API: A $identify event links an anonymous $anon_id to an $identified_id, forming a cluster. The canonical distinct_id is programmatically chosen by Mixpanel (could be the device ID or user ID — not user-configurable). [Identifying Users (Original)]
-------------------------
Funnel-Specific Caveat: ID Merge Delay
Even after calling .identify(), it can take up to 24 hours for the $device_id → $user_id mapping to propagate across all Mixpanel systems. This means:
"When analyzing a funnel that spans pre-login and post-login behavior in real-time, some users may be shown as dropped-off, even though they've performed the conversion event."
[Funnels FAQ; Identifying Users (Simplified)]
Once the merge propagates, the funnel will correctly reflect the conversion.
-------------------------
Summary
| Scenario | Funnel Behavior |
| - | - |
| Single distinct_id across all steps | ✅ Correctly counted as one user converting |
| Multiple distinct_ids, ID Merge configured | ✅ Merged into one identity cluster; counted as one user |
| Multiple distinct_ids, no ID Merge | ❌ Treated as separate users; drop-offs incorrectly shown |
| ID Merge configured but within 24hr window | ⚠️ May temporarily show as drop-off; resolves after propagation |
Best practice: Call .identify(<user_id>) at registration and login, and .reset() at logout to ensure proper identity linking. [Troubleshooting FAQs]
ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
in my project's settings: "This project is using the simplified ID Merge API." this is displayed kapa.ai
Since your project uses the Simplified ID Merge API, here's what that means specifically for your setup:
How Identity Works for You
Canonical distinct_id is always set to the $user_id — this is deterministic and not random, unlike the Original API. [Identifying Users (Simplified)]
Identity merging is triggered simply by including both $device_id and $user_id on the same event — no special identity events (like $identify or $create_alias) are needed. [Migrating to Simplified ID Merge]
Your Client-Side Implementation (2 steps)
Call .identify(<user_id>) when a user signs up or logs in.
Call .reset() when a user logs out.
After .identify(), send at least one event so the $device_id → $user_id mapping is created. [Identifying Users (Simplified)]
Key Advantages of Simplified API for You
| Feature | Simplified API |
| - | - |
| Canonical distinct_id | Always = $user_id (predictable) |
| Number of $device_ids per user | Unlimited |
| Merging two $user_ids | ❌ Not possible |
[Identity Management Overview]
For Funnels Specifically
Since your canonical distinct_id is always the $user_id, funnel stitching across pre-login and post-login events is reliable — as long as you call .identify() correctly. Note that the mapping can still take up to 24 hours to propagate across all reports, so real-time funnel analysis may temporarily show drop-offs. [Identifying Users (Simplified)]
ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
this is done on the dev side? or ui side? kapa.ai
Based on the conversation context, you're asking whether calling .identify() and .reset() is done on the developer (code) side or the Mixpanel UI side.
This is entirely done on the developer/code side — there is no UI toggle in Mixpanel to handle this. Your engineering team must implement these calls directly in your application code.
What developers need to implement:
Client-side (Web/Mobile SDKs):
Call .identify(<user_id>) at registration/login
Call .reset() at logout
[Identifying Users (Simplified)]
Server-side:
Generate and manage a UUID as the anonymous ID (store it in a cookie)
Set $device_id on anonymous events
Set both $device_id and $user_id on events once the user is authenticated
[Server-side Identity Management]
The only thing on the Mixpanel UI side is verifying which ID Merge API version your project uses (which you already checked in your project settings). Everything else — the actual identity management implementation — requires code changes by your development team.
ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
kapa.ai i mean doesn't this mean that simplied API means the merging is active and should automatically happen yet when i do a manual trace of ONE user, they have 3-4 distinct IDs
Great question — the Simplified API does not automatically merge IDs on its own. The merging still requires a specific trigger from your code. Here's why a user can still have 3–4 distinct IDs even with Simplified API enabled:
Why Multiple distinct_ids Still Exist
The merge is only triggered when a single event contains both $device_id and $user_id at the same time. [Identifying Users (Simplified)]
"When a $user_id and $device_id are present in the same event for the first time, a mapping is created to merge the two IDs together."
If your code is not calling .identify(<user_id>) at login (client-side), or not including both $device_id + $user_id on the same event (server-side), the merge never happens — regardless of which API version you're on.
Common Reasons for 3–4 Distinct IDs on One Real User
.identify() is not being called at login/registration, so each session or device generates a new $device_id that never gets linked to the $user_id.
.reset() is being called too aggressively (e.g., on every page load instead of only at logout), generating new $device_ids unnecessarily.
Server-side events are being sent with a hardcoded or inconsistent distinct_id instead of using the $device_id/$user_id pattern.
The 24-hour propagation delay — the merge may have happened but hasn't fully propagated yet, so the Activity Feed may temporarily show separate IDs. [Identifying Users (Simplified)]
What "Simplified" Actually Means
The "Simplified" part refers to the mechanism being simpler (no special $identify events needed, just include both properties on a regular event). It does not mean merging is automatic without any developer implementation. [Migrating to Simplified ID Merge]
Bottom line: Your dev team needs to audit whether .identify() is actually being called correctly at login. That's the most likely root cause of the 3–4 distinct IDs you're seeing.
ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
30 day volume vs 30 day queries? what do they mean? kapa.ai
These are two different metrics visible in Lexicon (Mixpanel's data dictionary):
30-Day Volume
The total number of times an event was fired by users in the last 30 days. It measures how frequently the event is actually being triggered in your product. [Lexicon Overview]
30-Day Queries
The total number of times project members queried that event in the Mixpanel UI or API over the last 30 days. This includes selecting events in reports, viewing reports, and queries in the "Users" and "Events" tabs — but excludes dashboard views. [Lexicon Overview]
-------------------------
Why This Distinction Matters
| Metric | Answers the question... |
| - | - |
| 30-Day Volume | Is this event actually firing in production? |
| 30-Day Queries | Is anyone on my team actually using this event in analysis? |
Together, they help you identify:
Events with high volume but zero queries → firing but nobody analyzes them → candidate for dropping
Events with zero volume → no longer firing → safe to drop
In fact, you can sort by volume in Lexicon and bulk-drop events with zero volume to clean up your implementation. [Lexicon Query Volumes]
ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
