About 16 minutes reading · 29 minutes practice
You will produce: A rating-request brief with implementation review and feedback-routing responsibilities.
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.
Quick check · pick a response
Make the call before you scroll.
Go deeper: practical decisions and tradeoffs
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.
Platform references for this work: Apple — Ratings and reviews · Google Play — Analyze ratings and reviews · Google Play — User ratings, reviews and installs
Your turn · two-minute exercise
Try the scenario. Make your case.
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.
Autosaved on this browser. Your work is private and does not sync between devices.
Your step-by-step procedure
Map value moments and identify inappropriate interruption points.
Review the current platform guidance with the implementation owner.
Specify an authentic request flow without incentives or selective positive-review routing.
Define operational checks and a process for learning from critical feedback.
Completed example · use the reasoning
A rating-request journey
Gabriel’s take: “Give us five stars” is not feedback. It is begging in a dialog box.
Constructed teaching material, not a client result. Adapt the evidence and product facts before using it for your app.
Meaningful moment
User successfully saves and revisits a journal
Eligibility
Use the platform-supported request mechanism and current constraints
Avoid
Incentives, coercion or routing only happy users to the store
Fallback
Let users reach support independently
Review
Inspect the actual app journey, not only the prompt copy.
Your turn · repair the decision
Make the call. Then compare.
Replace “Rate five stars to unlock export” with an appropriate plan.
Autosaved on this browser. Your work is private and does not sync between devices.
Explore the supporting case and interpretation
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: Ask after a meaningful completed task
Assessment: Review for suitability
Reason: User has experienced value
Flow choice: Reward a five-star review
Assessment: Reject
Reason: Manipulates feedback
Flow choice: Offer support to all users
Assessment: Useful parallel route
Reason: Does not condition honest reviews
Flow choice: Guarantee prompt display
Assessment: Reject assumption
Reason: 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.
Build a handover someone can use
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.
Your ASO assignment
Use your own app and evidence, or work through the teaching case. Keep your observations separate from assumptions and explain the reasoning behind your decisions.
Build something · track your work
Your assignment checklist
Tick each item after you have produced the work. Reading it does not count. The strategy deck will survive.
0 of 3 tasks checked.
Autosaved on this browser. Your work is private and does not sync between devices. Course completion is recorded separately.
Assess 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 to catch
- Offering benefits in exchange for favorable reviews.
- Treating the public rating average as a direct causal metric of one prompt change.
Sources and further reading
Platform references reviewed 29 September 2026. These sources support platform capabilities and constraints; the teaching frameworks, assignments and illustrative cases are original course material.
- Apple — Ratings and reviews — Review requests, responses and user-feedback practices.
- Google Play — Analyze ratings and reviews — Review analysis and response workflow.
- Google Play — User ratings, reviews and installs — Prohibition of manipulated and incentivized feedback.
Your ASO lesson notes
Use this space for your assignment, evidence and handover. Your notes save automatically in this browser. Download a copy to take with you.
Notes stay on this device and are not submitted to ASO Agency.
Complete your assignment with the Interactive ASO audit checklist.
Loading your progress…
Progress is saved only in this browser. It does not sync across devices. Mark a lesson complete after doing its exercise.