Your app's ROAS still counts the purchases Apple and Google refunded, so bid on net ROAS instead

Ad dashboards book an in-app purchase the moment it happens, and most of them never take it back. When Apple or Google later refunds that purchase, the money leaves your payout but stays in the campaign's revenue, so ROAS keeps crediting the ad that sold it. Net ROAS, revenue after refunds divided by ad spend, is the number that tells you which campaigns actually paid. You have to build it yourself, because the refund signal lands on your server, not in the ad network.

Why ROAS overstates revenue when refunds are left out

ROAS divides attributed revenue by ad spend. The revenue side is usually written once, at purchase, by an SDK on the device or a conversion import from the store. A refund is a later event that happens off the device, between the customer and Apple or Google. Unless something carries it back to the same campaign, the purchase keeps counting.

That would be harmless if refunds were rare and evenly spread. They usually aren't. A creative that promises more than the app delivers, an offer shown to the wrong audience, or a traffic source full of stolen cards will pull refunds toward specific campaigns. Gross ROAS hides exactly that difference.

What is net ROAS?

Net ROAS is the same ratio with refunds taken out of the top line: revenue attributed to a campaign, minus the refunds on those same purchases, divided by what the campaign cost. Some teams also take out store commission and tax. Whatever else you subtract, refunds are the part that changes which campaign wins.

Where refunds go missing between the store and your ad dashboard

Firebase logs Google Play refunds, not App Store refunds

Google's list of automatically collected events includes in_app_purchase, which fires when a user completes an in-app purchase, including an initial subscription, processed by the Apple App Store or Google Play. Its refund counterpart, app_store_refund, fires when an in-app purchase is refunded by Google Play, and Google marks it Android only. Neither app_store_refund nor the automatic subscription events are exported to BigQuery.

The same page says Analytics doesn't automatically measure paid-app purchase revenue and refunds, and that reported revenue may differ from the Google Play Developer Console. On iOS, nothing automatic subtracts an App Store refund from a purchase Firebase already logged.

Google Ads books the purchase value as the conversion value

For Android apps that use in-app billing, Google Ads can track in-app purchases by people who clicked your ad, with no code in the app. Google says the value of the purchase is automatically reported as the conversion value. For subscriptions, only the first purchase is recorded as a conversion, and only the first payment value is recorded. The help article doesn't mention refunds.

Google Ads does have a correction tool. Conversion adjustments let you restate a conversion's value without changing the count, or retract it, which sets its value to 0.00 and feeds both CPA and ROAS bid strategies. Google says online conversions can be adjusted only if you used a transaction ID, and a retracted conversion can't be adjusted again. That page doesn't mention app conversions, so confirm your conversion setup supports adjustments before you build on them.

Apple's ad postbacks close before many refunds arrive

AdAttributionKit has three conversion windows that start when the user first launches the app: days 0 to 2, days 3 to 7, and days 8 to 35. The app can update its conversion value until a window ends. Apple then sends the postback after a random delay, 24 to 48 hours for the first and 24 to 144 hours for the second and third. If the app locks a value early, the system ignores further updates in that window.

The fine-grained conversion value only appears in the first postback. Later postbacks carry a coarse value at best. A purchase on day 1 that Apple refunds on day 10 was reported in a postback that can't change anymore.

When app refunds arrive, and who decides them

Refunds don't land on one schedule. Some arrive within hours of the purchase and some months later, which is why a cohort's ROAS keeps drifting down after the campaign report looked final.

What a refund-blind ROAS costs in money

Take two campaigns with the same budget. The numbers below are an illustration, not a benchmark.

Gross ROAS tells you to move money into A. Net ROAS says B kept more of every dollar. If your bidding runs on gross value, the algorithm keeps finding more of A's buyers, because nothing ever tells it they asked for their money back.

Ad spend is only the first bill. A refunded customer also leaves these behind:

• Payouts. Affiliate, creator and influencer deals paid per purchase usually pay on the sale, not on the sale minus refunds, unless the contract says otherwise.
• Compute, API calls and storage. A refunded user ran your servers, your paid third-party APIs and your storage until access was revoked. Those invoices don't get refunded.
• Chargeback costs. Since August 3 2026, Google shifts the chargeback purchase price plus bank fees onto the developer, so a dispute-heavy Android traffic source costs more than the revenue it loses.
• Worse targeting. Value-based bidding trained on refunded purchases goes looking for more people like the ones who were paid back.

Is a high refund rate on one campaign fraud or a broken promise?

Often it's the promise. Apple's revocationReason tells you which side a refund fell on. A 0 means the App Store refunded the transaction for other reasons, for example an accidental purchase. A 1 means it refunded due to an actual or perceived issue within your app. A cluster of 1s from one campaign usually points at the ad creative or the onboarding it leads into. A cluster of unauthorized-charge reports on Google Play points at the traffic source.

How to build net ROAS for an app

You don't need a new tool to start. You need a few joins your data probably doesn't make yet.

• Keep the campaign on the user. Store the attribution result next to your own user ID at install, so any later transaction can be traced to a campaign.
• Keep the transaction on the user. Set an appAccountToken on iOS purchases and an obfuscated account ID on Google Play purchases, so every store event maps to your user without guessing.
• Listen for refunds on the server. Handle Apple's REFUND notification from App Store Server Notifications V2 and Google Play's voided purchase notifications. Poll the Voided Purchases API as a backstop, since it only returns voids from the past 30 days.
• Report gross and net side by side, by purchase cohort. Count each refund against the campaign and purchase date that earned it, not the day the refund showed up.
• Send corrections where a platform accepts them. If your Google Ads conversions carry a transaction ID, restate or retract the refunded ones. Where a platform can't take corrections, move its budget on net numbers instead.
• Answer the two evidence requests on time. RefundHalt answers Apple's CONSUMPTION_REQUEST inside the 12-hour window and Google Play's chargeback review inside 24 hours, so the refunds you can contest get your side of the story.

Should refunds count on the purchase date or the refund date?

For campaign decisions, the purchase date. A refund is a fact about a purchase, and the purchase belongs to a campaign. Finance books it on the refund date, which is why your ROAS report and your payout won't agree on any given day. Keep both views and label them.

When is a cohort's net ROAS final?

It settles in steps. Google's self-service refund window closes after 48 hours, Apple tells customers to expect an update on a refund request in 24 to 48 hours, and a Google Play unauthorized-charge report can come within 120 days of the transaction. Treat early numbers as provisional and recheck the same cohort later.