Feature Request: allow to split health statistics by Mobile OS, Desktop OS, Browser etc

[ghost]

[copied from discussion below, since there originally wasn't any detail here]

we are a game studio company that uses unity to build our games, with unity we create our iOS version and Android version of our game. both under the same Sentry Project. in sentry, under the Releases dashboard, Discovery and Widget, we can see our health statistics for the project (crash_rate, crash_free_rate for users or for sessions) the problem is that those statistics do not come with the information of which os.name it belongs too and there is no way to filter so we can truly understand if there is difference between Android Health and iOS health.

Request: A way to filter the release health data by OS.

┆Issue is synchronized with this Jira Improvement by Unito

[getsantry[bot]]

Assigning to @getsentry/support for routing ⏲️

[Kobby-Bawuah]

Hello @matanplay, could you further elaborate for whoever has to work on this?

[ghost]

@Kobby-Bawuah yes. we are a game studio company that uses unity to build our games, with unity we create our iOS version and Android version of our game. both under the same Sentry Project. in sentry, under the Releases dashboard, Discovery and Widget, we can see our health statistics for the project (crash_rate, crash_free_rate for users or for sessions) the problem is that those statistics do not come with the information of which os.name it belongs too and there is no way to filter so we can truly understand if there is difference between Android Health and iOS health.

[hubertdeng123]

Thanks for writing in, I'll make sure the appropriate team sees this

[getsantry[bot]]

Routing to @getsentry/product-owners-releases for triage ⏲️

[roggenkemper]

@matanplay just to clarify - your request is a way on the Releases page to filter by os.name in your case, so you can see the release health per os, not just per project since they both come from the same Unity project

[ghost]

exactly.

[lobsterkatie]

@matanplay - I'm going to put this into our backlog and bring it to our PMs for consideration.

[Angelodaniel]

In addition to that I would like to be able to see the crash_free_rate on a per page basis in Android and iOS.

"Our aim is to assess the health of our screens. Based on the information gathered, we will notify the relevant teams to ensure the stability of the page."

[Dhrumil-Sentry]

@matejminar @ale-cota - Will this be possible with the work being done for Developer Metrics?

[ghost]

@Dhrumil-Sentry while we are on this request - I would like to add a bit more "filtering" to release health: 1 - filter by country/geo (ability to answer what is my crash free rate in the US alone, or India alone for a specific release and specific mobile OS) 2 - filter by user id (ability to answer what is the crash free rate for the latest sessions of a specific user) 3 - is it possible to expose DAU? as a property we can use ?

[lobsterkatie]

@matanplay - those are interesting ideas. They're not possible currently, in terms of the data we send along with crashed/non-crashed sessions, but might be possible with the metrics offering we're developing. I'll let @matejminar and @ale-cota weigh in on that score.

[Angelodaniel]

Hey @lobsterkatie @Dhrumil-Sentry, would this proposed solution on Metric still be something for the future? Please revisit this topic as more customers are requesting the above feature 🙏

[Dhrumil-Sentry]

There are no concrete plans to support this feature as of now. We will keep the issue to open to gauge interest from users

[mortargrind]

@Dhrumil-Sentry Hello! 👋 I was redirected here by our Sentry support for our org.

I can't seem to use the regular built-in tags like browser/os etc. in crash rate related widgets in Dashboards. This is a critical feature for our org.

Because we have many web apps that are rendered inside native host apps, which can be an iOS or an Android app. Since the underlying browser engine implementation and the surrounding host application implementations are different, the crash rate will be different too. We need crash frate for each different OS to calculate separate golden metrics for host apps. These golden metrics are quite critical for our long term strategy as the whole org.

One hack I can think of is having 2 different Sentry projects for the same physical app to be able to use the "project" filter. But that would have an immense side effect on every other thing. The other hack might be using different release tags just for Sentry config (instead of v1.0.0 v1.0.0-ios/v1.0.0-android), which might have a lower impact on the developer workflow.

My general feedback related to this is: Dashboarding & querying things in general should be more flexible and elastic. Every app is different and as a result any developer working on any app might need to search for a slightly different answer based on their requirements and situation. If we continue on with this instance; the inability to have OS information for release or crash related queries seems completely arbitrary from the user's perspective (I am sure there are technical reasons for this situation based on the decisions you have made on your end in the past that cannot be changed easily). It's not predictable or scalable which questions (query) we ask (execute) from our perspective.

[getsantry[bot]]

Routing to @getsentry/product-owners-dashboards for triage ⏲️

[Dhrumil-Sentry]

Thanks a lot for this feedback. There are indeed technical reasons that make this infeasible to do today and it's not an easy lift in terms of technical effort and cost to make these tags available.

We will keep this feedback under consideration