Your App Rating Dropped: How Star Averages Work

Play Console shows you two different rating numbers, and they answer different questions — so the first step is establishing which one moved. Teams routinely panic about one while quoting the other, and the two behave nothing alike.

Google's ratings and reviews documentation distinguishes them. There is the Google Play rating — the figure shown to users, weighted toward recent ratings. And there is the lifetime average rating, the plain average since your app launched.

If the lifetime average barely moved while the displayed rating fell noticeably, nothing is wrong with your arithmetic — that is exactly what recency weighting produces, and it is the normal case.

One more detail before you start diagnosing: Google notes that new ratings do not immediately affect the published figure, with a delay of around 24 hours before ratings appear publicly. A drop you spot this morning reflects something that happened at least a day ago, which matters when you are lining it up against a release.

Across the 300+ apps we have managed since 2013, roughly half the "our rating collapsed" conversations end at this section. The visible number moved, the underlying quality did not change much, and the correct response is to understand the weighting rather than to launch a rescue campaign.

Because the number users see is deliberately not an average — Google states it is weighted toward more recent ratings to reflect changes and updates you make to your app. Once you know that, a drop that seemed impossible becomes predictable.

Work the plain arithmetic first, because it is what most founders do instinctively. An app with 10,000 ratings averaging 4.5 that receives 200 one-star ratings in a week lands at roughly 4.43 on a straight average — a change of less than a tenth of a star. If your displayed rating fell by half a star on that volume, the straight average cannot explain it, and people conclude something is broken.

Nothing is broken. Under recency weighting those 200 recent ratings carry disproportionate influence precisely because they are recent, which is the behaviour Google describes: the displayed figure is meant to reflect the app as it is now, not as it was averaged over its whole history.

The consequence that matters commercially is symmetrical, and it is the good news in this article:

• A bad fortnight hurts more than the maths implies. A regression, a bad release or an outage moves the visible number hard and fast.
• A good fortnight helps more than the maths implies. You do not need to out-vote your entire rating history to recover. You need a recent period that looks good.
• Old ratings stop being the obstacle they appear to be. The intuition that "we can never recover from those early one-stars" is wrong on Play, and it stops teams from trying.

Google does not publish the weighting formula, and we do not guess at one. What is documented is the direction, and the direction is enough to plan around: fix the cause, then generate a recent run of satisfied raters, and the visible number responds faster than a lifetime average ever could.

On the App Store yes, per version and per territory — on Google Play there is no equivalent, but the recency weighting is a softer, automatic version of the same thing. This is the largest structural difference between the two stores on ratings, and it changes what your recovery plan looks like on each.

Apple's ratings and reviews guidance spells out the mechanism and the caveat together. The summary rating is specific to each territory on the App Store, and you can reset it when you release a new version. Apple recommends using the feature sparingly — while resetting can ensure the rating reflects the most current version, which is useful if an update addresses users' previous concerns, having few ratings may discourage potential users from downloading your app. And resetting the summary rating will not reset your written reviews.

That last clause is the one that catches people. You can clear the stars and keep the one-star prose, which is frequently the worst of both worlds: a listing with almost no ratings and a visible wall of complaints about a version you already fixed.

On Google Play there is no reset, and you do not need one in the same way. The displayed figure already discounts your history in favour of your present. The Play playbook is therefore fix, then generate recent positive ratings; the App Store playbook adds an optional reset when the break with the past is genuinely clean.

Technical quality, a device-specific failure, or a change in who is installing you — none of which show up as a product complaint you would recognise. When the reviews do not explain the drop, these are the three places to look.

Technical quality is the most direct, and Google says so. Its documentation on app startup time states that an app with a slow start time does not meet user expectations, can disappoint users, and that this sort of poor experience can cause a user to rate your app poorly on the Play Store or even abandon your app altogether. Excessive startup is defined as 5 seconds or longer for a cold start, 2 seconds for warm and 1.5 seconds for hot, measured as Time to Initial Display.

Crashes and ANRs work the same way, and they have the additional property of being concentrated. A crash affecting one popular device model produces a burst of one-star ratings from users who all experienced the same thing, in the same week, without any of them describing it as a crash. Our piece on the vitals thresholds that decide distribution covers how to find the device responsible.

A change in acquisition mix is the one nobody suspects. If you started buying installs from a new source, or expanded into a new market, you are now being rated by a different population with different expectations of what your app is for. The app did not change; the raters did. This is worth checking against the date your rating moved before you go looking for a regression.

A release date is the strongest single clue. Line the rating chart against your release history, remembering the roughly 24-hour publication delay. If the drop begins within a day or two of a rollout, you are looking at a regression, and the fastest recovery is a fix rather than a ratings campaign. The cost of leaving it runs well beyond the stars — we cover that in why bad vitals act as a tax on acquisition.

Gate the prompt on how the user feels, put a button behind it, restyle it, or dress up a reply as solicitation — and on Play the stated consequence for review-reply violations includes suspension of your application. The tempting fixes are the prohibited ones, which is worth knowing before someone on your team builds one.

