App Review Triage - App Store & Google Play Alerts

Monitor new App Store and Google Play reviews and get them sorted into bugs, billing complaints and feature requests: one digest per app with the urgent ones on top, similar reviews grouped into themes, a flag when the rating drops, and one row per new review. It remembers what it already saw, so the second run only brings you what is new.

The sorting is keyword rules, and the keywords are English, so a review in another language usually lands in other at low confidence. Your own Anthropic key gives the unsure ones a second look; without one it still runs on rules alone.

Input	Your apps, each with an App Store URL, a Google Play URL, or both
Output	One digest row per app (buckets, urgent items, themes, rating change), plus one row per new review
Ceiling	Up to 500 reviews per app per store per run
Speed	Roughly 5 to 16 seconds a run for one app
Account needed	None. Your own Anthropic key is optional
Price	$0.40 per 1,000 new reviews on the Free plan, a little less on paid plans, plus small per-app and per-report charges listed below. The free plan's $5 a month covers about 12,500

🔍 What App Review Triage does

Every run it fetches the newest reviews for each app from each store you gave it, and compares them with the snapshot from last time. What is new gets a row.

Each new review goes into one bucket with a severity: bug or crash, billing complaint, feature request, praise, or other. Bugs and billing complaints come back as urgent items carrying their text and the app version, so a crash report does not sit at position 40 of a list nobody reads.

Similar reviews are grouped. Five people saying login fails after 4.2 arrive as one theme with an example and the review ids, not as five things to notice separately. A theme needs at least two new reviews, and praise is left out.

The rating is blended across both stores and compared with the last run's figure, so a fall of 0.1 or more is a flag rather than something you spot a week later.

Two optional outputs. webhookUrl posts a summary after every run, and a Slack incoming webhook works as it is. weeklyReport writes REPORT.html and REPORT.md into the run's key-value store, on the Storage tab.

📋 What data you get from each App Store and Google Play review

What you get	Field
The review: stars, title, text, author, date	rating, title, text, author, date
Which store and app, and a link	store, app_id, app_label, url, country
The app version the reviewer was on	version
Whether the developer replied, and the reply	developer_response, developer_response_text
Bucket, severity, confidence, the words that decided it, and whether rules or your key decided	triage
A stable id and a fingerprint that spots edits	review_id, content_hash
Per app: counts per bucket, the urgent reviews in full, the themes	bucket_counts, urgent_items, clusters
Per app: the rating before and after, both stores, and the drop flag	rating_before, rating_after, store_ratings, rating_drop_alert

▶️ How to monitor App Store and Google Play reviews

1. Open App Review Triage and click Try for free.
2. In Apps to monitor, replace the example with your own: a label and one or both store URLs.
3. Set Store country if you are not on us.
4. Paste a Slack incoming-webhook URL into Webhook / Slack URL if you want the summary pushed.
5. Click Start. Then schedule it, daily or weekly, and let the snapshot do its job.

💰 How much does it cost to monitor app reviews?

$0.40 per 1,000 new reviews on the Free plan, a little less on paid plans. The free plan's $5 a month covers about 12,500, before the small charges below.

What	Free plan	Paid plans
A new review, sorted and written as a row	$0.0004, so $0.40 per 1,000	a little less
Each app on your list, each run	$0.004	$0.002
The AI pass on an app, when your own key sorted something new	$0.0005	$0.0003
A report written	$0.005	$0.003

An app is checked whether or not it has anything new, so a quiet app on a daily schedule still costs its check. One that neither store answered for does not. The AI pass is charged once per app, only when your own key sorted at least one new or edited review (triage.method is llm). A review you already saw is not charged again, and an edited one is sorted again but not charged as new.

Competitor apps are charged the same way as your own: the check, each new review, the AI pass. Their reviews go into the report and the webhook summary only, not the dataset.

If you set a maximum charge for a run, it stops where the next charge would not fit, and the run's status says so.

📥 What you give it

{
  "apps": [
    {
      "label": "My App",
      "appStoreUrl": "https://apps.apple.com/us/app/instagram/id389801252",
      "playStoreUrl": "https://play.google.com/store/apps/details?id=com.instagram.android"
    }
  ],
  "maxReviewsPerRun": 100,
  "onlyNewSinceLastRun": true,
  "country": "us"
}

