A campaign report says 140% ROAS. Finance says the acquired users have not covered their acquisition cost. Both statements can be correct. The first may divide attributed purchase value by media spend; the second may use store proceeds after refunds and the cost of serving those users.
Mobile app ROAS is the revenue or conversion value credited to an acquisition activity, divided by its advertising cost, over a stated window. A useful report names the value source, deductions, attribution rule, acquisition population and maturity. A 100% revenue ROAS means that value equals media spend under that definition. It does not establish profit, cash payback or incremental revenue.
For an app team approving the next budget, the immediate job is to reconstruct the ratio. Start with what the campaign received as value, follow the transactions into the store or monetization ledger, and keep the resulting business return separate from the bidding metric.
Three return calculations answer different questions
The same acquisition cohort can support several return measures. Label them by the numerator rather than presenting every number as interchangeable ROAS.
Measure Numerator Denominator Decision it can inform --- --- --- --- Platform-native ROAS Conversion value credited under the platform's settings Media cost in that report Campaign operation within those definitions Proceeds return on media spend Reconciled developer proceeds associated with the defined cohort and horizon Media cost for acquiring that cohort Acquisition payback before other variable costs Contribution return on media spend Defined proceeds or revenue less agreed variable delivery costs, before acquisition cost The same media cost Whether observed contribution covers media at that horizon
The latter two labels are business calculations used in this guide, not universal platform columns. Finance must approve their definitions. If you include creative production, agency fees or measurement costs in the denominator, rename it as an acquisition-cost return and keep a bridge back to media-only reporting.
This separation prevents a common circular calculation: subtracting media from contribution and then dividing by media while comparing the result with a pre-acquisition contribution threshold. Write down whether contribution is measured before or after acquisition cost every time.
For per-user value curves and forecasts, use the mobile app LTV calculation guide. Here the task is narrower: decide whether an existing return claim is comparable and usable for a spend decision.
Trace the value before debating the target
Ask the person producing the report to trace one non-sensitive test transaction through the full measurement path. What amount was sent at purchase? Which currency accompanied it? Was the amount customer price, price excluding tax, estimated proceeds or an assigned proxy? What happened when a refund or renewal occurred?
A purchase count multiplied by a fixed assumed value can produce a conversion-value ratio. It should not be presented as observed purchase revenue without that qualification. Likewise, a forecast of subscriber value is not cash collected because a reporting tool labels it revenue.
The minimum value record should contain:
event name and originating app or backend;
transaction or other deduplication reference, with private identifiers protected;
value and currency definition;
treatment of tax, store fee, refund and reversal;
source report and extraction date;
attribution and reporting window;
whether the amount is observed, estimated, modeled or forecast.
Google's recommended-event documentation distinguishes purchase, refund and app ad-impression events, and directs implementers to their prescribed parameters (GA4 recommended events). The refund reference includes transaction identification and value/currency fields (GA4 event reference). That documentation describes the event contract; it does not prove your implementation sends it correctly or that every connected destination revises historical bidding value.
Test the actual path. Avoid solving a reporting discrepancy by immediately changing the production event amount. That could alter optimization as well as the chart.
Store sales, proceeds and payments need separate rows
Apple defines Sales as the amount billed to customers and provides separate refunded-sales and refunded-proceeds measures. Its analytics documentation also distinguishes estimated proceeds from the final payout (App Store Connect Sales). A report built from customer billings therefore cannot be compared directly with a developer-proceeds target.
Apple's Payments and Financial Reports documentation defines proceeds after applicable taxes and commission, and explains that estimates and actual payment may differ, including through exchange rates and withholding tax (Apple payments and proceeds). Cash arrival is another boundary again. Do not assign the entire bank payment to the campaign that happened to run during the payment month.
Google Play provides estimated-sales and earnings exports with distinct transaction, fee, tax, adjustment and refund information. Its current documentation also warns that fee-description values are changing and automated workflows may need updates (Google Play monthly reports). A parser that silently drops an unfamiliar fee line can make reported proceeds look better without any improvement in acquisition.
Do not repair this with a universal store deduction percentage. Google Play explicitly describes different service-fee circumstances (Google Play service fees). Use the terms and transaction treatment applicable to the app, product and territory, with finance review where needed.
For mixed-monetization apps, check the ad-revenue layer separately. AdMob's LTV definition combines purchase, subscription and advertising value, and its IAP revenue is already after store revenue share (AdMob LTV definitions). Subtracting store share again from that field would understate value. Never add an aggregate revenue field to its component purchase and ad fields without checking for overlap.
A fictional gross-to-contribution reconciliation
The following numbers are invented to demonstrate the method. They are not benchmarks, store fee rates, Sharply Labs results or an accounting recommendation.
Suppose a fully observed acquisition cohort cost $20,000 in media. For this example only, the campaign's attributed purchase-value total matches $28,000 of customer billings for precisely that cohort through D30. That alignment is an explicit assumption; a real team must prove it before subtracting costs from the total.
The hypothetical deductions below are distinct, non-overlapping adjustments under the team's finance definition.
Bridge row Amount Return relative to $20,000 media --- --- --- Credited customer billings through D30 $28,000 140% Less refunds not already removed −$2,000 Less applicable taxes and store charges not already removed −$6,000 Reconciled proceeds $20,000 100% Less agreed variable delivery and support costs −$4,000 Contribution before acquisition cost $16,000 80% Less media acquisition cost −$20,000 Contribution after media −$4,000
The 140% report has not demonstrated profitability. At the stated horizon, this fictional cohort has returned its media cost in proceeds but leaves a $4,000 shortfall after the defined variable delivery costs. Fixed overhead, creative, agency costs and other acquisition expenses are excluded, so this is not a company profit statement either.
The correct response depends on the authorized payback policy. An app with credible later contribution and sufficient funding might accept a D30 shortfall. Another may need earlier recovery. Neither decision follows from the 140% ratio alone.
If the campaign value and ledger population do not align, stop the arithmetic at the mismatch. Do not subtract all-app refunds from campaign-attributed revenue or allocate every fee by whichever ratio makes the numbers reconcile. Show the unmatched amount and the allocation assumption separately.
What is a good mobile app ROAS?
A good ROAS is one that meets the app's approved economic and cash constraints under a consistent value definition and horizon. There is no single ratio that establishes this across subscription, purchase and ad-supported apps.
A useful conditional calculation is:
Required revenue ROAS = (1 + other acquisition cost / media spend + desired surplus / media spend) / contribution fraction
Here, the contribution fraction is the share of the exact revenue numerator remaining after the agreed deductions and variable delivery costs, before acquisition. The surplus is a specified amount above those acquisition costs. All terms must use the same cohort and value horizon. This is a planning identity, not a forecast or bidding recommendation.
For a simpler illustration, if half of the chosen revenue measure remains as pre-acquisition contribution, covering media alone requires 200% revenue ROAS. If the chosen numerator is already contribution before media, the media-only coverage boundary is 100%. These statements use different numerators; they do not disagree.
The fraction cannot safely be borrowed from the company average when campaign mix changes the subscription plan, purchase type, geography or cost of serving users. An app with substantial inference, content-licensing or fulfillment cost needs those costs assigned under an explicit policy. A ratio calculated before them cannot authorize spend as if they did not exist.
Keep the cash constraint alongside the economic calculation. Upfront annual billings, later service obligations and store settlement schedules create different timing questions. Finance should determine the accounting and cash treatment; the UA report should expose the timing rather than settle it by label.
Align the acquisition population and the clock
Three clocks commonly get mixed: the date advertising ran, the date the user entered the cohort, and the date revenue or a refund was recorded. A fourth appears when money settles. Naming the month does not align these clocks.
A practical comparison specifies the cohort entry rule, acquisition period, value horizon, report timezone, attribution window and extraction timestamp. It also states whether re-engagement and reacquisition are included. D7 for a completed acquisition cohort is not equivalent to seven calendar days of revenue divided by the last seven days of spend.
Google's initial App campaign tROAS guidance recommends comparing a campaign with the same app ID, biddable event, locations and languages, and accounting for conversion lag (Google App campaign initial tROAS guidance). That supports a source-native campaign comparison. It does not make a finance D30 cohort calculation identical to the platform's conversion-window report.
Use the mobile app cohort analysis guide for entry rules and equal-maturity comparisons. In this report, present a small reconciliation: campaign credited value, matched cohort value, unmatched value and reasons for the gap. Leave unknown rows unknown rather than converting them to zero.
Do not sum credited revenue from multiple advertising platforms and call it unique acquired revenue. Establish a deduplicated business population or retain separate source-native views. Attribution is a crediting rule; proving incremental revenue requires an appropriate causal design.
The ROAS target and the observed business return are separate controls
A tROAS setting describes what the bidding system is being asked to seek from the values it receives. It is not a guarantee, and it does not automatically encode the company's full cost structure.
Google's App campaign bidding documentation describes dynamic revenue values for eligible in-app-event sources and expresses the target relative to spend over the event window (Google App campaign bidding). Before changing a target, verify the actual source, supported integration and value definition in the account. Do not assume every analytics or MMP field can be used unchanged for every campaign.
A finance-adjusted return can be useful outside the platform without being a supported bidding input. Keep both views until the team has validated what a proposed feed change would do. Changing values and changing the target simultaneously can make a before-and-after comparison difficult to interpret.
The Firebase versus MMP comparison covers feed ownership and procurement. The Google App campaign goals guide covers the earlier signal-selection decision. This article does not prescribe a new conversion event or campaign migration.
Ask an agency for the reconciliation, not another screenshot
Before accepting a return report, request a compact acceptance packet:
Metric definition. Exact numerator, denominator, horizon and whether the number is observed or predicted.
Lineage sample. A redacted trace from event to transaction to business ledger, including a renewal and refund where relevant.
Value bridge. Tax, fee, adjustment and variable-cost treatment, with already-net fields identified.
Population bridge. Included users, reacquisition rules, unmatched transactions and attribution limitations.
Close status. What can still change, who approves it and when the next comparable cohort matures.
Decision boundary. The return policy that permits maintain, constrain or test, including the cash constraint.
The packet should be reproducible from named exports. If it relies on an unexplained spreadsheet adjustment, ask for its owner and rule. If a provider cannot expose user-level detail because of privacy or aggregation, use the available aggregate seam and state the resulting limitation. Do not request unnecessary personal data to make the workbook look complete.
A finance owner approves the value definition; a measurement owner validates lineage; the media owner applies the approved operational decision. These are responsibilities to assign, not a claim that every company needs three separate employees.
When to hold, repair or test
Hold the comparison when cohorts have unequal maturity, a material refund period remains unresolved, the reporting currency changed or the population cannot be reconciled. Waiting for a defined evidence point is different from assuming performance will recover.
Repair the report when values are duplicated, a fee is deducted twice, transaction states are dropped or an estimate is labeled final. Preserve the original export and show the correction as a restatement. Do not rewrite historical definitions without a visible version note.
Test a media or product change when the return definition is stable and the economic constraint is established. Name the hypothesis, bounded spend exposure, observation horizon and rollback owner before launch. Better reporting does not itself establish that a bid, creative or paywall change will improve return.
The mobile app marketing dashboard guide places these decisions in a recurring close and action process. ROAS remains one input alongside retention, cash, acquisition quality and the uncertainty in later value.
Bring the return claim and its evidence
For established app teams evaluating an agency report or deciding whether active paid acquisition can support more spend, Sharply Labs' mobile app growth practice and performance marketing services provide the relevant starting point.
Request a scoped ROAS reconciliation review with a redacted spend-and-value export, the current attribution and cohort definitions, and the finance-approved treatment of fees, refunds and variable costs. The conversation examines which return claim the evidence supports, what remains unmatched and what should be validated next. The initial conversation produces a prioritized decision agenda with evidence gaps and ownership questions. Any deeper reconciliation, account access or test plan is scoped separately.
This does not promise profit, cash payback, lower CPI or CPA, higher ROAS, incremental revenue or scale. Private account settings, contracts and accounting judgments still need their respective owners. The useful outcome is a report that makes the next spend decision explicit and reviewable.