# Turn app-store reviews into product action

- **Canonical URL:** https://playbook.affpartners.io/en/practices/discoverability-rating/index.html
- **Markdown version:** https://playbook.affpartners.io/en/practices/discoverability-rating/index.md
- **Module:** ASO & SEO
- **Time:** 60 minutes to set up and 30 minutes per week

A review is a public signal about a specific experience, not merely a brand score. Separate critical issues quickly, respond without arguing, and turn repeated themes into product work.

## Outcome

One review queue with themes, priority, a safe response template, an owner, and links to product tasks.

## A public reply is read by more people than its author

A good reply acknowledges the experience, does not argue, and offers a safe next step without personal data. Most importantly, recurring complaints must reach the product owner and come back to the review once fixed.

## What you will need

- **Access:** App Store and Google Play reviews with the date, platform, country, and app version where available.
- **Reply owner:** A support or community manager with clear response times and escalation rules.
- **Product link:** A shared task queue where a recurring theme can be filed with examples and frequency.

## Terms in plain language

- **ASO — Improving an app's store page:** Definition: Work on the title, description, screenshots, rating, and queries so the app is easier to find and more convincing to install. Example: Rewrite the first screenshot captions so the value is clear without reading the full description.
- **Crash-free rate — The share of users without an app crash:** Definition: The closer it is to 100%, the fewer users experienced an app crash during the selected period. Example: 99.5% crash-free users means 0.5% experienced at least one crash.
- **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

Reviews go unanswered, the rating moves for no clear reason, and recurring complaints never reach support, development, or the product owner.

## How to set up the workflow

Do not reply straight from a notification, without context. First gather the reviews in one place, tag the theme and severity, then choose the right next step.

- **Store consoles**
  - **Source:** Export new reviews daily or weekly with the rating, language, platform, and version where available.
  - **If access is unavailable:** Without an automatic export, keep a shared table and save the link, date, and text of every important review.
- **Support and technical signals**
  - **Source:** Cross-check complaints about login, data, transactions, and crashes against tickets and error reports.
  - **If access is unavailable:** If the link is still manual, post critical reviews to a shared channel with the version and a request to confirm the scale.
- **Product task list**
  - **Source:** For a recurring theme, track the number of reviews, examples, the owner, the status, and the fix version.
  - **If access is unavailable:** If there is no task system, add a “next decision” column and revisit it during the weekly review.

## Set up the work with store reviews

1. **Build one queue.** Combine reviews from both stores in a table or work tool. Keep the original text, language, date, platform, and version.
   - **Where to do it:** In the shared queue, with a filter for new and untagged reviews.
   - **Example:** Android 4.2 · 1 star · “I can't see my history after the update” · June 12.
2. **Tag the theme and severity.** Flag security, money, data, login, and blocking errors immediately. Group the rest by a clear user theme.
   - **Where to do it:** In the theme and priority columns.
   - **Example:** History loss — high severity; a dark-theme request — a regular wish.
3. **Reply without arguing or promising.** Acknowledge the experience, give a safe next step, and do not ask for personal data in public. Do not promise dates the team has not confirmed.
   - **Where to do it:** In a public reply, in the user's language.
   - **Example:** “We understand — the history is not showing. Please contact us through the in-app support form and include your version; the team will investigate.”
4. **Escalate recurring themes.** Several similar reviews should become one signal with frequency, versions, and an owner — not scattered, unrelated notes.
   - **Where to do it:** In a product task or the weekly review.
   - **Example:** 8 reviews and 14 support requests about empty history on Android 4.2 → one high-priority task.
5. **Close the loop after the fix.** Once the fix is confirmed, update the public reply with the version. Do not ask the user to change the rating.
   - **Where to do it:** In the original review, after verifying the release.
   - **Example:** “The problem is fixed in version 4.3. Thank you for helping us find it.”

## Practical examples

- **A critical review becomes a task:** Eight reviews and 14 support requests about empty history on Android 4.2 merge into one problem with an owner and an urgent version check.
- **The loop closes in public:** After verifying version 4.3, the team updates the reply: the problem is fixed, thank you for the signal. There is no request to change the rating or post personal data.

## Finished artifact: Review and escalation queue

One row links the public signal, the safe reply, and the internal team action.

| Review theme | Priority | Public reply | Internal action |
| --- | --- | --- | --- |
| Login does not work | Critical | Acknowledge + safe help channel | Check the version and errors today |
| Status is unclear | High | Explain where to see the status | Collect 5+ examples into a product task |
| Feature request | Regular | Thank without promising | Track the frequency |
| Hard-to-find setting | Regular | Give a short route | Check the navigation |
| Fixed in 4.3 | Loop closing | Report the version and thank them | Watch the new reviews |

Never ask users to post personal or payment details in a review. Move individual cases to a secure support channel.

## Reply checklist

Before publishing, imagine the reply being read by a new user deciding whether the team can be trusted.

- [ ] Reviews are tagged by theme, platform, version, and severity.
- [ ] The reply acknowledges the experience and does not argue with the user.
- [ ] There are no requests to post personal data and no unconfirmed promises.
- [ ] Every recurring theme is linked to an internal task and an owner.
- [ ] After a fix, the team follows up with the version — without asking to change the rating.

## How to know the process works

- **Reaction:** The share of meaningful replies grows, and critical reviews get answered faster than before.
- **Product signal:** Recurring themes are merged and owned instead of remaining scattered comments.
- **Loop closing:** After the fix, the theme appears less often in new reviews and support requests.

## Key rule

Do not ask people to change their rating: fix the problem, confirm the fix, and let users judge the new experience themselves.

---

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