Investigate the journey before changing the request
Choose one common Android journey and describe the expected result. A habit app might ask someone to set up a habit, mark it complete and find the weekly view. Include a smaller screen and an older supported device in your testing round when those conditions matter to the app. A successful test on your own phone leaves those questions unanswered.
Collect enough detail to reproduce a reported issue: device model, operating system, app version and the actions leading to the problem. Distinguish a technical failure from confusing wording or an unmet expectation. Keep the original observations so you can check whether the next build actually addresses them.
Use the Google Play in-app review flow correctly
Google’s in-app review API lets users leave a Play rating within the app. Its guidance says to wait until someone has enough experience to give useful feedback, avoid excessive requests and avoid questions that screen for opinion or predict a score. Keep the system review card unchanged.
Select a completed task as your candidate moment, then examine what comes immediately after it. If another action requires attention, postpone the request. Keep your own support form accessible without making a positive answer the route to a public rating request. The person’s experience should determine their review, and your product flow should leave room for that decision.
Give Android testers a specific task.
Find useful observations and optional community ratings before your next build.
Create an Android testing briefHandle review quotas without a broken button
Google applies a changing time-based quota, so a request may not display a dialog. For a user-initiated “rate this app” action, Google recommends a Play Store destination instead of relying on a prompt that might not appear. Do not count an API attempt as a submitted public rating.
Check both paths in your release plan: the eligible moment within the product and the settings link someone deliberately selects. Record which app version and distribution channel you tested. If the prompt does not appear, continue the normal journey rather than showing a success message that claims a rating was saved.
Respond to the problem and track the release
Read new review comments alongside crash reports and support issues. Create an issue for a reproducible defect and keep its affected build and device conditions. For an unclear feature, test whether a label or explanation helps before redesigning the entire screen. Review themes are useful when they lead to a decision you can check.
When replying, acknowledge the specific difficulty and explain the next step or the released fix. Google’s review policy asks developers to keep responses focused on the issue and avoid requesting a higher score. It also prohibits incentivized or fabricated ratings. Keep discounts, testing credits and feature access independent of public review submission.
Use Android testing feedback to prepare a better build
On RateMyApp, publish a Google Play link and a brief that tells testers what to try. The resulting report can describe the device, the confusing moment and reproduction steps. Testers may also leave an optional community star rating after submitting their report. Report approval and credit rewards do not require a favorable score.
A closed testing round, a RateMyApp rating and a public Play review measure different things. Keep a record of which channel each finding came from. Compare the next release with the prior build, and check published store results in Play Console separately from your private test reports. RateMyApp does not post ratings to Google Play or guarantee public review volume.
Keep provider feedback separate from store rating growth
If you use a feedback service to investigate a journey, count the private reports separately from optional community stars and public store ratings. A service can help you learn what to improve without posting a store opinion on someone's behalf. Verify the rating destination and the funded deliverable before choosing a provider. The app-rating provider comparison and free-feedback collection are linked from our blog and guides library.
For a rating campaign, record your baseline period, eligible journeys, request attempts and the published store counts you can actually observe. Keep a release log and note acquisition changes during the same period. A successful request call is not a completed rating, and a higher average after a release does not prove which change caused it. Use a focused retest to verify the product fix and read store metrics as a separate signal.
Questions about app ratings
Why might the Google Play review dialog not appear?
Google applies a time-based quota and controls whether the review flow appears. Its quota can change, so do not assume a fixed number of requests or interpret a request attempt as a published rating.
Are closed-test ratings public Google Play reviews?
Google’s in-app review documentation says feedback from a closed test track is shared privately with the developer. Keep that feedback separate from public store ratings and from RateMyApp community ratings.