▸Example Mixpanel call (the "before")
import Mixpanel
let mixpanel = Mixpanel.mainInstance()
// Identifies the user — distinct_id becomes joinable to email forever:
mixpanel.identify(distinctId: userId)
mixpanel.people.set(properties: [
"$email": email,
"$name": fullName,
"plan": "pro",
])
mixpanel.track(event: "Paywall Purchase", properties: ["value": price])Most analytics SDKs back the unsent event queue with SQLite or UserDefaults / SharedPreferences — so a phone that's been confiscated, jailbroken, or restored from backup still contains analytics state. Respectlytics's queue is RAM-only, flushed on a 30-second timer; unsent events on force-quit are lost by design, in exchange for zero on-device forensic surface.
☑Remove Mixpanel cleanly
-
1
Remove
pod 'Mixpanel'fromPodfile -
2
Remove
implementation 'com.mixpanel.android:mixpanel-android:...'frombuild.gradle.kts -
3
Remove
mixpanel-react-nativefrompackage.jsonormixpanel_flutter:frompubspec.yaml -
4
Delete any
Mixpanel.mainInstance().people.set(...)oridentify()calls — those are the people-profile entry points -
5
Replace
mixpanel.track(...)call sites withRespectlytics.track("event_name") -
6
Delete the Mixpanel project (or revoke the project token) in the Mixpanel admin once you've confirmed no more events arrive
-
7
If you used Mixpanel-driven cohort exports for marketing, plan the cutover to whatever replaces those flows
⇋Mixpanel vs Respectlytics — ram-only event queue
| Mixpanel | Respectlytics | |
|---|---|---|
| Event queue persistence | SQLite / UserDefaults / SharedPreferences | In-memory ring buffer |
| Disk usage for analytics | 0.5–10 MB typical | 0 bytes |
| Forensic data on jailbroken / rooted devices | Persistent identifiers + queued events | None |
| Survives force-quit before flush | Yes | No (events lost — by design) |
❓Frequently asked questions
Doesn't this reduce data quality?
Marginally — typical force-quit-before-flush event loss is 0.5–2% depending on platform. For aggregate metrics (funnel rates, feature adoption, release deltas) this is invisible. For per-event reconciliation it would be a problem, but per-event reconciliation isn't a use case Respectlytics supports.
What's the actual flush cadence?
30 seconds by default, plus a flush on applicationDidEnterBackground (iOS) / onPause (Android). Most events reach the network within seconds of being fired.
Is this safe for crash analytics?
Crash analytics is a separate concern — use Sentry, Crashlytics, or Bugsnag (with their own crash-aware queues). Respectlytics is product analytics; crash data has different recoverability requirements and lives in different tools.
Why is this a privacy feature?
Devices that are jailbroken, rooted, restored from backup, or forensically imaged routinely surface analytics artifacts — distinct_ids, queued events, user properties — that survive uninstall in some cases. RAM-only storage moves the dump-recovery surface to zero.