Google Play Store Review Scraper By App Version & Device Type

Google Play Review Scraper — Reviews, Versions and Device Types

Google Play Review Scraper By App Version & Device Type scrapes Google Play Store reviews and stamps every row with two things a plain review export never gives you: the exact app build the review was left on, and the device class — phone, tablet, or Chromebook — it came from. Turn on rollups and the run also returns one aggregate row per app version per device class, with sample size, average rating, and star spread. Unlike scraping frameworks that return raw HTML, it returns typed JSON — ready for your bug tracker, your BI dashboard, or your pipeline without any parsing.

This guide covers every input and output field down to the source code, plus three concrete ways release-engineering, QA, and app-intelligence teams put it to work: post-release regression hunting, scheduled build monitoring, and bulk competitor datasets.

What Does Google Play Review Scraper Do?

It requests Google Play's own internal review endpoint for one or more apps, once per device class you select, and parses the raw response into structured rows — no headless browser. Each review carries the app version it was posted on and the device segment it came from, so a tablet-only bug or a version-4 regression is visible instead of averaged away. No Google account, login, or API key is required — every field returned is already visible to an anonymous visitor on the Play Store listing.

• Scrapes reviews for any public Google Play app, given a package name or listing URL
• Splits every app into up to three device-class passes: phone, tablet, Chromebook
• Stamps each review with the app version (build number) it was left on, where Google exposes one
• Builds an aggregate rollup row per app version × device class: sample size, average rating, star spread, first/last review seen
• Filters on star rating, keyword, language, date range, and a post-release time window — all applied before anything is saved
• Pushes a typed, uncharged error row for any app that cannot be reached, instead of silently dropping it

Features & Capabilities

The core mechanic is release-quality monitoring: reviews sliced along the two axes — app version and device class — that determine whether a build regression is visible at all.

How the extraction actually works

Google Play's review list is not present in the page's rendered HTML — it is fetched client-side through an internal batchexecute RPC endpoint identified by the id oCPfdb. The Actor loads the app's listing page once, extracts the request template for that RPC by anchoring on the literal string oCPfdb rather than a hardcoded slot index (Google has been observed to renumber these slots between deployments, which silently breaks a hardcoded-index approach), then POSTs paginated requests against that template. Sort order, star filter, device class, and the pagination cursor are all wired into specific offsets inside that request payload (payload[1][1] for sort, payload[1][4][1] for the server-side star filter, payload[1][4][8] for device class), so device and version segmentation are driven by real parameters Google's own client uses, not a client-side approximation.

Every filter — star rating, keyword, date range, version, post-release window, duplicate removal — is applied to the full collected set before any row is written or charged, so a filtered run's saved row count always matches what actually passed the filters.

Core features

• Device-class sweep (deviceSegments) — a separate pass per device class, each stamping the real deviceType on every row it returns
• Per-review app version (appVersion) — the build number Google attaches to the review, when it publishes one
• Version rollups (emitVersionRollups) — one row per deviceType × appVersion bucket, carrying sampleSize, averageRating, oneStarShare, fiveStarShare, firstReviewAt, lastReviewAt, and isCurrentVersion
• Post-release window (postReleaseWindowDays) — keep only reviews written within N days of the app's real "Updated" timestamp from the store listing
• Server-side star filtering — a single requested star value is pushed to Google's own filter, so the run downloads only the rating you asked for instead of discarding the rest locally
• Version and keyword targeting (versionsToTrack, mustContain) — narrow to exact build numbers or to reviews mentioning a term like crash or battery
• Uncharged accounting rows — a target that cannot be fetched produces a type:"error" row instead of vanishing, and it is never billed

How Google Play Review Scraper compares to other Google Play scrapers

Checked on the Apify Store, 26 July 2026.

Feature	Google Play Review Scraper	code-node-tools/google-play-reviews-scraper	sian.agency/play-store-apps-scraper
Device-class segmentation (phone/tablet/Chromebook)	✅	Not documented	Not documented
Per-version rollup (sample size, avg rating, star spread)	✅	Not documented	Not documented
Post-release time window filter	✅	Not documented	Not documented
Server-side single-star filter	✅	Not documented	Not documented
Uncharged error/accounting rows	✅ (type:"error", uncharged)	Not documented	✅ (status:"error" rows, documented as $0)
Reviews per request	Up to 1,000 (batchSize)	Not documented	Up to 50 (limit)
Documented export formats	JSON/CSV/Excel via Apify dataset	✅ JSON, CSV, Excel, HTML, RSS	✅ JSON, CSV, Excel

