# Lesson 47: App ratings strategy: plan in-app review requests

Coordinate review requests with product value and current platform rules.

Prerequisite: The app’s user journey, support process and rating-request implementation owner.

Teaching examples are fictional unless explicitly identified as platform definitions.

## Foundations

### Earn feedback through the product experience

Review requests should fit a sensible product moment rather than interrupt the user before they receive value. Map when a user can meaningfully evaluate the app and where a prompt would disrupt a critical task. The objective is authentic feedback. Do not frame rating work as buying favorable evidence or manufacturing a public reputation disconnected from the experience.

### Use supported mechanisms and verify rules

Coordinate with developers to use the platform’s supported review-request mechanism and current guidance. Avoid rewards for ratings, review manipulation or flows designed to suppress negative feedback while soliciting only praise. The marketing brief should describe the user moment and measurement need; engineering owns the implementation details and platform behavior, including cases when a prompt is not shown.

### Evaluate the process beyond average stars

Track whether requests occur appropriately, whether users encounter friction and whether review themes expose product issues. Ratings can be delayed, contextual or influenced by audience mix. Do not infer that a new request flow caused every change in the public average. Keep operational logs and product updates beside the observations, and route legitimate criticism into the improvement process.

## Apply the method

### Ask at a meaningful moment without distorting feedback

Identify a moment when the user has experienced the app's value and can reasonably judge it. Avoid interrupting a critical task or asking before the product has done anything useful. Use the platform's supported review-request approach and verify current implementation guidance. Do not promise that every request call will display a prompt; platforms control presentation behavior. Keep the request separate from access to features, discounts or rewards so feedback remains voluntary and genuine.

### Avoid selective positive-review routing

A process that asks whether users are happy and sends only happy users to the store can distort feedback and conflict with platform expectations. Provide support access to everyone without using it as a way to divert dissatisfied users away from honest reviews. Do not ask for a specific star rating or offer incentives. The underlying task is to improve the experience and ask appropriately, not engineer a misleading public score. Review the whole flow, including copy, timing and conditional branches.

### Measure the process without claiming attribution you lack

Track whether the request logic behaves as intended and monitor aggregate rating trends with release context. A new prompt strategy coinciding with better ratings does not prove it caused the change; a product fix may have mattered more. Review complaints for friction introduced by the prompt itself. Coordinate with engineering and support so frequency, eligibility and support routes are maintained. If the implementation changes, preserve the version and timing in the operational log.

## Procedure

1. Map value moments and identify inappropriate interruption points.
2. Review the current platform guidance with the implementation owner.
3. Specify an authentic request flow without incentives or selective positive-review routing.
4. Define operational checks and a process for learning from critical feedback.

## Worked example

Trail Notes considers asking for a rating immediately after launch. The team instead investigates a later moment when a user has completed a meaningful journal action, subject to platform behavior and product review. A proposed “give five stars to unlock export” offer is rejected. Support remains available to everyone, independently of whether they submit a favorable review.

| Flow choice | Assessment | Reason |
| --- | --- | --- |
| Ask after a meaningful completed task | Review for suitability | User has experienced value |
| Reward a five-star review | Reject | Manipulates feedback |
| Offer support to all users | Useful parallel route | Does not condition honest reviews |
| Guarantee prompt display | Reject assumption | Platform controls presentation |

The suitable timing still needs implementation and user-experience review. A completed task is not automatically the right moment for every app. The rejected reward is not improved by changing its size or wording; the incentive itself distorts the request. A support route can coexist with a review request when it remains available to everyone and does not filter who is permitted to provide public feedback.

## Your ASO assignment

1. Draft a request-flow brief tied to a genuine value moment.
2. List prohibited or misleading practices your process avoids.
3. Define how critical themes reach product and support owners.

Redesign a flow that says “Enjoying the app? Yes: rate five stars. No: contact support.” Explain how your alternative invites honest feedback and offers support without filtering sentiment.

## Handover

### Trigger design

Describe the meaningful experience, timing and interruption considerations.

### Flow map

Show every branch, including support access and review-request behavior.

### Policy references

Link current platform guidance and record review of incentives and selective routing.

### Implementation record

Assign engineering ownership and verify supported API behavior without guaranteed display assumptions.

### Monitoring

Track user friction and rating context without overclaiming causation.

## Check your work

- The request follows a meaningful experience rather than coerces praise.
- Platform behavior and rules are verified with the implementation owner.
- Support access is not conditional on a positive rating.

## Common mistakes

- Offering benefits in exchange for favorable reviews.
- Treating the public rating average as a direct causal metric of one prompt change.

## Knowledge check

A proposal asks happy users for public reviews and redirects everyone else away. What is wrong with it?

It attempts to shape the public evidence selectively rather than collect authentic feedback. Redesign around supported, policy-consistent requests and make support available independently. Product criticism should inform improvements, not become something the flow is designed to hide.

## Sources

- [Apple — Ratings and reviews](https://developer.apple.com/app-store/ratings-and-reviews/) — Review requests, responses and user-feedback practices.
- [Google Play — Analyze ratings and reviews](https://support.google.com/googleplay/android-developer/answer/138230?hl=en) — Review analysis and response workflow.
- [Google Play — User ratings, reviews and installs](https://support.google.com/googleplay/android-developer/answer/9898684?hl=en) — Prohibition of manipulated and incentivized feedback.

Platform references reviewed 29 September 2026.
www.asoagency.com