Google Play apps from app IDs, top charts, search, similar apps or a developer's catalogue: exact install count, installs gained between runs, ratings histogram, developer email, phone and address, permissions, data safety. Reviews with replies and star, device and date filters.
Title: "Exact Installs" instead of "Daily Installs". Over 20 hours Google updated the exact install counter for 77% of the apps tracked (runs eJqK7r5Uk9uvnBl7J → U3SZ9oSKb8N3GQ7bg), less often for smaller apps, so a per-day figure is not available for every app. The install change between your runs is still delivered. No code or output change.
0.1 — 2026-10-01
First version.
Apps from any mix of sources in one run: app IDs or Google Play links, top charts (Top free, Top grossing, Top paid × 53 categories × countries, up to 200 apps each), search terms, "Similar apps" of an app, and a developer's catalogue (by name, numeric ID or developer page link).
Every app row carries the full app record: Google's exact install count (realInstalls) next to the install bucket, rating, ratings count, reviews count and the 1–5 star histogram, price and in-app purchase range, version, update and release dates, release notes, content rating, tags, developer email, website, phone, address and legal name, privacy policy, permissions, data-safety labels and per-device ratings.
Change tracking between runs (on by default): installsGained, installsPerDay (when the snapshots are at least 20 hours apart), ratingsGained, scoreChange, versionChanged, previousVersion, and previousRank for top-chart and search positions. Snapshots are kept in a named key-value store in the user's account.
Ratings count, score and version are kept per country in the snapshot, so with several countries in one run ratingsGained, scoreChange and versionChanged compare with the same country (build 0.1.9 compared the Turkish rows of a Türkiye + Germany run with the German score). A snapshot written before this build gives no rating, score or version change on its next run; the install counter is compared as before.
Reviews mode (alone or with app rows): up to 1,000 reviews per request, every review Google shows for the filter or a maximum per app, newest / most relevant / by rating, star filter, all devices or one device type, review period, developer replies with dates, app version per review. Reviewer names can be left out; Google account IDs are never included.
Chart and search results keep their rank on every row; app IDs, similar apps and developer catalogues deliver an app once per country.
An app Google Play does not have, an empty chart or search, an invalid entry or a failed source leaves a free status row with the reason; the SOURCE_REPORT record explains every source. Google answers an empty review list for a package it does not have, so an empty review result is checked against the app and reported as not-found when the app does not exist.
Requests go direct, then through Apify datacenter proxy, then Apify residential proxy if Google Play limits them. A request that gets no answer at all (for example through a proxy that refuses connections) is logged as failed, not as an answer from Google Play (build 0.1.6 logged "Google Play answered ECONNREFUSED").
A search page that shows neither results nor Google's "No results" notice is not taken as an answer and is fetched again (build 0.1.1 once reported "meditation" in the UK as having no results; the same search returned 30 apps minutes later). A top chart, similar-apps list or developer page that comes back empty is asked once more before it is reported as empty.
Similar apps of an app Google Play does not have, and a developer name Google Play does not know, are reported as empty with the reason (build 0.1.2 reported them as failed with Google's raw error code).
A temporary error Google returns instead of a review page, a chart, a similar-apps list, a developer page or a single app is asked again up to three times (build 0.1.3 stopped one phone-only review list at 4,000 of about 5,360 reviews on such an error).
In mode apps the review settings are not used, so a review period left on "custom" without a date no longer stops an app-details run (build 0.1.5 stopped it with the date error).
Pricing: one app event per delivered app row (change tracking included) and one review event per delivered review. Status rows are free. A run stops fetching when it reaches the maximum cost set for it.
At the maximum cost, the log and SOURCE_REPORT now count the rows actually delivered (build 0.1.6 delivered and charged 24 rows but reported 48), nothing more is pushed once the budget is spent, and the sources the run did not reach are listed in SOURCE_REPORT as stopped (build 0.1.8 left them out).
Batch and Standby (HTTP API: /apps, /reviews) modes share the same code and events.
README: performance, data-quality and change-tracking figures measured on the Apify platform, with run IDs, including a 24-hour test of how often Google moves the install counter (two groups of apps, 9 reads) and what that means for one day's figures.
