What happens after a spike in bad reviews?

Better than the worst day.
Still worse than before?

All eight apps we could follow had a lower percentage of bad reviews after their spike day. But five still had a bad-review share at least 10 percentage points above their earlier baseline.

This is a small, retrospective study of written App Store reviews. It shows why “the spike has eased” and “feedback is back to its previous level” can mean different things.

Our theory was that most apps would remain above their previous bad-review level after a spike. We required at least ten apps with sufficient follow-up before calling that pattern supported. Only eight qualified, and the result changed under other reasonable definitions. The theory did not pass the full planned rule.

Why this matters for ASO

An ASO report can say an app’s negative feedback is improving because yesterday was worse. But users may still be leaving a much higher percentage of bad reviews than before the spike.

This study separates two questions: Did the bad-review percentage fall from its peak? And did it return toward the app’s earlier level? The same app can improve on the first measure and remain elevated on the second.

Here, “bad” means a 1-star or 2-star written review. A change from 30% bad to 50% bad is a rise of 20 percentage points. We are measuring the mix of retrieved written reviews, not the percentage of all users who are unhappy.

Claude improved from its spike, but remained above its baseline.

The share fell from 78.6% to 52.4%. That is a substantial drop from the spike day. Yet the follow-up was still 20 points above the 32.4% baseline.

Calling that a return to the previous review mix would hide the remaining difference. Calling it three continuously bad days would also be wrong: the first follow-up day was 27.3% bad, followed by 60.0% and 62.5%.

Kalshi fell below its earlier baseline.

Kalshi’s follow-up share was 4.9 points below its baseline. This is a different observed pattern from Claude’s. Neither example tells us what caused the spike, whether a product issue was fixed, or what happened to app rankings.

Five stayed above baseline. Three fell below it.

“Still elevated” means the pooled share over the next three days was at least ten points above the previous seven-day baseline. The three-day figure is total bad reviews divided by total reviews, not an unweighted average of three daily percentages.

The median change from baseline was +13.1 percentage points. The median change from the spike day was -20.7 points. These summarize eight selected apps; they are not estimates for all App Store apps.

No app stayed above our threshold on all three days.

Five apps passed the pooled three-day test. None passed it on every individual day. That is why this report says their combined follow-up share remained elevated, not that each day was consistently worse.

Each cell shows bad-review share and bad / total written reviews. Thresholds display rounded percentages; classifications use exact counts.

The majority finding was not consistent.

We specified five checks before calculating this experiment’s results. Each changes one part of the primary definition, with the larger-sample check changing all four sample-size minimums together. Each version selects the earliest qualifying spike per app before checking follow-up.

Counting only 1-star reviews left 3 of 9 apps elevated. Starting with a smaller ten-point spike produced 6 of 16. Both are below half. Starting with a larger thirty-point spike left just three eligible apps.

Requiring the follow-up to stay twenty points above baseline reduced the primary result to 2 of 8. The larger-sample check left only two apps, so it cannot settle the question.

The larger-sample minimums were 100 baseline reviews, 20 spike-day reviews, 60 follow-up reviews and ten on each follow-up day. All variants and app-level results are included in the download.

What if we count every spike, including repeated apps?

There were 17 qualifying spike days across ten apps. Fifteen had usable follow-up, spread across nine apps. Seven of those fifteen had an elevated pooled follow-up share. Repeated apps and overlapping windows make these dependent observations. They are not fifteen independent confirmations, and this diagnostic does not replace the primary first-spike-per-app result.

One spike per app, then three days of follow-up.

1. Start with the same 57-app US panel. These apps had appeared in the archived US top-free apps chart’s top 20 between 19 September and 25 October. This study uses their written reviews, not their rankings.
2. Check 27 possible spike dates per app. Dates run from 26 September through 22 October 2026, giving 1,539 candidate app-days. Follow-up ends no later than 25 October. Every window uses UTC.
3. Require enough earlier reviews. At least 50 reviews in the previous seven days and ten on the spike day. Retrieved timestamps must span the baseline start and the end of the spike day.
4. Define a sharp spike. At least five bad reviews on the day, with a bad-review share at least twenty percentage points above baseline. Unlike Experiment 18, the bad-review count does not have to double.
5. Select the earliest qualifying spike per app. Do this before looking at whether its future data pass the coverage requirements.
6. Require usable follow-up. At least 30 written reviews across the next three days, with at least five on each day, and retrieved timestamps extending beyond the follow-up window.
7. Compare with the original baseline. The main outcome is a pooled follow-up share at least ten points above that baseline. We also check each follow-up day separately.

Where the 1,539 candidate days went

Reused data, not a new review collection

We reused 21,750 written-review records collected for Experiment 15 on 27 October 2026, from 437 public-feed requests. The feeds returned reviews for 55 of the 57 apps, with up to ten pages per app. Empty or insufficient data were not counted as healthy feedback.

The rules were written before calculating Experiment 19’s outcomes. However, the review pool had already been analyzed in earlier experiments. This is exploratory follow-on research, not an untouched test set or an externally registered experiment.

Why a fall after the spike does not prove an app recovered

We deliberately selected unusually bad days. Even without a real improvement in an app, an unusually extreme observation can be followed by a less extreme one. This is often called regression toward the mean. We did not compare these apps with a suitable non-spike control group, so we cannot separate that effect from genuine changes in user experience.

Apple allows reviews and ratings to be edited, with the latest submission replacing the previous one. The timestamps in a later feed can therefore reflect edits rather than original submissions. Apple’s ratings and reviews documentation.

The public feed can omit deleted reviews, truncate older history or lag behind activity. Timestamps spanning a window do not prove complete coverage. Written reviewers are not all app users, and star-only ratings are not included. Apps can also share external events on the same dates.

This study does not establish that a spike predicts future bad reviews better than another signal. It does not measure ranking, conversion, installs, retention, listing localization or the impact of an ASO change.

The full evidence is included.

The ZIP contains all 1,539 candidate days, all ten selected apps, all 17 spike events, the five planned variations, deidentified review facts, source-request logs, the written rules, analysis code and independent verification.

A second implementation rebuilt the counts using UTC daily buckets and exact fractions. It verified the primary classifications and all five sensitivity variants, passing 74,442 checks. Most checks validate review IDs, scores and timestamps. This confirms processing consistency, not source completeness.

Extract and run python analyse.py, then python verify.py. Both run offline using Python’s standard library. No reviewer names or review text are redistributed.

1. Apple US written-review feed: Claude example. The download preserves original acquisition URLs, timestamps and response hashes. Live feeds change.
2. Apple ratings and reviews overview, checked 27 October 2026. Documents edited review behavior.
3. AppOrbit by ivershuo, pinned source. Earlier chart source used to select the panel, under ODbL 1.0. Attribution and derived-panel license included.