App Store Reviews Monitor & Analyzer — Apify Actor (deploy-ready, not yet published)

Fetches the most recent App Store reviews for any app and returns clean structured data plus a run summary (average rating, rating breakdown, low-rating share, most-reviewed app versions, top complaint signals in 1–2★ reviews). Built for ASO monitoring, indie devs, support/QA teams and scheduled "new bad review" alert pipelines (Make/Zapier/n8n via Apify schedules + webhooks).

Status: built and locally verified 2026-10-29 (offline sample test + live test, both below). No Apify account exists yet and nothing has been published — deployment steps are at the bottom.

Why this niche (scan summary, Oct 2026)

Selection rules: public/legit data only, visible demand, no dominant free incumbent, AI-maintainable, and pay-per-event economics that can't go negative (Apify retired rental pricing Apr 2026 — PPE is the only model for new Actors, and browser/proxy-heavy Actors can lose money per sale).

Winner justification: Apple's customer-reviews RSS feed is an official, login-free, public feed — no scraping arms race, no proxy bill, compute per run is a few plain HTTPS GETs, so PPE margin is structurally safe. Incumbents are beatable on fields/speed (bench: most-used Actor 71% fields filled, 183s vs 57s for a 300-review job) and none lead with analytics. The summary block (rating mix, low-rating share, top complaint words per version) is the differentiator: raw scrapers sell rows, this sells "is the new update hurting us?" in one scheduled run.

What it does

Input: an App Store app ID or apps.apple.com URL, a storefront country, and a max review count (≤500 — Apple's feed cap). Output: one dataset item per review + a SUMMARY object in the key-value store. Optional mode pushes only 1–2★ reviews to the dataset (alert pipelines) while the summary is still computed over everything fetched.

Input (/.actor/input_schema.json)

Output (per review)

reviewId, appId, country, author, rating, title, body, appVersion, updatedAt, helpfulVotes, totalVotes, isLowRating, negativeSignals, storeUrl

Summary (SUMMARY key)

reviewCount, averageRating, ratingBreakdown{5..1}, lowRatingCount, lowRatingSharePct, topVersionsReviewed, topNegativeSignalsInLowReviews, newestReviewAt, oldestReviewAt

Project layout

first-actor/
├── .actor/
│   ├── actor.json            # name/title/description, dockerfile + schema pointers
│   ├── input_schema.json
│   ├── output_schema.json    # dataset schema
│   └── pay_per_event.json    # PPE pricing (see below)
├── Dockerfile                # apify/actor-python:3.12
├── requirements.txt          # core is stdlib-only; SDK from base image
├── src/
│   ├── core.py               # ALL logic, pure stdlib — testable offline
│   └── main.py               # thin Apify entrypoint (charge → fetch → push)
├── local_run.py              # offline/live test harness, no account needed
├── tests/sample_feed.json    # real Apple feed page (captured 2026-10-29, trimmed)
└── output/                   # reviews.json / reviews.csv / summary.json from test runs

Local test results (2026-10-29, actually run)

Offline (python3 local_run.py --sample tests/sample_feed.json): 6 reviews parsed, avg 1.67, breakdown {5:1, 1:5}, low-rating share 83.3%.

Live (python3 local_run.py --app-id 389801252 --country us --max-reviews 20): 20 reviews parsed from Apple's live feed, avg 2.55, breakdown {5:7, 4:0, 3:0, 2:3, 1:10}, low-rating share 65.0%, newest review 2026-10-28. Full items in output/reviews.json; example item:

{
  "reviewId": "14721711404", "appId": "389801252", "country": "us",
  "author": "Larmyclarmyparmy", "rating": 1,
  "title": "Pausing music when opening the app",
  "body": "This is new with the last update. Instagram now pauses my music when I open the app...",
  "appVersion": "453.0", "updatedAt": "2026-10-28T06:28:12-07:00",
  "helpfulVotes": 0, "totalVotes": 0, "isLowRating": true,
  "negativeSignals": ["bug"]
}

Proposed pricing (pay-per-event, .actor/pay_per_event.json)

Economics: a 500-review run bills $0.35; compute is a few seconds of a small Python container (no browser, no proxy) ≈ $0.005–0.02 platform cost. Creator keeps 80% of event revenue minus platform costs (Apify's standard split; Apify reports $760K paid to creators in Jan 2026 and ~$1.6M in a recent month across the Store). Every Apify user also gets $5/mo free credits, so expect free-tier trial runs before real revenue — normal.

Honest expectation: week-1 paying users may be zero (a comparable niche build log reported exactly that). Store ranking is driven by README quality, working defaults, example tasks and early reviews — budget the first month as distribution work, not passive income.

Deployment steps (when Brian's Apify account exists — Brian's step)

1. Brian creates the Apify account and adds a payout method (PayPal/Wise) — account/payout are his alone; Muse never logs in.
2. From this folder: apify login (Brian) → apify push — or zip-upload via Console → Actors → Create Actor → upload.
3. In Console, confirm the PPE events from .actor/pay_per_event.json appear under the Actor's pricing (file placement matters: it must live in .actor/, or charges silently don't record).
4. Run the built-in example task (app 389801252, us, 50 reviews) and verify chargedEventCounts in the run object shows 1× actor-start + 50× review-scraped before making the Actor public.
5. Publish to Store with example tasks + this README's Store description (in actor.json), then submit for Store review.
6. Any publish/pricing change after that still goes through Brian's approval, per standing rules.

Maintenance notes

• Breakage risk: LOW. The RSS-JSON format has been stable for years and is an official feed. Main risks: Apple retiring the feed (would hit every competitor equally) or an app having <50 reviews in a storefront (handled: pagination stops on an empty page; summary handles 0 reviews).
• No proxies/browsers to babysit. If a storefront returns non-JSON (rare regional quirk), the run fails loudly rather than billing for junk — actor-start is the only charge in that case; monitor failed-run rate after launch.
• Known limits: 500 reviews/app/run max (feed cap); most-recent order only (Apple offers sortby=mosthelpful — a v1.1 toggle is a one-line change in core.py); Play Store reviews are a separate v2 (different, unofficial endpoints — deliberately out of scope for v1's legit-data rule).
• Roadmap if it gets traction: v1.1 sort toggle + multi-app input; v1.2 scheduled-diff mode ("only reviews newer than last run" via KVS state — the monitor pattern that supports the $0.10 start fee best); then the Shopify price/stock monitor as Actor #2.