Google Play Store Reviews Scraper

Google Play Review Scraper — Ratings, Review Text and Dates

Google Play Review Scraper extracts public app reviews from the Google Play Store as structured JSON: star rating, full review text, reviewer display name, helpful votes, the reviewer's Google user ID, a direct review URL, and the review date as both Unix epoch seconds and an ISO 8601 UTC timestamp. Paste app URLs or bare package names, filter by star, keyword, app version or date window, and rows land in the dataset as they pass the filters. Runs on Apify — no Google account required.

What is Google Play Review Scraper?

Google Play Review Scraper is an Apify Actor that reads the Google Play Store's own review endpoint for any Android app and returns 17 typed fields per review. Targets are given as full Play Store URLs or bare package names such as com.spotify.music, and every filter you set is applied before a row is written, so you are never handed rows you asked it to exclude.

No Google account, Play Console access or API key is needed. Only data visible on the public store listing is collected.

It is built for mobile product managers tracking release sentiment, support and ASO teams triaging complaints, and developers piping review text into an analysis or LLM pipeline.

What Google Play review data is publicly available to scrape?

Every review on a Google Play listing — its text, star rating, author name, avatar, helpful votes and date — is visible to any visitor with no sign-in. What sits behind a login is the app owner's side of the same data, inside the Google Play Console.

Data Category	Public on the listing	Play Console (app owner login)
Review text, star rating, review date	✅ Returned	—
Reviewer display name and avatar	✅ Returned	—
Helpful vote count	✅ Returned	—
Reviewer's Google user ID on the review	✅ Returned	—
App version a review was written against	✅ Public — used here as a filter, not emitted as a column	Full per-version breakdowns
Developer reply to a review	✅ Public on the listing	❌ Not returned by this Actor
Reviewer email, device model, purchase history	❌	Owner's own app only
Posting or moderating a reply, deleting a review	❌	Owner's own app only

Google Play Review Scraper only returns publicly visible data — what any visitor sees. Nothing behind a login wall.

What data can I extract with Google Play Review Scraper?

Each row is one review, carrying the review itself, its author, the app it belongs to, and run accounting.

Field Name	Description
reviewId	Google's own review identifier — the deduplication key
rating	Star rating as Google returns it, 1–5
reviewer	Reviewer's public display name
userId	Google user identifier carried on the review; null when Google omits it
body	Full review text
helpfulCounts	Helpful vote count; null when the slot is absent
reviewUrl	Deep link back to the review on the app listing
userImage	Reviewer avatar image URL
date	Review date as YYYY-MM-DD, UTC
reviewedAt	The same instant as an ISO 8601 UTC timestamp
timestamp	Unix epoch seconds for the review
reviewedIn	Short language code of the storefront locale the request was served in
language	The same storefront locale code as reviewedIn
position	1-based order among the rows saved for this app
appId	Package name the row belongs to
scrapedAt	ISO 8601 UTC timestamp of when the page was parsed
errorReason	null on review rows; a short code on accounting rows
errorMessage	Present only on accounting rows — the failing input plus the error text, truncated to 500 characters

Review and reviewer fields

reviewId, rating, body and helpfulCounts are the core of a row. reviewId is Google's identifier and it is stable, so deduplicating a merged historical dataset across runs is an exact match rather than a fuzzy one. reviewer, userId and userImage identify the author; reviewUrl is built from appId and reviewId, so every row links back to the review on the listing.

Timestamps, locale and run accounting

The review date arrives once and is emitted three ways: timestamp (Unix seconds, exactly as Google sends it), date (YYYY-MM-DD) and reviewedAt (ISO 8601 UTC). When Google supplies no usable timestamp, all three come back null rather than a guessed value — and note that a review with no date is dropped whenever endDate or recentDays is set.

reviewedIn and language are worth reading carefully: both hold the same short code, and it describes the storefront locale the request was served in, not a per-review detected language. They are identical on every row of a run.

position restarts at 1 for each app in a multi-app run and counts only rows that survived filtering. scrapedAt is stamped once per fetched page, so all rows from the same page share it.

🤖 Add-on: Need additional review data?

