Why mobile observability has to start with the user

Most observability practice was built for servers you control end to end. Hanson Ho, Android architect at Embrace and an approver on the OpenTelemetry Android SDK, spends his time on the part of the stack nobody controls at all: the millions of individual phones an app actually runs on.

He explains why mobile observability has to measure whether users succeeded rather than raw CPU, memory or latency, why some signal loss from devices is completely fine, and why the single highest-leverage thing to track first is simply whether one critical workflow succeeded or failed.

Chapters

• 0:01:33 — From Twitter-scale data to user-focused mobile observability
• 0:04:37 — Why mobile observability is technically harder than it sounds

My passion is basically connecting users to observability in general, and making their experience the final arbiter of whether something is successful.

• 0:08:30 — Device fragmentation, and why "slow" is relative to the user

Benchmarking only goes so far. Production data really tells you what happens in the wild.

• 0:11:49 — Why some signal loss on mobile is completely fine

If you can improve the conversion rate, improve performance in a demonstrable way — this is a way for you to get not only job security, but promotions.

• 0:15:24 — From raw telemetry to something you'd call operational intelligence
• 0:19:11 — Why some apps can afford to be slow and others can't
• 0:24:01 — Embrace's philosophy: track success, not just execution
• 0:26:12 — Why OpenTelemetry matters even more for mobile
• 0:30:57 — The one workflow to instrument first if you're starting out

Key takeaways

• The real measure of mobile performance isn't CPU, memory or raw latency — it's whether the user successfully completed the thing they were trying to do.
• Most mobile teams' first hurdle isn't technical, it's structural: they don't own their app's entire workflow, which makes instrumentation inherently more fragile than on a backend you fully control.
• Losing signal from some devices is fine, as long as the loss isn't systematically biased toward one segment — mobile observability is a large-sample statistics problem, not single-system monitoring.
• The simplest, highest-leverage thing to instrument first is binary: did this one critical workflow succeed or fail, end to end.
• Not every app can afford to be slow: low-stickiness categories like food delivery lose users to a competitor instantly, while something like banking has more tolerance — but not unlimited tolerance.
• Tying performance directly to a business metric like conversion rate is, in Ho's words, "a golden ticket" — it's the single clearest way to stop observability tooling looking like a cost center with no visible return.