Unity’s built-in analytics and crash reporting is like the dashboard of a car. It can tell you the basics, but if you care about maintaining and getting the most out of your engine you need a good mechanic. We’ve previously covered that gamers care about one metric above all, regardless of genre: stability. Having your mobile game not suffer from crashes, memory leaks, or ANRs (app not responding) has a direct correlation with increasing both the retention and LTVs (Life-Time Values) of your gamers.

In this piece we’re going to discuss the pitfalls of relying on the built-in Unity tools as well as why mobile games will need a good monitoring SDK at all.

Why does any of this matter for my mobile game?

Mobile gamers have brutal expectations and demands. Quick pill to swallow: Your mobile game is probably not unique in its genre, and if it is unique and currently successful then copy-cats are just around the horizon. Defending your established moat and retaining an active player-base is absolutely critical to your app’s success and your company’s revenue stream.

But Unity has built-in analytics and crash-reporting features…

It does, but they are baseline minimum features designed to be a jumping-off point, but are nowhere near comprehensive for delivering the necessary reports to ensure stability and performance of a mobile game. This isn’t us saying “don’t use it” — we’re telling you “don’t rely on it.”

In fact, Unity’s analytics are great for everything game-related: they give you good data on your core users, their behaviors, and revenue streams. Unity’s crash reporter is equally useful as a good starting point for basic information — but this is only useful for the issues that are easy to solve. When your game expands in features and needs, you’ll inevitably hit a ceiling and realize that the tough issues require much more than basic information to resolve.

But just like how your car’s dashboard can’t tell you that your tire treads are worn out or that your brakes need changing, Unity’s tools can only be relied on for the absolute basics. Mobile engineering teams need far more information than what Unity can provide to shorten their TTIs (Time to Identify) and TTRs (Time to Resolution) and provide a stellar experience for gamers.

Information is paramount

You really can’t compromise when it comes to the data generated for each mobile issue. In fact, how the mobile engineering team is able to respond and prioritize an issue is directly impacted by the level of the crash report’s fidelity and overview of the data’s scope.

The scope of the crash log is truly what makes or breaks the TTIs and TTRs. For some reason, traditional mobile engineering is expected to simply “make do” with limited information.

Let’s use an example:

The most effective way to get information about problems in your game is to monitor and log it. Input from customers/gamers is certainly helpful but can be unreliable. So a crash happens, and Unity’s built-in tool gives you the basics:

  • Stack trace, 1 for each thread
  • Stack memory
  • CPU register information
  • Exception or signal code/message

You might realize that this is the baseline to qualify being considered for a crash reporter, just like a car’s dashboard is the baseline to qualify as a “diagnostics report”. In essence, Unity’s crash reporting system is as effective as turning on the Check Engine light on your car’s dashboard, then you drop it off at the mechanic so they can do the diagnostic testing to figure out what’s wrong. For mobile engineering, this report would be viewed by the PM or Engineering Lead and then assigned to whichever engineer who is A: free and hopefully B: is “close enough” to the issue to be able to resolve it.

What follows may seem very familiar to most engineers:

  1. Look at the report, pore over the stack trace, and analyze where things could have gone wrong
  2. Identify the issue (hopefully?) and attempt to resolve it
  3. Push and test a solution
  4. Tested solution failed to resolve issue, possibly resulted in new issues popping up
  5. Look over the report again, pore over the stack trace, and analyze where things could have gone wrong

This is a case of not having a comprehensive report in the first place, also colloquially called the “blind” approach. In the worst case scenario, the generated crash report doesn’t even contain the relevant information necessary to aid the engineer in identifying the cause of the issue.

In summation:  the application became unstable, crashed, and generated a bare minimum “crash report”. An engineer (or four) were sent on a wild bug chase with faulty information and engineering resources were wasted. (Even worse, new bugs popped up while trying to fix the crash.)

Information is truly the pain point here.

Unity’s own crash reporter admits that it is not all-inclusive with its reporting: “iOS crash reporting cannot capture crashes caused by the application running out of memory and then being closed by the operating system.”

This is why we liken Unity’s built-in tools to a vehicle’s dashboard. Use it, but don’t rely on it. When things break down, a better report will fast-track the ability of any engineer to locate the source of the crash and fix it.

What relevant information should be included in these logs and reports to aid mobile engineering teams in reducing their TTIs and subsequently, their TTRs?

  • Networking – seeing slow or failing first and third party calls
  • User session replay – viewing the user actions and technical events that make up every user’s experience
  • Session stitching – combining proximate foreground sessions to uncover issues that originate in previous sessions
  • Session properties – tracking features, user segments, regions, etc. to inspect the data you care about
  • System and background crashes – detecting crashes that traditional error monitoring solutions miss (like memory leaks)
  • Intelligent crash deduping – identifying and solving the root cause of a crash
  • Logging and breadcrumbs – investigating user flows throughout the app to identify shortcomings

How Embrace helps mobile gaming teams

Embrace is a data driven toolset to help mobile engineers build better experiences. We are a comprehensive solution that fully reproduces every user experience from every single session. Your team gets the data it needs to proactively identify, prioritize, and solve any issue that’s costing you users or revenue.

 

Need help improving the performance and stability of your Unity games? Take our SDK for a spin!

Request a demo and see how we help teams set and exceed the KPIs that matter for their business!