apps takes objects, not plain URLs. An entry that is not an object is skipped, which is the quickest way to end up with a run that checks nothing.

Field	Default	What it is
apps	none, required	One entry per app: an optional label, plus appStoreUrl, playStoreUrl, or both. One store is fine.
competitorApps	empty	Same shape. Adds a comparison of their new-review themes to the report and the webhook summary.
country	us	Two-letter store country, both stores. Pick one and stay on it: the snapshot is not kept per country.
maxReviewsPerRun	100	Reviews fetched per app per store, 10 to 500, most recent first.
onlyNewSinceLastRun	true	What makes this a monitor rather than a dump. Turn it off and every fetched review is sorted, though rows and charges still cover new reviews only.
detectBugsCrashes, detectBillingComplaints	true	Whether those buckets are flagged as urgent on the digest.
detectFeatureRequests	true	Feature requests are always counted in bucket_counts and are never urgent, so this switch changes nothing today.
detectRatingDrops	true	Flag a fall of 0.1 or more in the blended rating against the last snapshot.
clusterThemes	true	Group new reviews that say the same thing.
weeklyReport	true	Write the forwardable HTML and Markdown report.
webhookUrl	empty	Where to POST the run summary. A Slack webhook URL works directly.
anthropicApiKey	none	Your own key, in a secret field, billed to your own Anthropic account. Only reviews the rules are unsure of, under 0.6 confidence, use it.
useLLMTriage	true	Does nothing without a key. Set it off to stay on rules even when a key is present.

📤 What you get back

Two kinds of row. First the per-app digest, real, from a run on 3 October 2026, with the long review texts cut short:

{
  "type": "app_digest",
  "run_at": "2026-10-03T13:14:49.031408+00:00",
  "label": "My App",
  "app_id": "app_c9aa11a4733bf08e",
  "sync_status": "ok",
  "stores": ["app_store", "google_play"],
  "fresh_count": 20,
  "new_count": 20,
  "changed_count": 0,
  "bucket_counts": {"bug_or_crash": 1, "billing_complaint": 0, "feature_request": 0, "praise": 13, "other": 6},
  "urgent_count": 1,
  "urgent_items": [
    {"store": "app_store", "rating": 1, "title": "stopped working", "text": "won’t load when i refresh. stuck on a loading screen, ...", "version": "448.0.0", "bucket": "bug_or_crash", "severity": "high", "url": "https://itunes.apple.com/us/review?id=389801252&type=Purple%20Software", "review_id": "as_14617869562"}
  ],
  "clusters": [
    {"theme": "account disabled", "mentions": 2, "dominant_bucket": "other", "dominant_version": "448.0.0", "example": "My account was disabled without proper explanation, ...", "review_ids": ["as_14617849737", "gp_6a2a06ab-39d6-41db-ac33-db34a944b0ff"], "summary": "2 new reviews mention 'account disabled' (re: v448.0.0)"},
    {"theme": "because", "mentions": 2, "dominant_bucket": "bug_or_crash", "dominant_version": "448.0.0", "example": "My account was disabled without proper explanation, ...", "review_ids": ["as_14617869562", "as_14617849737"], "summary": "2 new reviews mention 'because' (re: v448.0.0)"}
  ],
  "rating_before": 4.094,
  "rating_after": 4.094,
  "rating_change": 0,
  "rating_drop_alert": false,
  "store_ratings": {"app_store": 4.69067, "google_play": 3.9900448}
}

Then one row per new review. This is the urgent one from the same run:

{
  "type": "new_review",
  "run_at": "2026-10-03T13:14:49.031408+00:00",
  "review_id": "as_14617869562",
  "store": "app_store",
  "app_id": "389801252",
  "app_label": "My App",
  "rating": 1,
  "title": "stopped working",
  "text": "won’t load when i refresh. stuck on a loading screen, sucks because i actually spent money on this app",
  "author": "sgsgsgshdhddbebxndb",
  "version": "448.0.0",
  "date": "2026-10-02T00:18:34-07:00",
  "developer_response": false,
  "developer_response_text": null,
  "country": "us",
  "url": "https://itunes.apple.com/us/review?id=389801252&type=Purple%20Software",
  "is_competitor": false,
  "content_hash": "a02d684580305bf25b55ea1e5a8a4a01284f6e69",
  "triage": {"bucket": "bug_or_crash", "severity": "high", "version": "448.0.0", "keywords": ["stopped working", "stuck"], "method": "rules", "confidence": 0.96}
}

