Net ROAS vs “Apple ROAS”: How Refunds and Retroactive Revenue Break Your Decisions in Apple Search Ads

Indie teams often optimize Apple Search Ads by reacting to ROAS numbers. The problem: Apple’s spend is fixed, but your recognized revenue can move around after the fact—especially with subscriptions. If you don’t account for refunds and other retroactive adjustments, you end up making decisions that fight the wrong metric.

This post is about building a decision-friendly view of ROAS—net of refunds and adjustments—and using it to diagnose whether your Apple Search Ads traffic is actually low-quality or you’re just seeing reporting artifacts.

Why “Apple ROAS” can lie for a few days

Apple Search Ads reports spend by install attribution. But your revenue pipeline (often RevenueCat → App Store Server API/StoreKit → your dashboards) may apply changes later:

• Refunds: A subscription can refund, and you may see revenue go negative or drop after the initial purchase.
• Billing retries / dunning: Some failed payments lead to later successful payments (or cancellations), shifting recognized revenue.
• Plan changes and proration: Upgrades/downgrades can generate retroactive adjustments.
• Entitlement corrections: If you rely on webhook/event mapping, late-arriving events can change what you count.

None of this changes the user journey in the moment—your ads still drove the install. But it can change the revenue you attribute to that cohort, which makes your ROAS look unstable.

The symptom pattern

If you see any of these, assume you’re not looking at “real” monetization quality yet:

• ROAS looks great right after launch, then drops after a few days.
• ROAS looks terrible early, then improves later.
• Different campaigns/ad groups fluctuate wildly day to day even when taps and install conversion look steady.
• Your CPI is consistent, but “CPA by ROAS” swings.

Step 1: Create two ROAS views—gross and net

You want to separate what happened at install time from what the user ultimately paid (minus corrections).

At minimum, compute:

1. Gross ROAS: revenue you recognize without subtracting refunds/adjustments.
2. Net ROAS: revenue adjusted for refunds/chargebacks/negative events.

If you use RevenueCat, you typically can derive this by filtering to subscription transactions and subtracting refund outcomes (exact implementation depends on how you export events).

Rule of thumb: For decision-making, base “cut/scale” on net ROAS, but use “gross ROAS” to debug quickly.

Step 2: Build a cohort table by install date (not report date)

Most teams accidentally compare apples to oranges by using report timestamps. Do this instead:

• Bucket installs by install date (or attribution date).
• For each bucket, compute revenue over multiple windows (examples: day 1, day 3, day 7, day 14).
• Track refunds/negative adjustments in the same windows.

This lets you answer:

• “Are my users paying later?” vs
• “Are my users paying then getting refunded?”

Even if you don’t have perfect granularity, this cohort approach will reveal the direction of change.

Step 3: Decide what you’re optimizing for (quality vs speed)

Once refunds enter the picture, “best” optimization depends on your business goal.

If you optimize for speed (gross ROAS)

You’ll make earlier decisions and potentially scale campaigns that later refund.

Use gross ROAS only to:

• Find which keywords/taps are producing installations that lead to initial monetization.
• Iterate quickly on discovery (keywords, bids) without waiting two weeks.

If you optimize for quality (net ROAS)

You’ll make fewer, more reliable scaling decisions.

Use net ROAS to:

• Approve or reject expansion of ad groups that are converting into durable subscriptions.
• Cut bids/campaign spend that is attracting users who don’t stick.

Step 4: Connect ROAS instability back to the funnel

Now use ASA and funnel metrics to figure out where the problem is:

A) Tap quality issue (top of funnel)

• TTR low (taps/impressions) or CPT is spiky.
• Ad group keywords look irrelevant.
• Fix: keyword relevance, match type strategy, negative keywords.

B) Install conversion issue (middle)

• TTR decent, but installs/taps (conversion rate) is low.
• Fix: product page readiness (screenshots, pricing/plan clarity, availability).

C) Monetization quality issue (bottom)

• Install conversion is fine.
• Gross ROAS seems okay initially, but net ROAS drops due to refunds/adjustments.
• Fix: subscription offer clarity, paywall expectations, onboarding, and any in-app mismatches that trigger refund behavior.

The important move: don’t treat refund-driven net ROAS drops as an ASA delivery problem automatically. If taps and installs are stable but refunds surge, your traffic may be fine and your expectation management is off.

Step 5: Add a “refund rate” lens (even if approximate)

You may not have a clean refund metric early, but you can still build an approximate indicator:

• For each cohort/ad group, compute:
  • Gross subscriber revenue (or initial purchase revenue)
  • minus refund-adjusted revenue
• Express it as a percentage of gross.

If two ad groups have similar taps→installs, but one has a much larger drop from gross to net, that’s your smoking gun.

Step 6: Make your decision rules “net-aware”

Here’s a practical approach that avoids knee-jerk changes.

For cutting spend

Only cut bids (max CPT) or reduce budgets when both conditions are true:

• Gross ROAS underperforms (so you likely have a real monetization problem), and
• Net ROAS remains bad after at least one “stabilization window” (choose something like day 7–day 14 based on your refund cadence).

For scaling spend

Scale only when:

• Gross ROAS is strong and
• net ROAS doesn’t show early refund drag.

If net ROAS stabilizes slower than your team wants to wait, do smaller step increases and re-check cohorts rather than scaling aggressively.

Step 7: Sanity-check attribution mapping (but don’t overreact)

Refunds can still be the real cause, but there’s one attribution-adjacent pitfall worth mentioning.

• Revenue attribution should map installs → entitlement/purchase events via the AdServices token.
• If your mapping pipeline delays events, net revenue for older cohorts might “catch up,” making gross/net differences look inconsistent.

Use a quick check:

• Pick a single ad group.
• Compare gross vs net across multiple cohort dates.
• If differences are consistent and directional, it’s likely real refunds/adjustments.
• If differences flip randomly with no trend, look for event mapping lag or duplicate counting.

What to change once you find the root cause

Refund-adjusted ROAS issues usually resolve with changes at the right layer.

• If gross is fine but net drops: focus on subscription expectation alignment (offer clarity, onboarding promises vs reality, paywall timing).
• If gross is also weak: revisit keyword relevance, match type usage, and product page conversion.
• If net stabilizes later: don’t cut too early—use cohort windows for decisions.

(And yes—if you’re already tracking your funnel and ASA metrics daily, this becomes a lot less stressful: you’re not guessing whether the ads are “bad” when the truth is that the revenue is still moving.)

If you want a second set of eyes that turns your Apple Search Ads + revenue signals into a short prioritized change list, you can run that through AdsBuddy—just remember: you stay in control of approving every change.

Closing takeaway

Apple Search Ads can’t “know” how refunds and subscription adjustments will land in your revenue pipeline. If you optimize directly off raw ROAS without distinguishing gross vs net, you’ll sometimes cut the right keywords too early—or scale the wrong ones because early revenue temporarily looks healthy.

Build a cohort-based net ROAS view, compare gross→net movement, and then decide whether your next action should target bids/keywords/product page or subscription expectation and onboarding.