If your use case is feeding structured data to an LLM, the output-format row is the decision-maker — HTML parsing inside an agent loop is a reliability failure mode, not a feature. Every row here is typed JSON on every run.

When another tool might suit you better

If you need Apple App Store reviews in the same run as Google Play, andok/app-store-reviews covers both stores from one Actor (documented dual-store support, checked 26 July 2026) — this Actor is Google Play only, so the equivalent iOS coverage is a separate Scrapio Actor. If your project needs Google Play app search, top charts, or category data alongside reviews, sian.agency/play-store-apps-scraper bundles five operations behind one dropdown; it is the better fit for a full ASO toolkit, though it does not segment reviews by device class or roll them up by version.

Google Play Review Scraper within the Scrapio data stack

Google Play Review Scraper covers Google Play reviews, segmented by app version and device class. For the iOS equivalent, Scrapio publishes Apple App Store Review Scraper By Country & Storefront. For non-app-store review data, Scrapio's Google Maps Scraper — Rating, Review & Open Status Filter covers local-business reviews, and Goodreads Review Scraper — Sentiment & Theme Analysis covers book reviews. Each keeps the same typed-JSON dataset pattern.

Why do developers and data teams scrape Google Play reviews?

📱 Mobile QA and release engineering

A release engineer ships a build, then runs this Actor with versionsToTrack set to the new version number and postReleaseWindowDays set to 7. The output isolates exactly the first week of feedback on that build — daysFromAppUpdate and isPostRelease separate pre-release noise from real post-release reaction, and deviceType reveals whether a regression is tablet-specific before it shows up in a wider crash report. The rollup row's oneStarShare gives a single number to watch per device class per version.

📊 AI training data and RAG indexing

body is the high-information text field — free-form user complaints, praise, and bug reports tied to a specific appVersion and deviceType. For RAG enrichment, index body alongside appVersion and rating so an agent can answer "what are tablet users saying about version 9.1.60" against live data. For training data, rating, oneStarShare, and fiveStarShare are the most structurally consistent fields across every app and version, since they are always typed numbers or null, never a missing key.

📈 Competitive and market intelligence

Point the Actor at a competitor's package name, enable rollups, and track averageRating and oneStarShare per appVersion across their release cadence. A rollup row's recentChanges field carries the "What's New" changelog for the current version, so a rating drop can be matched to the exact release notes that likely caused it.

🔬 Research and academic use

The dataset is limited to what Google Play already shows an anonymous visitor — no account data, no private reviews. Suitable for public-sentiment research segmented by device class and release, at any scale a research budget can fund; no scraping infrastructure of your own to maintain.

🎥 Product and SaaS development

App-intelligence dashboards, ASO monitoring products, and release-health tools can build on the rollup rows directly — sampleSize, averageRating, and the star-share fields are already aggregated per version and device, so a product doesn't need to compute its own rolling statistics from raw review rows.

🍚 Input Parameters

All 17 parameters below come directly from .actor/actor.json. None are required — every field has a default or an empty-means-"no filter" behavior. Most parameters also accept the equivalent key from the standard Google Play review scraper (noted below); when both are present, the base key wins.

