ASO Brings the Installs - Refunds Take Back the Revenue

App Store Optimization is usually sold as a visibility play: rank higher, get more downloads, grow. That is true, but it only tells half the story. Downloads are not revenue. Between the moment ASO earns you an install and the moment that install becomes money in your account, there is a leak that almost nobody puts on the ASO dashboard - refunds.

This guide follows the whole funnel from ASO to cash - visibility, installs, paid conversions, then refunds - and shows how to estimate what that last step actually costs you. The example uses recent App Store and Google Play benchmarks so the numbers are grounded, not hypothetical.

The funnel from ASO to revenue

Think of growth as a funnel. ASO works at the top, but the money is decided at the bottom:

• Visibility: your app appears in search and browse (impressions). Keywords, title and subtitle, custom product pages and store listings, and in-app events all push this number.
• Store page visits: users tap through. Screenshots, preview video, rating and reviews convert those visits.
• Installs: the unit ASO is most often measured by.
• Paid conversion: the share of installs that become a paying customer, through a subscription or an in-app purchase.
• Revenue: your gross sales from those paying users.
• Refunds: a slice of those sales gets sent back. This is the stage where money stops being yours.

A few 2026 figures put the funnel in context. The average store-page-to-install conversion is roughly 28-33% on the App Store and 23-28% on Google Play. Subscriptions now make up about 78% of App Store non-game revenue, and because cost-per-install for paid ads has climbed 30-50% since ATT, more teams are leaning on ASO in the first place. That makes the top of the funnel even more important - and the bottom of the funnel even more expensive to ignore. (ASO trends and benchmarks 2026)

Why a bigger ASO win can be smaller than it looks

The reason refunds belong in the ASO conversation is that ASO scales everything downstream - including the bad stuff. Suppose you tighten your metadata and creative and lift installs by 50%. If your refund rate stays flat, the absolute number of refunds grows by roughly 50% too. You did the work to earn that traffic; a meaningful part of the payoff is handed back at the checkout.

If you measure revenue per install using gross sales, you will overstate the return on your ASO. What you actually care about is revenue kept, which is gross sales minus refunds. And refunded users are not gone for good - many come back, buy again, and refund again, so the loss compounds across the customer lifetime.

Estimate the loss: a worked example

Here is a concrete way to model it. Plug in your own numbers; the shape is the point.

Refund loss jumped from $240 to $450 - an extra $210 a month handed back, even though the refund rate never moved. Your ASO work brought in $5,250 more in gross revenue, but only $5,040 more actually stayed. That gap is the refund tax, and it is invisible in a dashboard that only tracks installs and gross sales.

The formula

You can estimate your own monthly refund loss with one line:

Refund loss = Installs x Paid conversion x ARPU x Refund rate

Each input is easy to find:

• Installs: the units per month from App Store Connect or Google Play Console.
• Paid conversion: the share of installs that ever pay - pull this from your paywall or subscription analytics.
• ARPU: average revenue per paying user for the period, or per first purchase.
• Refund rate: refunded transactions divided by paid transactions.

A caveat worth repeating: a flat refund rate hides the real damage. Abuse is concentrated, not evenly spread. A small group of buyers who purchase, use, and refund - or hop from one subscription to another - can account for a disproportionate share of the total. Your average of 4% might really be 2% genuine mistakes plus a cluster of serial refunders, which is precisely why a flat-rate estimate should be treated as a floor, not the full story.

What you can do about the refund side

Both stores give you a way to push back - but only if you respond in time with the right data.

• Apple: a CONSUMPTION_REQUEST arrives through App Store Server Notifications V2. You answer through the Consumption API, sending consumption state, time since purchase, account age, and renewal history.
• Google Play: Real-time Developer Notifications surface voided purchases, and orders.reviewrefund lets you contest chargeback-related refunds on Android.

Responding with evidence lets you contest the abusive slice while leaving genuine customers alone. The tricky part is that the response window is short and notifications arrive at any hour, so most teams automate it. RefundShield applies a consistent policy from your transaction data and logs every decision - no SDK or code changes required, and the policy stays under your control.

The mechanics are covered in more depth elsewhere: the complete App Store refund guide, the Google Play chargeback guide, and what refund abuse actually looks like in practice. For picking a policy, see the docs on protection presets.

ASO decides how much revenue enters the funnel; refunds decide how much leaves. If you track keywords and installs but not refunds, you will keep finding growth that does not quite add up. Add a refund line to your ASO dashboard - it is the difference between an impressive install count and revenue you actually keep.