Google Play Store Review Scraper With App Details & Ratings

Google Play Review Scraper — Reviews and 1-5 Star Rating Counts

Reads a Google Play app's listing page, then samples its reviews — returning one app row carrying the store's real 1-to-5 star rating counts, plus one row per sampled review, all as structured JSON. Every response includes app metadata, publisher contact details, the store-wide rating histogram, and review text with date, helpful votes and app version. It's ready to pass directly to an LLM, index into a vector store, or feed a monitoring pipeline — no login, cookie or Google API key required to run it.

What is the Google Play Review Scraper?

The Google Play Review Scraper With App Details & Ratings is an Apify Actor that opens a public Google Play app listing, extracts the app's metadata and its real 1-to-5 star rating counts straight from the listing page, then pages through the same review feed Google's own site uses to sample individual reviews. What sets it apart from ordinary review scrapers: it doesn't stop at the average score. It returns exactly how many 1-star, 2-star, 3-star, 4-star and 5-star ratings an app has, each star's share of the total, an average recomputed from those counts as a cross-check on the number Play displays, and how far the reviews you actually sampled lean from that store-wide mix.

No Google account, Play Console login or API key is needed — every field comes from the same public page a visitor sees in a browser. The Actor accepts a list of app package names or Play Store URLs and runs them one after another in a single job.

• 📱 App listing metadata — title, developer, score, install count, current version, release notes, genre, content rating and pricing
• ⭐ The 1-to-5 star rating histogram — real counts and percentage shares per star, not a re-derivation from the sample
• 💬 Review sampling — reviewer name, star rating, text, date, helpful votes and the exact app version the review was left on
• 🎯 Server-side and client-side filtering — by star rating, keyword, app version, date range and recency
• ↕️ Sort control — most relevant, newest first, or by rating
• 📲 Device segmentation — sample reviews written on phones, tablets or Chromebooks

What data can you get with the Google Play Review Scraper?

The Actor writes three row types into one dataset, told apart by the type field: app, review, and error.

Result type	Extracted fields	Primary use case
App listing (type: "app")	title, developer, score, installs, version, genre, contentRating, price, developerEmail and more	App-profile lookups, market research, publisher outreach
1-to-5 star rating histogram (embedded in the app row)	ratingsOneStar…ratingsFiveStar, shareOneStarPct…shareFiveStarPct, averageRatingFromHistogram, skewOneStarPts…skewFiveStarPts	Rating-distribution analysis, ASO, release-quality tracking
Reviews (type: "review")	reviewer, rating, body, date, helpfulCounts, appVersion, userId, reviewUrl	Sentiment analysis, support triage, competitor benchmarking
Diagnostics (type: "error")	errorReason, errorDetail, target	Confirming a target was attempted and why it produced no rows

The 1-to-5 star rating histogram

This is the field competing Google Play scrapers don't return. Most tools give you an average score (4.2 stars) or, at best, a re-derived split computed from whatever reviews they happened to sample. This Actor reads the actual store-wide histogram Google embeds in the app listing page — the same counts Play itself uses to compute the average — so the numbers aren't a projection from a few hundred sampled reviews, they're the real distribution across every rating the app has ever received. On top of the raw counts, the Actor computes each star's percentage share, recomputes the average from the five counts as a sanity check on the displayed score, and measures the skew: how far the star mix of the reviews you actually pulled sits from the store-wide mix, in percentage points, suppressed below 20 sampled reviews so a small sample never masquerades as a trend.

{
  "ratingsOneStar": 3881214,
  "ratingsTwoStar": 596979,
  "ratingsThreeStar": 809050,
  "ratingsFourStar": 1872473,
  "ratingsFiveStar": 18851797,
  "ratingsHistogramTotal": 26011513,
  "shareOneStarPct": 14.92,
  "shareFiveStarPct": 72.48,
  "averageRatingFromHistogram": 4.2,
  "sampleOneStarPct": 9.0,
  "sampleFiveStarPct": 78.0,
  "skewOneStarPts": -5.92,
  "skewFiveStarPts": 5.52,
  "skewIsSignificant": true
}