Parameter	Required	Type	Description	Example Value
releaseTargets	No	array	One or more Play Store URLs or package names, e.g. com.spotify.music or https://play.google.com/store/apps/details?id=com.spotify.music. Base key startUrls also accepted and takes priority when present.	["com.spotify.music"]
deviceSegments	No	array	Device classes to sweep: mobile, tablet, chromebook. Runs one pass per class and stamps the real class on every review. Default ["mobile"].	["mobile", "tablet"]
versionsToTrack	No	array	Keep only reviews left on these exact build numbers, e.g. 9.1.60.1970. Empty keeps every version. Base key appVersion also accepted.	["9.1.60.1970"]
postReleaseWindowDays	No	integer, min 0, default 0	Keep only reviews written within N days after the app's last store update (real Updated timestamp). 0 = no window.	7
emitVersionRollups	No	boolean, default true	Append an aggregate row per device class × app version: sample size, average rating, 1★/5★ share, first/last review, whether it's the current store version. Star shares stay empty below 5 reviews.	true
criticalOnly	No	boolean, default false	Narrow to 1★ and 2★ reviews. Ignored when starsIncluded is set.	false
reviewsPerVersionScan	No	integer, min -1, default 200	Reviews to keep per app, per device class. -1 = unlimited. Base key maxReviews also accepted.	300
orderBy	No	string, enum newest / mostRelevant / rating, default newest	Review sort order. Base key sortBy also accepted.	"newest"
starsIncluded	No	array, enum "1"–"5"	Star ratings to keep. A single value is pushed to Google's own server-side filter. Base key ratingFilter also accepted.	["1", "2"]
batchSize	No	integer, min 1, max 1000, default 200	Reviews fetched per request. Base key reviewsPerPage also accepted.	200
pageDepth	No	integer, min -1, default -1	Hard cap on paginated requests per app per device class. -1 = unlimited (the review budget stops the run instead). Base key pagesToScrape also accepted.	-1
beginAtPage	No	integer, min 1, default 1	Skip the first N−1 pages before collecting. Those pages are still fetched, only discarded. Base key startPage also accepted.	1
mustContain	No	array	Keep only reviews whose text contains at least one of these terms, case-insensitive.	["crash", "freeze"]
lastNDays	No	integer, min 0, default 0	Keep only reviews from the last N days. 0 = no limit. Base key recentDays also accepted.	30
latestReviewDate	No	string, default ""	Drop anything newer than this date (YYYY-MM-DD). Empty = no limit. Base key endDate also accepted.	"2026-07-01"
localeFilter	No	array, enum of 37 code - Language name values	Keep only reviews served in these storefront languages. Base key language also accepted.	["en - English"]
dropDuplicates	No	boolean, default true	Remove repeated review IDs within each device-class pass. Base key uniqueOnly also accepted.	true
proxyConfiguration	No	object	Optional proxy for the Play Store requests. Google Play serves these endpoints without a proxy in most cases; a residential exit is used automatically as an escalation if a request is refused.	{"useApifyProxy": false}

Example input

{
  "releaseTargets": ["com.spotify.music"],
  "deviceSegments": ["mobile", "tablet"],
  "versionsToTrack": ["9.1.60.1970"],
  "postReleaseWindowDays": 7,
  "emitVersionRollups": true,
  "criticalOnly": true,
  "reviewsPerVersionScan": 300,
  "orderBy": "newest",
  "mustContain": ["crash", "freeze"]
}

Supported URL types and input formats

releaseTargets accepts three shapes, matched by the same normalizer the base scraper uses:

• A bare package name — "com.spotify.music"
• A full Play Store URL — "https://play.google.com/store/apps/details?id=com.spotify.music"
• An object with a url key — {"url": "com.whatsapp"}, so output piped in from another tool works unchanged