For the other side of the mobile market, Apple App Store Review Scraper & App Ratings Summary covers iOS reviews and per-app rating summaries — the natural pair for a cross-platform sentiment dataset. Google Maps Scraper — Reviews & Sentiment Analysis does the same job for physical locations, and Goodreads Review Scraper With Reviewer Lead Enrichment covers book reviews and reviewer details.

Why not build this yourself?

Google Play has no public API for reading other developers' reviews. The Play Developer Reply to Reviews API exists, but Google's published documentation scopes it to apps in your own Play Console account — it is a tool for answering your own users, not for reading a competitor's. Anything else means reading the store front-end, and that front-end does not serve reviews in HTML.

Reviews come from Play's internal batchexecute RPC, and the awkward parts are structural rather than hard:

• The request template has to be lifted out of the app detail page, along with a session id and the Play front-end build tag, and both of those change.
• The template lives in a numbered ds:N slot that drifts between Play releases. This Actor locates it by its RPC id instead, because anchoring on the slot number silently parses an unrelated RPC and returns zero reviews on every run without ever erroring.
• Responses are chunked, length-prefixed frames with a JSON string nested inside a JSON array, and reviews sit at fixed positions in unlabelled arrays.
• Pagination is cursor-only. There is no page number to jump to, and the server will happily hand back a cursor that does not advance.
• An HTTP 200 with the expected frame missing is a soft block, not a success. A status-code-only check reads it as an empty page.

None of these are individually difficult. Together they are why a hand-rolled version tends to return zero rows after a Play front-end change, without raising an error.

⚠️ How many reviews you can actually collect

Two ceilings apply, and they belong to different parties. Stating them plainly matters more than quoting a big number.

The Actor's ceiling: 10,000 reviews per app. maxReviews accepts up to 10000, and -1 resolves to that same figure. Anything higher is clamped in code. This is the Actor's own limit, not Google's.

Page size: 1 to 1,000. reviewsPerPage is clamped into that range before the request is built. The source records 1,000 as the largest page size Google Play honours; larger values are not.

A Google-imposed per-app ceiling: none is applied anywhere in this Actor's code. Collection for an app stops when the first of these happens — maxReviews is reached, pagesToScrape is reached, Google stops issuing a pagination cursor, the cursor repeats itself, or two consecutive pages return nothing but reviews already seen. How deep the cursor actually goes varies by app and by sortBy, and this Actor neither measures nor guarantees it.

If you are arriving from an App Store scraper, that is the difference to internalise: there is no fixed per-app number here to plan around.

How to use Google Play Review Scraper

Google Play Review Scraper runs on Apify. Start it from the Apify Console, or call it through the Apify API.

1. Open Google Play Review Scraper on Apify and click Try for free
2. Put at least one app into App Package Name or URL (startUrls) — a full play.google.com/store/apps/details?id=... link or a bare package name both work
3. Choose Sort By and Device Type, and set any filters you want: star rating, keywords, app version, endDate or recentDays
4. Set Max Reviews — it counts rows saved after filtering, per app
5. Click Start; rows appear in the output table as they pass the filters
6. Export as JSON, CSV or Excel, or read the dataset through the Apify API

How to scale to bulk review extraction

startUrls is a list, so one run can cover many apps: paste every package name or URL into it and each is processed in turn, with its own maxReviews budget and its own position sequence starting at 1. Filters, sort order, device type and page size are run-level — they apply identically to every app in the list. Rows carry appId, so splitting the finished dataset back out per app is a single group-by. Apps are processed sequentially, one at a time, rather than in parallel.

What can you do with Google Play review data?

• 📉 A mobile product manager investigating a rating drop sets sortBy: "newest" with recentDays: 14, then reads rating against reviewedAt to find the day sentiment turned.
• 🎧 A support lead triaging complaints runs ratingFilter: ["1","2"] with keywords: ["crash","login","refund"] and pushes body plus reviewUrl into the ticket queue, so every ticket links straight back to the review.
• 🧪 A release engineer verifying a rollout sets appVersion to the two most recent builds and compares the rating spread across the returned rows.
• 💻 An ASO analyst hunting form-factor bugs runs the same package twice, once with deviceType: "tablet" and once with deviceType: "chromebook", then diffs the body text for device-specific complaints.
• 🤖 An AI engineer building a support agent indexes body keyed on reviewId, with rating, reviewedAt and helpfulCounts as metadata filters, so a RAG query can be scoped to "one-star reviews from the last 30 days".

