kapa.ai can I send custom user property value to braze cohort streaming?
(edited)
kapa.ai can I send custom user property value to braze cohort streaming?
kapa.ai can I send custom user property value to braze cohort streaming?
When exporting cohorts from Mixpanel to Braze, the exported user data is limited to a fixed set of properties:
$distinct_id
$first_name
$last_name
$partner_user_id
$phone
[Cohort Sync Overview] There is no mention in the documentation of being able to send arbitrary custom user properties as part of a Braze cohort sync. However, there is one relevant customization available: you can set a User ID Property when configuring the Braze integration. This should be a Mixpanel user property that matches the Braze External ID. If you don't set one, Mixpanel defaults to using the $braze_external_id property to match users between the two systems. [Braze Integration] If you need to send additional custom properties to a destination, the Custom Webhooks option does allow you to specify extra properties to export beyond the defaults — but this applies to webhook destinations, not the native Braze integration. [Custom Webhooks] In summary, the native Braze cohort sync does not support sending custom user property values beyond the predefined set listed above.
ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
The knowledge sources provided don't contain information about "local evaluation experiments" or a concept called "jumping variant" in the context of Mixpanel experiments. However, if you're observing unexpected or unstable variant distributions in your experiment, the knowledge sources do mention a related concept: Sample Ratio Mismatch (SRM). This is when the actual number of users in each variant differs significantly from the planned split. Common causes include:
Bugs in the randomization or bucketing logic
Exposure events not firing consistently across variants
Users being reassigned to different variants mid-experiment
[Health Checks] If you're seeing variant counts that seem off or unstable, Mixpanel's built-in SRM health check (using a Chi-squared test) can help detect whether the imbalance is beyond what random chance would explain. [Experimentation Terms] Could you clarify what you mean by "jumping variant"? If you can describe the behavior you're observing in more detail, I can try to point you to the most relevant information.
ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
Based on the knowledge sources available, here's what's relevant to users being reassigned to different variants mid-experiment: Mixpanel's documentation does mention variant reassignment as a known concern. Specifically, for Feature Flags:
"Users will not be reassigned different variants when purely increasing overall rollout %. If rollout % is initially decreased, or if variant splits are altered, then variation reassignment may occur for users."
[Feature Flags] So if your experiment's rollout percentage was decreased or variant splits were changed after the experiment started, that could explain why a user sees a different variant in a new session. Additionally, Sticky Variants is a feature designed specifically to prevent this kind of reassignment:
"If a user is assigned to a sticky variant B, regardless of how variant splits, rollout percentage, or cohort memberships change in the future, the user will continue to see variant B."
[Feature Flags] Note that the control variant is always non-sticky by design — this means control group users can be moved to other variants if allocations change. This could be a contributing factor to what you're observing. Recommendations based on the docs:
Check if variant splits or rollout % were modified after the experiment launched.
If consistent variant assignment is critical, enable Sticky Variants for your non-control variants.
If you want all users (including control) to be sticky, set control to 0% and allocate 100% to other variants.
The knowledge sources don't go into further detail about local evaluation specifics that might cause mid-session reassignment beyond these scenarios.
ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
Based on the knowledge sources, Sticky Variants are not supported in Local Evaluation mode. This is explicitly stated across all server-side SDK documentation:
"Targeting by Mixpanel cohorts and sticky variants are not supported in Local Evaluation mode."
[Go Flags] [Java Flags] [Node.js Flags] This is likely the root cause of the variant reassignment you're seeing. Since local evaluation evaluates flags entirely within the SDK (without calling Mixpanel servers at assignment time), it cannot persist sticky variant assignments for users. To get stable, consistent variant assignments, you would need to switch to Remote Evaluation, which does support sticky variants. The trade-off is that remote evaluation makes a network call to Mixpanel servers at assignment time, which introduces some latency compared to local evaluation. [Feature Flags Implementation]
ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
Based on the knowledge sources, there isn't an alternative solution explicitly documented for achieving sticky variant assignments while still using local evaluation. The limitation is fundamental to how local evaluation works — since flag evaluation happens entirely within the SDK without server calls, it cannot maintain persistent variant state for users. The knowledge sources do describe local evaluation's latency characteristics, which may be reassuring:
"Flag evaluation happens locally within your SDK with minimal latency (<1ms)."
The latency concern with remote evaluation is primarily at assignment time (the network call to Mixpanel servers). However, the knowledge sources note that flag configurations are cached via Google Cloud CDN for global low-latency access, and polling latency for cached calls is quite low across regions (e.g., ~17–29ms depending on region). [Feature Flags Implementation] Additionally, both Node.js and Go SDKs support evaluating all flags for a user at once with remote evaluation, which can help minimize the number of network calls:
"There is also the capability to evaluate all flags for a given user context at once, to avoid needing to make multiple calls to get individual flag variants for the same user. This is particularly useful for remote evaluation to avoid incurring additional network calls." [Node.js Flags]
So while the knowledge sources don't offer an alternative to remote evaluation for sticky variants, batching all flag evaluations into a single call could help mitigate the latency impact if you do switch.
ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
kapa.ai If i want to do experiment or feature flag, and using runtime property filter. Is it correct that during SDK initialization I need to send the custom property in order to do the filter? Can it automatically use the user property info that is already stored in the user / profile property?
Yes, your understanding is correct. For Runtime Targeting, you must explicitly pass the custom properties during SDK initialization (or when updating context). The SDK does not automatically pull from stored Mixpanel user/profile properties. This is consistently documented across all SDKs. For example, in the JavaScript SDK:
"If you are using Runtime Targeting in any of the feature flags in your project, then any properties that you use in targeting should be included in a custom_properties node within context"
mixpanel.init("YOUR_PROJECT_TOKEN", {
debug: true,
flags: {
context: {
company_id: "X",
custom_properties: {
platform: "web",
},
},
},
});The same requirement applies to Android, Swift, Flutter, React Native, and server-side SDKs — runtime properties must be passed explicitly at request time. [Android Flags] [Swift Flags] In summary:
✅ Runtime property filters work, but you must supply the property values yourself at initialization (or context update time).
❌ The SDK will not automatically fetch or use stored Mixpanel user profile properties for runtime targeting.
If you want to target based on properties already stored in Mixpanel user profiles, you would need to use Cohort Targeting instead (which does use stored user properties), keeping in mind that cohorts refresh on a ~2-hour cadence. [Feature Flags]
ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
Based on the knowledge sources, Runtime Events do NOT use historical events — they only count events that occur after the flag is enabled. This is explicitly stated:
"Only events that occur after the flag is enabled count toward activation. Historical events from before the flag was created or enabled are not counted."
[Runtime Events] Additionally, if you disable and re-enable the flag, the timestamp resets and users must perform the event again after re-enablement:
"The flag's 'enabled at' timestamp updates. Users who previously triggered the event must perform it again after re-enablement to receive the variant."
[Runtime Events FAQ] Also worth noting: Runtime Events are designed for client-side SDKs only and are not supported on server-side implementations. [Runtime Events FAQ] In summary:
❌ Runtime Events do not use historical events stored in Mixpanel.
✅ The SDK watches for the event to occur in real-time, after the flag is enabled.
❌ Unlike Runtime Properties (which you pass explicitly at initialization), Runtime Events are monitored automatically by the client-side SDK via mixpanel.track() calls — no need to pass them manually in the context.
ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
Based on the knowledge sources, the variant activates very quickly after the event is triggered:
"The variant activates on the next call to getVariant or isEnabled after the event is reported."
[Runtime Events FAQ] So in practice, there is no significant delay — as soon as the event is tracked via mixpanel.track() and the SDK reports it, the very next flag evaluation call will return the active variant for that user.
ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.