Why we redefined sessions (And why it makes your data better)

Here is the short version:

• What Embrace previously called a “session” is now called a “session part.”
• What Embrace previously called a “stitched session” is now simply called a “session.”

In practice, a session is now the full, continuous arc of a user’s time in your app, from open to close. A session part is a smaller slice within that, the same granular unit that was previously called a session.

We are also updating the stitching window. Previously, five minutes of inactivity would end a session. Going forward, that threshold moves to 30 minutes of inactivity, with a 12-hour maximum session duration. If you have a use case for configuring these thresholds, please reach out to your CSM or email us with these examples.

These definitional changes bring Embrace in line with how most tools in the observability space handle sessions, and more importantly, they match the way your team naturally thinks about user behavior. What’s more, this change is the building block that unlocks valuable new metrics to measure user experience.

A visit-level session is what makes metrics like engagement duration, bounce rate, and abandonment rate possible, the kinds of signals web teams have relied on for years that have never had a true mobile equivalent. It also enables concepts like issue density and user resiliency so you can see if an issue merely slows a user down, or causes them to give up completely.  And ultimately, this is the first step on a longer road toward capabilities like Core Mobile Vitals and user happiness scores. We will share more about all of these as they come online.

While this is a terminology and model change, not a data change, we want to be upfront: some of your metrics on our curated pages will shift slightly. Your existing metrics on custom dashboards, alerts, and metrics API will stay the same, so you should not see any breaking changes. The labels for metrics on the dashboard will be updated to match the new nomenclature.

Because rate-based metrics like crash-free rate are now calculated at the session level rather than the part level, a single session may now contain more than one crash. A crash triggers the end of a part, but it does not end a session. This means crash-free rate and similar metrics may look a little different than before. The changes should not be dramatic, but you will notice some differences, and we don’t want that to catch you off guard.

We have more details in our documentation on exactly which metrics are affected and what to expect.

We have built a transition experience to make this as smooth as possible. When an existing Embrace customer logs in to the platform after your SDK update rolls out, you will see a brief modal detailing the changes. From there, you will enter a transition period where you can toggle between session-derived and part-derived metrics side by side, allowing you to compare your dashboards, check for unexpected deltas, and adjust any custom reporting you have in place.

For each customer account, the permanent switchover to session-derived metrics will happen once two conditions are met:

• At least 75% of new sessions are coming in on an updated SDK, and
• At least 30 days have passed since your first new session part from an updated SDK is observed

After that, your fixed dashboard experiences will show session-derived metrics only. Part-derived metrics will still be available in custom dashboards for anyone who needs them for continuity or historical comparison.

Deployment of the updated Embrace SDK is required for this change to take effect. We are updating all web and mobile SDKs. The updates are backwards compatible, but some method names are changing to reflect the new terminology. For example, methods that previously referenced a session will be updated to reference a part instead, reflecting that sessions now represent the full user journey across multiple parts.

New accounts created on the updated SDK will only ever know the new definitions.

Full details on method name changes are in the SDK documentation.

This change does not affect our pricing model. Embrace has always billed on the more granular unit of engagement representing discrete user interactions, and that’s not changing. What is changing is the term we use to identify that unit. In the old lexicon, this was called a session. Moving forward, this will be called a session part. Contract terminology will be brought up-to-date during renewal cycles. As always, we are happy to work with your team to answer any questions.

One thing worth knowing: some API endpoints, data destinations, and standard metrics will continue to use the old terminology for a short period after launch. In the coming months, we are planning to update those and we will make a separate announcement when that happens. In the meantime, if you are pulling data programmatically, know that references to “session” in those places still mean what they used to mean.

This is not a breaking change. Nothing in your existing setup will stop working overnight. You have a comfortable transition window, your dashboards will not break, and the old metrics will remain accessible in custom dashboards even after the permanent switchover. If you are a new customer who has implemented the updated SDKs, your metrics will be session-based from day one.

Your CSM is always available to walk you through what this means for your specific setup. We’ve updated relevant sections of the Embrace documentation to reflect this change, and you can read more about it here.