Every one of these is callable from an agent framework over the Apify API, since the Actor is a standard HTTP-triggered run.

How does Google Play Review Scraper handle rate limits and blocking?

Requests are paced rather than hammered: every review page waits one second plus up to one second of random jitter before it is sent, and apps are processed one at a time. The HTTP client holds at most 10 connections, 5 per host, with a 90-second total timeout (30s connect, 45s read).

Requests go out direct by default — proxyConfiguration is prefilled to useApifyProxy: false. Blocking is detected two ways: an HTTP 403, 429 or 503, and an HTTP 200 whose body is an HTML page or is missing the expected RPC frame — a soft block that a status-code-only check would read as success. On either, the Actor escalates once to an Apify residential proxy and retries, up to three attempts per request with exponential backoff plus jitter. An HTTP 404 is treated as a fact about the target, so it neither burns retries nor escalates to a paid proxy.

There is no CAPTCHA solving in this Actor.

If a page still fails mid-run, the Actor re-bootstraps the app page for a fresh session and retries that page once. If nothing had been saved for that app yet, an uncharged accounting row is written explaining why; if rows were already saved, that app stops with partial data.

⬇️ Input

Every parameter below is read straight from the Actor's input schema. Only startUrls is required.

Parameter	Required	Type	Description	Example Value
startUrls	Yes	array	App URLs or bare package names, one entry per app. Objects shaped {"url": "..."} are also accepted, even though the schema declares plain strings.	["com.spotify.music"]
deviceType	No	string	Which device's review pool to read: mobile, tablet or chromebook. Sent to Google as part of the request, so it genuinely changes the review set. Default "mobile".	"tablet"
sortBy	No	string	mostRelevant, newest, or rating for highest first. Applied server-side; mostRelevant leaves Google's own default ordering untouched. Default "mostRelevant".	"newest"
rating	No	integer	A single star value, minimum 1, maximum 5. Applied server-side, so non-matching reviews are never fetched. Default null, meaning all ratings.	1
ratingFilter	No	array	Star values as strings, "1" to "5", multi-select. Overrides rating when set. Two or more values are filtered client-side while paginating; a selection of exactly one is pushed server-side like rating. No default.	["1","2"]
keywords	No	array	Keep only reviews whose text contains any of these strings, case-insensitive substring match on body. Reviews with no text are dropped when this is set. No default.	["crash","refund"]
appVersion	No	array	Keep only reviews Google recorded against these app versions. Exact, case-insensitive match. The version is read from each review but is not emitted as an output column. No default.	["68.279"]
endDate	No	string	Keep only reviews posted on or before this date, YYYY-MM-DD. Default "", meaning no limit.	"2026-06-30"
recentDays	No	integer	Keep only reviews from the last N days. Minimum 0. Default 0, meaning no limit.	30
uniqueOnly	No	boolean	Drop repeated reviewId values across pages within one app. Default true.	true
maxReviews	No	integer	Reviews saved per app, counted after filtering. Minimum -1, maximum 10000. -1 resolves to the Actor's 10,000 ceiling. Default 100.	500
reviewsPerPage	No	integer	Reviews requested per API call. Minimum 1, maximum 1000; values outside that range are clamped in code. Default 200.	200
pagesToScrape	No	integer	Maximum pages per app, counted from startPage. Minimum -1. -1 means unlimited, and the run stops at maxReviews instead. Default -1.	-1
startPage	No	integer	Begin saving at this page. Minimum 1. Default 1.	1
proxyConfiguration	No	object	Apify Proxy settings. Prefilled {"useApifyProxy": false} — requests go out direct, and a residential proxy is used automatically only if a request is blocked.	{"useApifyProxy": false}

Four behaviours are worth knowing before you write your input:

• startUrls is the required field, and a run without it does nothing loudly. With an empty or missing list the Actor logs "No app URLs or package names were provided" and exits successfully with an empty dataset — no rows, no accounting row, no failure status. Check the row count, not the run status.
• maxComments is accepted as an undocumented alias for maxReviews. It is not in the schema and not shown in the Console, but the code maps it. If both are supplied, maxReviews wins.
• pagesToScrape: 0 behaves like 1, because the page budget is checked after the first eligible page has been processed. Use -1 for unlimited.
• startPage costs time, it does not save requests. Google Play only pages forward with a cursor, so earlier pages are still fetched and then discarded.