The app listing row

Ahead of an app's reviews, the Actor emits one type: "app" row carrying the full listing: title, developer, score, install count (both the bucketed "500,000,000+" string and the exact internal figure), current version, release notes, genre, content rating, price and currency. Turn on includePublisherContact for the developer's email, website, privacy-policy link and postal address (where Play publishes one), or includeStoreMedia for the icon, header image, screenshot list and promo video URL. This row is where the rating histogram lives, so it's the anchor record for any per-app profile or competitor comparison.

⚠️ Coverage and limits

• The rating counts require the app row. The 1-to-5 star histogram is written onto the type: "app" row. If you turn off attachAppRecord, no app row is emitted — and with it, no ratingsOneStar…ratingsFiveStar fields — even if includeStarDistribution stays on. Leave attachAppRecord on if the star counts are what you're after.
• The histogram is read from the listing page, not measured from the sample. It reflects whatever Google has published on that page at scrape time. The Actor never fabricates a histogram: if the listing's rating block is missing or malformed, the star-count fields come back null rather than zero.
• appVersion coverage on review rows depends on sort order. Per the Actor's own input schema: roughly 99% of reviews carry a version stamp under mostRelevant, versus roughly 88% under newest — the newest reviews are the likeliest to arrive without one. Reviews with no version are dropped by the versionsToInclude filter, so prefer mostRelevant when filtering by version.
• Skew is suppressed below 20 sampled reviews. skewOneStarPts…skewFiveStarPts and skewSampleSize are null until the sample clears that floor; skewIsSignificant tells you which case you're in.
• No fixed per-app review ceiling in the code. reviewSampleSize accepts up to 100000, or -1 for uncapped — the run then keeps paging until Google's own cursor stops advancing, which is not a number this Actor controls or predicts.
• Legacy base-actor input keys still work. This Actor is a superset of an older base scraper and still reads its original key names (startUrls, maxReviews, sortBy, deviceType, rating, ratingFilter, keywords, appVersion, language, endDate, recentDays, uniqueOnly, startPage, pagesToScrape, reviewsPerPage). If a run input JSON supplies both a legacy key and this schema's equivalent key with different values, the legacy key wins for that field.
• sampleLanguages filters by storefront locale, not per-review language detection. Every review fetched in a run carries the same locale — the one the app page was requested with — not a per-row language classification.

Why not build a Google Play review scraper yourself?

Google Play has no public API for reading another publisher's reviews or rating histogram. The Google Play Developer API lets a verified owner manage and reply to reviews for apps they themselves administer in Play Console — it has no endpoint for looking up a competitor's app, its rating distribution, or its review text. For any use case involving apps you don't own — competitor benchmarking, market research, ASO analysis across a category — there is no first-party API to call.

Building this in-house means reverse-engineering Google Play's internal batchexecute RPC surface: the same undocumented endpoint the Play website itself uses to fetch reviews, driven by a request template embedded in the page's inline AF_initDataCallback script data. That template is not stable — the slot this Actor targets by its id:'oCPfdb' marker has already drifted position once in the page's internal data-block indexing, silently breaking naive integrations that anchor on a fixed index instead of the id. Add anti-bot escalation (soft-block detection on a 200 response, not just 403/429/503) and proxy cost for blocked requests, and the maintenance burden of a homegrown scraper is ongoing, not one-time.

What's the difference between an app's star average and its 1-to-5 star rating counts?

An app's star average is a single decimal number — 4.2 — the one figure Google Play shows next to an app's name. Its 1-to-5 star rating counts are the full histogram behind that number: how many ratings sit at each star value. The average alone can't tell you whether an app has a healthy, broad base of 4- and 5-star ratings or a polarized mix of many 1-stars offset by many 5-stars — two very different distributions can produce the same 4.2 average.

This distinction matters for release monitoring: a version that spikes 1-star ratings while barely moving the average is a real regression the average hides. It matters for ASO and competitor analysis too — a narrow, book-ended distribution signals a divisive app in a way the average never will.