If startUrls (the base scraper's key) is present in the input, it takes priority over releaseTargets.

📦 Output Format

Every run writes to one Apify dataset. Rows come in three shapes, told apart by type and isRollup: "review" rows, "version" rollup rows, and "error" accounting rows. Together their fields are exactly the 34 columns shown in the dataset's default view. Export as JSON, CSV, Excel, or any other format the Apify Console offers, or read the dataset through the Apify API.

Output for reviews

{
  "reviewId": "gp:AOqpTOFmAVORqfWGcaqfF39ftwFjGkjecjvjXnC3g",
  "rating": 2,
  "reviewer": "Jordan M.",
  "date": "2026-06-14",
  "reviewedIn": "en",
  "body": "Since the last update the app crashes every time I open playlists on my tablet.",
  "userImage": "https://play-lh.googleusercontent.com/a/ACg8ocJ...",
  "position": 3,
  "helpfulCounts": 12,
  "appId": "com.spotify.music",
  "timestamp": 1749907200,
  "language": "en",
  "type": "review",
  "isRollup": false,
  "appVersion": "9.1.60.1970",
  "deviceType": "tablet",
  "reviewedAt": "2026-06-14T12:00:00+00:00",
  "reviewAgeDays": 41,
  "appCurrentVersion": "9.1.62.1980",
  "appUpdatedAt": "2026-06-10T08:00:00+00:00",
  "daysFromAppUpdate": 4.17,
  "isPostRelease": true,
  "reviewUrl": "https://play.google.com/store/apps/details?id=com.spotify.music&reviewId=gp:AOqpTOFmAVORqfWGcaqfF39ftwFjGkjecjvjXnC3g",
  "scrapedAt": "2026-07-25T09:00:00+00:00"
}

appVersion is Google's own version tag on the review and is null when Google does not expose one for that review — this varies by app and is never guessed. appCurrentVersion and appUpdatedAt come from the app's store listing, read once per app, and are attached to every review row from that app.

Output for version rollups

{
  "type": "version",
  "isRollup": true,
  "appId": "com.spotify.music",
  "appVersion": "9.1.60.1970",
  "deviceType": "tablet",
  "sampleSize": 42,
  "averageRating": 2.86,
  "oneStarShare": 0.3095,
  "fiveStarShare": 0.1905,
  "firstReviewAt": "2026-06-10T08:15:00+00:00",
  "lastReviewAt": "2026-07-20T17:42:00+00:00",
  "isCurrentVersion": false,
  "appCurrentVersion": "9.1.62.1980",
  "appUpdatedAt": "2026-06-10T08:00:00+00:00",
  "recentChanges": null,
  "scrapedAt": "2026-07-25T09:00:00+00:00"
}

sampleSize is the review count behind every ratio on the row, so the denominator is always visible. oneStarShare and fiveStarShare are null when sampleSize is under 5, so a one-review version can never read as a 100% failure rate. recentChanges (the "What's New" text) is only attached to the rollup row that matches the app's current store version — every other version's rollup carries null there.

An error accounting row looks like this — never billed, and visible instead of silently missing:

{
  "type": "error",
  "isRollup": false,
  "appId": "com.unknown.app",
  "deviceType": "mobile",
  "errorReason": "bootstrap_failed",
  "errorMessage": "Could not determine app id from URL",
  "scrapedAt": "2026-07-25T09:00:00+00:00"
}

When no target at all is supplied, a top-level error row is pushed with appId: null and no deviceType, since no device pass ever started.

Full output field reference

All 34 fields the Actor ever writes, grouped by which row type carries them. These are the same columns shown in the dataset's default view.

Fields on every row type

Field	Description
type	"review", "version", or "error" — which of the three row shapes this is
isRollup	true only on version-rollup rows
appId	Google Play package name, e.g. com.spotify.music
appVersion	Build number the row concerns — the review's build for review rows, the bucket's build for rollup rows
deviceType	mobile, tablet, or chromebook
scrapedAt	ISO 8601 timestamp of when this row was produced

Review-only fields

Field	Description
reviewId	Google's unique review identifier
rating	Star rating, 1–5
reviewer	Reviewer display name as shown on Google Play
date	Review date, YYYY-MM-DD
reviewedIn	Short language code the review was served in
body	Full review text
userImage	Reviewer avatar image URL, or null
position	1-based position of the review within this app/device pass after filtering
helpfulCounts	Number of "helpful" votes on the review
timestamp	Unix epoch seconds of the review
language	Same short language code as reviewedIn
reviewedAt	ISO 8601 form of timestamp
reviewAgeDays	Days between the review and the time the run executed
appCurrentVersion	Version currently published on the store, read from the app's listing, or null when Google exposes none
appUpdatedAt	ISO timestamp of the app's last store update
daysFromAppUpdate	Days between the store update and the review; negative means the review predates the update
isPostRelease	Whether the review's timestamp is at or after the store update
reviewUrl	Deep link to the review on the Play Store

Rollup-only fields

Field	Description
sampleSize	Number of reviews behind this bucket's figures
averageRating	Mean rating across the bucket
oneStarShare	Share of 1★ reviews in the bucket; null below 5 samples
fiveStarShare	Share of 5★ reviews in the bucket; null below 5 samples
firstReviewAt	Earliest review timestamp seen in the bucket, ISO 8601
lastReviewAt	Latest review timestamp seen in the bucket, ISO 8601
isCurrentVersion	Whether this bucket's appVersion matches the store's current version; null when the store publishes no current version
recentChanges	The app's "What's New" changelog text, only populated on the rollup row matching the current version

Error-only fields

Field	Description
errorReason	Short machine-readable failure code, e.g. bootstrap_failed, fetch_failed, invalid_input
errorMessage	Human-readable detail for the failure, truncated to 300 characters

Schema stability and export options

Field names stay stable across Google Play front-end changes, because the Actor parses Google's internal RPC response structure rather than rendered HTML — a visual redesign of the Play Store does not change these column names. When emitVersionRollups is on, the run also writes rollup rows to a second, named dataset (version-rollups-<runId>, visible in the Apify Console's Storage tab) as a convenience mirror of the same rows already in the default dataset. Export from either dataset as JSON, CSV, Excel, or via the Apify API — no other delivery mechanism is built into this Actor.

Pricing is pay-per-event: the charged event is row_result, fired once per review row and once per rollup row pushed to the default dataset. type:"error" rows are pushed without a charged event and are never billed — filter them out of a cost estimate with type != "error".

💡 Google Play Review Scraper Strategy Guide