Example input

{
  "startUrls": [
    "https://play.google.com/store/apps/details?id=com.supercell.brawlstars",
    "com.spotify.music"
  ],
  "deviceType": "mobile",
  "sortBy": "newest",
  "rating": null,
  "ratingFilter": ["1", "2"],
  "keywords": ["crash", "login", "refund"],
  "appVersion": [],
  "endDate": "",
  "recentDays": 30,
  "uniqueOnly": true,
  "maxReviews": 500,
  "reviewsPerPage": 200,
  "pagesToScrape": -1,
  "startPage": 1,
  "proxyConfiguration": { "useApifyProxy": false }
}

⬆️ Output

One row per review, the same 17 keys every run, typed and normalized. Values Google does not supply come back as null rather than a missing key. Export as JSON, CSV or Excel, or read the dataset through the Apify API.

Each saved review is charged as one row_result event. Accounting rows are never charged. When a target cannot be scraped, the Actor writes a row with every review field null, errorReason set to a short code, and an extra errorMessage key holding the input and the error text — pushed without a charged event. A failed app stays auditable in your dataset instead of disappearing from the count.

Filter charged review rows with errorReason is None (row.get("errorReason") is None in Python, errorReason == null in a dataset filter). The codes you can see are app_not_found, bootstrap_blocked, bootstrap_failed, invalid_input, fetch_failed and no_reviews_matched_filters.

Two shape details to note: errorMessage exists only on accounting rows — review rows omit the key entirely rather than nulling it — and it is not part of the default table view, so read the raw JSON to see it. The app version behind the appVersion filter is likewise read internally and never emitted.

Example output

A review row:

{
  "reviewId": "a1c4e8f0-31b2-4d77-90ab-cdef12345678",
  "rating": 2,
  "reviewer": "Priya M.",
  "date": "2026-07-18",
  "reviewedIn": "en",
  "body": "Loved this app for years but the last update crashes every time I open a playlist offline. Rolled back to the previous version and it works fine again. Please fix the offline cache.",
  "userImage": "https://play-lh.googleusercontent.com/a/ACg8ocK9pZ2n7QfX3vB1m6Yh",
  "position": 14,
  "helpfulCounts": 212,
  "appId": "com.spotify.music",
  "timestamp": 1784332951,
  "language": "en",
  "userId": "104829173650284917305",
  "reviewUrl": "https://play.google.com/store/apps/details?id=com.spotify.music&reviewId=a1c4e8f0-31b2-4d77-90ab-cdef12345678",
  "reviewedAt": "2026-07-18T09:22:31Z",
  "scrapedAt": "2026-07-25T14:06:12Z",
  "errorReason": null
}

An uncharged accounting row, written when a package name does not exist:

{
  "reviewId": null,
  "rating": null,
  "reviewer": null,
  "date": null,
  "reviewedIn": null,
  "body": null,
  "userImage": null,
  "position": null,
  "helpfulCounts": null,
  "appId": null,
  "timestamp": null,
  "language": null,
  "userId": null,
  "reviewUrl": null,
  "reviewedAt": null,
  "scrapedAt": "2026-07-25T14:06:19Z",
  "errorReason": "app_not_found",
  "errorMessage": "com.example.notarealapp: Google Play returned 404 — check the package name or app URL"
}

How does it work?

Google Play serves reviews from an internal RPC rather than from HTML, so the Actor works the way the store's own page does. It first loads the app detail page and lifts three things out of it: the session id, the Play front-end build tag, and the review RPC's request template. The template is located by its RPC id, never by the numbered slot it happens to occupy, because that slot number drifts between Play releases.

Your sort order, device type, page size and single-star filter are written into that template, then the Actor posts it to the store's batch endpoint and walks forward page by page using the cursor Google returns. Responses are chunked RPC frames; they are decoded into flat rows, and every filter you set is applied to each review before it is pushed.

Requests start on a direct connection and escalate to an Apify residential proxy only after a block. Only publicly visible listing data is collected — no Google account, cookie or session is used. Because the Actor reads a structured RPC rather than rendered markup, a Play Store visual redesign does not change your field names.

Integrations

Google Play Review Scraper is an Apify Actor, so it works with anything that can call the Apify API or consume a dataset.

