ReviewFold
Guide · Google Play
How to analyze Google Play reviews for recurring problems
Your own app already has a free review summary in Play Console. The work that changes a decision is reading the reviews behind a theme — for your app or a competitor’s — and turning that into one testable question.
01 · Your own app
Google already summarizes your reviews. Use that first.
Play Console shows reviews and topic groupings for your own app at no cost. Paying to learn that users mention crashes or pricing is paying for something you already own.
Open the reviews section of Play Console before you consider any third-party tool. If your question is “what topics do our reviews mention this month,” the console answers it, and it has access to the complete review set rather than a sample.
Check the source, not this page
Google documents the review and topic views in its Play Console help: support.google.com — Play Console reviews. We link it rather than describe it in detail, because the console changes more often than this page will.
What Play Console does not do is help you read someone else’s reviews, or keep a competitor sample organised around a research question. That is where the rest of this method applies.
The rule: if the question is about your own aggregate topics, stop here. If it is about a specific recurring problem and you need the text, continue.
02 · A competitor’s app
Public reviews are a sample of what people chose to write.
A competitor’s public reviews are readable, and they are biased in a specific way worth naming before you quote them.
Most users never write a review. The people who do are usually either very pleased, very blocked, or asked by the app at a particular moment. That makes public reviews good for vocabulary and failure modes, and bad for measuring how common anything is.
Reliable for
- The words users actually use for a task
- Workarounds people invent when the app blocks them
- Breakage tied to a version, device or region
- Tasks the app does not appear to support at all
Not reliable for
- How many users are affected
- Whether a problem causes churn or refunds
- Comparing two apps’ quality by review count
- Any statement about “most users”
A theme count is a property of your sample, not of the app’s user base. Write “14 of the 200 reviews I read” rather than “14% of users.”
03 · Scope
Fix four things before you read a single review.
Every claim you make later inherits these four choices. Changing one halfway through is how two people end up disagreeing about the same app.
-
01
Which app, exactly
Same package, not a lookalike or a regional clone. Search results on Google Play include apps with near-identical names.
-
02
Which region
Reviews, pricing and even feature availability differ by country. Pick one region and keep it for the whole comparison.
-
03
Which time window
Recent enough to reflect the current build. A 2023 complaint about a screen that no longer exists is not evidence about today.
-
04
How many reviews
A cap forces you to stop when the pattern repeats. A report here covers up to 200 of the most recent public reviews.
04 · Reading
A theme is a pointer, not a finding.
Grouping compresses 200 reviews into a dozen labels. That is useful for navigation and dangerous as a conclusion, because a label hides disagreement inside it.
For every theme you intend to act on, read at least three of the reviews behind it. If you cannot, mark the theme as unread rather than treating the count as evidence. In practice, three is usually enough to see whether the group is coherent or is really two different complaints sharing a word.
The three questions to ask of each theme
1. What task was the reviewer trying to finish? 2. What did they expect the app to do? 3. Is this about the current build, or an older one?
If you cannot answer all three from the reviews, the theme is a lead, not a decision.
05 · Sorting
Separate an ask from a complaint.
“I hate the paywall” and “bring back the ad-supported option” can appear under one theme and mean different things. Sorting them changes what you build.
Split the reviews behind each theme into four groups. The categories are deliberately narrow so that two people sorting the same reviews reach roughly the same answer.
Requests
Names a capability that does not exist, or asks for a specific alternative path. Actionable only after you check whether it already exists.
Change reports
Describes something that used to work differently. Often the most informative group, and the easiest to misread as a request.
Complaints
Expresses frustration without a task, an expectation or a version. Useful as sentiment, weak as a spec.
A fourth group — off-topic, contradictory or unreadable — should be kept, not deleted. It is the counter-evidence that stops a tidy story. The competitor review guide walks through one theme where this split changed the conclusion.
| Theme | Reviews behind it | What it actually asks | Still true today? | Next test |
|---|---|---|---|---|
| Theme 1 | read 3–5 | request / change / complaint | checked in current build | one question |
| Theme 2 | — | — | — | — |
| Theme 3 | — | — | — | — |
The first row shows what a filled entry looks like; the others are blank. This is an empty worksheet, not a report output — it exists so the sorting survives the meeting it was done for.
06 · Decision
Finish with one question and one check.
An analysis that ends in a feature list usually ends in a guess. An analysis that ends in a question you can test is reusable.
Write the question in a form someone else could falsify: Can [which user] complete [which task] when [which condition holds]? Then pick the cheapest check — the current build, the help centre, five minutes with a real user, or an instrumented event.
- If the task is impossible today: you have a candidate fix, not a priority.
- If the task is possible but unclear: the fix may be copy or entry point, not a feature.
- If the reviews describe an old version: close the theme and note why.
- If the reviews disagree: keep both sides and test the difference, not the loudest side.
Only after that check does the work belong on a roadmap. Ranking themes against each other is a separate decision, and review volume alone is not enough to make it.
Limits
What this method will not tell you.
Being explicit about the ceiling is what makes the rest of the analysis usable in a meeting.
- Not prevalenceA sample cannot tell you how many users are affected, or what share of them are silent.
- Not causationReviews describe what happened, not why. A crash report is not a root cause.
- Not revenueNothing here connects a complaint to refunds, churn or store ranking.
- Not a scoreNo ranking of themes by importance. That is a product decision, made with data this method does not have.
Before you buy anything
When you do not need a tool for this.
A tool helps when
- You are reading a competitor’s reviews, not your own
- You need the excerpts kept next to the themes
- Two people need to review the same evidence set
- You want the sample scope written down and repeatable
Skip it when
- The question is about your own app’s aggregate topics — Play Console is free
- You need historical trends rather than a recent sample
- You need replies, alerts or keyword tracking
- You have not decided which question you are answering
Current support, stated plainly
- Apple App Store: US and Canada. Google Play: US.
- Up to 200 recent public reviews per report.
- One app and one region per report; no cross-region merge.
- Free preview shows themes and counts with limited detail.
- The paid full report adds the excerpts, PDF and review CSV.
- No replies, keyword tracking, alerts or historical archive.
Run the method once
Put one Google Play app through the steps.
Paste a public Play Store link, read the themes, then open the reviews behind the one that matters. The point is the reading, not the grouping.