Chapter 7 of 12
App competitor analysis: listings, reviews and positioning
In this chapter: how to read reviews as a biased sample rather than as a vote, how to count themes honestly, and how to treat competitors' claims as claims. You will turn an afternoon of reading into one positioning decision.
The problem
A useful app competitor analysis compares apps serving the same user task in the same store and market. Start with one or two relevant alternatives, record what their listings actually say, and look for a difference your current app can demonstrate. Public pages reveal positioning; they do not reveal a competitor's conversion rate or exact revenue.
Build a comparison you can act on
| Question | Your app | Competitor | Evidence to record |
|---|---|---|---|
| Who is it for? | Write the audience your page addresses. | Write the audience their page addresses. | Storefront, language, date and the exact listing field. |
| What does it help someone do? | Name the main task. | Name the main task. | The visible claim, separated from your interpretation. |
| How is the promise demonstrated? | Inspect the first screenshots. | Inspect the same part of their listing. | What the screenshot shows; do not infer features from a slogan. |
| Why do reviewers choose it? | Tag a defined sample of recent reviews. | Use a comparable sampling rule. | Themes with counts and sample size, never a share of all users. |
| What can you truthfully say better? | Verify it in your released app. | Check whether their listing addresses it. | One message to test, plus what would disprove the idea. |
Select competitors by the job people hire the app to do, not only by category rank. A large general-purpose app can be an alternative, but its audience, brand recognition and traffic may make its aggregate ratings a poor benchmark. If a feature or price cannot be verified from the available evidence, mark it unknown.
Reviews are the only place where strangers tell you, in their own words, what they expected and what they got. They are also a trap. One eloquent 1-star review can reset a roadmap. A competitor's listing that says "the most private journal" can make your own page feel weak. And a spreadsheet that says "18% of reviews mention sync" quietly turns into "18% of users have sync problems" by the time it reaches a planning meeting.
What is going on
Reviews are a sample, and a biased one
Who writes reviews is not random. People write when they are delighted or annoyed, when the app asks at a good or bad moment, and when they have time. Several platform mechanics shape the sample further:
- When you ask. On the App Store the system rating prompt can be shown up to three times in a 365-day period [S07]. On Google Play the in-app review dialog has a time-bound quota, and it may not appear if you call it more than once in a short period [S17]. Where you place the prompt changes who answers.
- How ratings are summarized. Apple's summary rating is per territory, and you can reset it with a new version — Apple recommends doing so sparingly, and a reset does not remove written reviews [S07]. The rating shown on Google Play is weighted towards more recent ratings [S15].
- Language and country. You read the reviews in languages you understand, for the countries you open. That is a filter too.
So a review sample tells you what some users say, not how many users feel it. Always record the sample: platform, countries, languages, date range, star ratings included, and how many reviews you read.
Count themes, then say what the count means
A theme count is useful for comparing themes inside the same sample — "sync complaints are more common than pricing complaints in the 60 reviews we read" — and for comparing the same theme across periods with the same sampling method. It is not a percentage of users. Write it as "11 of 60 reviews read (US and UK, English, 1 July–15 September)", not "18% of users".
Use a simple code sheet:
- Read each review once and tag up to two themes: a problem ("export fails"), a wish ("wants dark mode"), a reason for choosing the app ("no account needed"), a comparison ("switched from X").
- Add the version and star rating.
- Only after tagging, count.
Reasons for choosing the app are gold for positioning: they are the words real users use for the value you deliver.
Competitor claims are claims
A competitor's listing is a statement of what they want you to believe. It is evidence of their positioning, not of their product's quality or their results. Three rules:
- Do not copy a claim you cannot prove for your own app. On Google Play, ranking claims such as "#1" are not allowed in the listing, and unattributed testimonials are not allowed in the description [S14].
- Do not treat a competitor's review count as a measure of their downloads or revenue. Nothing public tells you that.
- Look for gaps: something users in your reviews value that neither you nor the competitor say clearly on the page.
Stay inside the review rules
Never offer rewards for ratings or reviews, and never pressure or trick users into rating. Google Play's policy forbids incentivized ratings and manipulating ratings, reviews or installs [S16]; its in-app review guidance says not to ask opinion questions such as "Do you like the app?" before or while showing the rating prompt [S17]. Apple states that manipulating reviews or rankings, or using third-party services to do so, can lead to removal from the Apple Developer Program [S06]. Apple asks for concise replies without marketing language [S07]; Google asks that replies not solicit or promote [S15].
Worked example
Fictional example · E7 · Quillnest · tags: ios, reviews, small-sample
Situation. Quillnest is an iOS journaling app made by a solo developer. Goal: sharper positioning. A larger competitor recently changed its subtitle to lead with privacy. The developer wants to rewrite Quillnest's subtitle and first screenshot to say "the most private journal".
Sample. 60 most recent written reviews on the App Store, US and UK, English, 1 July–15 September, all star ratings.
Theme count (up to two tags per review, so the tag counts add up to more than 60):
| Theme | Reviews | Typical wording |
|---|---|---|
| Reason: "export to PDF/Markdown is easy" | 11 | "finally I can get my entries out" |
| Reason: "no account needed" | 8 | "no sign-up, just write" |
| Problem: iCloud sync delay | 7 | "entries show up late on iPad" |
| Wish: templates | 6 | "prompts for mornings" |
| Mentions privacy explicitly | 3 | "private" |
| Other / single mentions | 31 | — |
Observations. In this sample, export and "no account needed" are the most frequent reasons users give for choosing the app. Privacy is mentioned in 3 of 60. The current Quillnest listing mentions export only in the fourth screenshot and does not mention "no account" at all.
Hypotheses.
- Users choose Quillnest for data ownership (export, no account) more than for privacy as such. Supported in this sample; not a measure of all users.
- Leading with "the most private journal" would copy the competitor's position without evidence that Quillnest is more private. A claim the developer cannot prove.
- The sync-delay reviews point to a technical issue that could hurt ratings. Needs a check (chapter 6), independent of positioning.
Decision: Position on data ownership, as a test. Do not use "most private". Test a new first screenshot that says "Your journal, yours to export — no account needed" — both true of the current version — as a product page optimization treatment against the current screenshot, with a minimum run set from chapter 4's planning rule [S04]. That split test, not a custom page, is what can show whether the message converts better for the same visitors. Separately, use the same screenshot on a custom product page [S03] for the next community post (chapter 9); its numbers describe how that community responds, not whether the message beats the default. Open a separate investigation of the sync delay. Revisit the subtitle only after the product page optimization test ends.
What would change the decision. If a larger, more recent sample (for example the next 60 reviews after the sync fix) shows privacy as a frequent reason for choosing Quillnest, reconsider.
Do this now
- Define your sample before reading: platform, countries, languages, date range, number of reviews.
- Tag each review with up to two themes, its star rating and its version.
- Count and write each count with its sample ("11 of 60 reviews read…").
- Collect the exact phrases users use for why they chose the app.
- Read one competitor's listing and write down its three main claims, marking each "provable for us", "not provable for us" or "not relevant".
- Pick one positioning idea that is true for your current version and supported by your users' own words, and plan to test it (chapter 4) rather than replacing the default page.
- Separate technical themes (crashes, sync, login) into chapter 6's triage.
Don't change anything yet when…
- Your sample is small, one-sided (only 1-star), from one country or from before a major version.
- The theme you want to act on is a single vivid review.
- The positioning would rest on a claim you cannot prove for your current version.
- The most frequent theme is a bug — fix or investigate that first.
- You have just reset your App Store summary rating or changed your review prompt; the sample is shifting.
Worksheet
Review-theme sheet — sample definition, tagging grid, theme counts with their sample, user phrases, competitor claims and one positioning decision.
Optional: if your goal is positioning, Next Move can compare your public listing with one competitor's and, from a bounded sample of public reviews, propose a positioning comparison or listing copy draft. It reports review shares as shares of the sample it read, and asks you to confirm any feature it would mention.
Sources
- S03 — Custom product pages (Apple Developer) — https://developer.apple.com/app-store/custom-product-pages/
- S04 — Product page optimization (Apple Developer) — https://developer.apple.com/app-store/product-page-optimization/
- S06 — App Review Guidelines (Apple Developer) — https://developer.apple.com/app-store/review/guidelines/
- S07 — Ratings, reviews, and responses (Apple Developer) — https://developer.apple.com/app-store/ratings-and-reviews/
- S14 — Metadata policy, Play Console Help — https://support.google.com/googleplay/android-developer/answer/9898842
- S15 — Ratings and reviews, Play Console Help — https://support.google.com/googleplay/android-developer/answer/138230
- S16 — User ratings, reviews, and installs policy, Play Console Help — https://support.google.com/googleplay/android-developer/answer/9898684
- S17 — In-App Reviews API (Android Developers) — https://developer.android.com/guide/playcore/in-app-review
Worksheet for this chapter
Optional: try it on a real listing
The free Next Move form prepares one move from public evidence, with this chapter's goal already chosen. Nothing runs until you choose Generate, and this chapter works without it.
Find my next move — free