Why Avoid Objects as Event Properties in Status Tracking?

·Nov 04, 2025 11:02 PM·

If I want to have a list of keys and values relating to the status of a list of related options (enabled/disabled) as my event property, why is it recommended against using objects in the documentation as event properties? Would the alternative be to make each status an its own event property instead?

2 comments

· Sorted by Oldest

kapa.ai
APP
·
·
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
kapa.ai
APP
·
·
Based on the knowledge sources, Mixpanel does support objects as event properties, but with limited capacity and specific recommendations.
According to the Supported Properties Data Type documentation, objects have the following characteristics:
- Limited support: "Mixpanel supports object in a limited capacity. We recommend using the five non-object data types for most use cases as they are fully supported in the UI." - Limits: Event Property = 8KB, User Profile Property = 256KB, max 255 keys per nested object with a max nesting depth of 3 - UI support: "Mainly supported in core reports (i.e. Insights, Funnels, Flows, Retention, Users / Cohorts, Events) as filters and breakdowns. Property Names (ie keys) within an object are not supported in Lexicon."
The key limitation is that property names (keys) within an object are not supported in Lexicon, which is Mixpanel's data governance tool for managing and documenting your data structure.
Alternative Approach
For your use case of tracking enabled/disabled status for related options, you have a couple of alternatives:
1. Separate Boolean properties: Yes, you could create individual event properties for each option (e.g., option_1_enabled: true, option_2_enabled: false). This approach would give you full UI support and make it easier to filter and breakdown by each option's status.
2. List property: If you only need to track which options are enabled, you could use a List property containing the names of enabled options (e.g., enabled_options: ["option_1", "option_3"]).
The separate properties approach would provide the most flexibility for analysis in Mixpanel's UI, though it may result in more properties to manage.
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.

Why Avoid Objects as Event Properties in Status Tracking? | Mixpanel Community

kapa.ai
APP
·
·
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
kapa.ai
APP
·
·
Based on the knowledge sources, Mixpanel does support objects as event properties, but with limited capacity and specific recommendations.
According to the Supported Properties Data Type documentation, objects have the following characteristics:
- Limited support: "Mixpanel supports object in a limited capacity. We recommend using the five non-object data types for most use cases as they are fully supported in the UI." - Limits: Event Property = 8KB, User Profile Property = 256KB, max 255 keys per nested object with a max nesting depth of 3 - UI support: "Mainly supported in core reports (i.e. Insights, Funnels, Flows, Retention, Users / Cohorts, Events) as filters and breakdowns. Property Names (ie keys) within an object are not supported in Lexicon."
The key limitation is that property names (keys) within an object are not supported in Lexicon, which is Mixpanel's data governance tool for managing and documenting your data structure.
Alternative Approach
For your use case of tracking enabled/disabled status for related options, you have a couple of alternatives:
1. Separate Boolean properties: Yes, you could create individual event properties for each option (e.g., option_1_enabled: true, option_2_enabled: false). This approach would give you full UI support and make it easier to filter and breakdown by each option's status.
2. List property: If you only need to track which options are enabled, you could use a List property containing the names of enabled options (e.g., enabled_options: ["option_1", "option_3"]).
The separate properties approach would provide the most flexibility for analysis in Mixpanel's UI, though it may result in more properties to manage.
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.

2 comments

2 comments

Alternative Approach

Alternative Approach