Are App Store Reviews Fake? Why Bought Ratings Backfire

Someone messages me: "Do you know a channel that can get us a batch of five-star reviews?" I ask why. Because a competitor's rating sits slightly higher, and the rating is the first thing people look at on the store page.

I pass on that work. Not out of purity — we build store pages for clients, and once you put something false into a rating, every release after it has to be explained.

The short version

Buying reviews is a one-time cost with a long tail. The money is small. The maintenance is not.

Once your rating sits at a place it did not earn, everything downstream has to agree with it: when the reviews were posted, which versions they mention, how the stars are spread, how review volume compares to install volume. One of those will contradict the others. The stores do not need to be clever to notice.

Users notice earlier than the stores. The people reading your review list are more careful than we give them credit for. They scroll to the oldest entries. They look for a specific situation. They check whether a five-star review names a single feature.

So I treat this as a balance-sheet problem, not a risk problem. Borrowed ratings are a negative asset.

Why fake reviews are harder to hide now

Not because the rules got stricter. Because the baseline of a review pool changed.

Real reviews carry a few natural marks. They cluster around releases. They match the language of the market they were written in. Stars pile up at both ends and thin out in the middle. The writer names a feature or a specific failure.

Fake ones invert all four. They arrive in a burst. The wording is one template with words swapped. Five stars plus "works great" and nothing else. The account has no other behaviour attached to it.

There is a cruder tell as well: language and region. You seed reviews on the US storefront, the text is English, but the accounts are registered elsewhere and have only ever reviewed apps in another market. That mismatch does not need semantic analysis to filter.

The stores do not judge a single review. They judge whether this batch looks like the rest, and outliers in a homogeneous pool identify themselves.

Check the current official guidance before you ship, but the direction is not in doubt: both stores filter for review authenticity now, not just the individual reviews that get reported.

What Apple and Google look at

On the App Store, ratings and reviews live on the product page. Developers can reply, users can mark a review as helpful, and anyone can report one. Apple prohibits manipulating ratings and reviews; enforcement runs from removing reviews to, in serious or repeated cases, action against the developer account.

On Google Play, reviews pass through filtering, and reviews judged fake or abusive may not be shown to everyone. Ratings are also weighted by country and device, so the same app can display a different score in different markets.

Different wording, same line: no incentives in exchange for reviews, no manipulation of ratings.

The conversion cost lands before the ranking cost

Most people buy reviews expecting a ranking move. I read it the other way round: the ranking effect is second-hand, the conversion effect is immediate.

Rating is one signal among several, and it is read together with installs, retention and engagement. Raise the rating while retention stays flat and the signal set stops agreeing with itself. A signal set that does not agree with itself does not get the weight it is asking for.

What happens right away is on the page. People read reviews to find evidence, not praise. A wall of "great app, recommended" tells them nothing. They back out and open the next result, where somebody wrote "export stutters, but support fixed it the next day".

That is the mechanism behind the negative return. You paid for a page that makes people trust you less.

And there is a reckoning date. The reviews come off, the rating drops back, and every claim you made about that rating has to be withdrawn.

One counterintuitive note: a page with nothing but five stars and no flaw mentioned reads like nobody used the product. A rating reduces uncertainty; it is not meant to simulate perfection.

Three traps on the App Store side

First, firing the rating prompt at launch. The system limits these prompts, and users can switch off in-app rating requests entirely in Settings. Prompt before someone has got any value and you push them toward that switch, which you cannot undo later. The right moment is right after something went well: an export finished, a level cleared, a report generated.

Second, replies. Developer replies are public. "Thanks for the feedback, we will improve" tells every future reader that nobody reads the reviews.

Third, versions. Some teams plan to wash an old rating with a large update. That route closed a while ago.

Different traps on Google Play

The in-app review API does not guarantee a dialog. It is quota-limited, and the store decides whether to show it based on the user's state. "We integrated the API, so ratings should come" is a wrong assumption, and it is where a lot of teams get stuck thinking their integration is broken.

Second, a Play rating can carry no text at all. A star with nothing attached has almost no information in it, which also makes it the easiest thing to flag — there is nothing for a human reviewer to check.

Third, competitors. If a burst of one-star reviews hits you, the correct move is reporting specific reviews through the official channel, not organising a counter-wave of five stars. The counter-wave puts your account into the same judgment pool, and that cost lasts.

When I tell people to stop

Three situations where I ask the team to leave the rating alone, whatever the budget.

The rating is low and the bad reviews point at one broken feature. Buying reviews here is painting a room that leaks. People install, hit the same wall, leave, and write something more specific on the way out.

The app launched recently, or you just changed the bundle name or package name. The sample is too small. Any seeded batch is a large share of the total, which makes it the most visible thing on the page.

You are already trading something for reviews — in-game currency, cash back, a raffle entry. Both stores prohibit that on its own. Stop it first, then we can talk about the rating.

There is also a case where the worry is misplaced. A competitor outranks you on rating, but its users are a different shape — a utility against your content app. Compare conversion there, not stars.

What a low rating actually needs

Layer one is the product. Take the reviews from the last release, group them by feature and failure, and see whether they converge. If they will not group, the problem is expectation setting, not the build.

Layer two is prompt timing. Move the rating prompt from launch to the moment of value. Within a couple of weeks the content changes — not the count, the specificity.

Layer three is replies. Ten careful replies to specific complaints do more than a hundred five-star lines. A reply is written for the next reader, not for the person who left the review.

The order matters. Fix the prompt before the product and you walk more people into the same wall. Skipping to layer three, writing replies like a press release, then concluding that replying does not work is the most common mistake.

One check you can run today

Put reviews on a timeline next to installs.

Real review volume should follow install peaks with a short lag, and follow release dates the same way. If a cluster of reviews appears between two install peaks, or lands on a weekend when nothing shipped and nothing ran, look at that cluster on its own.

Then watch a second number: reviews divided by installs over the same period. On one app that ratio tends to be stable. A step change has two explanations — you changed the prompt timing, which is good, or something was added, which is not.

What to do next

1. Export the reviews from the last release and group them by feature and failure mode; find the one that repeats. 2. Move the in-app rating prompt from launch to just after a successful action, then read the reviews two weeks later. 3. Reply to ten specific complaints, each naming the problem, its current status, and the plan for the next release. 4. Stop every incentive-for-review programme you are running, including raffles, cash back and in-app currency.

If your review list already looks too tidy, get a second pair of eyes on it before the next release. We do this work for a living, but I would rather you never have a rating problem to fix.