Learning by Example
The 1-Star Android App Review
Deconstructing, Responding, and Avoiding: 3 Real-World Examples
Your code is complete, your tests have all passed, and your app is now published to the Google Play Store. People are downloading it and the early reviews are trickling in and they are positive. Things are really starting to get exciting now. Your users appreciate the obvious hard work and time that you have put into the app. Your confidence is starting to soar and then it happens. You receive the dreaded 1-Star review.
Do not fret my fellow Android developer! For even the greatest, most popular, and most widely downloaded apps in the Google Play Store have all felt the sting of the 1-Star review. In fact I would challenge you to find an app in the Top Charts that has a perfect record devoid of 1-Star reviews.
It is not a matter of will you receive a 1-Star review, but rather a matter of when will you receive a 1-Star review. So with that in mind it is paramount that when you do receive it, you are able to (1) understand what went wrong, (2) respond to it in a clear and respectful way so that you do not turn other potential users off and (3) avoid the same mistake from happening again.
In this article I will present to you two real-world examples of 1-Star reviews and a third example that was a very close call. I will demonstrate what went wrong that led to why the reviews were left and I will show you what could have been done to avoid the reviews from having been left in the first place.
Exhibit 01 — “Nothing Works”!
The first example of a 1-Star review that I would like to exhibit is screen captured below. Whereas some 1-Star reviews provide you with very little useable information, this one was quite clear with what went wrong. The user is very plainly stating that nothing is working for him other than a couple of features. This can understandably be very frustrating, especially since one of the only features that was working for him was the “Donate” feature, ouch!
Now obviously I would not have published the app had I experienced the same issues during my testing. This is, however, a common example of one of the more maddening things that a developer can communicate to their colleagues that are having issues with their software.
So the question becomes: why does it work on my device, but not on their device? If you look again at the screenshot of the review above then you’ll see something very important to this analysis that could easily be missed. A small link in the bottom-right hand corner that says “MORE”. If one were to click on this link then they would see additional details about the device of the user who left the review as screen captured below from this specific review:
With this additional information you as the app developer / tester are now equipped with what a detective might call a lead. You now know the exact specifications of the device that is encountering issues. I had never even heard of a DuraForce PRO with Sapphire Shield device prior to this review, but now that I had this information I was able to easily enough create an Android Virtual Device (AVD) using the AVD Manager inside of Android Studio that could emulate this user’s device. Soon after creating the AVD I was now experiencing the app as the user had experienced it and I could now see first-hand what had led this user to leave the 1-Star review. This was the deconstruction / analysis phase of dealing with the 1-Star review.
Next came the response phase of handling a 1-Star review. Now that I could reproduce the issues that were occurring on this device using the emulator (AVD) mentioned above; I was able to quickly enough fix the issues by providing layouts specific to this lower density device. I then published an app update to the Google Play Store that included these new layouts. Next I responded to the review that had been left (the response is shown below) effectively communicating to the user that an update was available in case they would like to give the app another go. This is a very important step in dealing with a 1-Star review as it may (honestly not often, but may) result in the user updating their review thereby improving your overall app rating.
The final step that I took with the handling of this review was to determine if there was anything that I could do to ensure that this did not happen again. It probably goes without saying, but it is important to understand that when you publish an app that specifies, for example, a minimum SDK version of 19 (KitKat) or 21 (Lollipop) as most apps that are published today do, that your app could be installed on hundreds or even thousands of different types of device configurations. You are obviously not going to have physical devices on-hand for each of these possible configurations and so how do you maximize your testing coverage? One option is to take a reactive approach and handle these types of issues as they are reported, but there will likely be a cost associated with this approach in the way of negative reviews. Another approach is to grow yourself a virtual device farm that includes as many of the more prevalent configurations as possible and create test cases that are then executed on each of the virtual devices within this farm either manually prior to pushing any updates out or automatically as part of your continuous integration (CI) / continuous delivery (CD) pipeline. A third approach would be to leverage a cloud-based device farm that usually consists of both virtual and physical devices. A couple of the more popular cloud-based device farms are Firebase Test Lab and Amazon Device Farm. This last approach may not be feasible for many individual or indie developers as there are associated monetary costs with using these services outside of a very limited usage.
Exhibit 02— Everything Should Be Free, I Hate It!
The second 1-Star review that I would like to exhibit (screenshot is below) is quite a bit different from the first one. This 1-Star review was not left due to any bugs or compatibility issues with the app. Rather this review was left for an app that included in-app products that the user felt very strongly should be made available for free for everyone. One thing that I have learned from attempting to monetize apps is that there is a group of people that exists that have very passionate opinions about having to pay money for anything.
So what can I do with this review? Clearly this person is very unhappy about having to pay money in order to unlock some of the features within the app. That part of the review is plain to see, but how do I address this type of concern and still be able to try and make money from the countless hours that I pour into creating and publishing and maintaining this app?
The answer to that question will probably differ depending on the situation. In this situation, this was an app that had a primary user base consisting of children. Kids do not usually have money to spend on apps or in-app products or app subscriptions and so the money you make with these apps usually comes from the kids asking their parents for the item. When the parents inevitably say “No” as they very often will, or when the kid and/or parent(s) do not have the money to throw at something as unnecessary as an in-app product, the angry and forlorn child will often respond by leaving a very unflattering review for your app. The more thought that I gave to this the more it bothered me. Not only was I depriving kids of something they wanted which was bad enough, but I was also setting my app up for failure as these kids were out for blood and would surely sink my app to the deepest depths of the Play Store ocean with their negative reviews.
The solution that I ultimately landed on was to try and circumvent this grisly outcome by essentially removing the paywall from in front of the locked features. Users could still pay to unlock an item within the app (each item had a cost of 99 cents USD), but for users such as kids that did not want to or could not pay money I offered an alternate mechanism by which they could unlock items. I did this by integrating with what are called Rewarded Video Ads. For every rewarded video ad that the user watched to completion they would earn one credit. Earn 10 credits and you have enough to unlock one of the in-app products. The one word of caution that I would give with this approach and for any app that you attempt to monetize by including ads is that if your app’s audience includes children then you’ll need to ensure that the ad provider that you integrate with is only serving up kid-appropriate content. Otherwise you will find yourself in violation of Google’s Play Store policies. More information can be found here. The screenshot below is from this particular app and it shows a locked feature that can be unlocked either by paying for it the old-fashioned way or alternately by using in-app credits.
This did not stop all of the negative reviews for this app as some users just do not want to pay money or have to watch ads in order to unlock content. However, with this system of earning in-app credits in place and making it so those credits could be used to purchase in-app products I now had a go-to reply for any negative reviews that were left due to locked features.
As for prevention, it can be difficult if not impossible to always predict how users will or will not embrace an element of your app. There are, however, tools available to you so that you don’t have to rely on a crystal ball. For example the Play Store offers alpha and beta channels for acceptance testing your app prior to releasing it. There are also many providers of A/B testing services that allow you to run app experiments. These experiments can help you to make informed decisions that can help you to avoid that 1-Star review.
Exhibit 03 — Blank Screen or Web Page Unavailable
Okay, so this one was not actually a 1-Star review, but rather just comments inside of a discussion board within one of my apps that I happened to see in time to get a quick update out to avoid receiving one or more 1-Star reviews.
Basically it was pretty similar to Exhibit 01 (“Nothing Works!”) only it was very specific in stating that the “Learn” feature of my Bernie 2020 app was not loading a web page as expected. A screenshot of the discussion board from the app is below. Now on my primary test device, a Samsung Galaxy S6 with Android Nougat 7.1.1, everything naturally worked as expected. However, as it turns out, not all of my users are running the app on a Samsung Galaxy S6 with Nougat. Go figure. 😲
So the first step to this problem was again to quickly identify (or deconstruct) why this feature was working on some of my users’ devices and on my device, but not on all devices. This needed to be resolved as quickly as possible so that the 1-Star reviews didn’t start pouring in as users really can be fickle beasts.
It didn’t take very much digging before I came across the following note (screenshot below) in the Android documentation stating that beginning with Android Pie (API level 28), cleartext support in WebViews was disabled by default meaning that either you’ll need to display secure (https) URLs in your WebView or you’ll need to enable cleartext for it.
Thankfully this one turned out to be a simple fix. I just replaced my “http” URLs with “https” ones and I was good to go. I was able to quickly put an app update on the Play Store and I immediately transitioned into damage control mode (responding). To do this I went onto the app’s discussion board and posted that the issue had been identified and resolved and that an app update was available. I got very lucky with this one that no one left a negative review.
So how could this have been avoided? The easy answer here, like most bugs that deal with Android fragmentation, is test case coverage and executing those test cases on a wide variety of device combinations that your app supports. The test cases below exemplify how one might test this scenario.
Everyone who publishes apps to the Google Play Store will eventually receive a 1-Star review. When receiving one, rather than getting upset and throwing things and devolving into a puddle of tears, try instead to ask yourself the following questions:
- Why was the review left (problem identification / analysis / deconstruction)?
- How should you respond to the user who left the review (damage control / potentially get a revised review / if all else fails, threaten bodily harm)?
- What can you do to avoid additional negative reviews from being left (resolving the issue / test case coverage / submitting an app update)?
I hope that this article helped to demonstrate how these questions may be answered and how a 1-Star review can actually be an opportunity to learn and grow as an app developer.
Thanks for your interest!