App Release Review Impact: Rating by Version
Pricing
Pay per event
Groups App Store and Google Play reviews by app version and shows how each release changed the rating, with significance flags and the complaints that are new in that version.
im:version coverage measured on 2 October 2026 (three feed pages per storefront): 100 % on 2,437 reviews from 18 storefronts (1064216828 us/jp, 284882215 us, 389801252 us, 324684580 gb, 310633997 de, 835599320 us, 363590051 us/br, 327630330 us, 585027354 de, 1459969523 us/in, 333903271 us, 422689480 gb, 1130498044 us, 1094591345 jp, 982107779 us). The App Store threshold is now 90 % (about 10 points under the lowest read, the margin Google Play has under its 29.5 % lowest read); Google Play stays at 20 %. A read of 21 % from the App Store used to give rows carrying only a note; it is now a left-out storefront. Fixture check: im:version kept on 80 % of the entries gives exit 91 under 0.19 and green rows under 0.18.1064216828 with us healthy and gb at 10 % gave, with minReviewsPerVersion 3, rows with countries ["us"], and with minReviewsPerVersion 300 a status row with countries ["us","gb"] and sourceUrl of us next to a note that said gb was left out. Now both branches take countries and sourceUrl after the coverage filter.gb at 80 % next to a healthy us with the two sentences of the status message, status row countries and sourceUrl with gb at 10 % and with gb at 0 %); the tests that used 75 % App Store coverage as the healthy partial case now use 95 %. clockedHttp in http.test.js runs on a fixed clock: under 0.18 the real time of the failed attempt leaked into remainingMs() and the assertion 44999 !== 45000 failed in 3 of 14 loaded runs of node --test.node --test 139/139, prefill live exit 0 with 7 rows, cost measured again $0.0274 per 1k rows (23.7 s, 24 rows from the example input), the price of $4 per 1k is x145.7 the cost.1064216828 with us and gb and im:version removed from gb gave a green run with two billable rows whose countries were ["us","gb"] although gb contributed no review, with only the aggregate "50 of 99 reviews carry an app version"; with the field removed from us instead, the whole app failed with exit 91 and 0 rows although gb held 49 reviews with a version. Now a storefront with no versioned review, or with less than 20 % of them, is left out of the statistics, named in the note of every row ("gb: none of 49 reviews carries an app version, so this storefront was left out of the version statistics (its feed may have changed)") and in the status message, and removed from countries and sourceUrl; a healthy storefront next to it keeps its rows. The app fails only when no storefront reaches the threshold.raw[10] on 2 October 2026, 400 to 500 reviews per read: Snapchat us 62.0 %, jp 54.0 to 54.8 %, br 53.2 %, ru 56.6 %, id 29.5 to 32.2 %; Telegram us 63.3 to 64.2 %, br 74.6 to 75.5 %, de 83.6 %; Duolingo 92 to 93 %, Spotify 84.8 %; the other 20 apps in us/en 79.8 to 93.0 %. Coverage does not depend on the depth of the read (Telegram 69.3 % at 5000 reviews). Under 0.17 the input {"apps":["com.snapchat.android"],"googlePlayCountry":"id","googlePlayLanguage":"id"} gave exit 91 and 0 rows with the diagnosis "the source may have changed", while us gave 4 billable rows; now both give rows, the Indonesian one with "id: 161 of 500 reviews carry an app version" in the note. The lowest healthy read is about 10 points above the threshold; a field that disappears (0 %) or drops to 10 % still fails.gb without versions next to a healthy us, us without versions next to a healthy gb, gb at 10 % next to a healthy us, two storefronts without versions, two storefronts at 10 % with the counter and the per-storefront numbers); run.test.js is split into three files so that node --test runs them in parallel (suite wall time 38 s instead of 110 s).minReviewsPerVersion or adding App Store countries, which cannot produce a row when no version was seen. Measured on a fixture (1064216828, us, im:version removed from every entry): 25 reviews gave exit 91, 15 reviews gave exit 0 with the filter advice. Now any read where no review carries a version is a changed-source failure of that app (free status row, run fails when no other app delivered).im:version kept on 20 of 200 entries gave the same three billable rows with reviewCount 3 / 11 / 6 instead of 23 / 108 / 69 and avgRating 1.00 instead of 2.09, with no sign on the rows.note of every row and of the status row says "N of M reviews carry an app version, so the version statistics rest on fewer reviews." (Google Play leaves the version empty on a share of reviews: 31 of 200 in the recorded Spotify sample). A complete read keeps note null.minReviewsPerVersion (or onlyRegressions or the other filters left nothing) now carries the partial-read notice that billable rows already carried. Under 0.15 the notice went only to billable rows, so the status row of an app with no qualifying version dropped it. Measured on a fixture (1064216828, us, page 2 failing with HTTP 403, 50 of 200 reviews read): minReviewsPerVersion 3 gave rows with "reading stopped after 50 reviews (HTTP 403 ...)", while 300 gave a single status row that advised lowering the filter or adding App Store countries and quoted the 500 reviews per country limit, although the real cause was the HTTP 403, which passes on a rerun.onlyRegressions finds nothing, other filters match nothing) and for an empty store answer. When the read was incomplete the threshold advice is replaced with "Reading was incomplete, so run again before changing the filters."; the advice about countries and maxReviewsPerApp stays for a complete read.onlyRegressions).actor.json, package.json and this file agree on the version again.im:rating are no longer filtered out before validation. A feed that changed its format gives a status row with the reason after one try (not a green empty run with a "run again" hint), and a page where only some entries lack the field gives billable rows with a note and the number of dropped entries in the run status.aggregateRating.ratingCount of the JSON-LD; measured 02.10: Spotify 36,412,939, Reddit 4,849,780, Firefox Focus 271,806): with 50 or more ratings it is a status row of kind blocked with the count and the number of tries ("this does not show whether the app has written reviews"), the run fails when no other app delivered reviews; with fewer ratings or none the status row says the app may have no written reviews yet.note carries "the endpoint answered empty for the batch after N reviews and reading stopped there (reason), so the oldest reviews of the window may be missing". Under 0.13 reading ended with note null (measured: 200 of 400 requested reviews, no trace).com.spotify.music, 400 reviews, batch 1 = 200 reviews, batch 2 failing), one app went from 4 billable rows to exit 91 and zero rows, and next to a healthy App Store app the run was green and silent with no Google Play rows at all. Now the 200 reviews stay in the version rows (identical rows and review counts as with a healthy end of the feed) and the note says "us: reading stopped after 200 reviews, so the older reviews of the window are missing (HTTP 403 ...)". An error before the first review is still a failure of that app with a status row.note like the App Store ones: "us: 100 of 200 review entries failed validation and were left out, so the version statistics of this storefront rest on fewer reviews". Under 0.12 half of the entries without id gave fewer rows (one version disappeared) and lower review counts with note null.id; source-level tests of fetchPlayApp).gb without the id field or with im:rating = "4 stars", next to a healthy us) is now named in the note of the version rows and in the run status: "gb: N review entries were read but none passed validation, so the review format of this storefront may have changed", or "gb: N of M review entries failed validation and were left out" when only part of them fail. Under 0.11 the rows were billed with note null and the only trace was the global count of dropped reviews.id, part of the entries invalid, healthy storefronts without a note, end-to-end run with an invalid gb next to a healthy us). Removed a no-op substitution in the term stemmer.us healthy and gb page 1 answering 403, the run went from 5 billable rows (249 reviews) to exit 91 and zero rows, and with a healthy Google Play app next to it the run was green and silently returned only the Google Play rows (4 rows instead of 9). Now the failing country is listed in the note ("gb: not read (HTTP 403 ...)") and the other countries are delivered, in either order; an app fails only when no country could be read (all-403 still ends the app with the original error kind and app data).com.reddit.frontpage on Google Play, 500 reviews in 2 s when read alone) got "No request was sent" and the run failed with 3 status rows and zero billable rows (152.3 s, exit 91). Now each app starts with at most an equal share of what is left of the 150 s (apps left counted including itself), capped at 75 s, and never below 9 s: with three apps two silent App Store apps used 50.0 s each, got status rows, and the Google Play app delivered 500 reviews in 2.2 s (102 s for the run). With two apps the first still gets 75 s.im:rating was "4 stars"), the Actor reads no further pages of that storefront and the app gets a status row "Read N reviews of App Store ... but none passed validation, so the review format may have changed", with the app name and storefront. Under 0.9 the error was "Could not read: App Store ... ()" with an empty note, because the storefront was counted as blocked or as a failure with an empty list.com.reddit.frontpage got zero requests and then delivered 500 reviews in 1.3 s on its own; with the prefill shape both rows were status rows and the run ended FAILED). Now every app starts a fresh 75 s (beginApp) and a cap of 150 s covers the whole run. Measured on 1 October 2026 with the App Store host accepting connections and never answering and Google Play live: the App Store app 75.0 s and a status row, then 500 reviews from Google Play in 18 s, run total 93 s. With the feed answering 200 without entries for us, gb and de: App Store 81.5 s, then Play delivered 500 reviews (the 0.8 run took 85 s and gave Play nothing).note such as "gb: reading stopped after N reviews ..."); a country that fails without any review is listed in note while the other countries are delivered; only when no country delivered anything the app gets a status row. An exhausted budget after empty answers keeps the empty-feed explanation instead of the transport message "No attempt was made".appName, countries (the storefronts looked up) and sourceUrl whenever the store answered the lookup, the same fields as the other status rows. The dataset schema describes it.Promise.race with an AbortController, because the socket timeout does not fire on a connection that hangs) shortened to what is left of the budget, and no attempt starts when less than 3 s is left. Measured on the same silent server: 15 requests in 75.0 s together (the first used the whole budget, the other 14 were refused at once). Requests that succeed do not use the budget.lowStarTopTerms: olderShare and lift are null when all older versions hold fewer than 12 low-star reviews (6 of 9 rows of the example input had a pool of 4 to 10 and a lift that was only the size of the pool: versionShare times (pool + 1) / 0.5). The lift now divides by the older share taken at least at 1 % and at least at one review of the pool, so an absent term gets the same lift at pools of 200 and 2000 and a smaller one at small pools. newComplaintTerms uses the same function for its lift gate.lowStarTopTerms is [] when the version has 8 or more low-star reviews but no word or pair occurs in 4 of them (lowStarTopTermsText is null for it) and null below 8 reviews; schema, README and the text field now describe both. On the example input: terms on 8 of 24 rows, [] on 1, null on 15; lift on 2 rows.olderShare and lift as null (its older pool has 6 low-star reviews); the text no longer says that a lift near 1 is old and a high one new without the 12-review condition.package.json version 0.8.0 (it was 0.1.0).send that never answers, lift against pool size, [] against null).compareRatings used the normal constant 1.96 as the threshold and as the margin multiplier, without the t quantile and the Welch degrees of freedom, and with zero variance it called any difference of means significant with a margin of 0. Now the margin is the t quantile for the Welch-Satterthwaite degrees of freedom times the standard error, and each group's variance is floored at 1/12 (star ratings are whole numbers), so identical ratings never give a margin of zero. Example: [1,1,1] against [2,2,2] was regressed with margin 0; it is still regressed with a margin of 0.65 stars, and [5,5,5] against [4,5,5] is no longer significant.minReviewsPerVersion 3 on the six example apps: 49 comparable rows, 17 rows with 5 reviews or fewer, 4 significant changes and none of them from a version with 7 reviews or fewer (0.6: 5 significant, 3 of them from 4 to 7 reviews, and 2 rows with a margin of 0.05 or less); the narrowest margin is 0.45 stars on a row with 4 reviews.views.overview (the Version impact table in the Store) no longer has the column New complaints: it was empty on 23 of 23 rows of the Actor's own example input. The field stays in the dataset, in fields and in the API; the table keeps Top low-star terms (8 of 23 rows), the other columns are filled on 17 or 23 of 23 rows.regressed row. Measured on the example input on 1 October 2026: at 500 reviews per app 17 comparable rows gave 3 regressed, 1 improved, 2 stable and 11 inconclusive (6 baselines); at 5000 reviews 100 comparable rows gave 7 regressed, 5 improved, 8 stable and 80 inconclusive. newComplaintTerms is filled on 0 of 23 rows at 500 and on 11 of 106 at 5000. The README states the test, the variance floor and the simulated false-alarm rate.429 Retry-After: 120 slept 362 s and ran 363 s, more than the 5 minutes of the daily Apify test.Retry-After is honoured only while it fits: 429 Retry-After: 120 on a first page now ends that request at once with an error that names the 120 s wait and the 75 s budget, the app gets a free status row and the other apps are read. Once the budget is spent every request gets a single try. The sleep of a run is at most 75 seconds; the run also spends time on the requests themselves and on the 1.2 second gap between App Store requests.views.overview (the Version impact table in the Store) gets the column "Top low-star terms" from the new field lowStarTopTermsText (the five terms of lowStarTopTerms as one string with the lift, for example "log (lift 11.1), working (lift 4.2)"). The column "New complaints" stays, but it is empty at the default depth, so the table no longer rests on it alone.Retry-After: 120 on the first page sleeps nothing and makes one request; Retry-After within the budget is honoured and subtracted from the feed pool; the text field of the top terms).note of a row now tells two cases apart. A gap (an empty page followed by a served page) says that up to 50 reviews per page are missing and that page 1 holds the newest reviews; an empty page after the last served page says that the oldest reviews of the window may be missing. Before, every empty page, also the last one of the window, was reported as "missing from the newest part" and counted 50 reviews each.countries with only unknown storefront codes (for example eu) and no other app delivering anything ends with "No App Store storefront code to read was valid for App Store (eu) ..." instead of "None of the requested apps exists"; the status message names codes that were not looked up.newComplaintTerms keeps its strict test; the README, the dataset schema, PRICING.differentiator and the use cases no longer present it as filled at the default depth. Measured on 1 October 2026 on the six example apps from Google Play: 0 of 25 rows at 500 reviews per app, 2 of 62 at 2000, about 10 of 73 at 5000 (older versions inside the window hold only a few 1-2 star reviews, so null is structural). lowStarTopTerms is filled on 8 of 25 rows at 500 and is the field to use for triage. The README example is now a real 500-review row with a significant drop and newComplaintTerms: null.dataset_schema.json states z of at least 3 (the code always used 3, the schema said 3.3).movies is read as movie (it was movy, next to movie in the same top five), and suspend and suspended, log and logging are no longer listed as two terms of one top list.trend has a fifth value, inconclusive. Before, stable was also given when the sample could not tell: in the 0.3 review 10 of 48 rows with a rating change of 0.4 stars or more were marked stable, next to a Reddit change of -0.95. Now stable needs a change under 0.15 stars and a 95 % margin of at most 0.3 stars, and regressed or improved need a significant change of at least 0.15 stars; everything else is inconclusive. New field ratingDeltaMargin (half-width of the 95 % interval, stars), and deltaSignificant and the margin are columns of the Store table view. The onlyRegressions status row counts the drops that are not significant.newComplaintTerms no longer needs a 15 % share and a threefold lift together, which left it empty on 46 of 48 rows (large samples: a term in 15 % of the reviews is also common in older versions; small samples: zero hits in older versions gave an automatic lift). A term now has to pass a one-sided two-proportion test against all older versions (z of at least 3), appear in at least 4 reviews and 3 % of the low-star reviews, be at least twice as frequent as before and, when the previous version has 8 or more low-star reviews, at least twice as frequent as in the previous version. The field is null when no comparison is possible (oldest version, fewer than 12 low-star reviews in the version or in the older ones) and [] only when the comparison was made and nothing stood out; before, both were [].newComplaintTermStats (term, lowStarReviews, versionShare, olderShare, lift) and lowStarTopTerms (the five most frequent terms of the low-star reviews with the same numbers, for every version with at least 8 low-star reviews, so a regression row always shows what the unhappy reviews are about and how much of it is new). Contractions such as "you're" are stop words.stable fell from 12 to 0; newComplaintTerms is non-empty on 9 of the 23 rows that can be compared (0.3: 3 of 60 rows), null on the 37 rows with too few low-star reviews to compare, and lowStarTopTerms is filled on every row with 8 or more low-star reviews. Large-sample regressions can still return [] by design; the top terms carry the signal there.eu, en) is reported in the status message and the row note, and uk is read as gb; an iTunes lookup that answers with any other error ends the run, because it means the lookup API changed; any other source error of one app (HTTP error from Google Play, changed format) becomes a free status row, the other apps are delivered, and the run fails only when no app delivered any reviews. Before, countries: ["us", "uk"] ended the run as an error after two rows had been billed.maxReviewsPerApp up to 5000 for Google Play.newComplaintTerms needs at least 12 low-star reviews in the version and in all older versions together (was 8) and a term in at least 4 reviews (was 3), because terms from small samples were noise.maxItems stops the run.note with the number of reviews that arrived; a page shorter than 50 ends the paging without another request.countries and sourceUrl of a row now name only storefronts that supplied reviews.newComplaintTerms compares a version only with older versions, so the field means what its name says; a complaint that persists into the next release is no longer credited to it, and the oldest version has no terms. Field description and README corrected (15 % share, three times the frequency).found: false; when no requested app exists the run fails with the reason.