Calling Google Play Review Scraper from Python

from apify_client import ApifyClient

client = ApifyClient("<YOUR_APIFY_TOKEN>")

run = client.actor("<YOUR_USERNAME>/google-play-store-review-scraper").call(run_input={
    "startUrls": ["com.spotify.music", "com.supercell.brawlstars"],
    "sortBy": "newest",
    "ratingFilter": ["1", "2"],
    "recentDays": 30,
    "maxReviews": 500,
})

reviews = [r for r in client.dataset(run["defaultDatasetId"]).iterate_items()
           if r.get("errorReason") is None]

for r in reviews:
    print(r["appId"], r["rating"], r["reviewedAt"], r["body"][:80])

Works in Go, Ruby, Node.js, cURL — any language that can make an HTTP request. Filtering on errorReason is None separates real reviews from the uncharged accounting rows.

No-code tools (n8n, Make, Zapier)

In n8n, use the Apify node — or an HTTP Request node pointed at the Apify run endpoint with your token — and pass the same JSON input shown above; an IF node on errorReason then splits real reviews from accounting rows. In Make, the Apify module supports run-and-wait, so a daily sweep with recentDays: 1 can feed a Google Sheets or Slack step directly. Zapier can trigger on run completion and forward new low-star reviews into a ticketing tool. All three handle scheduling, so recurring review monitoring needs no code.

Is it legal to scrape Google Play reviews?

Collecting publicly published reviews is broadly treated as permissible where no authentication is bypassed, and this Actor reads only what any visitor sees on a Play Store listing — no Google account, no Play Console, no login.

The caveat that matters: reviews are personal data. reviewer is a display name, userId is a persistent account identifier, userImage is a portrait, reviewUrl links back to an identifiable post, and body is an individual's own words, which may disclose anything they chose to share. Processing that for EU, UK or California data subjects means you need a lawful basis under GDPR, UK GDPR or the CCPA/CPRA, and the usual obligations follow: data minimisation, a defined retention period, and a route for handling access, deletion and objection requests.

Minimisation is straightforward here, because sentiment analysis rarely needs identity. If your use case only needs rating, body, reviewedAt and helpfulCounts, drop reviewer, userId, userImage and reviewUrl at ingestion — that is the first cut to make, and it removes almost all of the identifying surface.

Consult legal counsel if your use case involves bulk storage of personal data.

❓ Frequently asked questions

What Google Play review fields does Google Play Review Scraper return?

The five you will use most are rating, body, reviewer, reviewedAt and helpfulCounts. Every row also carries reviewId, appId, reviewUrl, userId, userImage, date, timestamp, language, reviewedIn, position, scrapedAt and errorReason — 17 keys in total. See the data fields table above for the full list.

Does Google Play Review Scraper require a Google account or login?

No. No Google account, no Play Console access, no API key, no cookies. Google Play publishes reviews on the public app listing and that is all this Actor reads. The only credential involved is your Apify token.

How many reviews can I extract per app in one run?

Up to 10,000 — that is the Actor's own hard ceiling, and maxReviews: -1 resolves to it. There is no separate Google-imposed per-app ceiling in this Actor's code. In practice an app often stops earlier, when Google stops issuing a pagination cursor, when the cursor repeats, or when two consecutive pages return only reviews already seen. maxReviews counts rows saved after filtering, so a narrow keywords or appVersion filter will usually finish below your cap.

What happens if the app has no matching reviews, or the URL is wrong?

Three distinct outcomes, and two of them are visible in the dataset. A package name or URL Google Play does not recognise returns HTTP 404 and produces an uncharged accounting row with errorReason: "app_not_found". Reviews that were fetched but matched none of your filters produce one uncharged row with errorReason: "no_reviews_matched_filters" and the inspected count in errorMessage — that is your signal to widen a filter. The third case is the quiet one: an app that genuinely has no reviews at all in the pool you selected returns no row whatsoever, only a log line, because there was nothing to inspect. If an appId you supplied is missing entirely from the dataset, that is what happened.

Can I scrape multiple apps at once?

Yes. startUrls is a list and accepts full Play Store URLs and bare package names mixed together in the same run. Each app gets its own maxReviews budget and its own position sequence starting at 1, and every row carries appId so you can split the dataset afterwards. Apps are processed sequentially, one after another.

