App Review Monitor
Pricing
from $0.38 / 1,000 reviews
App Review Monitor
App review monitor that triages new App Store and Google Play reviews into bugs, billing complaints and feature requests, with similar reviews grouped and a flag when the rating drops. One row per new review, one digest per app, alerts to Slack. $0.40 per 1,000 reviews.
Pricing
from $0.38 / 1,000 reviews
Rating
5.0
(1)
Developer
Dami's Studio
Maintained by CommunityActor stats
0
Bookmarked
2
Total users
0
Monthly active users
3 hours ago
Last modified
Categories
Features
Share
App review monitor for new App Store and Google Play reviews, 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, in the review language you set. 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, and the review language |
| Output | One digest row per app (buckets, urgent items, themes, rating change), plus one row per new review |
| Ceiling | Up to 5,000 reviews per app per run on Google Play, or with readAllNewReviews on, every new one since the last run, up to 10,000. A run stops a little before its time limit and keeps the apps it has checked |
| 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 Monitor does
Every run it fetches the newest reviews for each app from each store you gave it, and compares them with last time's snapshot. 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
- Open App Review Monitor and click Try for free.
- In Apps to monitor, replace the example with your own: a label and one or both store URLs.
- Set Store country and Review language if you are not on
usand English. - Paste a Slack incoming-webhook URL into Webhook / Slack URL if you want the summary pushed.
- 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 |
A new review read past the max with readAllNewReviews on | $0.0004, the same as any new review | 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","language": "en"}
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. On the App Store it picks that country's reviews. On Google Play it sets where the app's rating is read from. Pick one and stay on it: the snapshot is not kept per country. |
language | en | en, es, pt, fr, de, it, tr, id or ru. Google Play sends the reviews written in this language, and the sorting reads it in the reviews of both stores, along with English. Pick one and stay on it: another language brings its own first batch. |
maxReviewsPerRun | 100 | Reviews fetched per app per store, 10 to 5,000, most recent first. |
readAllNewReviews | false | Turn it on and a run keeps reading past maxReviewsPerRun until it gets back to the reviews the last run delivered, so a busy app loses none between runs. The first run with it on reads up to the max, to know where to start. Up to 10,000 new Google Play and 5,000 new App Store reviews per app per run; any more come with the next run. Your own apps only: competitor apps keep to the max. |
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. null when the store reports none. |
developer_response | Google Play only. |
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. |
catch_up | On the digest row, with readAllNewReviews on, per store: first_run, complete, more_waiting or stopped_short. |
🧾 Reading the output
type separates the kinds of row. Both share one table view, so the columns look sparse: 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 |
| The time-limit note | type: "notice" with errorCode: "TIME_LIMIT" | no |
Newer reviews waiting for the next run, with readAllNewReviews on | type: "notice" with errorCode: "MORE_WAITING" | no |
| A read that could not get back to the last run's reviews | type: "notice" with errorCode: "STOPPED_SHORT" | no |
No sample row; codes TIME_LIMIT, MORE_WAITING, STOPPED_SHORT. sync_status: "ok" with new_count: 0 means nothing new came back this run.
💡 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.
- No developer replies from the App 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 |
| A one-off pull of Google Play reviews, 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 10,000 reviews per app, 30,000 with readAllNewReviews.
Can it sort reviews in Spanish, German or Turkish?
Set language to English, Spanish, Portuguese, French, German, Italian, Turkish, Indonesian or Russian: Google Play sends reviews in it, and the sorting reads it. For the App Store, set country to that market too.
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?
The API tab has code for Python, JavaScript and
the CLI. MCP clients like Claude and ChatGPT use
https://mcp.apify.com/?tools=fetch-actor-details,dami_studio/app-review-triage-monitor; coding assistants can load
our skill
file. All
three bill 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.