🎯 Strategy 1: Real-time enrichment pipeline

Trigger a run right after a release goes out: call the Actor via the Apify API with versionsToTrack set to the new build and postReleaseWindowDays: 7. As rows land, append appVersion, deviceType, rating, and body to your bug-tracker or QA dashboard — isPostRelease and daysFromAppUpdate let you filter out any stragglers reviewing the previous build. A CI/CD release webhook is a natural trigger for this pattern.

🎯 Strategy 2: Scheduled monitoring and alerting

Set up an Apify Schedule to run daily or weekly with emitVersionRollups: true. Store each run's rollup rows keyed by (deviceType, appVersion), then diff oneStarShare and averageRating against the previous run on the same key. Alert when oneStarShare for the current store version (isCurrentVersion: true) rises past your own threshold — that is the signal a new build is degrading in the wild.

🎯 Strategy 3: Bulk dataset build

For a research or competitor corpus across many apps, note that within a single run each app and device-class pair is scraped sequentially, not concurrently. To parallelize a large app list, split it into batches and launch one Apify run per batch via the API — each run's dataset can then be exported and concatenated into one CSV or loaded into a database.

Strategy comparison at a glance

Strategy	Best for	Run pattern	Output format
Real-time enrichment	Post-release QA triage	Single run, triggered per release	Review rows appended live
Scheduled monitoring	Ongoing regression alerting	Recurring Apify Schedule + external diff	Rollup rows, keyed by version × device
Bulk dataset build	Competitor or research corpus	Multiple runs launched in parallel via API	Dataset export merged to CSV

🌴 Related Google Play Scrapers & Tools

Google Play Review Scraper is Scrapio's only Google Play Actor built around version and device segmentation. For the equivalent iOS coverage or adjacent review-analysis work, these Scrapio Actors use the same typed-dataset pattern:

Scraper	What it extracts
Apple App Store Review Scraper By Country & Storefront	iOS app reviews, segmented by country storefront — the App Store counterpart to this Actor
Google Maps Scraper — Rating, Review & Open Status Filter	Local-business reviews and ratings, filterable by open status
Goodreads Review Scraper — Sentiment & Theme Analysis	Book reviews with sentiment and theme extraction

How to integrate Google Play Review Scraper with your stack

Google Play Review Scraper works with any language or tool that can make an HTTP request, since it runs on Apify and its results are a standard Apify dataset.

Python

from apify_client import ApifyClient

client = ApifyClient("<YOUR_APIFY_TOKEN>")

run = client.actor("<YOUR_USERNAME>/google-play-store-review-scraper-by-app-version-device-type").call(
    run_input={
        "releaseTargets": ["com.spotify.music"],
        "deviceSegments": ["mobile", "tablet"],
        "emitVersionRollups": True,
        "reviewsPerVersionScan": 300,
    }
)

rows = client.dataset(run["defaultDatasetId"]).iterate_items()
reviews = [r for r in rows if r.get("type") == "review"]

import csv
with open("play_reviews.csv", "w", newline="", encoding="utf-8") as f:
    writer = csv.DictWriter(f, fieldnames=["appId", "appVersion", "deviceType", "rating", "body"])
    writer.writeheader()
    for r in reviews:
        writer.writerow({k: r.get(k) for k in writer.fieldnames})

Node.js

import { ApifyClient } from 'apify-client';

const client = new ApifyClient({ token: '<YOUR_APIFY_TOKEN>' });

const run = await client.actor('<YOUR_USERNAME>/google-play-store-review-scraper-by-app-version-device-type').call({
    releaseTargets: ['com.spotify.music'],
    deviceSegments: ['mobile', 'tablet'],
    emitVersionRollups: true,
});

const { items } = await client.dataset(run.defaultDatasetId).listItems();
const rollups = items.filter((i) => i.isRollup);
rollups.forEach((r) => console.log(r.appVersion, r.deviceType, r.averageRating, r.oneStarShare));

Async and scheduled pipelines

For fire-and-forget large jobs, start the run through the Apify API and poll client.run(runId).get() for status, or use an Apify webhook configured to fire on run completion for downstream automation. For recurring monitoring, use Apify Schedules to run this Actor on a cron interval without any code managing the trigger.

🎯 Who Needs Google Play Review Scraper? (Use Cases & Industries)

📱 Release and QA engineering teams

A mobile QA lead sets versionsToTrack to the build just shipped and postReleaseWindowDays: 7, then filters on deviceType: "tablet" to check whether a tablet-specific layout bug is showing up in review text before it reaches a support queue.

