Do you know what a metric is? And why these metrics are important?
Back in the day, if I needed to look something up, I’d pull out my trusty Webster’s dictionary and start flipping through its pages and look up “metric.” It can take a minute or two to find what you want. Unless I just happened to open the dictionary and luckily ended right in the “ME” section. Has that happened to you?
Today, these definitions are provided about as fast as you can type — you just Google the word you need. And within milliseconds sometimes, you have your answer. It’s amazing!
So, you Google “define metric,” and you get:
a system or standard of measurement
In my last article, I talked about mobile performance and the three important performance metrics to look at optimizing when developing your app.
They are availability, throughput, and response time. We need to be able to measure these metrics so that we can understand how we can make them better.
But why?
Why are these metrics important? Why is performance important?
To many, especially when an app is being developed, performance is usually considered an afterthought. People tend to either don’t care, or they don’t have the time to worry about performance.
I’ve worked with app developers a number of times over the years, and what I’ve found is that they’re usually strapped for time when it comes to development timelines for an app. What’s often most important during those times is to get the app released with the features they want or have been requested to include as quickly as possible.
When the app is being marketed, it needs to happen as well as it can be. Much focus, deservedly so, is put into marketing the app.
If they’re doing PR that will be used, that needs to be done as well as it can be done.
But performance?
It’s usually considered not as big a deal. So some may wonder, “Well, why does it matter?”
I’m going to get into some of that.
The 25 percent
In the AppDynamics study I mentioned the last article, it mentioned how venture capital firm, Kleiner Perkins, did a study and found that some 25 percent of mobile apps make up Internet traffic. So a lot of the apps out there are going across the Internet. The SDKs, APIs, and ads I mentioned in that article all have data going across the Internet.
Many apps make money through advertisements. Each of those ads showing up on a user’s screen is a call out over the network to Google, Apple, or whatever ad network is being used. If the user’s phone is bogged down with something else, or using too much memory, those ads may take extra time to show up.
We have to not forget about performance. We have to be concerned about it. It may be considered a low-priority task, but you can forget about it at your own app’s peril.
Just like you focus on certain features of your app, you have to focus on performance like it’s a feature as well.
Let’s talk about a couple of reasons:
1. Users want it all
We can’t afford to forget about performance, not only because of app issues, but also because users want it all.
The Compuware report mentioned previously states that users expect their apps to load in about two seconds. Similar reports from app vendors Dynatrace, New Relic, and others show similar numbers.
Even studies from SEO reports from Google and others show that site speed is becoming more and more important. Site speed is now a factor in Google’s Page Rank algorithm.
Speed is a feature
So speed is becoming more and more important. It’s always been important to performance people like me who analyze applications for a living and making sure they’re as fast as possible. But it may not be as much the case for others, even those in IT since IT is so broad.
For those people, you need to know that your users want their apps to respond in about two seconds or less. This is what these studies are showing us. Anything beyond two seconds, and these users start to think about other things and moving on.
Once the app starts taking anywhere close to five or 10 seconds, a lot users are leaving your app.
These studies have shown time and time again that this two-second number is something developers and app owners need to seriously look at. You need to do some app testing upfront to make sure that you’re somewhere around two seconds.
Something to think about as well is that it’s not a cut-and-dries type number. A lot of this depends on your app and how much the user wants the app. I’ve heard before that a bad app in a good market trumps a good app in a bad market any day.
Are you GE?
It also depends on who makes the app. At the end of the day, if you’re Google, Facebook, or, who knows, GE, users might be a bit more lenient with something a little slower than two seconds.
But if you’re an indie developer, a small app owner or Gary’s Electric trying to get your app about how to save on electricity bills in potential customers hands, you probably can’t afford anything much slower than two seconds.
If that’s you, you definitely want to look at your app’s speed. The bottom line is that you want your app to be fast. And if it’s not, your users will leave, and likely head to your competitor.
2. Too little too late?
One of the things that are done by developers, app owners, and others is to implement user feedback tools. One of those tools is called Apptentive.
The hope is that if your app is having some problems or issues, a user can just tap a “feedback” button so that this user can get in touch with you and let you know about it. The app may be too slow for them or it may have just crashed. Whatever the problem, the user can communicate this information to you or your team so that you can identify the cause – and hopefully fix it as soon as possible.
Well, the problem with this is that it may be too late. Depending on the experience that your users have with your app, they may be able to somewhat overlook it, if it happens once, maybe twice. But as we saw in that AppDynamics study, the chances of that are low. Maybe they won’t mind if they love your app and they have some past good experiences with your app. Again you’re not Facebook or Google. You’re GE — Gary’s Electric.
The thing is, you really don’t know. As I mentioned in the previous article, mobile users are a different kind of user. They know that there usually are a lot of different options out in the app world for them. And if your app isn’t cutting it, they could just as easily move on to another app.
So you must remember that getting user feedback is good. It’s important to have that. But in some cases, it may be too late.
3. Read those reviews?
The next reason not to forget about performance is your app’s reviews. Unlike feedback – where it may be too late – checking your app’s reviews is definitely too late.
There are a number of different ways outside of the app stores to see the reviews that your app is getting. There are a number of places to get them.
You have companies like Mobile Action, Appfigures, SensorTower, and App Annie. And this is just a short list of the ones I’m even aware of and used. They make it easier to see all of your reviews from across many countries when compared to the app stores.
So you can see there are a lot places to get those reviews. But the problem is that by the time you’re looking at your reviews for potential problems that current users are experiencing, it’s really too late. Looking at your reviews can help you identify issues to make your app better for future potential users. But the current ones, especially the user who wrote the review, are likely gone and moved on to a competitor because of the frustration they faced with your app.
What can you do?
How do you make sure that your app is in fact ready for “prime time,” as they say?
What you do is this — you test early and you test often.
But why do you want to do that? Well, here are four reasons:
Baselining
One of the things you always want to do is know how your app typically functions. When you’re testing early and often, it helps you to develop a baseline of your app’s performance.
I’m not a developer, but I’ve worked with many over the years. I know lot of developers typically use some version checking software, like GitHub or Bitbucket — or at least they should be. When they check in their code, they’re saving a working copy of the code up to that point after whatever tests they had done.
A lot of these types of software do it automatically for you, but you’re able to keep a “good” copy, and that basically is your baseline. It’s how you saw everything was working well at the time. Once you’ve checked it in, it’s like saying, “Okay. I know this is the one that works.” That is your baseline.
Baselining shows you how everything is performing. So when you test your app for performance early, you are able to capture that baseline and be able to compare it to others later on. You now know what an acceptable number is for your app’s response time and overall performance.
Identify issues
Another thing testing early and often does is it helps you to faster identify issues. When you have that baseline, you can more easily compare it to what you know is a good performance.
If you have an app and some user is coming to you saying, “It’s slow” — or someone, like a beta tester, says, “It’s slow. It takes five seconds to launch” — if you have a baseline, you know whether that’s good or bad. If your baseline tests have shown that that it takes two seconds to launch your app, then something bad has caused an increase in launch time.
You now have something to work off of, but if you’ve never had that baseline and they tell you it takes five seconds or something like that, then you have no clue as to whether this response time is good or bad. So having that baseline is very important.
Pre-release testing
Another reason to test early and often is for pre-release testing. This helps you make informed decisions about what you can improve with your app — helps you know if there are potential issues that you can take a look at.
One of the things that I want to use as an example of this is the 2012 U.S. presidential election. During election season, many gear up for all the debating, the back and forth, and all the extra stuff that comes with that. People seem to pay special attention to any mistakes the candidates make in their campaigns.
Well in 2012, the Republican candidate, Mitt Romney, released an app called “A Better America.” The app was released, somehow the developers missed that “America” was misspelled.
I don’t know what kind of pre-release testing that they did, if they did any at all, but this was missed. People who had already downloaded the app took screenshots and you can clearly see that America was spelled wrong.
You want to be able to do some pre-release testing to make sure that you can identify some of the areas that you can improve in. In the case of this Mitt Romney app, I wouldn’t really say that this is a performance issue, but testing upfront in general is something that helps you avoid these types of situations.
Post-release testing
Another reason to test early and often is post-release testing. You want to be able to test after your app has been released. An example of that of when that maybe didn’t happen was with ESPN, the sports and entertainment cable network.
Before the start of the 2016 National Football League season, ESPN released a fantasy app. But the app kept crashing when users tried to open it.
I doubt that ESPN didn’t do any pre-release testing, but clearly they did not anticipate this issue. And not enough, if any, post-release testing was done.
Users were complaining, and ESPN had to apologize and scramble to identify what the issue was that caused this crashing problem. Being able to do some post-release testing — and then monitoring, once that app has been released — is very key and important.
In the next article, I will talk about the things to focus on when doing these types of tests.
Photo credit: Pexels
