App Review Triage Monitor — App Store & Google Play Alerts

App Review Triage: new App Store and Google Play reviews, sorted into bugs, billing and requests

Give it your apps and it reads the new reviews from both stores, sorts each one into a bucket (bug or crash, billing complaint, feature request, praise, other), groups the ones saying the same thing, and tells you when the rating moved. It remembers what it already saw, so the second run only brings you what is new.

The classifier is keyword-based and its keywords are English, so a review in another language usually lands in other at low confidence. That is the main reason to add your own Anthropic key: with one set, the ambiguous reviews get a second look. Without one it still runs, on rules alone.

The App Store's public feed carries about 500 recent reviews per app and no developer replies, so replies only ever come from Google Play.

🔔 What App Review Triage does

Every run it fetches the most recent reviews for each app, from each store you gave it a URL for, and compares them against the snapshot it kept last time. What is new gets a row.

Each new review goes into one bucket with a severity. 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 cluster with an example and the review ids, not as five things to notice separately.

The rating is tracked across both stores against the last run's figure, so a drop is a flag rather than something you spot a week later.

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

Competitor apps feed the comparison in that report and the webhook summary. Their reviews are not written as dataset rows, and they are checked and processed the same way your own are.

📥 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.

📤 What you get back

Two kinds of row. First the per-app digest, real, from a real run:

{
  "type": "app_digest",
  "run_at": "2026-09-14T05:42:04.860601+00:00",
  "label": "My App",
  "app_id": "app_c9aa11a4733bf08e",
  "sync_status": "ok",
  "stores": ["app_store", "google_play"],
  "fresh_count": 10,
  "new_count": 10,
  "changed_count": 0,
  "bucket_counts": {"bug_or_crash": 0, "billing_complaint": 0, "feature_request": 0, "praise": 5, "other": 5},
  "urgent_count": 0,
  "urgent_items": [],
  "clusters": [],
  "rating_before": 4.096,
  "rating_after": 4.097,
  "rating_change": 0.001,
  "rating_drop_alert": false,
  "store_ratings": {"app_store": 4.69062, "google_play": 3.9933133}
}

Then one row per new review. This real row also shows the language limit: a one-star review in Hindi, which the rules could not place, so it landed in other at 0.2 confidence.

{
  "type": "new_review",
  "review_id": "gp_f8c2b0af-356e-4d7b-a14b-763ca2d2ebee",
  "store": "google_play",
  "app_id": "com.instagram.android",
  "app_label": "My App",
  "rating": 1,
  "title": "",
  "text": "mere original account ko bhi suspend Kar Diya",
  "author": "Hashim khan Hashim khan",
  "version": null,
  "date": "2026-09-13T05:40:16",
  "developer_response": false,
  "developer_response_text": null,
  "country": "us",
  "url": "https://play.google.com/store/apps/details?id=com.instagram.android",
  "is_competitor": false,
  "content_hash": "1b3b199fb19e4faee3f1a7dee827b51933be9417",
  "triage": {"bucket": "other", "severity": "low", "version": null, "keywords": [], "method": "rules", "confidence": 0.2}
}

🧾 Reading the output

type separates the two kinds of row, and both share one table view, so the columns look sparse either way. Export it, or open a row.

One thing to watch: sync_status: ok with new_count: 0 means nothing new was found, and a store quietly refusing looks the same. A steady zero from one store on a busy app is worth checking by hand.

The report files land in the run's key-value store as REPORT.html and REPORT.md, on the Storage tab.

▶️ How to run it

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?

An app is checked whether or not it has anything new, so a quiet app on a daily schedule still costs its check. A review you already saw is not charged again, and an edited one is re-sorted without being charged as new.

💡 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.
• Watching a rival's themes without reading their reviews yourself.

🚧 What it does not do

• The rules are English. Other languages usually land in other at low confidence. Your own

Anthropic key is the fix.

• One bucket per review. A crash report that also asks for a feature gets the stronger of the

two, not both.

• About 500 App Store reviews per app, and no developer replies from that store.
• It does not reply to reviews or touch your listings.
• It cannot tell "nothing new" from "could not look".
• One country per run, and the memory is not kept per country, so switching mid-stream compares

against the old country's snapshot.

• The blended rating needs both stores answering. If one store's metadata fails, the blend

becomes the other store's number, which can look like a drop that never happened.

• Competitor reviews are not written as rows.

🧭 Which review monitor do you need?

❓ Questions people ask

Do I need an Anthropic key? No. The built-in classifier runs on rules and needs nothing. A key only sharpens the ambiguous cases, and it bills to your own Anthropic account.

How does it know what is new? It keeps a snapshot of the review ids and their content hashes between runs, in its own key-value store. Nothing to configure.

Can I monitor one store only? Yes. Give an app just the App Store URL or just the Play URL.

Will it post to Slack? Paste an incoming-webhook URL into webhookUrl. It posts after every run, including quiet ones.

What happens on the first run? Everything it fetches is new, so expect a big first batch. Set maxReviewsPerRun low for that run if you would rather ease in.

Is scraping 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.