The Only Mobile Metrics Worth Reporting

Most monthly app reports lead with daily actives, session length and screens per session. None of those has a published threshold, and none of them has a consequence attached by anyone but the person reading the slide.

Two metrics do. Google publishes exact numbers for them and states what happens when you cross the line, which makes them the only figures in a mobile report that are not a matter of interpretation.

The two with a published consequence

Android vitals, updated 26 August 2026, defines bad behavior thresholds for user-perceived crash rate and user-perceived ANR rate, and is explicit about the effect:

"If your app or game exceeds a bad behavior threshold, Play may reduce the visibility of your title. Play may also show users a warning on your store listing."

Two things in that chart deserve attention.

The ANR threshold is stricter than the crash threshold. 0.47% against 1.09%. Google treats a freeze as worse than a crash, which is the reverse of how most teams triage — a crash produces a stack trace and a ticket; a freeze produces a user who assumes the phone is broken. If your bug process prioritises crashes because they are easier to see, it is prioritising the metric with the looser threshold.

The per-model threshold exists because averages hide things. An app can sit comfortably under 1.09% overall and be at 8% on one phone model — unusable for everyone who owns that device, invisible in every average. That is precisely the failure a monthly report built on aggregate numbers cannot show.

And three more with exact numbers

Android vitals also defines excessive startup times, measured with Time to Initial Display:

Read these as floors rather than goals. Being under the threshold means you are not flagged; it does not mean the app feels fast. But they give you something a product conversation usually lacks: a number that is not a matter of opinion.

The honest limit on all of this

These are Android store rules, not a universal standard. Apple provides metrics through App Store Connect and MetricKit, but does not publish bad behavior thresholds with a stated consequence.

So a report that presents "crash rate under 1.09%" as a cross-platform pass mark is overstating it. What you can say honestly is that one platform has published the line and the other has not, and that being on the right side of a published line is worth more than being on the right side of an internal target somebody invented.

What a monthly report should contain

If the thresholds above are the only figures with consequences, the report writes itself:

1. User-perceived crash rate, overall and for your worst device model.
2. User-perceived ANR rate, same two views.
3. Cold start time, against the 5-second line.
4. The three worst device models by each metric, because that is where an average is lying to you.
5. Whatever business number the app exists to move — orders, bookings, completed tasks — which is yours to define and is the only reason the app was built.

That is five things. Everything else — session length, screens per session, retention curves — belongs in a diagnostic view you open when one of those five moves, not in the document a stakeholder reads.

Where we say no

We do not report daily actives as a headline. It rises when marketing spends and falls when it stops, and it tells you nothing about whether the app works.

We do not report averages without the worst device model beside them. An average that hides an unusable phone is not a measurement, it is a reassurance.

And we do not treat crash-free sessions as a quality metric on its own. A user who never crashed and never came back is counted as a success by that number, which is how a report can improve while a product dies. The product question sits in the app-versus-website decision, not in the crash dashboard.

What to do this week

1. Open Android vitals in Play Console and read the two core stability metrics against the thresholds above.
2. Switch the view to per-device and find your worst model. Compare it to 8%.
3. Check cold start against 5 seconds, and note that the threshold is not a target.
4. Cut your monthly report to five lines. If a number has no threshold and no consequence, it is a diagnostic.
5. Fix ANRs before crashes when you have to choose, because the threshold says the platform does.

If you want the reporting set up so that the five lines come out of the tooling automatically rather than being assembled by hand, tell us what the app is meant to move — or see how we scope this on the mobile app development page.