Why Your Apple Search Ads ROAS Looks Random: Revenue Reporting Differences (Net vs Gross, Refunds, Trials)

Running Apple Search Ads for an iOS app is “simple” in the way the auction is simple: you bid, you get taps, and eventually you get installs and purchases. The part that often breaks is everything after attribution—especially how your revenue is calculated.

If your ROAS swings wildly week to week (or improves right after you make bid changes but then collapses), the cause is frequently not your bids. It’s a mismatch between what you think you’re measuring (net revenue, refunds included, subscription rules, trial timing) and what’s actually flowing through your app analytics / RevenueCat mapping.

This post is a practical checklist to make sure your Apple Search Ads ROAS is stable enough to act on.

H2: What Apple Search Ads actually attributes (and what it doesn’t)

Apple’s Ads Attribution uses the AdServices attribution token to connect:

• Install → in-app purchase events / subscription events (via your app reporting)

A key implication for indie teams:

• Apple Ads does not give you “revenue per keyword.”
• You only have a chain: install attributed in Apple ≈ install user, then your analytics layer decides what counts as revenue, when it counts it, and which events tie back to that user.

So if your purchase/revenue definitions differ from reality (or from what you’re viewing in dashboards), your ROAS will look chaotic even with perfectly consistent ad delivery.

H2: The 4 most common revenue-reporting mismatches that distort ROAS

1) Gross revenue vs net revenue (refunds, chargebacks, billing retries)

Many “ROAS dashboards” accidentally mix:

• Gross: initial charge amount
• Net: gross minus refunds/chargebacks and adjustments

If your subscription business has trials, cancellations, or occasional refunds, gross-vs-net can swing ROAS in ways that don’t reflect ad quality.

What to check (concrete):

• In your analytics/revenue system (often RevenueCat): confirm whether you’re using net revenue or gross revenue for ROAS calculations.
• Confirm whether refunds/chargebacks are included and how they’re represented (negative events, adjustments, or separate fields).
• If you have billing retries (e.g., failed payment followed by success), verify whether the “revenue recognized” metric includes retries or only successful charges.

Why it hurts Apple Search Ads:

• Apple attribution resolves installs within ~24h.
• Purchases and adjustments can resolve later.
• If you compute ROAS using a metric that changes after the fact (refunds applied later), ROAS becomes a moving target.

2) Subscription trial timing: counting the trial as “revenue” (or not counting eventual conversions)

Trials are a classic ROAS illusion generator.

Common failure modes:

• You count trial start as revenue (usually $0, but it can still be treated as “conversion” in some event schemas).
• You count only initial purchase and ignore the fact that you’re optimizing for future renewals.
• Your dashboard window is too short, so users acquired via ads haven’t had time to convert.

What to check:

• In RevenueCat, identify which event(s) you’re treating as purchase revenue for ROAS:
  • trial start
  • conversion from trial → paid
  • paid renewals
• Ensure your “purchase” definition matches what you actually want to optimize for.

A simple sanity test:

• Pick one app week where nothing significant changed in ads.
• Export or review:
  • number of attributed installs
  • paid conversion count
  • average time-to-paid conversion
• If conversion lags consistently, any ROAS calculation using a short window will look random.

3) “Adjusted revenue” logic drift between sources

Sometimes the number you’re using for ROAS doesn’t come from the same place as the number you consider “real finance revenue.” Examples:

• RevenueCat dashboard shows one number; your finance BI shows another.
• You’re using events (purchase occurrences) but comparing to recognized revenue (which may follow different accounting rules).

What to check:

• Decide which metric is your “single source of truth” for ROAS:
  • net subscriber revenue (after refunds)
  • recognized revenue vs billable revenue
  • renewals included or not
• Align Apple Search Ads ROAS reporting to that exact metric.

Why it hurts decisions:

• If you’re optimizing bids using a metric that excludes renewals or includes adjustments differently, you’ll under- or over-invest in acquisition channels.

4) Attribution token mapping inconsistencies (install attribution ≠ revenue mapping)

