Analytics tells you what users did. Crash reporting tells you when the code failed. The two answer different questions and should stay independent. The link between them is a single shared opaque token: the session_id.
🎯 Why You Want Both Systems
Crash reporting and analytics get conflated because both fire when something happens in the app. They are different tools:
| Question | Tool |
|---|---|
| "How many sessions completed checkout?" | Analytics |
| "Which screens get the most engagement?" | Analytics |
| "What stack trace caused this NullPointerException?" | Crash reporting |
| "Is this crash specific to one OS version?" | Crash reporting |
| "What was the user doing when it crashed?" | Both, correlated |
🔌 Keep Them Separate (and Why)
Tempting shortcut: send crashes through your analytics SDK or vice versa. Avoid it. Two reasons:
- •Different reliability requirements. Crash reporters need to capture and persist a payload before the process dies. Analytics queues events for periodic flush. Mixing the two compromises both.
- •Different privacy surfaces. Crash reports inevitably include device class, OS, sometimes breadcrumbs with form values. Keeping that data on the crash provider — not in your analytics database — gives you a cleaner blast radius.
🔗 The Session-ID Correlation Pattern
The cleanest pattern is this:
- Respectlytics generates a session_id. RAM-only, two-hour rotation. This is your correlation key.
- On app start, fetch the current session_id and set it as a tag in your crash reporter. Sentry calls this
setTag; Crashlytics calls this a custom key. - When the session rotates, refresh the tag. The crash reporter now has the same key your analytics has.
- Cross-reference in incident triage. When a crash spikes, filter Respectlytics events for the matching session_id to see what users were doing in the lead-up.
The session_id is not personally identifying — it is an opaque, rotating token. You are linking activity records, not users.
🛠️ Wiring Up Sentry
Swift
// On session start / rotation:
let sessionId = Respectlytics.shared.currentSessionId
SentrySDK.configureScope { scope in
scope.setTag(value: sessionId, key: "rl_session_id")
}Kotlin
val sessionId = Respectlytics.currentSessionId()
Sentry.configureScope { scope ->
scope.setTag("rl_session_id", sessionId)
}Crashes now appear in Sentry tagged with the matching session_id. Triage flow: Sentry → grab the tag → filter Respectlytics by session → see the events.
🔥 Wiring Up Firebase Crashlytics
Swift
let sessionId = Respectlytics.shared.currentSessionId
Crashlytics.crashlytics().setCustomValue(sessionId, forKey: "rl_session_id")Same pattern in React Native, Flutter, and Android. Refresh the custom key on session rotation.
Do not pass user identifiers from your auth system to either tool unless you have a specific support need and consent. Stack traces alone resolve most crashes.
📈 The Metrics That Matter
Three numbers cover most of the value:
| Metric | Source |
|---|---|
| Crash-free session rate | Crash reporter (sessions w/o a crash) divided by Respectlytics session count. |
| Conversion-killing crashes | Crashes correlated with sessions that started checkout_started but never reached checkout_completed. |
| Last events before crash | Filter Respectlytics by the session_id from a Sentry alert; sort by timestamp. |
🛡️ Privacy Pitfalls in Crash Data
Crash reporters collect more than you think by default. Audit at least these:
- •User IDs. Off by default in some SDKs, on in others. Verify.
- •IP addresses. Most providers retain them; check the provider's settings.
- •Breadcrumbs from network calls. Request URLs and bodies frequently leak tokens; configure scrubbing.
- •Screenshots / view hierarchy. Some SDKs offer this; it almost always captures user content.
- •Form values in stack traces. If your view-models hold raw input, exception messages can include it. Avoid throwing exceptions with user data in the message.
A crash reporter with PII scrubbing turned on plus Respectlytics for product analytics gives you a stack with two clean data surfaces — without making either system carry the other's risk.
💡 Why session-based fits this pattern especially well
Persistent user IDs in crash reports turn every incident into a privacy event. A rotating, RAM-only session_id is a shared opaque token that lets you correlate without coupling identities. Less risk, same triage signal.
❓ Frequently Asked Questions
Should you use both analytics and crash reporting?
Yes. They answer different questions. Analytics tells you what users did. Crash reporting tells you when the code failed.
Can you correlate Sentry crashes with Respectlytics sessions?
Yes. Pass the Respectlytics session_id to Sentry as a tag and filter both systems by it.
What is a crash-free session rate?
The percentage of sessions that did not produce a crash. A more product-relevant signal than absolute crash counts.
Should crash reports include user IDs?
Avoid them by default. Most crashes resolve from stack traces; persistent user IDs in crash data are a frequent source of accidental PII.
Do crash reporters collect personal data?
Often, yes — by default. Audit the SDK's defaults, turn off what you do not use, and configure scrubbing for sensitive fields.
Legal Disclaimer: This information is provided for educational purposes and does not constitute legal advice. Consult your legal team to determine the requirements that apply to your specific situation, especially regarding the configuration of third-party crash-reporting SDKs.
Related Reading
- Session IDs Are Not User IDs
- Testing Your Analytics Implementation
- Analytics in CI/CD: Automated Event Validation
- SaaS Mobile Companion App Analytics — Where crash-free session rate is a headline KPI