This Actor returns both. The average arrives as score / scoreText on the type: "app" row (as Play reports it), while the full count-and-share breakdown arrives in the same row's ratingsOneStar…ratingsFiveStar and shareOneStarPct…shareFiveStarPct fields, plus averageRatingFromHistogram — the mean recomputed from the five counts, as a cross-check on the displayed score.

How to scrape Google Play reviews with the Review Scraper

1. Open Google Play Store Review Scraper With App Details & Ratings on the Apify Store and click Try for free (or Start, if you already have it saved).
2. Enter one or more values in appTargets — a Google Play package name (com.spotify.music) or a full listing URL, one per line.
3. Set the review controls that matter for your job: reviewSort for chronological vs. relevance order, starsToInclude to sample only certain star values, sampleDevice to segment by phone/tablet/Chromebook, and reviewSampleSize for how many review rows you want per app.
4. Click Start to run the Actor.
5. When the run finishes, open the Dataset tab and export the results as JSON, CSV, Excel, XML or HTML table — or read them straight from the Apify API.

{
  "appTargets": ["com.supercell.brawlstars"],
  "reviewSampleSize": 200,
  "reviewSort": "newest",
  "starsToInclude": ["1", "2"]
}

How to sample multiple apps in one run

appTargets accepts one package name or Play URL per line, so a single run can queue as many apps as you like — the Actor processes them sequentially and writes each app's listing row followed by its reviews into the same dataset. There's no separate batch-upload input; add every app you want to a single appTargets list, or run the Actor multiple times (once per app set) if you want each app's results in a separate dataset.

⬇️ Input

All fields are optional — the schema ships with a working prefill (com.supercell.brawlstars) so a first run needs no configuration at all.

Parameter	Type	Default	Constraints
appTargets	array of strings	—	Google Play app URLs or package names, one per line. Both forms accepted.
attachAppRecord	boolean	true	Emit one type: "app" row per app ahead of its reviews.
includeStarDistribution	boolean	true	Add the 1-to-5 star counts, shares, histogram average and sample skew to the app row.
includePublisherContact	boolean	true	Add developerEmail, developerWebsite, developerAddress, privacyPolicy to the app row.
includeStoreMedia	boolean	false	Add icon, headerImage, screenshots, screenshotCount, video to the app row.
reviewSampleSize	integer	100	Min -1, max 100000. Review rows to return per app, counted after filtering. -1 = no cap.
reviewSort	string (enum)	"mostRelevant"	"mostRelevant", "newest", or "rating".
starsToInclude	array of strings	—	Enum values "1"–"5". Keep only these star ratings. A single value is filtered server-side by Google.
sampleDevice	string (enum)	"mobile"	"mobile", "tablet", or "chromebook".
mustContainKeywords	array of strings	—	Keep only reviews whose text contains at least one of these words (case-insensitive).
versionsToInclude	array of strings	—	Keep only reviews left on these exact app versions, matched against the version stamped on each review.
lastNDays	integer	0	Min 0. Keep only reviews from the last N days. 0 = no time limit.
newestDate	string (date)	""	Keep only reviews written on or before this date (YYYY-MM-DD). Empty = no upper bound.
sampleLanguages	array of strings	—	Enum of 36 code - Language pairs (e.g. "en - English"). Filters by storefront locale, not per-review language detection.
singleStarRating	integer (nullable)	null	Min 1, max 5. Shorthand for a one-star-value sample. Ignored when starsToInclude is set.
dedupeById	boolean	true	Drop reviews already saved in this run, matched on the Google review ID.
batchSize	integer	200	Min 1, max 1000. Reviews requested per API call. Values above 1000 are clamped to 1000, the highest Google was observed to honour.
maxPagesPerApp	integer	-1	Min -1. Hard stop on paging regardless of reviews kept. -1 = no page limit.
beginAtPage	integer	1	Min 1. Start saving from page N. Pages 1..N-1 are still fetched and discarded — Google's cursor can only be walked forward.
proxyConfiguration	object	{"useApifyProxy": false}	Apify Proxy configuration. If a request is blocked, the run escalates to a residential IP once and retries.

