How and When to Ask for Reviews (Including iOS 10.3)

Starting with iOS 10.3, developers will be able to ask users for app reviews and ratings directly within the app, without redirecting them to the app store. When to ask for a review is even more important. How do you think a user would rate your app after an app crash?

How to ask for Ratings and Reviews

In-App (iOS 10.3+)

Starting with iOS 10.3, developers will be able to ask users for app reviews and ratings directly within the app, without redirecting them to the App Store. See here for details.

This is good for app developers, as they can control when to ask for reviews, and the users of your app won't leave the app.

On iOS 10.3 and above, you will use the requestReview() method. It is important to note that you can not call this method in response to a button click. See the SKStoreReviewController class for details.

Your app will, however, support iOS versions earlier than 10.3. For versions before 10.3, continue using the link to app store.

Although you should call this method when it makes sense in the user experience flow of your app, the actual display of a rating/review request view is governed by App Store policy. Because this method may or may not present an alert, it’s not appropriate to call it in response to a button tap or other user action.

RequestReview() May or May Not Show the Ratings Alert

1. Note: 10.3 includes an option to disable these alerts altogether under settings.
2. Function requestReview() always shows an alert box in development.
3. Function requestReview() never shows an alert in apps distributed via Testflight, and...
4. .... Function requestReview() sometimes shows an alert for apps distributed via the App Store, depending on the App Store policy.
5. Also, apps can only prompt customers for a rating or review three times in a year regardless of the version number updates.

Explicitly Asking for Reviews/Ratings Pre-iOS 10.3

To explicitly ask for a review or rating via a button click, and for pre-iOS10.3, app developers can continue to deep link to the app on the App Store.

You can continue to include a persistent link in the settings or configuration screens of your app that deep-links to your App Store product page. 

To automatically open a page on which users can write a review in the App Store, append the query parameter action=write-review to your product URL.

For example, you can deep link to the following link from your iOS app to take you to the Netflix app’s review page directly. You can, alternatively, enter the link in Safari browser on an iOS device.

itms-apps://itunes.apple.com/app/id363590051?action=write-review

Responding to Reviews

Developers will be able to respond to criticism and thank users for positive reviews

Developers and users will be able to edit their reviews and responses

See http://daringfireball.net/2017/01/new_app_store_review_features for further details.

When to Ask for Ratings and Reviews

Asking for App Store Ratings for Your App

It makes sense for app publishers to encourage users to provide favorable ratings, simply because the likelihood of users downloading an app is much higher for apps with high ratings.

There are millions of apps on the App Store, but the number of users who give a rating or review on an App Store is amazingly low.

1. On average, more than 58% of the 3+ million of apps have zero reviews.
2. Of the users who used your app at least two times, only 0.2% to 1.4% rate an app.

To weed out bad apps, iOS originally used to ask for reviews when a user deleted an app.  This obviously led to a bunch of negative reviews on the app store. AppiRator (circa 2009) attempted to circumvent and ask for reviews earlier in the life cycle of the app and is widely used by a number of apps. Users are prompted to rate right away, be reminded to rate later in a few days, or skip rating the current version. Prompting is delayed till the app has been used for a few days and a few times.

AppiRator uses alerts, which are considered very obtrusive and super annoying, and does not account for immediate user experience before asking for a rating. For instance, you don’t want to ask for a rating if your app just crashed, the backend is not responsive or the app took a long time to load.

User Psychology, Attitudes, and Behavior

Every positive and timely managed negative experience helps with app growth.

Even simply asking for ratings at the right time can go a long way in getting favorable ratings, but more importantly, such actions communicate the app publishers’ commitment to providing delightful and engaging app experiences.

A happy user is more likely to rate favorably.  But how do you determine that the user is happy?

Conventional wisdom suggests simply asking the user if they are happy. This is making a decision based on "what people say."

Attitudinal Targeting Techniques

The purpose of attitudinal research is usually to understand or measure people’s clearly expressed beliefs, which is why attitudinal data is used excessively in marketing departments and customer-, partner-, and employee-satisfaction market research surveys.

“What people say” vs. as “what they do” may be different. Furthermore, it is not always convenient to ask questions in an app, as it always disrupts the workflow of an app user.

Behavioral Targeting Techniques

Actions derived from “what people do” in your app and “how they use it” are always better indicators of user experience in your app. So, using the example topic of asking for ratings, how can you determine a good time to ask for them?

A good time to ask for ratings is when a user does something positive in your app, like winning a difficult game or invites other users or advocates to your app.

On the other hand, look at the app above. Images failed to load. It is not a good idea to ask for a rating when a user is not having the best experience.

In determining when not to ask for a rating:

You don’t want to ask for a rating if your app just crashed, the backend is not responsive, a resource failed to load, or the app took a long time to load.

Once you determine it is a good time to ask for ratings, you may still want to ask the user if they would like rate your app simply to get permission to redirect them to the App Store – but you can personalize the message.

Let’s say you noticed a user solved a puzzle faster than the average, and the user has used your app more than three times in the last seven days. It is time to ask for a rating with a personalized message: Wow! You are a great strategist and solved the puzzle in under 7 minutes! Would you help us out and rate us on the App Store?”

Alternatively, say you noticed a user started to share content with Slack three times, but never successfully finished it. Time to redirect to support. “Seems like you are having trouble with sharing content from the app. Would you like to see a 90-second video and/or let us know how we can be helpful?”

Here are some positive and negative experiences you can look for in your app.

Representative Positive Experiences

• User made a repeat purchase. Ask for a rating while avoiding alerts.
• User does something positive in your app, like winning a difficult game
• User reaches the Wall of Fame.
• User finishes a task faster than the average time to finish said task.
• User finishes a task successfully.
• User invites other users to join your app via SMS, message, or email from you within your app
• User advocates for or shares your app on social media.
• User opts in for push notifications.
• User shares her phone number with your app.
• User opts in to share contacts, geo location.
• User shares content on social media.
• Uses your app consecutively in the last three days.
• 7D user stickiness (number of times user used app in last seven days) is three or more.
• 30D user stickiness (number of times user used app in last 30 days) is between 10 and 14.
• User makes an in-app purchase.

Representative Negative experiences

• App crashed for the first time.
• App crashed for the second time within an hour.
• App crashed for the third time in the last seven days.
• An image resource did not load.
• It took longer than 3 seconds to load page on Wi-Fi.
• It look longer than 5 seconds to load page on cellular.
• Save operation failed.
• Backend is not responsive.
• User started to share content but never successfully finished.
• User declined push notifications.
• User declined access to contacts.
• User clicked on area of screen where there is no action associated or is confused by the UI.
• An engaged and active user has never used a specific screen