# Ask for ratings and collect in-app feedback

- **Canonical URL:** https://playbook.affpartners.io/en/practices/quality-reviews/index.html
- **Markdown version:** https://playbook.affpartners.io/en/practices/quality-reviews/index.md
- **Module:** Product quality
- **Time:** 75 minutes to set up the foundation

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.

## Outcome

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

## 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 event:** One confirmed action after which the user got a result: saved, completed, configured, or successfully finished a journey.
- **Response channel:** A support queue, email, or ticketing system with an owner and a clear first-response time.
- **Development:** The native rating prompt on iOS and Android and a short in-app feedback form.

## Terms in plain language

- **Analytics event — A record of a specific user action:** Definition: The app sends an event when a user opens a screen, taps a button, or completes an action. Example: registration_started and registration_completed reveal how many people abandon registration.
- **CTA — The main action offered to the user:** Definition: A CTA is a button or link with a clear next step and expected outcome. Example: “Continue registration” is clearer than “Next”.
- **Conversion — The share of people moving to the next step:** Definition: Shows how many people who started a step completed it or reached the next one. Example: 80 registrations completed from 100 started: 80 ÷ 100 × 100% = 80% conversion.

## 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.

## 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**
  - **Source:** In analytics, find the moment of a confirmed result and make sure the event fires only after success.
  - **If access is unavailable:** If there is no event, trigger the request only from the confirmed-result screen and file a tracking task.
- **Support themes**
  - **Source:** Group the 30 most recent requests and keep 3–4 clear reasons in the form, plus a free-text comment.
  - **If access is unavailable:** Without history, start with these categories: a problem, unclear how to do something, a suggestion, other.
- **Request context**
  - **Source:** Pass the app version, platform, screen, and error ID automatically — the user should not have to hunt for this data.
  - **If access is unavailable:** 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

1. **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.
   - **Example:** After the third successfully saved item, not right after installing the app.
2. **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.
   - **Example:** The system decides whether to show the dialog; the app does not promise a bonus for a rating.
3. **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.
   - **Example:** The login error screen has a “Report a problem” option, and the profile has a permanent “Help and feedback” item.
4. **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.
   - **Example:** Category: login; Android 13; version 4.3; login screen; screenshot attached.
5. **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.
   - **Example:** 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.

## 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.

## Key rule

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.

---

- [HTML version](https://playbook.affpartners.io/en/practices/quality-reviews/index.html)
- [All practices](https://playbook.affpartners.io/en/)