Give it an app ID or a Play Store link and get the reviews back as a table - the text, the star rating, the date, the likes, the app version the reviewer was on, and the developer's reply where one exists. Ten columns, one row per review.
Most review exports are a one-off snapshot. The thing that makes this one useful is what happens when you run it again next month.
Every row carries a review_id. Across our 842 rows there were 559 distinct ones - and not a single run contained a duplicate of its own. The repeats were all between runs, which is exactly what you would expect when you pull the same app twice. That gives you a clean key: union the exports, drop rows whose review_id you already hold, and what remains is genuinely new.
The reference also documents a cutoff parameter that takes an oldest-timestamp, so you can ask for nothing older than your last pull rather than fetching everything and discarding most of it. Between that and the id, a monthly pull stays cheap however large the review history gets - and it does get large: our sample reaches back to August 2016.
One structural difference from the other scrapers on this site is worth flagging. There is no query column here. The submitted app is echoed as app_id instead, so if you batch several apps in one run, that is the column you group on.
Four settings, and two of them are what keep a recurring pull small.
Filtering to a single star rating works only when the sort is set to rating.
This is the export header in sheet order, identical across all 11 runs. The fill rates are counted over the 842 rows those runs returned, covering 559 distinct reviews across three apps.
com.facebook.katana. Present on all 842. This is what identifies the input - there is no query column on this service.https:// and always on Google's user-content host.2025-03-08. Present on all 842 and matched YYYY-MM-DD in every one. Ours spanned nearly ten years.8.116.0.213. Present on 702 of 842 - but see the note below, because coverage varies a lot by app.Eight of the ten columns were present on every single row. Only app_version and reply vary, and both do so in ways worth understanding before you build - the note below covers them. Worth knowing about ordering too: the spreadsheet puts review_id last, while the JSON export puts it second. Same ten columns either way, so read by name rather than by position.
All four come from reading the 842 rows rather than the reference, and each one changes how you would write the job.
Our 842 rows held 559 distinct review_id values, and no individual run contained a duplicate of its own - every repeat was across runs, from pulling the same app more than once. So the id is stable between pulls and unique within one. Union your exports on it and you get a growing review history rather than a pile of near-identical files.
reply was populated on 15 of 842 rows - under two percent. Every one of those fifteen was on a one-star review, and all fifteen belonged to a single app; the other two apps in our sample had none at all. That is far too small a sample to call it a rule about how developers behave, but it is more than enough to say a reply-driven feature will be looking at an almost-empty column most of the time.
Overall it was present on 702 of 842 rows, which sounds comfortable until you split it by app: 90% on one, 84% on another, and 14% on the third. So a version-by-version quality breakdown is realistic for some apps and not for others, and the aggregate figure will not tell you which you are dealing with. Check the coverage on your own app before you build a chart on it.
Across our rows the split was 35% one-star, 11% two, 12% three, 7% four and 35% five - a U-shape, with the fewest reviews sitting in the middle. Whatever mean you compute from that describes almost nobody. The useful readings are the shape itself and the text behind each end of it, which is the reason to pull the reviews rather than the store's headline score.
Where a full review history beats the summary on the store page.
Because app_version travels with the review, you can cut sentiment by build rather than by month. A rating dip stops being a mystery and becomes a specific release - and if the next version's reviews recover, you have your answer without instrumenting anything.
Competitor reviews are public and unusually candid. Pull the one-star text for a rival app and you get an unfiltered list of the things people cannot stand about it - which is both a roadmap and a supply of language for your own positioning.
Fix the app list, re-run on a schedule and deduplicate on review_id. What arrives each time is only what is new, so a spike in one-star volume is visible as it happens rather than at the end of a quarter when someone finally checks the store.
No subscription, no minimum, no per-seat licence. Your first 500 rows are on us - after that, pay-as-you-go.
Every new account, one-time. No credit card required. All scrapers unlocked. 500 rows is several apps' worth at a sensible per-app limit, which is enough to see the rating shape and check your own app's version coverage.
Roughly $2 per 1,000 reviews. Recurring pulls are where this gets cheap: deduplicating on the review id and using the cutoff means a monthly refresh costs a fraction of the first run, however long the history is.
Volume pricing, SLAs, dedicated workers and bespoke onboarding for teams watching a portfolio of apps on a fixed cadence. Tell us your numbers and we'll quote.
LIVESCRAPER10 at checkout.Most products ship on both platforms, and the complaints rarely line up. These two cover the other side.
The same job on Apple's side. Running both for one product is the only honest way to tell a platform-specific bug from a real one.
Before you can read an app's reviews you need its listing. Search a keyword set and get the apps that rank for it, one row each.
Short answer: yes, with one thing to keep in mind - a review carries a display name, so treat it with a little more care than a price list.
Play Store reviews are public. Anyone can read them without an account, and collecting publicly visible information for research is long-established practice. As long as the data is publicly available and the process doesn't disrupt the site, there are no federal laws prohibiting it.
The part worth being deliberate about is that author and author_image describe a person, even if only by a display name they chose to publish. Under GDPR that is personal data, so the ordinary obligations apply: have a reason for holding it, keep it no longer than you need, and don't try to enrich it into a real identity. If your analysis is about the app rather than the reviewers - which it almost always is - dropping those two columns on import costs you nothing.
Google's terms restrict automated access, so this remains a terms question. We touch nothing behind a login, run no third-party trackers on the data layer, and your exports auto-delete after 30 days.
The questions we hear most. Anything else? Talk to us - humans, not bots, write the answers.
app_id, author, author_image, rating, date, review, likes, app_version, reply and review_id. That is the export header, identical across 11 runs. Eight were present on every one of our 842 rows; only app_version and reply varied. The spreadsheet puts review_id last and the JSON puts it second, so read by name rather than position.com.facebook.katana or a full Play Store link to the same app both resolve, and you can mix them in one run of up to 1,000. The app is echoed back as app_id on every row, which is what you group on when you batch several.review_id, and across our 842 rows no single run ever repeated one internally - the duplicates were all between runs. Deduplicate on it and you keep only what is new. There is also a cutoff setting that takes an oldest-timestamp, so you can avoid fetching the old history at all.2016-08-16 to 2026-07-10 - close to a decade of history for the apps we pulled. How deep any single run goes is governed by the per-app limit and the sort order you choose.reply was populated on 15 of our 842 rows - under two percent - and all fifteen happened to be on one-star reviews of a single app. Plan for the column to be empty most of the time.Submit your app IDs and get the reviews back as rows - text, rating, date, likes, version and reply. Your first 500 rows are free.
The Play Store shows you a star average and the reviews it decides are most relevant. Neither is much use for work: the average flattens a distribution that is usually anything but flat, and the reviews you are shown are a rotating handful chosen by someone else. The Google Play Reviews Scraper returns the underlying reviews as a table instead - one row per review, carrying the text as written, the star rating, the date, the helpful-vote count, the app version the reviewer was running, the developer's reply where one exists, and a stable id for the review itself. Submit app IDs or Play Store links, up to 1,000 in a run, choose how many reviews per app and how to sort them, and export as CSV, JSON or Excel.
The ten columns on this page are measured rather than assumed. They are the export header, identical across 11 runs, and every figure quoted comes from the 842 rows those runs returned - 559 distinct reviews across three apps. Eight of the ten were present on every row. Two were not, and both are worth knowing about before you build: app_version appeared on 702 of 842 overall but its coverage ranged from 90% on one app down to 14% on another, and reply appeared on only 15 rows in total. One limit of the evidence should be said plainly: those runs covered three apps, which is enough to establish the shape of the output and how the columns behave, and not enough to predict what any particular app of yours will return. The free tier exists for that.
What makes this service worth wiring into something permanent is the review id. Across all 842 rows there were 559 distinct ids, and not one run contained a duplicate of its own - every repeat was between runs, exactly as you would expect from pulling the same app twice. That makes the id a reliable deduplication key: union your exports, discard ids you already hold, and you have a review history that grows rather than a folder of overlapping snapshots. The reference documents a cutoff parameter that takes an oldest-timestamp as well, so a recurring pull need not fetch the archive each time. That matters more than it sounds, because the archive is deep - our sample reached back to August 2016.
Two further things shape how the data reads. The first is polarisation: the ratings in our sample split roughly 35% at one star and 35% at five, with only 7% at four, so the middle of the scale is nearly empty and any mean computed from it describes almost nobody. The interesting content sits at the two ends, which is the argument for reading the text rather than the score. The second is that this is the one scraper here with no query column - the submitted app comes back as app_id, so that is the field to group on when you batch. Note also that the export's column names are the export's own; the API reference describes the same data using different names for its raw response, so build against the header you actually receive. Start free: your first 500 rows cost nothing and need no credit card.