Can bad reviews double without the review mix getting worse?

Bad reviews doubled.
Usually, the review mix worsened too.

We found 17 days when an app’s bad-review count was at least twice its recent daily average. On 16 of those days, bad reviews also made up a larger share of the retrieved written feedback.

The theory we tested: an app can get more bad reviews simply as part of a larger volume of written feedback, while the percentage of bad reviews stays flat or falls.

The count rose while the bad-review share fell in only one app-day. We had required examples in at least three different apps to establish the proposed repeated pattern. That rule was not met.

The stronger descriptive result runs the other way: 16 of 17 count spikes coincided with a higher bad-review share in this selected sample. That is not proof of worsening satisfaction among all users.

“More bad reviews” can describe two different changes.

An ASO dashboard might show twice as many 1-star and 2-star reviews. That count alone does not tell you whether the app attracted more written feedback overall, whether a larger percentage of reviewers were unhappy, or both.

We measured both the number of bad written reviews per day and their share of all retrieved written reviews. In this study, most count spikes came with increases in both.

Ten of the 17 spikes had a bad-review share at least 10 percentage points higher than the baseline. Six had a rise of at least 20 points. For example, moving from 30% bad to 50% bad is a 20-point rise.

The count and the share answer different ASO questions. A higher count means more negative written feedback to deal with. A higher share means negative feedback became more common within the retrieved review sample. Neither measures installs, conversion or overall app quality by itself.

Claude’s count rose even though total review activity did not.

Claude, 5 October

4.9 → 11

Bad reviews per day: baseline average → current day

32.4% → 78.6%

Share of retrieved reviews that were bad

Baseline: 34 bad out of 105 reviews across seven days. Current day: 11 bad out of 14 reviews.

What changed?

The previous week averaged 15 written reviews per day. The current day had 14.

So the 2.26× bad-review count did not come with more total written-review activity. The current sample had a much larger share of bad reviews.

This describes the retrieved reviews dated to these windows. It does not establish what caused the change or how all Claude users felt.

The exception still had 92% bad reviews.

Shots, 4 October

9.4 → 24

Bad reviews per day: baseline average → current day

97.1% → 92.3%

Share of retrieved reviews that were bad

Baseline: 66 bad out of 68 reviews across seven days. Current day: 24 bad out of 26 reviews.

Why the percentage fell

The bad-review count grew 2.55×, while total written-review activity grew faster, at 2.68×.

That made the bad-review share lower. But the app still had 24 bad reviews out of 26, so the lower percentage was not evidence of healthy feedback.

The fall was only 4.8 percentage points. It did not pass the stricter check requiring a ten-point decline.

Dates and daily windows use UTC. Review timestamps come from a later public feed and can reflect edits. These examples are not a contemporaneous archive of new review submissions.

All 17 events, including the exception.

These 17 events came from nine apps. Several apps appear more than once, and adjacent days share much of their baseline. The rows are not 17 independent apps.

The lower-share counterexample did not become a wider pattern.

Using only 1-star reviews produced the same single counterexample. Keeping only the first spike for each app also left that one example.

The larger-sample rule left six spikes and no counterexamples. Shots’ 4 October baseline contained 68 reviews, so it failed the stricter 100-review requirement. Exclusion under a stricter rule does not make its original observation false.

Using a 14-day baseline or requiring the bad-review count to triple produced no counterexamples. The original result remains one out of 17, not whichever variation looks most convincing.

Compare one full day with the previous week.

We considered each of the 57 apps on each of 30 UTC dates, from 26 September through 25 October 2026. That produced 1,710 candidate app-days.

For a day to enter the comparison, the retrieved history had to extend across the whole current day and its seven-day baseline. We also required:

• At least 50 written reviews in the baseline.
• At least seven bad reviews in the baseline.
• At least ten written reviews in the current day.

A count spike required at least five bad reviews in the current day, and at least twice the baseline daily average. For example, 35 bad reviews across the previous seven days means a baseline of five per day. Ten on the current day would meet the doubling requirement.

We then compared the bad-review percentages. The proposed counterexample required the current share to be no higher than the baseline share. Calculations used exact counts rather than rounded percentages.

Where the data came from

We reused the 21,750 written-review records collected for Experiment 15 on 27 October 2026. These are not newly acquired reviews. The public feeds returned reviews for 55 of the 57 apps, with up to ten pages retrieved per app.

The panel was originally selected from apps appearing in the archived US top-free apps chart’s top 20 between 19 September and 25 October. This experiment does not test chart positions or downloads.

Those 297 usable days came from 27 apps. The other 30 apps contributed no eligible day. Missing or insufficient data were not treated as an absence of bad reviews.

Every counted day is available to inspect.

The download includes all 1,710 candidate days and their status, all 297 eligible days, every spike, every sensitivity result, the reused review facts, original request logs, the analysis rules and independent verification code.

The independent implementation rebuilt daily star-count totals and reproduced the classifications and calculations. It passed 69,416 checks, most of them validating individual review IDs, star values and timestamps. These checks verify the processing, not the completeness or representativeness of the public feed.

Extract the ZIP and run python analyse.py, then python verify.py. Both use Python’s standard library and work offline. Reviewer names and review text are excluded.

1. Apple US written-review feed, Claude example. Exact URLs and capture times for all 437 original requests are included. Live feeds change.
2. Apple: ratings and reviews overview. Source for the treatment of edited reviews and ratings.
3. AppOrbit pinned source, by ivershuo. Earlier source for panel selection, under ODbL 1.0. Derived panel attribution and license included.