Google's In-App Review API documentation is unusually direct about this:

• No pre-qualifying questions. Your app should not ask the user any questions before or while presenting the rating button or card, including questions about their opinion such as "Do you like the app?" or predictive questions such as "Would you rate this app 5 stars". The "happy path only" prompt that many apps ship is explicitly out.
• No call-to-action button to trigger it. Because the quota can change, you should not have a button that triggers the API, since a user may have hit their quota and the flow will not show — presenting a broken experience. For that use case, redirect to the Play Store instead.
• No tampering with the design. Surface the card as-is without modifying size, opacity, shape or other properties, add no overlay on top of or around the card, and do not programmatically remove it once shown.
• There is a quota you cannot see. Google enforces a time-bound quota, calling the flow more than once in a short period — its example is less than a month — might not display a dialog, and the specific value is an implementation detail that can change without notice.

On replies, Google's ratings documentation notes that failure to observe its reply guidelines may result in suspension of your application. That is a disproportionate penalty for what teams often treat as a customer-service channel, and worth flagging to whoever is actually writing the replies.

The design consequence of all this is a real one. You cannot filter for happy users before prompting, so the prompt has to be placed where users are genuinely likely to be happy — which is a product decision about timing, not a funnel you can build.

Fixing the cause, then generating a recent run of positive ratings — and on Play there is a second, under-used lever: users can change the rating they already left. That last mechanism is documented and almost nobody builds around it.

Google states that users can only rate an app once, but they can update their rating or review at any time. A one-star rating is not a permanent record. It is a current opinion that its author is free to revise, and under recency weighting a revised rating is a recent rating.

That turns the recovery sequence into something concrete:

Step two is the leverage. You are not asking a stranger for a favour; you are telling someone who took the trouble to complain that their complaint was addressed, through a channel that pushes to their phone. In our experience the response rate on that is far better than any cold prompt, and it converts your worst ratings rather than merely outnumbering them. Our guide to getting app ratings and reviews covers the volume side.

After a completed, successful sequence — and never on launch or as the direct result of a user action, which Apple states explicitly. The rules differ enough between platforms that a single shared implementation usually breaks one of them.

Apple's guidance on requesting App Store reviews sets hard limits: the system displays the review prompt to a user a maximum of three times within a 365-day period, and people can disable requests for reviews from ever appearing on their device. Its timing guidance is to avoid showing a request immediately when a user launches your app, even if it is not the first launch, and to avoid requesting a review as the result of a user action.

That second rule is the one most often broken. A prompt fired when someone taps "rate us" is a review requested as the result of a user action, and it is also the case Google warns against for a different reason — the quota may silently prevent the dialog from appearing at all. For a deliberate user-initiated path, Apple documents a manual deep link instead, of the form https://apps.apple.com/app/idYOURAPPSTOREID?action=write-review, and Google's advice is to redirect to the Play Store.

Both platforms also share a limitation worth designing around: you cannot tell whether it worked. Google's integration documentation states the API does not indicate whether the user reviewed or not, or even whether the review dialog was shown, and that if an error occurs during the flow you should not inform the user or change your app's normal flow.

Yes, and more than most teams assume, because a reply is a notification rather than a comment — Google states users receive both a push notification and an email when you reply. This is the highest-leverage and least-used tool in the whole ratings area.

Google's ratings documentation sets out the mechanics: developers can provide one public response per user review, and after replying the user receives a push and an email notification. Replies must be clear and relevant, respectful, and free of solicitation, and failure to observe the guidelines may result in suspension of your application.

The "no solicitation" rule matters for how you word it. You are not permitted to treat the reply channel as a place to ask for a better rating. What you can do is tell someone that the specific problem they reported has been fixed and in which version — which is factual, relevant and useful, and which gives a reasonable person a reason to look again on their own initiative.

Two operational points make this workable at scale:

• Prioritise by cause, not by recency. Reply first to the reviews describing the thing you just fixed. Those are the people most likely to revise, because their complaint has a resolution attached.
• One response per review. You get a single public reply, so make it specific. A generic acknowledgement spends the only reply you have on that user.

The wider point is that ratings are not a marketing surface you can only observe. On Play they are an editable record with a notification channel attached to it, and that is a genuinely unusual property. Teams that work it systematically recover faster than teams running prompt campaigns, because they are converting existing negatives rather than diluting them.

Treat the rating as a downstream indicator of technical quality and release discipline, because that is what it mostly is. Almost every rating emergency we are called into was preventable at the release that caused it.

The rating deserves this attention because of where it sits. It is one of the most prominent elements on a store listing, so it acts as a multiplier on every visitor you attract — including every visitor you paid for. A rating problem is therefore an acquisition problem with a delay, which is the argument that usually gets it prioritised properly. Our guide to store listing conversion covers where it sits among the other conversion levers.

If your rating has moved and you cannot tell whether it is a regression, an acquisition-mix change or the weighting doing its job, that is usually a quick diagnosis for someone who has seen it before — tell us what the two numbers are doing, or see how we approach the listing as a whole in our ASO work.