Define what the person needs to experience first
Write down the reason someone installed the app in the first place. A scanner needs to return a usable result. A budgeting tool needs to help someone understand a transaction. A learning app needs to make a lesson worth completing. The eligibility rule should reflect that purpose rather than an arbitrary delay after installation.
List the conditions that could make the task incomplete: a failed upload, an unanswered permission request or a result that has not finished processing. Suppress your own eligibility event when those conditions apply. This helps you judge the request in context without predicting whether the person will choose a high or low rating.
Choose a pause in the journey, then verify it
Take one candidate moment, such as saving an item and returning to the collection. Walk through it on a real supported device. Check what the person sees before the request and what they would naturally do afterward. A request that interrupts the next obvious action may feel premature even though an event called “success” has fired.
Write a short acceptance checklist for your team: the task has finished, the result is understandable, the user can continue, and the app does not repeatedly interrupt the same journey. Use the first release of this rule as an experiment. Revise it when observations show that the chosen moment does not fit how people actually use the app.
Test the moment before asking for a review.
Publish a brief for the journey around your rating request and collect candid feedback.
Get feedback on your appUse the native request and a deliberate store link
Follow the current StoreKit or Google Play review documentation when implementing the contextual request. The platform decides whether the native flow appears. For a deliberate settings action, provide the appropriate store destination. These are two different user paths, so test each one independently and describe it accurately in your interface.
For any explanatory copy outside the native card, ask for an honest experience rather than a specific star score. Keep the system card intact. A plain settings label such as “Review this app” is easier to understand than a promise of rewards or a claim that everyone should leave five stars.
Offer support and feedback without screening the rating
Keep a support link available where a person can find it, whether they like the app or are frustrated by it. Explain what information helps with a problem: app version, device and steps. Avoid placing a private support route behind a negative opinion while routing only favorable opinions toward a store review.
Google specifically advises against questions about a user’s opinion before or during the review card. You can collect usability feedback as a separate task with its own purpose. Give that form a clear label, such as “Report a problem” or “Send product feedback,” so someone understands where their message will go.
Measure what happened without inventing review conversions
Keep eligibility, request attempts and published store results distinct. A request attempt is something your app can record; it does not prove that a person saw a dialog or submitted a review. When comparing releases, note any acquisition campaign, major bug fix or change in the audience that could also explain the outcome.
Before shipping the prompt, use RateMyApp to test the surrounding journey. Ask a developer to attempt the core task and report any friction. They can optionally leave a community rating after submitting their report. Use that score and the written findings as product feedback, while tracking App Store and Play ratings in their own consoles. Testing credits never depend on publishing a public store review.
Questions about app ratings
Should I request an app review during onboarding?
Usually, the person needs to complete a useful task before they can evaluate the app. Choose an experienced-use milestone and check that the request does not interrupt the next action.
What should I measure after changing a review request?
Record eligible journeys and request attempts separately, then examine published ratings in the store console. Keep a release log and avoid treating a successful request call as proof of a submitted rating.