Mobile teams can be notified of issues from many sources, such as user complaints, bad app store reviews, and error tracking tools. However, the notification alone frequently lacks the context necessary to identify and solve the problem. In this post, we’ll go over why accessing individual user sessions is the best way for mobile teams to fix bugs affecting the user experience.

Mobile teams lack context surrounding problems

Have you ever seen an app store review written like the following?

The 1-Star Review

The problem with reviews like these is not that they exist. We actually want users to let us know when our apps deliver sub-par experiences so we can improve them.

The real problem is that the review doesn’t provide enough user and device information about the issue.

  • Is this the first time the user opened the app?
  • Was this a cold start or a launch from the background?
  • What version of the app are they running?
  • What device and OS do they have?
  • What was their network connectivity?

Without sufficient information to isolate the specific environment the problem occurred in, it becomes incredibly difficult to reproduce the issue.

The CEO problem

Your CEO approaches you—having attempted to access the mobile app—and asks you to solve the blank screen they encountered.

Does the above scenario sound familiar?

You might feel there’s more information here than in the previous example. After all, you know what OS your CEO uses, what version of the app they’re running, their device, and more.

But what was the real issue?

Your CEO can only point to the symptom, but not the cause. A blank screen could stem from any number of root causes:

  • The application is crashing.
  • An endpoint is failing.
  • There was a loss in network connectivity.
  • A web view failed to load.
  • The OS killed an app process.

Without knowing precisely what was happening in the app, we’re left to explore a ton of possibilities.

Mobile has too many variables

In mobile, there is no end to the unique combinations of experiences and environments our users have. Without specific context about how a user experienced an issue, a developer could easily spend hours or days trying to reproduce it. And that is not counting the additional time it takes to implement a solution.

With a smaller user base, it might be possible to reach out to customers directly and speak with them about their experiences. But users often don’t know the issue that’s plaguing them. They might conflate a networking issue with a crash or lead you down any number of rabbit-holes.

You need a way to get as close to the user experience as possible without having to watch over a user’s shoulder.

This means that, for any user experience, you need data like the following:

  • User device information
  • Network calls and their status codes
  • Logs and breadcrumbs
  • The views and activities a user visited
  • The order and timing of the complete user journey through your app

Basically, you need access to the user session.

What is a user session?

A user session is everything a user did from the time they launched the app to the time they stopped it (force quit, backgrounded, terminated by the OS, etc.). This includes both user actions and technical events of the app itself.

User actions include things like which screens they navigate to and where they tap on the screen. Technical events include things like network calls and logs.

Mobile tools vary in their completeness in presenting this information, so it’s important to select one that gives your mobile teams actionable data to solve their tough issues.

The user session provides context into all of the events the user experienced that may have led to the main issue they faced. And it’s important to use both device-side and server-side monitoring to get a complete picture here. For example, a server-side tool might register an endpoint as healthy, but the network call could still take too long to process on the device, leading to freezes and force quits. With device-side context, mobile teams are better armed to identify the cause of negative user experiences.

With access to device-side user session data, you can understand the actual user experience. You can discover issues like:

  • Slow network calls, or ones that fire out of order, leading to bugs.
  • Users abandoning key user flows like checkout or purchase because they fail or take too long to complete.
  • Users facing blank screens because of failing web views.
  • Slow startup times stemming from blocking the main thread or bad actor third-party SDKs.
  • Memory leaks causing background crashes.

Ideally, mobile teams have access to every user session. That way, they can look up any user and immediately reproduce the issue. Additionally, if multiple users report the same issue, you’ll be able to compare individual events in each session to spot anomalies.

How can we get access to user sessions?

You have two options when it comes to providing developers with the data they need to deliver a stable app:

  • Buying third-party tool(s).
  • Building your own homegrown tool.

When choosing, it’s important to keep in mind the following questions:

  • Are your developers prepared to build and maintain internal tooling rather than work fully on your application?
  • Will your internal tooling provide enough coverage for mobile?
  • Will you use the same tools your backend teams use, even though they were not built for the needs of mobile?
  • How will you monitor performance in addition to stability?
  • How will you identify issues that do not lead to app failure but nevertheless result in lost revenue and user churn?
  • Is the third-party tool comprehensive and includes all the necessary data in the same place?

The mobile landscape moves quickly, and the best chance to succeed against best-in-class apps is to continually ship stable features that provide wonderful user experiences.

For most teams we work with, developers are most productive when they can do two things:

  • Spend less time identifying, prioritizing, and solving issues
  • Spend more time building features

It’s possible you can achieve these goals with internal tooling. Larger companies can afford to dedicate entire teams to internal tooling. They can completely customize what they build for their workflow. However, when deciding whether to build or buy, it’s important to account for the scope of what a complete tool looks like and the maintenance that comes along with it.

Teams often don’t realize just how big the gaps are in mobile. They might build their own logging or analytics, and then end up buying third-party tools to supplement their internal tooling. This results in slower onboarding when developers change teams, an increase in tooling complexity, and a lack of external support.

In comparison, when you buy a mobile-only tool, you get access to a wealth of resources:

  • Tooling – built specifically for the needs of mobile teams
  • Support – experts to talk to and who can help with troubleshooting, reporting, and benchmarking
  • Alerts – proactive alerts so you don’t have to cover everything yourself

We’ve seen mobile teams eschew third-party tooling because it wasn’t built specifically for their needs. That is increasingly no longer the case. As mobile becomes a more integral part of our lives, the tooling dedicated to it has improved dramatically.

It’s time to consider a comprehensive platform that is built for mobile and can empower your team to ship the best app possible.

How Embrace can help

Embrace is a data driven toolset to help mobile engineers build better experiences. If you’d like to learn more about Embrace, you can check out our website or  request a demo.

Or dive right into how we can help your mobile teams: