Use case

Understand what app users do

The store tells you how many people installed it. It tells you nothing about whether they opened it twice.

The situation

An app is harder to measure than a site and the questions are the same: which screens people reach, whether they come back, and whether the last release made things worse.

The specific difficulty is that you cannot fix a bad build by deploying. It is out there until people update, and the first warning is usually a review.

How it is done

1. Add the SDK. There is one for Android, iOS, Flutter, React Native, Kotlin Multiplatform, Unity, .NET and Electron. Each takes the app ID and one call to start.

2. Name your screens carefully. An app has no URL, so the name your SDK reports is what appears in every report. This is the one decision at install time that you cannot cheaply change later.

3. Read stability per release. Crash-free rate, split by app version. In total it is meaningless during a staged rollout, because a bad build reaching a tenth of users dilutes to a tenth.

4. Annotate the release. The difference between "engagement fell in week 12" and "engagement fell when we shipped 4.2".

5. Expect old builds to keep reporting. The wire format is frozen at version 1, so a build published two years ago still sends data. Filtering by version is how you read the reports, not an advanced feature.

Where this stops

There is no speed data, and there will not be a fake one. An app SDK sends when a screen happened, not how long anything took. Inventing a number from the gap between two screens would measure how fast somebody taps. If you need launch times and frame rates, that is a performance tool.

No heatmaps, no recordings, no feedback widget. Those need a page to attach to. An app gets screens, sessions, retention and errors, and that is the whole list.

A crash-free rate hides a feature that fails quietly. The app stays up and the screen does nothing. Screens per session is the signal there, not stability.