Attribution is an install-level signal. Revenue mapping depends on how your app reports the user and how RevenueCat (or your mapping layer) ties the subscription purchase back to the right user.

Even if Apple attribution is correct, you can still end up with:

• purchases not linked to the attributed user
• duplicate linkage
• user identity changes (anonymous → authenticated) breaking the mapping

What to check:

• Verify your RevenueCat integration around identity:
  • anonymous ID handling
  • switching to authenticated user IDs
  • ensuring the same identity is used for attribution mapping
• Confirm that subscription purchases are attributed to the same internal user record that was used for the install attribution.

Practical rule: if your ROAS dashboard shows installs but “near-zero attributed revenue” for a subset of users, identity mapping is usually the culprit.

H2: A stability-first workflow to validate ROAS before changing bids

Here’s a workflow that indie teams can run in a few hours.

Step 1: Freeze ad changes for validation

Don’t change bids/keyword set/countries while you validate reporting. Otherwise you’ll mix two problems.

Step 2: Pick one ROAS window that respects subscription timing

Use a window long enough that you’ve seen the bulk of the revenue you care about.

• For non-subscription purchases: you may only need a shorter window.
• For subscriptions with trials: use a longer window (trial-to-paid lag + at least one renewal cycle if that’s part of your model).

Don’t guess—inspect your time-to-revenue distribution once.

Step 3: Reconcile three numbers for the same date range

For the same date range (or cohorts):

1. Attributed installs from Apple Ads (from your Apple Ads performance export)
2. Attributed purchasers/subscriber events (from your analytics)
3. Revenue used for ROAS (net vs gross, refunds included)

They won’t match perfectly in timestamps, but they should be consistent in direction and magnitude.

Step 4: Check for “metric inversion”

Look for these red flags:

• taps rise, installs stable, but ROAS changes wildly → revenue metric inconsistency
• installs stable, purchases stable, but revenue changes → refunds/adjustments or net vs gross confusion
• installs rise, revenue doesn’t → trial conversion not counted in your ROAS window or mapping issues

H2: How to make ROAS comparisons actually actionable

Use ROAS definitions that don’t change after the fact

If you can, base ROAS on revenue metrics that settle quickly and won’t be frequently revised due to late refunds/adjustments.

If you must use a metric affected by late events, compare using windows where it has largely stabilized.

Separate “acquisition efficiency” from “customer value maturity”

For subscription apps, you usually have two questions:

• Is Apple bringing users who subscribe? (early conversion)
• Is Apple bringing users who keep renewing? (later value)

If you mix these, you’ll make contradictory bid decisions.

A practical approach:

• Track an early ROAS metric (install → paid conversion / early recognized revenue)
• Track a later ROAS metric (install → renewals)
• Make bidding decisions based on the metric that matches your business cycle (and use the other one as a guardrail).

Don’t overreact to one-day ROAS spikes

Even with perfect mapping, revenue events are not evenly distributed day-to-day (refunds, retries, delayed payments). Treat ROAS like a signal with lag, not an instant measurement.

H2: Quick checklist you can run today

• Confirm whether your ROAS revenue metric is net vs gross.
• Confirm refunds/chargebacks are included (and how they appear).
• Confirm which subscription events count toward purchase revenue (trial start vs paid conversion vs renewals).
• Ensure your ROAS window is long enough for trial conversion/renewal timing.
• Verify RevenueCat/user identity mapping doesn’t break the attribution token → user → purchase chain.

Closing takeaway

When Apple Search Ads ROAS looks random, don’t start by blaming bids. Start by validating that your revenue definition (net vs gross, refunds, subscription timing) and your attribution mapping (install → user → purchase) are aligned. Once those match, ROAS becomes stable enough to optimize keywords, bids, and countries without chasing reporting noise.

If you use AdsBuddy to review your Apple Search Ads + revenue data, this is exactly the kind of “looks fine on the surface” issue we try to catch before you spend time tweaking the wrong lever—just keep in mind the most important fix is usually upstream: make sure the revenue metric feeding ROAS is consistent.