kapa.ai Hi! We are seeing many users from mobile platforms who lack a $device_id property, even though their distinct_id is formatted as $device:123.... Could you please explain if this is expected behavior? Also, when will the $device_id field be populated with the value from the distinct_id for these users?
Yes, this can be expected depending on how the events are sent.On projects using Simplified ID Merge, Mixpanel still supports events that only have distinct_id and no $device_id / $user_id. In that case Mixpanel infers the missing reserved properties from the distinct_id value: - If distinct_id is prefixed with $device:, Mixpanel treats it as an anonymous device ID and sets $device_id to the part after the prefix.
Example: distinct_id = "$device:anonymous111" → $device_id = "anonymous111". [Migrating – considerations]The docs explicitly show that for such events Mixpanel will populate $device_id server‑side, even if you didn’t send it: LBKS// Triggered event { "event": "App Install", "properties": { "token": "{{token}}", "distinct_id": "$device:anonymous111" } }LBKS// $device_id is set by Mixpanel { "event": "App Install", "properties": { "token": "{{token}}", "distinct_id": "$device:anonymous111", "$device_id": "anonymous111" } }LBKS
[Migrating – considerations]So for your case: - Seeing users whose distinct_id looks like $device:123... but where you didn’t send $device_id is expected.
- Mixpanel should automatically populate $device_id from that distinct_id as shown above. The docs do not state a delay for this specific mapping, but they do note that identity-related mappings can take up to 24 hours to fully propagate across all reports. [Identifying users – FAQ]If you are still not seeing $device_id after that kind of delay, the knowledge sources don’t provide further troubleshooting steps; in that case you’d likely need to contact Mixpanel Support with concrete event examples.
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.
kapa.ai I’ve checked with our developers, and it turns out they are calling mixpanel.identify using the distinct_id value that is already formatted as $device:123.... As a result, in the Mixpanel dashboard, we see many users where distinct_id is set to $device:123...but the $device_id field remains empty. These users have existed for almost two months, with the last events dated early December 2025. This confirms that the $device_id field is not being populated automatically. Could you clarify if calling identify with an anonymous ID is the reason why the $device_id field stays empty?
Let me check the knowledge base for you again. One moment! 📚
You’ve likely pinpointed the core issue: the docs strongly imply that you should not use an anonymous $device: ID as the identified user ID, and that doing so will affect how $device_id is handled.From the Simplified ID Merge docs: - When you send only distinct_id and it is prefixed with $device:, Mixpanel will treat it as an anonymous ID and internally set $device_id to the part after the prefix. [Migrating – considerations]
- But the intended pattern is:
- Anonymous: send $device_id only.
- Identified: send $user_id (and optionally $device_id), and let Mixpanel set distinct_id to $user_id. [Identifying users simplified]In other words, identify(<user_id> ) is supposed to be called with a stable user ID (e.g. DB ID), not with the anonymous $device: value. [Identifying users simplified – client-side]The knowledge sources do not explicitly describe what happens if you call .identify("$device:123..."), nor do they explicitly say that this will prevent $device_id from being populated. So I cannot definitively confirm the exact internal behavior.However, based on the docs: - Using $device: as the user identifier is contrary to the recommended pattern (where $device_id is the anonymous ID and $user_id is the canonical user ID). [Identifying users simplified]
- The automatic backfilling example (inferring $device_id from distinct_id = "$device:...") is shown for events where you send only distinct_id, not for events where you also call identify with that same value. [Migrating – considerations]Given that: - It is very plausible that calling identify with an anonymous $device: ID is the reason you’re ending up with distinct_id = "$device:123..." and no $device_id on those users.
- The docs do not state that Mixpanel will later “fix” this and retro-populate $device_id in that misconfigured pattern, and your 2‑month observation suggests it will not.Because the documentation does not explicitly cover this misuse case, I can’t state with certainty that this is the only cause, but it is the most consistent explanation with the guidance provided.What to change going forward (per docs)
- Ensure mixpanel.identify() is always called with your real user ID (e.g. DB ID), not with $device:.... [Identifying users simplified – best practices]
- Let the SDK manage $device_id automatically, or explicitly send $device_id for anonymous events and $user_id for identified events. [Understanding simplified ID merge]For the already-affected users, the knowledge sources don’t describe a supported way to retroactively “repair” missing $device_id in this specific scenario, so for concrete remediation you’d likely need to contact Mixpanel Support with example profiles and event payloads.
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 don’t provide a single consolidated list of “limitations if you never call identify,” but they do describe behaviors that imply some important constraints. I’ll stick to what’s explicitly covered.
1. No linking of pre‑ and post‑login behavior
Identity management is what lets Mixpanel stitch anonymous sessions across devices and across anonymous → logged‑in transitions into one user. If you never call identify (or otherwise use $user_id / $identify server‑side), then: - Each $device_id (or anonymous distinct_id) is treated as a separate user. [Identity management in action]
- You cannot accurately analyze funnels or journeys that span “before login” and “after login” for the same person, because Mixpanel has no way to know those sessions belong to the same user. [Identity management in action]
2. Limited cross‑device / cross‑platform stitching
Without identity management: - A user on web and mobile will appear as two different users (two distinct_ids / $device_ids). [Identity management in action]
- Reports that depend on “true unique users” across platforms (e.g. DAU/MAU, retention, funnels) will over‑count users and fragment their history.
3. User Profiles are harder to use or may be missing
User Profiles are tied to $distinct_ids, and the docs recommend: - “We recommend waiting until after a user is identified before setting user profile properties.” [Identifying users simplified – FAQ]
- “Avoid creating profiles for anonymous users.” [Identifying users simplified – best practices]If you never identify: - You either don’t create profiles at all, or you create profiles for anonymous IDs that will never be merged into a stable user identity.
- Any profile properties you set for anonymous users are not preserved when IDs are later linked to a $user_id (if you ever start identifying later). [Identifying users simplified – FAQ]
4. Harder querying and troubleshooting by your own user ID
Best practices explicitly say to: - Track your own user ID as a super property and as a user property, and to call identify with that ID. [Identifying users simplified – best practices; Identifying users original – FAQ]If you never identify: - You won’t have a stable $user_id in the identity cluster.
- You can still send your own ID as a normal event/user property, but you lose the built‑in identity resolution and have to rely on those properties manually for analysis and debugging.
5. No use of ID Merge features
ID Merge (identity clusters) is what lets Mixpanel: - Merge $device_id and $user_id (Simplified) or anonymous and identified IDs via $identify / $merge (Original). [Understanding simplified ID merge; Identifying users original – server-side]If you never identify / never send $user_id: - You effectively don’t use ID Merge at all, so each anonymous ID is its own cluster and cannot be combined into a single user across time/devices.---The docs do not say that specific Mixpanel features (e.g. funnels, retention, cohorts) are disabled if you don’t call identify; you can still run all reports on anonymous users. The limitations are about data quality and user‑level continuity, not about UI features being turned off.
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.
