How to analyse app reviews: a method for product teams

Why product teams should read reviews

Knowing how to analyze app reviews well gives a product team a stream of feedback from real users, in their own words, about problems that analytics may not show: a wallet that fails at the last step, a confusing return flow, a search that misses common spellings. Unlike surveys, nobody chose the questions. Unlike support tickets, reviews are public and read by every prospective user.

Step 1: a product taxonomy

Build categories around your product's areas and the user journey, so each one maps to a team.

• Account: sign-up, login, OTP, profile.
• Discovery: search, filters, recommendations, content.
• Purchase: cart, checkout, payments, offers and coupons.
• Fulfilment: delivery, tracking, returns, refunds.
• Quality: performance, crashes, battery, data use.
• Support: help, chat, call centre.

Step 2: classify every review

Tag each review with every area it mentions and the sentiment of each mention. "Love the deals but the app crashes at checkout" is positive about offers and negative about crashes at checkout. Keep the exact words behind each tag so engineers can read precisely what users report.

Step 3: measure by month and release

• Complaint share for each area: reviews complaining about it divided by all reviews in the period.
• The same split by app version, for the last few releases.
• The change against the previous month or version.
• The number of reviews behind each figure.

Step 4: route to owners

Give each area an owning team. When an area's complaint share rises, send the owner the trend, the affected versions and ten representative reviews. Engineers act on specific evidence; a chart of falling ratings rarely gets a ticket.

Step 5: close the loop

• When a fix ships, reply to recent reviews about the problem to say it is fixed in the new version.
• Compare the issue's complaint share in the new version with the old one.
• Record what was fixed and the result.

If you also have stores

For retail, food and service brands, app reviews and store reviews describe one customer relationship. Use the same top-level themes for both, such as delivery, returns and staff, so you can see whether a returns problem is an app problem, a store problem or both. Report the two sources separately so a change in one is not hidden by the other.

Common questions

Checklist

• Taxonomy mapped to product areas and owners.
• Every review classified with sentiment per mention.
• Complaint share by month and by version.
• Evidence sent with every issue routed.
• Fixes checked against the next version's reviews.

A worked example

A grocery app classifies 4,200 Play Store reviews from the last quarter. Delivery and product quality are the largest topics, and both are stable. Search is small, about 5% of reviews, but its complaint share doubled in the last month. Reading the reviews shows users searching in Hindi or Hinglish and getting no results, after a search index change. The search team gets the trend and 20 reviews; a fix to transliteration ships three weeks later, and search complaints on the next version fall back to their earlier level.

Volume alone would have pointed the team at delivery. The trend in a small topic found the problem that the release had caused.

Pitfalls

• Reading only one-star reviews. Four- and five-star reviews often contain specific complaints and requests.
• Ignoring non-English reviews, which in some markets are a large share.
• Reacting to the latest few reviews instead of trends.
• Sending charts without quotes to engineering.

Doing this with Falcon

Falcon classifies every Google Play review of your app into themes, sub-themes and specific issues with the sentiment of each mention, kept separate from your store reviews but on the same taxonomy. Negative share by topic and month shows which problems are new or growing, and every issue opens the reviews behind it, with the supporting words highlighted.