This is how debugging often goes.
An error alert comes in.
I open the issue.
I find a user ID.
I copy it into analytics.
Nothing.
Try a device ID.
Find a session.
Open the replay tool.
Search around the same timestamp.
Go back to the error tool because I forgot the release number.
Then someone asks whether the user was part of the new experiment.
Open another dashboard.
At some point you're not debugging anymore.
You're doing data archaeology.
Most of the information exists. That's the annoying part.
It just exists in different places.
For one broken checkout session I might want to know:
The user opened checkout at 14.
They had new_payment_flow enabled.
They clicked Pay.
POST /payment/init failed.
A JavaScript exception happened right after.
They clicked Pay again.
Same result.
Then they left.
That's enough context for me to have a useful conversation with the person who owns the payment flow.
And if there's a replay attached, even better.
I don't need four separate investigations.
Mobile has basically the same problem.
Maybe instead of a JavaScript exception the app crashes.
Maybe instead of a page it's a screen.
The shape of the investigation doesn't really change.
User did something.
Software responded.
Something failed.
User reacted.
That's the story I want.
A lot of observability products are getting very good at collecting more data.
I'm not convinced most teams need more data.
They need fewer gaps between the data they already have.
See the full picture across web and mobile.
Connect application health, user behavior, attribution, and product context with ScaleBun.
Explore ScaleBun →