Can I choose a country or language for the reviews?

No — this Actor has no country or language input, and adding one to your JSON does nothing. The language and reviewedIn fields describe the storefront locale the request happened to be served in, they hold the same value as each other, and that value is identical on every row of a run. What does change the review set is deviceType: Google Play keeps separate review pools per form factor, and that choice is sent as part of the request.

Am I charged for failed apps or empty results?

No. Only saved review rows are charged, as row_result events. Accounting rows — app_not_found, bootstrap_blocked, bootstrap_failed, invalid_input, fetch_failed, no_reviews_matched_filters — are pushed without a charged event. Filter them out with errorReason is None. The corollary is worth noting too: because filters run before anything is pushed, reviews you excluded by rating, keyword, version or date are never charged either.

Does Google Play Review Scraper work with Claude, ChatGPT and other AI agent tools?

Yes. It is callable as a standard HTTP endpoint through the Apify API, so LangChain, CrewAI, n8n or a hand-written tool definition can invoke it and receive typed JSON with no parsing step. Review text arrives clean, so body can go straight into an LLM context window or a vector store with no HTML stripping.

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

Checked on the Apify Store on 25 July 2026. neatrat/google-play-store-reviews-scraper is the most used of the three and documents 11 output fields with a single-app appIdOrUrl input; its listing also states that non-paying Apify users are limited to 5 total runs and 500 total reviews across all runs. solidcode/google-play-store-reviews-scraper documents the widest surface — 24 fields including developer replies and app metadata, plus country and language selection — and its listing states that Google's "Most Relevant" ordering is capped at roughly 50–150 reviews per app, a claim about Google that this Actor does not independently verify. moving_beacon-owner1/my-actor-1 documents four output columns (User, Rating, Date, Review). What this Actor documents that the others do not: which filters run server-side versus client-side, that error rows are pushed uncharged and exactly how to filter them out, and that its 10,000-per-app ceiling is its own rather than Google's.

Does it return data LLMs can use directly, and which fields suit RAG indexing?

Yes — typed, normalized JSON with consistent field names across runs, no HTML parsing and no selectors. For RAG, body is the field to embed: it is the only free-text field and it chunks cleanly, one review per chunk, keyed on reviewId. Use rating, reviewedAt, timestamp, helpfulCounts and appId as metadata filters — they are the most structurally consistent fields across records, and they turn "what are people complaining about" into a query you can scope by app, star and date. All values return as typed primitives, so no normalization pass is needed before indexing.

What happens when Google Play changes its layout or anti-bot system?

The scraper is maintained, and the design already anticipates the most common breakages: the review RPC template is located by its id rather than by a slot number that drifts between Play releases, and the session id and build tag are harvested live from the app page on every run instead of being hardcoded. Because reviews are read from a structured RPC rather than rendered markup, a Play Store visual redesign generally does not affect the output at all. Your field names and types stay the same on your end.

Can I use it without managing proxies or browser infrastructure?

Yes. There is no browser to run and no proxy account to create. Requests start on a direct connection, and if Google blocks one the Actor escalates itself to an Apify residential proxy and retries with backoff. You can pin proxy settings in proxyConfiguration if you want to, but the default of no proxy is what most runs use.

🔗 Related scrapers

Scraper Name	What it extracts
Apple App Store Review Scraper & App Ratings Summary	iOS app reviews, star ratings and rating summaries
Goodreads Review Scraper With Reviewer Lead Enrichment	Book reviews, ratings and reviewer details
Google Maps Scraper — Reviews & Sentiment Analysis	Place reviews with sentiment scoring
Google News Scraper By Publisher & Site Filter	News articles filtered by publisher and site
Amazon Top Rated Products Scraper	Highest-rated Amazon products with rating data

Coming from the Apple sibling? Its README documents Apple's ceiling of 500 reviews per app per storefront, which forces you to split collection by country code. This Actor's code contains no equivalent Google-imposed per-app ceiling — the only hard cap in it is its own 10,000-per-app limit, and collection otherwise runs until Google's pagination cursor stops advancing.

💬 Your feedback

Found a bug, or need a Google Play review field that is not yet returned? Open an issue on the Actor's Issues tab. Reports that include the exact input JSON and the package name you ran are the fastest to reproduce and fix.