📊 App-intelligence and analytics platforms

A platform ingesting rollup rows (averageRating, sampleSize, oneStarShare per appVersion) into a dashboard can show version-over-version rating trends per device class for any tracked app, without computing its own aggregates from raw reviews.

📈 Competitive and market research teams

An analyst points the Actor at competitor package names on a weekly Apify Schedule, tracking averageRating and recentChanges together to correlate a rating shift with the exact changelog that shipped it.

🔬 Researchers

Public-sentiment researchers use the review corpus segmented by device class and app version to study how software updates affect user sentiment differently across device types — all from data any Play Store visitor can already see.

Is it legal to scrape Google Play reviews?

Yes — Google Play Review Scraper extracts only reviews and app metadata that Google Play already displays to any anonymous visitor. In the United States, hiQ Labs v. LinkedIn (9th Cir. 2019) held that scraping publicly accessible web data does not violate the Computer Fraud and Abuse Act, a precedent widely applied to public-data scraping generally. Separately, Google's Terms of Service may restrict automated access to its own site; violating a platform's terms is a civil contract matter between you and Google, not a criminal one, and does not by itself make the data you collect unlawful to hold.

Reviewer display names and avatar images are personal data under GDPR and CCPA, even where pseudonymous. Google Play Review Scraper returns only publicly accessible data. What you do with that data is your responsibility — consult legal counsel before using reviewer names or avatars in a way that could identify an individual, and before any commercial application involving personal data.

❓ Frequently asked questions

Does Google Play Review Scraper work without a Google account?

Yes. It makes anonymous requests to Google Play's own review endpoint — no Google account, login, cookie, or API key is used. The only credential you need is your Apify API token to run the Actor.

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

It detects blocks by status code (403/429/503) and by inspecting the response body for an "unusual traffic" interstitial or a /sorry/ redirect page, so a soft block returning HTTP 200 is still caught. On a block, it retries with exponential backoff and escalates from a direct connection to a residential proxy exit automatically. A custom proxyConfiguration is optional — Google Play typically serves these endpoints without one.

Can I run Google Play Review Scraper at scale without getting blocked?

Within a single run, apps and device-class passes are scraped one at a time, not in parallel — this is a real limitation of the current implementation, not a documented throughput figure. To scale across many apps, launch multiple runs in parallel via the Apify API, one per app batch. No uptime or throughput SLA is published for this Actor.

How fresh is the data Google Play Review Scraper returns?

Live per run. Every run fetches the current review list and the app's live listing page directly from Google Play at the time it runs — nothing is served from a cache.

Which fields work best for AI training and RAG indexing?

For RAG indexing: body is the highest-information text field, paired with appVersion and deviceType for context. For training data: rating, oneStarShare, and fiveStarShare are the most structurally consistent fields, since they are always typed numbers or null, never a missing key. All fields return as typed primitives requiring no normalization before indexing.

Does personal data appear in the output, and who is responsible for it?

Reviewer display names and avatar images (reviewer, userImage) can constitute personal data. The Actor returns only what Google Play already displays publicly; lawful basis for storing, processing, or republishing that data sits with you as the user, not with the Actor.

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

Yes, as a standard HTTP endpoint through the Apify API — any agent framework that can make a request (LangChain, CrewAI, a custom tool definition, n8n) can invoke it and receive typed JSON directly, with no HTML parsing step before it enters an LLM context window.

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

Checked on the Apify Store, 26 July 2026: code-node-tools/google-play-reviews-scraper documents the broadest export-format list (JSON, CSV, Excel, HTML, RSS) and a wide client-side filter set, but does not document device-class segmentation or version rollups. sian.agency/play-store-apps-scraper bundles five Google Play operations (search, charts, details, reviews, categories) in one Actor and documents free status:"error" rows, but reviews are not segmented by device class or rolled up by version. andok/app-store-reviews covers both Google Play and Apple App Store from a single Actor, useful if you need both stores in one pipeline. This Actor's difference is the version-and-device axis: every review is stamped with the build and device class it came from, and rollups aggregate both together — none of the three document that capability.

Disclaimer

Google Play Review Scraper extracts only publicly available data from Google Play. This tool is intended for lawful use cases only. Users are responsible for complying with Google's terms of service and applicable data protection laws in their jurisdiction. This Actor is not affiliated with, endorsed by, or sponsored by Google LLC; "Google Play" and related marks are trademarks of Google LLC, used here only to describe the publicly available data this tool helps collect.