Most observability practice was built for servers you control end to end. Hanson Ho spends his time on the part of the stack nobody controls at all: the millions of individual phones your app actually runs on.
Hanson Ho is the Android architect at Embrace, a company focused on user-centric observability for mobile and web, and an approver on the OpenTelemetry Android SDK. Before Embrace he worked on Android performance and reliability at Twitter/X, Salesforce and SAP.
Backend observability has decades of shared practice behind it — controlled environments, infrastructure you own, predictable failure modes. Mobile has almost none of that. Ho's argument, built from years of watching what happens when an app leaves the data center and lands on hundreds of millions of devices in the wild, is that mobile observability has to be built around a different question entirely: not whether the system ran correctly, but whether the person holding the phone actually got what they came for.
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.
Why mobile observability is harder than it looks
Ho's list of reasons starts with something structural rather than technical: most mobile teams have simply never had to actively collect production data the way backend teams have. A small mobile shop often has no backend infrastructure to receive telemetry or dashboards to visualize it, so they default to whatever the platform gives them — Google's Android Vitals, for instance, which reliably catches large, obvious failures like a startup crash but says nothing about a subtler regression affecting one segment of users.
The deeper structural issue is that most mobile teams don't own their app's entire workflow. Unlike a backend service where one team can reason about the whole request path, a mobile app is built from modules that different teams and even different vendors' libraries control — which makes instrumentation inherently more brittle, especially across refactors. Add genuinely difficult environmental conditions on top — intermittent connectivity, unpredictable OS-level throttling that can slow a device without warning, the need to cache and batch data efficiently rather than burning bandwidth or battery — and collecting good mobile telemetry is a harder engineering problem than it looks from the outside, before anyone has even decided what to do with the data.
My passion is basically connecting users to observability in general, and making their experience the final arbiter of whether something is successful.
Fragmentation, and why "slow" doesn't mean the same thing twice
Android's device and OS fragmentation is real, but Ho is careful to frame it correctly: it's an amplifier of an existing problem, not a separate one. Even on identical hardware, runtime conditions vary constantly, and — more importantly — user expectations for what counts as "slow" vary by person and context. A one-second response might feel instant to someone used to worse, and frustratingly slow to someone used to better.
That's why Ho anchors mobile measurement around the delta, not the absolute number. If you can hold everything else constant and vary just the response time, the difference in how many users complete the workflow — the drop-off between one second and ten — is the thing that's actually measurable and actionable, in a way an absolute performance number in isolation isn't.
Benchmarking only goes so far. Production data really tells you what happens in the wild.
Why some signal loss on mobile is fine
Adam raised a common instinct: trust backend telemetry completely because it's reliable, and treat client-side data as inherently suspect because firewalls, privacy tools and dropped connections all reduce what you actually receive. Ho's reframe is that you don't need every signal, provided the loss isn't systematically skewed toward a particular device, OS version or user segment — because mobile observability is fundamentally a large-sample statistics problem, not single-system monitoring. With enough devices, the law of large numbers means a real regression will surface in the data you do get, even with some inevitable, evenly distributed loss.
That framing also reshapes how to think about percentile metrics like P95. They're a useful benchmark, but Ho calls the specific percentile "a bit of trivia" next to the more important work of finding exactly where users are falling down — by diffing across app versions, device conditions, or time windows, and drilling into what specifically changed for the users on the wrong side of that line.
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.
From telemetry to something worth calling operational intelligence
The step from raw mobile telemetry to genuine operational intelligence, in Ho's account, starts with aggregation. Once you're tracking a workflow's success rate in aggregate — a typical 85% that suddenly drops to 80% — the size of your user base does the rest of the work: even a handful of percentage points is statistically significant at scale, and matching that drop against a release timeline usually points straight at the cause, since mobile app versions are discrete and traceable in a way gradual backend rollouts often aren't.
The instrumentation philosophy that makes this possible is deliberately minimal at the start: track success or failure for your single most important workflow first, rather than trying to capture everything at once. Rich context — geography, device tier, app version — can be layered on afterward to speed up investigation, but the initial signal that tells you something is wrong doesn't require it. Ho's pointed advice for teams overcomplicating this: if you can't capture every detail, that's fine — a clean signal on the one workflow that matters is worth more than a noisy signal on everything.
Why some apps can't afford to be slow, and others can
Stakes vary sharply by category, and Ho is specific about why. Rideshare and food delivery apps have low stickiness — users have no loyalty to the app itself, only to the outcome, so a slow experience sends them straight to a competitor. Banking sits at the other end: switching banks over a clunky app is a much bigger decision, so tolerance is higher, though not infinite.
Latency also compounds in ways that are easy to underestimate on mobile specifically. A slow parsing step that costs 100 to 200 milliseconds on a fast device can cost multiple seconds on a low-end phone under real-world conditions — and without production data, that gap is invisible, because no reasonable benchmarking setup tests every device and network condition combination a real user base actually experiences.
Embrace's philosophy: track success, not execution
Asked what he'd pitch as Embrace's core philosophy, Ho's answer is consistent with everything else in the conversation: the thing that matters isn't how long the CPU ran or how much memory was used, it's whether the user got value from the interaction. Embrace's "User Journeys" feature reflects that directly — tracking funnel drop-off similarly to product analytics, but tied to the underlying technical performance data that explains why a conversion rate moved, not just that it did.
That user-first framing extends to how Ho thinks about linking mobile and backend data together through OpenTelemetry's shared context — letting a team follow a single user action from a tap on a screen through to the backend systems handling the request, rather than treating frontend and backend telemetry as two unconnected data sets.
Why open standards matter even more on mobile
As an OpenTelemetry Android SDK approver, Ho is direct about why standards matter here specifically: they reduce the friction of actually using the data once you've collected it. If a backend team already has OpenTelemetry-based tooling and semantic conventions in place, mobile telemetry that speaks the same language plugs into infrastructure that already exists, rather than requiring a second, mobile-specific stack built from scratch. He compares it to a penalty kick in football — being on an already-understood standard puts you close to goal with good odds, instead of having to build up play from your own half every time.
That interoperability also matters for mobile observability's status inside larger organizations. Teams with an "enterprise observability" mindset can be slow to treat mobile as a first-class citizen precisely because it sits outside the data center — adopting the same standard the backend already uses is one practical way to close that gap.
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
- 0:08:30 — Device fragmentation, and why "slow" is relative to the user
- 0:11:49 — Why some signal loss on mobile is completely fine
- 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
About the guest
Hanson Ho is the Android architect at Embrace, a user-focused observability platform for mobile and web, and an approver on the OpenTelemetry Android SDK. Before Embrace he spent time at Twitter/X, Salesforce and SAP, working on Android performance and reliability at scale.
Where to listen
Related content
- Getting the right signals: Mobile observability with Embrace and SquaredUp
- The Single Pane of Glass in Modern Observability
- How to get complete CI/CD pipeline observability
- Why dashboards still matter in the age of AI
Ho's whole argument comes down to seeing whether users actually succeeded, not just whether the infrastructure behaved. If you want that same clarity across the rest of your stack, you can start using SquaredUp for free.