Field	How to read it
triage.bucket	One bucket per review: bug_or_crash, billing_complaint, feature_request, praise or other.
triage.severity, triage.confidence	high, medium or low, and how sure the classifier was. Sort by confidence to find what needs a human.
triage.method	rules or llm, so you can always see which decided.
triage.keywords	The words that drove the call. Empty when nothing matched.
review_id, content_hash	The id is prefixed as_ or gp_ by store. The hash is what spots an edited review.
version	The app version the reviewer was on, when the store reports one. Often null.
developer_response	Google Play only. The App Store feed does not carry replies.
clusters	On the digest row: the theme, how many mentions, the dominant bucket and version, an example and the review ids.
rating_before, rating_after, rating_drop_alert	Blended across the stores you gave it. store_ratings keeps them separate.

🧾 Reading the output

type separates the two kinds of row. Both share one table view, so the columns look sparse either way: export it, or open a row.

Row	How to spot it	Charged
A per-app digest	type: "app_digest"	the app check, when a store answered
A new review	type: "new_review"	yes
A failed app	type: "app_digest" with sync_status: "failed" and an error	no, unless a store answered first

No sample row, no error codes. One thing to watch: sync_status: "ok" with new_count: 0 means nothing new was found, and a store that did not return its reviews looks the same. A steady zero from one store on a busy app is worth checking by hand.

💡 What people use it for

• A morning Slack post of everything new, bugs and billing complaints at the top.
• Catching the crash nobody filed a ticket for, visible only in reviews of one version.
• Counting the feature people keep asking for, rather than remembering it.
• Rating-drop alerts on release days, when a bad build hits the score first.

🚧 What it does not do

• One bucket per review. A crash report that also asks for a feature gets the stronger of the two, not both.
• Themes come from shared words, so now and then one is a plain word like "because". Read the example before acting on a theme.
• About 500 App Store reviews per app, and no developer replies from that store.
• It does not reply to reviews or touch your listings.
• One country per run, and the snapshot is not kept per country, so switching mid-stream compares against the old country's figures.
• The blended rating needs both stores answering. If one store's figures fail, the blend becomes the other store's number, which can look like a drop that never happened.
• It is not an official Apple tool. Dami's Studio is independent and is not affiliated with or endorsed by Apple or Google, or by any other company named on this page.

🧭 Which app review scraper do you need?

If you want	Use
New App Store and Google Play reviews, sorted and sent to Slack	This one
An app's App Store details, or up to 500 of its reviews in one pull	App Store Scraper
Google Play reviews by country and language, filtered by star and date	Google Play Reviews Scraper
Google Play app details by keyword, category or package	Google Play Apps Scraper
New Google reviews and rating drops across your shop or branch locations	Google Reviews Monitor
Changes on a rival SaaS site's pricing, changelog and homepage	SaaS Competitor Monitor

❓ Questions people ask

Do I need a developer account or an API key to monitor app reviews?

No. It reads the public store pages, so it works on any app, yours or a rival's. The Anthropic key is optional and only sharpens the cases the rules are unsure of.

How does it know which reviews are new?

It keeps the review ids and their fingerprints between runs, in a key-value store called app-review-triage-state on your own account. Nothing to configure. It remembers up to 10,000 reviews per app.

Can I monitor one store only?

Yes. Give an app just the App Store URL or just the Google Play URL.

What happens on the first run?

Everything it fetches is new, so expect a big first batch, up to maxReviewsPerRun from each store. Set it low for that run if you would rather ease in.

Can I call it from code or connect it to an AI assistant?

Yes. The API tab has ready-made code for Python, JavaScript and the command line. For Claude, ChatGPT or another MCP client, connect https://mcp.apify.com/?tools=fetch-actor-details,dami_studio/app-review-triage-monitor. Either way the run happens on your Apify account at the same price.

Is scraping app reviews legal?

These are public store pages. Reviews carry author names, which are personal data under GDPR and similar laws, so have a reason for holding them. Apify's write-up on the legality of web scraping is a good starting point, and we are not lawyers.

🆘 If something breaks

Open the Issues tab on the actor page. Send the app URLs and the run ID. The digest row's sync_status and error usually name the reason already. Never paste your Anthropic key into an issue.