> For the complete documentation index, see [llms.txt](https://doc.batch.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://doc.batch.com/guides-and-best-practices/message/in-app-messaging/how-to-ask-users-for-an-app-review.md).

# How to ask users for an app review?

Getting ratings and reviews is essential in any app marketing strategy to encourage downloads and get useful feedback.

## What is an app review request? <a href="#h_d35de8b8bf" id="h_d35de8b8bf"></a>

You can ask your users to rate your application directly by displaying the **native request** (provided by Apple or Android), or by displaying first a **pre-request**.

### Native request <a href="#h_ab7f4fa3ff" id="h_ab7f4fa3ff"></a>

Apple and Android provide APIs to ask your users to rate and review your application. Thanks to these APIs, your users see a native prompt appear directly in your application, as below:

<figure><img src="https://downloads.intercomcdn.com/i/o/398421377/8703c261b06cc47ed3ddde0b/image.png?expires=1744884900&#x26;signature=44d9fcc35c7b35ec254e7ba9f5f4dc32b6937c9927397c1ff79315f1a08dc119&#x26;req=dykvEst%2FnoZYFb4f3HP0gA3Jpg2GymChltfIopqvhE4qwY%2B4Sd3s0fvNI4cK%0Am6R6ey6XM49JrGvO%2Bg%3D%3D%0A" alt=""><figcaption></figcaption></figure>

### Pre-request <a href="#h_52907a8340" id="h_52907a8340"></a>

Batch recommends setting up a pre-request with Batch before displaying the Apple or Android native prompt. Users first receive an In-App message asking them if they want to rate the app. If they answer yes, the native prompt appears.

<figure><img src="https://509463063-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfiAYaWDWqtFZeXxyg67F%2Fuploads%2FriQMgztEZNcyU4fG3Vv8%2FCleanShot%202026-10-20%20at%2018.23.42%402x.png?alt=media&amp;token=7ab56c69-bd15-48e7-b437-2d29d2ae0962" alt=""><figcaption></figcaption></figure>

## Why should I set up a pre-request? <a href="#h_d7bcb288fa" id="h_d7bcb288fa"></a>

### iOS <a href="#h_00a0a9d52f" id="h_00a0a9d52f"></a>

On iOS, the native prompt relies on the **Apple SKStoreReviewController API** ([Apple Developer documentation](https://developer.apple.com/app-store/ratings-and-reviews/)). Keep in mind that:

* The prompt can be displayed up to three times in a 365-day period. If users leave a rating, it will not be possible to ask them again for a year.
* Users can disable rating requests in their iOS settings (**Settings → App Store → In-App Ratings & Reviews**).

<figure><img src="https://downloads.intercomcdn.com/i/o/398422186/d013b69880bede9b162fb535/Untitled.gif?expires=1744884900&#x26;signature=da08f47b755a1d5a6ddf482083e387a5d55b54a920b74cdf2fcb8db68e9de81a&#x26;req=dykvEst8nIlZFb4f3HP0gFRTOuf5xaxcskTFPpwv9TcE80dmyONzRi981gTb%0AqX6pdHs6fEyzGbZVUw%3D%3D%0A" alt=""><figcaption></figcaption></figure>

* There is no way to know if Apple’s prompt has already been displayed to a user.
* The API doesn’t provide metrics on ratings and reviews.

### Android <a href="#h_5fd0988698" id="h_5fd0988698"></a>

On Android, the native prompt relies on the In-App Review API ([Android Developers documentation](https://developer.android.com/guide/playcore/in-app-review)). Keep in mind that:

* Google may refuse to display the native prompt if it has already been triggered recently ("for example, less than a month", according to Google’s documentation).
* The API doesn’t provide metrics on ratings and reviews.

By setting up a **pre-request** with Batch, you make sure the native prompt is only displayed to users who agreed to rate your app, at the right moment, and you can measure how many users clicked on your pre-request.

## How to set up a pre-request? <a href="#h_b538aa46cd" id="h_b538aa46cd"></a>

To set up a pre-request, create an [In-App automation](https://doc.batch.com/getting-started/features/customer-engagement-platform/orchestration/in-app-automations) with a button that opens the native request provided by Apple or Android.

### Who? <a href="#h_feb27bdfd8" id="h_feb27bdfd8"></a>

It is important to choose the right targeting for rating campaigns. In the **Targeting** step of your automation, target engaged users, for example users who have been active recently. This will allow you to get feedback from people who regularly use your app.

It is also useful to target users based on your industry. If you sell items, you can target users who have made a purchase in the last few months. Similarly, if you provide a service, targeting people who have signed up for a subscription is a good idea.

{% hint style="warning" %}
You must offer app ratings **to all your users**, not only satisfied ones.
{% endhint %}

### When? <a href="#h_81913e1ed2" id="h_81913e1ed2"></a>

It is essential to display the pre-request at the right time, for example when a customer has finished a purchase or made a specific engaging action. Select this action as the **trigger event** of your In-App automation.

{% hint style="warning" %}
Be careful not to interrupt the buying process!
{% endhint %}

As the native prompt can only be displayed a limited number of times, add a **capping** to your automation so users don’t see the pre-request too often.

### What? <a href="#h_63a668d1cd" id="h_63a668d1cd"></a>

Create your message with the [In-App Composer](https://doc.batch.com/getting-started/features/customer-engagement-platform/content/composer), for example with a **Fullscreen** or **Modal** format, as below:

<figure><img src="https://downloads.intercomcdn.com/i/o/405683788/e970a8ddd89314c76175dee2/image.png?expires=1744884900&#x26;signature=644d7198efa66a54d484a897e741ff2856b83808c731a914e576c312d640f6b2&#x26;req=cCAiEMF9molXFb4f3HP0gHh6r2xH8jlmcb7XtgBkr8ZLSEB8IabaPHfWUJ1C%0AbOaBsmpEnbEkBu6Ujw%3D%3D%0A" alt=""><figcaption></figcaption></figure>

Keep the content neutral, such as “**Rate our app**”.

Then, redirect users to the native request, not to a feedback survey if they are not satisfied with your app. To do that, select the **Rating** [action](https://doc.batch.com/getting-started/features/customer-engagement-platform/message/in-app) on your button:

<figure><img src="https://509463063-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfiAYaWDWqtFZeXxyg67F%2Fuploads%2FIQidoUDil5rmoVNThr4e%2FCleanShot%202026-10-20%20at%2018.14.14%402x.png?alt=media&amp;token=1bae3f18-03f8-479f-829b-f9fb184d11a2" alt=""><figcaption></figcaption></figure>

* **iOS:** the button displays the native app rating prompt.
* **Android:** the button displays the Google In-App Review prompt. The Play In-App Review library must be included in your app (see the [Android SDK integration](https://doc.batch.com/developer/sdk/android/sdk-integration)).

### From a push notification

You can also ask for a review right after a user opens a push notification, with a **Mobile Landing**:

1. In your push message, open the **Open app or link** menu and select **Show Mobile landing** (requires SDK 3.0 or higher).
2. Select (or create) a Mobile Landing template and edit its content.
3. On the button, select the **Rating** action.

The same limits apply: on iOS, the native prompt can be displayed up to three times a year, so enable **Capping** in the timing settings of your orchestration. On Android, the Play In-App Review library is required.

See [Push](https://doc.batch.com/getting-started/channels/push) and [In-App & Mobile Landing](https://doc.batch.com/getting-started/features/customer-engagement-platform/message/in-app).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://doc.batch.com/guides-and-best-practices/message/in-app-messaging/how-to-ask-users-for-an-app-review.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.