Rating Recovery and In-App Review Prompt Programme

Moving a 4.2 average to 4.5 on an app carrying 12,000 lifetime ratings takes about 7,200 new five-star ratings. At the eight to fifteen per cent of displayed prompts that actually produce a rating, that is somewhere near 60,000 prompt displays, and Apple's system shows any single user at most three in a rolling year. We do that calculation before quoting. For a fair number of apps the honest answer is that the average is not moving this quarter and the budget belongs somewhere else. Where the rating is actually decided: At the moment the prompt fires. Not at app open, not after a support ticket closes, not following a discount. We place it after a completed second outcome: the second delivered order, the second confirmed booking, the second successful checkout. It gets specified for engineering as a condition on your own event stream rather than a timer or a session count. On iOS the system decides whether the request is displayed at all, so the placement has to be worth spending a scarce impression on. On Android the In-App Review API carries its own quota and will silently do nothing once you exceed it, which is why an untested Android prompt often looks broken and is simply rationed. Geography and recency: Google Play weights recent ratings and shows a visitor the rating for their own country and device type. A 4.1 global average is frequently a 3.6 in your largest market, and that is the number the buying visitor sees. Apple shows per-storefront ratings. We work and report storefront by storefront, which for most clients is the first time they see where the damage actually sits rather than an average that hides it. Replies, and what they are for: We build a triage taxonomy that separates app defects from operations. For food and local services apps most one-star reviews are about a courier, a shop or a tradesperson, and writing release-note apologies for those trains a product team on the wrong signal. Operations issues route to the operations owner with a weekly count attached. Play replies notify the reviewer and a measurable share of them revise the rating afterwards; we track that revision rate, because reply volume measures effort and revision rate measures effect. Resetting the summary rating: Apple allows a reset with a new version. It is worth using roughly once in the life of an app, only where a specific defect caused a collapse and the fixed build has shipped. We have recommended it twice. If a rating is low because the product disappoints people, a reset buys three months and then returns you to the same number. What we refuse: Purchased or incentivised ratings. Review gating, meaning any flow that asks how someone feels before deciding whether to show them the store prompt: it is against both stores' policies and it is the most common thing we are asked for. Prompts fired immediately after a promotion. Templated replies with the app name substituted in. Public replies that describe a defect we know to be real in terms chosen to mislead the next reader. Who this is not for: Apps under roughly 30,000 monthly active users, where prompt volume cannot outrun a large lifetime rating base within a quarter. Teams whose rating problem is a product problem they have already decided not to fix. What you receive: A prompt placement specification your engineers implement against named events, the review taxonomy, a written response library your team owns and keeps, weekly triage during the engagement, and a monthly read on storefront averages, ratings velocity and rating revision rate.