No parameter in this schema is marked as a secret or credential — the Actor doesn't require an API key, login token or account of any kind, so there is nothing here that needs masking.

Example input

{
  "appTargets": [
    "com.supercell.brawlstars",
    "com.duolingo"
  ],
  "attachAppRecord": true,
  "includeStarDistribution": true,
  "includePublisherContact": false,
  "includeStoreMedia": false,
  "reviewSampleSize": 150,
  "reviewSort": "mostRelevant",
  "starsToInclude": ["1", "2"],
  "sampleDevice": "mobile",
  "mustContainKeywords": ["crash", "refund"],
  "dedupeById": true,
  "batchSize": 200,
  "proxyConfiguration": { "useApifyProxy": false }
}

Common pitfall: the appTargets value must be a package name (com.spotify.music) or the store listing URL (https://play.google.com/store/apps/details?id=...) — not a search-results URL or a market:// deep link, neither of which resolve to a parseable app id.

⬆️ Output

Every run writes typed, normalized JSON rows to the Actor's default dataset, one schema per type value. Export as JSON, CSV, Excel, XML or HTML table from the Apify Console, or pull rows directly through the Apify API / apify-client SDKs.

Scraped results

[
  {
    "type": "app",
    "isChild": false,
    "appId": "com.supercell.brawlstars",
    "appUrl": "https://play.google.com/store/apps/details?id=com.supercell.brawlstars",
    "title": "Brawl Stars",
    "summary": "Fast-paced 3v3 multiplayer battles",
    "score": 4.2,
    "scoreText": "4.2",
    "ratings": 26011596,
    "reviewsTotal": 812345,
    "installs": "500,000,000+",
    "minInstalls": 500000000,
    "realInstalls": 544867104,
    "version": "58.297",
    "updated": "2026-06-30T00:00:00Z",
    "released": "Dec 12, 2018",
    "recentChanges": "Bug fixes and performance improvements.",
    "genre": "Action",
    "genreId": "GAME_ACTION",
    "contentRating": "Everyone 10+",
    "androidVersion": "6.0 and up",
    "price": 0,
    "currency": "USD",
    "free": true,
    "offersIAP": true,
    "developer": "Supercell",
    "developerId": "5700313618786177705",
    "ratingsOneStar": 3881214,
    "ratingsTwoStar": 596979,
    "ratingsThreeStar": 809050,
    "ratingsFourStar": 1872473,
    "ratingsFiveStar": 18851797,
    "ratingsHistogramTotal": 26011513,
    "shareOneStarPct": 14.92,
    "shareFiveStarPct": 72.48,
    "averageRatingFromHistogram": 4.2,
    "sampleSize": 150,
    "sampleOneStarCount": 14,
    "sampleFiveStarCount": 117,
    "sampleOneStarPct": 9.33,
    "sampleFiveStarPct": 78.0,
    "skewOneStarPts": -5.59,
    "skewFiveStarPts": 5.52,
    "skewSampleSize": 150,
    "skewIsSignificant": true,
    "ratingsPerMillionInstalls": 47740.9,
    "reviewsPerMillionInstalls": 1490.8,
    "developerEmail": null,
    "developerWebsite": null,
    "privacyPolicy": null,
    "scrapedAt": "2026-07-26T09:00:00Z"
  },
  {
    "type": "review",
    "isChild": false,
    "reviewId": "gp:AOqpTOF...",
    "rating": 1,
    "reviewer": "J. Alvarez",
    "body": "Matchmaking has been broken since the last update, constantly paired against much higher trophy players.",
    "date": "2026-07-24",
    "reviewedAt": "2026-07-24T18:12:03Z",
    "timestamp": 1785456723,
    "reviewedIn": "en",
    "language": "en",
    "helpfulCounts": 42,
    "appVersion": "58.297",
    "userId": "104829384756201938475",
    "userImage": "https://play-lh.googleusercontent.com/a/AGNmy...",
    "reviewUrl": "https://play.google.com/store/apps/details?id=com.supercell.brawlstars&reviewId=gp:AOqpTOF...",
    "position": 1,
    "appId": "com.supercell.brawlstars",
    "appTitle": "Brawl Stars",
    "appDeveloper": "Supercell",
    "appScore": 4.2,
    "appRatingsTotal": 26011596,
    "appInstalls": "500,000,000+",
    "appCurrentVersion": "58.297",
    "storeShareForThisRatingPct": 14.92,
    "scrapedAt": "2026-07-26T09:00:14Z"
  },
  {
    "type": "review",
    "isChild": false,
    "reviewId": "gp:AOqpTOG...",
    "rating": 2,
    "reviewer": "Priya S.",
    "body": "Fun core gameplay but the ad frequency between matches has gotten out of hand.",
    "date": "2026-07-23",
    "reviewedAt": "2026-07-23T11:44:51Z",
    "timestamp": 1785370091,
    "reviewedIn": "en",
    "language": "en",
    "helpfulCounts": 11,
    "appVersion": "58.297",
    "userId": "998271038475620194875",
    "userImage": "https://play-lh.googleusercontent.com/a/AGNmy...",
    "reviewUrl": "https://play.google.com/store/apps/details?id=com.supercell.brawlstars&reviewId=gp:AOqpTOG...",
    "position": 2,
    "appId": "com.supercell.brawlstars",
    "appTitle": "Brawl Stars",
    "appDeveloper": "Supercell",
    "appScore": 4.2,
    "appRatingsTotal": 26011596,
    "appInstalls": "500,000,000+",
    "appCurrentVersion": "58.297",
    "storeShareForThisRatingPct": 2.29,
    "scrapedAt": "2026-07-26T09:00:15Z"
  },
  {
    "type": "error",
    "isChild": false,
    "appId": "com.example.notreal",
    "target": "com.example.notreal",
    "errorReason": "app_not_found",
    "errorDetail": "AppNotFound: https://play.google.com/store/apps/details?id=com.example.notreal",
    "scrapedAt": "2026-07-26T09:00:20Z"
  }
]

The full field list — every key the row-building code writes, not just this table's illustration — is:

App row (type: "app"): appId, appUrl, title, summary, description, score, scoreText, ratings, reviewsTotal, installs, minInstalls, realInstalls, version, updated, released, recentChanges, genre, genreId, contentRating, contentRatingDescription, androidVersion, price, currency, free, offersIAP, iapRange, developer, developerId, scrapedAt, plus — when includePublisherContact is on — developerEmail, developerWebsite, developerAddress, privacyPolicy; when includeStoreMedia is on — icon, headerImage, screenshots, screenshotCount, video; and when includeStarDistribution is on — ratingsOneStar…ratingsFiveStar, ratingsHistogramTotal, shareOneStarPct…shareFiveStarPct, averageRatingFromHistogram, sampleSize, sampleOneStarCount…sampleFiveStarCount, sampleOneStarPct, sampleFiveStarPct, skewOneStarPts…skewFiveStarPts, skewSampleSize, skewIsSignificant, ratingsPerMillionInstalls, reviewsPerMillionInstalls.

Review row (type: "review"): reviewId, rating, reviewer, date, reviewedIn, body, userImage, position, helpfulCounts, appId, timestamp, language, reviewUrl, reviewedAt, userId, appVersion, scrapedAt, plus the app-context stamp: appTitle, appDeveloper, appScore, appRatingsTotal, appInstalls, appCurrentVersion, storeShareForThisRatingPct.

Diagnostic row (type: "error"): appId, target, errorReason, errorDetail, scrapedAt. These rows are pushed without a charged event — see the Pricing note under Frequently Asked Questions.

Every row also carries type and isChild. isChild is always false in the current build — there is no nested child-row hierarchy in this Actor's output, so the field carries no information today.

How can I use the data from the Google Play Review Scraper?

• 📈 ASO and app marketers: track whether a release is shifting the 1-star count specifically, not just nudging the average — filter versionsToInclude to the version you just shipped and read skewOneStarPts.
• 🤖 AI engineers and LLM developers: query an app package name, receive structured JSON, and pass body, rating and the histogram fields to a model as grounded context for a summarization or sentiment agent.
• 📊 Market researchers: pull ratingsPerMillionInstalls and reviewsPerMillionInstalls across a set of competitor apps to compare engagement independent of raw install count.
• 🧩 Product teams: sample only starsToInclude: ["1", "2"] sorted newest after a release to triage real complaints instead of reading an average that hides them.

How do you monitor an app's rating histogram over time?

Rating-histogram monitoring means running this Actor against the same app (or app set) on a schedule and comparing each run's ratingsOneStar…ratingsFiveStar, shareOneStarPct…shareFiveStarPct and averageRatingFromHistogram fields against the previous run's. Because the histogram is read fresh from the listing page every run, a real shift in the counts between two runs reflects a real shift in how the app is being rated — not sampling noise, since it isn't derived from your review sample at all.

The workflow: schedule a run across your app-package list, store each run's app row keyed by appId and scrapedAt, then diff ratingsOneStar and shareOneStarPct against the prior run. A rising 1-star share alongside a falling averageRatingFromHistogram right after a version bump is a concrete regression signal — pair it with versionsToInclude set to that version to pull the actual complaint text behind the number. The skewOneStarPts field on the same row tells you, in the same run, whether your currently-sampled reviews are already trending worse than the store-wide mix, which is often the earliest warning before the full histogram catches up.

To automate the cadence, use the Apify platform's own Schedules feature (Apify Console → Actor → Schedules) to run this Actor on a recurring interval and land each run's output in a fresh dataset for comparison.

🔌 Integrate the Review Scraper and automate your workflow

The Google Play Review Scraper works with any language or tool that can call the Apify API — there's no bespoke protocol to learn.

REST API with Python

from apify_client import ApifyClient

client = ApifyClient("<APIFY_API_TOKEN>")

run = client.actor("<YOUR_USERNAME>/google-play-store-review-scraper-with-1-5-star-rating-counts").call(
    run_input={
        "appTargets": ["com.supercell.brawlstars"],
        "reviewSampleSize": 100,
        "reviewSort": "newest",
    }
)

for item in client.dataset(run["defaultDatasetId"]).iterate_items():
    if item["type"] == "app":
        print(item["title"], item["ratingsOneStar"], item["shareFiveStarPct"])
    elif item["type"] == "review":
        print(item["rating"], item["body"][:80])

Scheduled monitoring and delivery

The Actor has no built-in webhook or push-delivery feature of its own — it writes to an Apify dataset like any Actor. Use the Apify platform's Schedules to trigger recurring runs, and Apify's Actor/task webhooks to fire an HTTP callback on run completion so a downstream system can pull the fresh dataset without polling.

Is it legal to scrape Google Play reviews?

Yes — scraping publicly visible Google Play listing and review data is generally lawful in most jurisdictions, and this Actor returns only what any visitor sees on the app's public listing page. It requires no login and accesses no account-gated content.

App metadata (title, developer, pricing, install count, the rating histogram) is business and product data, governed primarily by Google Play's Terms of Service and database-rights considerations rather than personal-data law. Review rows are a partial exception: fields like reviewer, userId and userImage can constitute personal data under GDPR and CCPA where the data subject is identifiable, so store and process those fields in line with your applicable regime, particularly for EU or California users. Scraping for internal monitoring or research carries a different risk profile than scraping for AI-training or redistribution — evaluate accordingly. Consult your legal team for commercial use cases involving bulk data storage.

❓ Frequently asked questions

Does the Review Scraper support other storefront languages?

Yes — set sampleLanguages to one or more of 36 supported code - Language pairs (e.g. "de - German") to keep only reviews fetched from a matching storefront locale. Leave it empty to sample every locale the run happens to hit. This filters by the locale the review page was requested with, not per-review language detection, so every row in a single run shares the same value.

What's the difference between reviewSort and sampleDevice?

reviewSort controls which slice of the review feed Google returns — "mostRelevant" (what a shopper sees first), "newest" (chronological, best for tracking a release), or "rating" (highest-rated first). sampleDevice controls which device segment ("mobile", "tablet", "chromebook") the reviews were written on — Google segments reviews by device, and the version mix differs per segment. The two are independent and can be combined.

How does the Review Scraper handle Google Play's anti-bot measures?

It detects soft blocks by content, not just HTTP status — a 200 response missing the expected WIZ_global_data or AF_initDataCallback markers is treated as blocked, not as a successful empty page. On a detected block or a 403/429/503 status, it retries with exponential backoff and, on the first block, escalates once to a residential proxy IP if proxyConfiguration is enabled.

Does the Review Scraper extract the 1-to-5 star rating counts?

Yes — they arrive as ratingsOneStar through ratingsFiveStar, plus shareOneStarPct…shareFiveStarPct and averageRatingFromHistogram, on the type: "app" row, whenever includeStarDistribution and attachAppRecord are both on (the default). They come back null if Google Play's listing page doesn't expose a parseable rating block for that app.

How many reviews does the Review Scraper return per app?

Up to reviewSampleSize (default 100, max 100000), counted after all filters are applied. Set reviewSampleSize to -1 for no cap — the run then keeps paging until Google's own pagination cursor stops advancing for that app, which isn't a fixed number the Actor controls.

How do I monitor an app's rating histogram over time?

Schedule recurring runs against the same appTargets list using Apify's Schedules feature, and diff ratingsOneStar…ratingsFiveStar and shareOneStarPct…shareFiveStarPct between runs, keyed by appId and scrapedAt. See "How do you monitor an app's rating histogram over time?" above for the full workflow.

Does the Review Scraper work with Claude, ChatGPT, and AI agent frameworks?

It's callable as a standard HTTP endpoint through the Apify API, so any agent framework that can make an HTTP request — including Claude tool use, LangChain, or a custom agent loop — can call it, receive the JSON dataset, and ground a response in the returned app and review data. It is not currently exposed through a dedicated MCP server.

How does the Review Scraper compare to other Google Play scrapers?

Checked on the Apify Store on 2026-07-26: fascinating_lentil/google-play-store-scraper returns app metadata only — no reviews, no rating histogram, direct package-id lookups. inexhaustible_glass/google-play-scraper returns reviews plus optional app metadata, with sort and country/language controls, but its listing documents only a headline score and review count — no 1-to-5 star breakdown or sample-vs-store skew. Neither listing documents a rating histogram, per-star share, or skew metric. This Actor is the only one of the three whose documented output includes the store-wide rating counts and the sample-vs-store skew alongside the review sample.

Can I use the Review Scraper without managing proxies or Google Play credentials?

Yes. No Google Play account, cookie, or API key is required — every field is read from a public listing page. proxyConfiguration defaults to disabled; enable Apify Proxy only if you start seeing blocks, and the Actor will escalate to a residential IP automatically on the first detected block.

What happens if I supply both this Actor's own input keys and the older base-actor key names?

The older key wins for that field. This Actor is a superset of an earlier base scraper and still reads its original key names (startUrls, maxReviews, sortBy, deviceType, rating, ratingFilter, keywords, appVersion, language, endDate, recentDays, uniqueOnly, startPage, pagesToScrape, reviewsPerPage) so old input JSON keeps working — but if a single input object sets both, say, startUrls and appTargets to different app lists, startUrls is the one that's used. Stick to one key set per run input to avoid surprises.

💬 Your feedback

Found a bug, an app where the histogram doesn't parse, or a field you need that isn't here? Message Scrapier through the Actor's page on the Apify Store — issues and feature requests are read and actioned there. Reports of specific appId values that fail help track down listing-page format changes fast.