Mixpanel has fully retired its legacy /decide endpoint, the API older SDK versions used to fetch feature flags, A/B test assignments, and some autotrack configuration at runtime. Teams running current SDKs were migrated to the newer flag-delivery mechanism automatically and won’t notice anything. Teams still running an older SDK version somewhere in their stack — a legacy web snippet, an unmaintained internal tool, an old mobile build still in the wild on devices that never auto-updated — now have code making calls to an endpoint that no longer answers.
The failure mode here is quiet by design. A /decide call that used to return feature-flag values now returns nothing useful, and most integrations were written to fail gracefully to a default state rather than crash. That’s good engineering practice in isolation, but it means a broken flag fetch looks identical to a flag intentionally set to its default — nobody gets an error, a dashboard doesn’t turn red, and the only symptom is a feature-flag rollout or experiment that quietly stops behaving the way it’s supposed to for a subset of users.
Data Points to Track
- SDK version distribution: the Mixpanel SDK version in use across every client surface — web, iOS, Android, and any server-side integration — so you can identify exactly where a legacy version is still deployed
- Feature-flag fetch success rate: whether flag-delivery calls are completing and returning expected values, tracked separately from whether the app rendered a default fallback
- Fallback-to-default rate: how often a feature flag resolves to its hardcoded default rather than the value Mixpanel would have assigned, since a spike here on affected clients is the clearest signal of a broken dependency
- A/B test assignment consistency: whether users are landing in the experiment variant their cohort assignment expects, or silently defaulting to control
- Legacy client population: device or session count still reporting an SDK version old enough to have depended on
/decide, so you know the actual blast radius rather than guessing from release notes
Setup Steps
- Audit every Mixpanel integration point across web, mobile, and server-side code for the SDK version pinned in each, treating any version predating the current flag-delivery mechanism as an update candidate regardless of how minor it seems.
- Add an SDK-version property to your own event payloads so you can query your own analytics for exactly which sessions are still running an at-risk version, rather than relying on package manifests alone.
- Instrument a fallback-triggered event any time a feature flag or experiment assignment resolves to its hardcoded default, so a rollout that quietly stops targeting correctly shows up as a countable metric.
- Force-update or gate legacy mobile builds that can’t reach current app-store versions, since those devices will keep depending on the retired endpoint indefinitely without a client-side fix.
- Re-run a full audit of active experiments and feature-flag rollouts immediately after any SDK upgrade, confirming assignment consistency before trusting the results of anything currently running.
Actionable Insights
A rising fallback-to-default rate isolated to a specific SDK version is the fastest way to catch this before it skews a live experiment’s results — if a meaningful slice of an A/B test’s population silently defaulted to control instead of getting their assigned variant, the read-out on that test is compromised even though nothing technically errored. Cross-reference fallback rate against SDK version distribution first, since the fix is almost always an update, not a code change to the flag logic itself.
The broader lesson is that any feature-flag or experimentation dependency on a third-party endpoint deserves its own health metric, distinct from your product’s own uptime — a silent default-fallback failure mode doesn’t look like an outage, but it can invalidate a quarter’s worth of experiment data if nobody’s watching for it.
Related Resources
Need help tracking this in your app?
Our team sets up analytics pipelines for mobile and web teams every day. Talk to us and get your first events flowing in under an hour.
Talk to an expert