How to Compare Google Play Review Themes Without Misleading Percentages

Decide what the comparison should answer

Choose a question narrow enough to code consistently. For example: “In the public reviews collected for these two apps, what do people report about signing in?” That gives you a topic and a clear boundary. It does not ask the sample to reveal market share, churn or the experience of people who never wrote reviews.

If you manage the app, begin with Play Console's ratings and reviews tools. Google documents review filters, CSV downloads and theme summaries for eligible apps. Its owner-side information is a different source from a public competitor export. Google also explains that reviewers can update their submissions and that new public reviews can be delayed, so a collection date should not be treated as a perfectly complete event cutoff.

For a public competitor comparison, TubeText's App Reviews Actor documents Google Play collection by app ID or link. This tutorial deliberately stays within Google Play; it does not mix stores into one denominator.

1. Record a collection brief before collecting

Keep these settings with the dataset:

• App identifiers and the research question.
• The same country and language query settings for each app.
• Sort order, requested review cap and selected ratings.
• Collection time and a link or reference to the source run.
• The calendar window you intend to analyze.

Country and language are query settings, not proof of each reviewer's residence or identity. “Newest 200” also does not guarantee an equally long period for every app.

Here is illustrative input for the documented input form. Replace both placeholder IDs before using it:

{
  "apps": ["com.example.replace_app_a", "com.example.replace_app_b"],
  "maxReviewsPerApp": 200,
  "sort": "newest",
  "starRatings": [],
  "country": "us",
  "language": "en",
  "onlyNew": false,
  "includeAppDetails": false,
  "aiInsights": false
}

The cap is a request, not a coverage promise. Leaving star ratings empty includes all ratings in the requested sample. If you intentionally collect only one- and two-star reviews, call the result a complaint-sample analysis and do not use it to estimate the negative share of all reviews.

2. Freeze the evidence and count exclusions

Keep the original export unchanged. On a separate working sheet, retain actual review rows with usable text. The output schema distinguishes review, app-summary and AI-insight rows and documents fields including appId, rating, text, date and appVersion. A summary or an error row must not become a review in your count.

Assign each retained row a local evidence reference, such as “run-1 / row-17.” This is your worksheet identifier, not a documented universal review ID. Do not claim reliable cross-run deduplication from identical text alone: unrelated people can write the same short phrase, and a review may later change.

Before comparing, write down the exclusion counts. Missing text cannot be theme-coded. Missing dates prevent placement into a date-bounded analysis. A missing version belongs in “version unknown,” not the latest release. Keep these groups visible rather than quietly replacing missing values.

When two capped exports span different periods, pick a shared window and recount both apps inside it. If a cap truncates that window, disclose the truncation. Equal settings help reproducibility; they do not turn public reviews into a random sample of users.

3. Write a small theme codebook

Start with a few definitions you can apply without guessing. A practical login codebook might look like this:

On a narrow screen, scroll the table sideways to read all columns.

These are analyst-created labels, not Actor output. Use a separate column for tone if you need it. A five-star review can mention a defect; a one-star review can describe a pricing objection rather than a technical failure.

Read a small calibration batch before labeling the full sheet. If two readers disagree, refine the definition and revisit earlier labels. A solo reviewer can recode a sample later and note changed decisions. Record the codebook version so that a later comparison does not silently change what a theme means.

4. Calculate shares with visible denominators

Count a review once per theme, even if it repeats the complaint. A review can have several themes, so their percentages may add to more than 100%.

Use:

Theme share in this sample = retained reviews mentioning the theme / all retained reviews in the defined sample.

Fictional example after applying one shared window and exclusion rules:

On a narrow screen, scroll the table sideways to read all columns.

The appropriate finding is: “Sign-in failure appeared in 12 of 80 retained reviews for A and 10 of 50 for B.” It is not “B's users are more likely to experience login failure.” These samples do not establish user-level incidence, equivalent exposure or causation.

For a before-and-after release comparison, use explicitly defined periods, report each denominator and separate known versions from unknown ones. A date near a release does not prove which version a reviewer used. A change in mentions is a question to investigate, not proof that the release caused it.

5. Deliver a brief that someone can inspect

Download the blank theme worksheet. Its local evidence IDs, inclusion decisions and theme columns are analyst-added fields; it contains no real reviews or product results.

Finish with one paragraph per important theme:

• What the label means and which sample it describes.
• Mention count and denominator for each app.
• A few evidence-row references, including an ambiguous or contrary example when relevant.
• Missing information that limits the conclusion.
• The next investigation, such as checking a sign-in flow on the relevant version.

Keep personal reviewer details out of the brief unless genuinely necessary. Summarize rather than republishing long review text. Public availability alone does not settle the rights to reuse content.

Optional AI insights can help propose labels, but the documented report uses up to 300 recent reviews per app. Do not assume it analyzed the same manually filtered sheet or every exported row. Review its themes and examples before presenting them as findings.

Cost and execution boundaries

At the public free-plan event rates checked on 23 October 2026, reviews are $0.0001 each, app summaries are $0.002 each and optional delivered AI reports are $0.05 each. Actor Start is separate at $0.00005 per GB, with at least one event. For a fictional run delivering 400 reviews at the default 512 MB with summaries and AI off, those event charges total $0.04005. This is arithmetic, not an executed invoice. Check current pricing and your plan before running.

If you already have a permitted review export, you can use the worksheet without another collection. If you need collection help, the existing CSV export recipe covers that step. For other source types, use the TubeText catalog.

The finished result should make a narrower claim easier to trust, not make a larger claim look precise.