Practice 01.05 · Product quality

Ask for ratings and collect in-app feedback

An app-store rating and a problem report serve different needs. Ask for a rating after real value, while keeping a clear way to report a question or bug available to every user.

Practice outcomeA map of two fair journeys: a native rating request after success and an in-app feedback route with a response owner.

75 minutes to set up the foundation

In plain language

Do not cherry-pick happy users — create the right moment

A rating request is appropriate after a completed useful action, when the user has already seen the result. It does not replace help, though: the “Report a problem” path must be available to everyone, not only to those who first picked a low score.

What you will need

Success eventOne confirmed action after which the user got a result: saved, completed, configured, or successfully finished a journey.

Response channelA support queue, email, or ticketing system with an owner and a clear first-response time.

DevelopmentThe native rating prompt on iOS and Android and a short in-app feedback form.

Terms in plain language

When to use it

The team learns about problems only from public reviews, the rating prompt appears at random, and reporting an issue inside the app is hard.

In plain language

How to choose the moment and the form

Start with one successful journey and one request type. Do not try to collect ratings on every screen at once.

Useful-action event

In analytics, find the moment of a confirmed result and make sure the event fires only after success.

If there is no event, trigger the request only from the confirmed-result screen and file a tracking task.

Support themes

Group the 30 most recent requests and keep 3–4 clear reasons in the form, plus a free-text comment.

Without history, start with these categories: a problem, unclear how to do something, a suggestion, other.

Request context

Pass the app version, platform, screen, and error ID automatically — the user should not have to hunt for this data.

If automatic transfer is not possible yet, show the version in the form and let the user attach a screenshot.

Set up two honest channels

Choose a confirmed moment of value

The rating request should follow a successful result — not the first launch, registration, or an attempted action.

Where to do it: In analytics and on the result confirmation screen.
What the result looks like: After the third successfully saved item, not right after installing the app.

Use the native prompt

Use the platform's standard dialog, without your own star pre-selection or requests for a specific score.

Where to do it: In the app, after the success event, with a frequency cap.
What the result looks like: The system decides whether to show the dialog; the app does not promise a bonus for a rating.

Open feedback to everyone

Add a visible way to report a problem, a confusing step, or an idea — regardless of whether the user saw the rating prompt.

Where to do it: In the help section and next to errors or critical actions.
What the result looks like: The login error screen has a “Report a problem” option, and the profile has a permanent “Help and feedback” item.

Pass the context automatically

Attach technical details and a simple category to each request. Do not make users recall the app version or an error code.

Where to do it: In the ticketing system or support queue.
What the result looks like: Category: login; Android 13; version 4.3; login screen; screenshot attached.

Close the loop

Set a first-response deadline and group recurring themes weekly. When a problem is fixed, tell the user.

Where to do it: In the support rules and a short product review.
What the result looks like: Reply within one business day; themes with 5+ requests a week get an owner and a decision.

Practical examples

A rating request after confirmed value

After the third successful save, the app calls the platform's native dialog. There is no custom star picker, no bonus promise, and no request for a specific score.

Help available at the moment of error

On the failed login screen, the “Report a problem” button sends the version, platform, screen, and error code to support; a reply is promised within one business day.

The finished artifact

Two journeys instead of one trap

Separate rating and help. Each journey has its own moment, action, and owner.

Journey	Moment	What the user sees	What the team does
App rating	After the 3rd successful save	Native iOS/Android dialog	Monitors prompts and the rating
Error on a screen	The user taps “Report”	Short form + screenshot	Support replies within 1 business day
Confusing journey	Help button next to the action	Category + comment	Product clusters themes weekly
User idea	The “Help and feedback” section	Free text	The team confirms receipt

Do not show your own star picker before the system prompt, and do not route users to different channels based on their expected score.

Launch checklist

Rating and feedback complement each other; they must not sort users into “good” and “bad.”

The rating request is tied to a confirmed useful action. The platform's standard dialog is used, with no star pre-selection. In-app feedback is available to every user. Version, platform, screen, and error are passed automatically or easy to add. Requests have an owner, a first-response deadline, and a weekly theme review.

How to know the system works

Prompt relevance

The native dialog appears after success, with no rise in irritation or uninstalls.

Signal quality

In-app requests carry context and cluster into recurring themes the team can act on.

Team reaction

First-response time drops, and repeat requests stop coming for fixed themes.

Do not beg for five stars and do not hide the path to help: a good rating starts with real value and an honest reaction to problems.