Customer-Centric Observability: Experiences, Not Just Metrics

Martin and Jess recently conversed with Todd Gardner of RequestMetrics as part of the O11ycast podcast. We don’t normally write blogs based on these conversations, but there were impactful comments in that episode that bear repeating. You can listen to the full conversation if you wish. Let’s get into it!

Frontend observability

Frontend observability is a tricky problem. No website is free of errors or slowdowns; sites break down in weird ways for all kinds of reasons. Accounting for every possible combination of platform, browser, extensions, and (sometimes baffling) user behavior would be an impossible task. 

How do we decide which errors are important? One useful framework for making these frontend development decisions is customer-centric observability.

The user experience is what matters

Customer-centric observability is all about the user experience. If a problem doesn’t rise to the level of being logged as an error but it causes an issue for the user, it’s more important than an error the customer never perceives. All the observability, logs, and metrics in the world are meaningless if the actual experience of using the application is bad. 

No user thinks, “Well, the application won’t load for me, but at least Hypothetical Company has great distributed tracing on the backend! I love that Hypothetical Company can model my terrible experience accurately and I am excited to start and/or continue giving them money.” 

Maybe some users somewhere have thought that, but they’re not exactly a large enough segment of the market to be a good target audience. 

How can we get real observability into the user experience? 

Separating frontend signal from noise

There is no shortage of tools that provide insight into what’s happening on your app’s frontend. Google Analytics tells you where data came from, security tools tell you when your page has bad JavaScript, performance tools give you page load times. 

Each of these tools, however, adds more JavaScript to load. And, each of them is limited in scope and typically aligned to a specific role or department. Let’s say page A and B on an app both experience intermittent slowdowns on some devices. What does that actually mean to the user? 

We know generally that faster load times are better, but as Goodhart’s law reminds us, the specific metric shouldn’t become the target. What matters is the impact. “How fast is fast enough?” is not an easy question to answer.

Combining data from these different tools lets us answer the question of impact. When the slowdown happens on page A, conversion rates drop by 50%. When the slowdown happens on page B, conversion rates aren’t impacted. That’s the approach of customer-centric observability. A slowdown or error that looks identical from the load time metric alone can have a vastly different impact on the user experience. The holistic experience of using the app is what’s important.

Conclusion

The frontend is the proverbial final frontier of observability. I recommend listening to the rest of the conversation that inspired this blog post. 

Jessica has also written about the state of OpenTelemetry in the browser. It’s an area of ongoing work.

Interested in client-side instrumentation for browser applications using Honeycomb? We have you covered with this in-depth whitepaper.