Time-Window ROAS: Stop Judging Apple Search Ads Too Early (Subscriptions, Trials, and Delayed Revenue)

Apple Search Ads attribution will tell you which installs belong to your ads, but it doesn’t guarantee the revenue shows up quickly. That matters most for subscriptions, free trials, and any offer where the first payment happens days after install. If you’re checking ROAS after 1–2 days and adjusting bids, you can easily train your budget to chase the wrong signal.

This post gives you a repeatable way to evaluate ASA using time windows so you make bid changes based on revenue that has had time to actually occur.

The core problem: attribution ≠ revenue timing

Apple’s ad install attribution token is resolved within ~24 hours, and RevenueCat (or similar tooling) can map that install to purchases/renewals. But purchase/renewal timing is driven by your App Store economics:

• Free trials delay the first paid event.
• Monthly/annual billing means most revenue lands on the billing date, not the install date.
• Refunds, cancellations, and upgrades can change the net picture later.

So “ROAS today” is really “revenue earned within X days of install.” If you don’t control X, ROAS will look noisy or even inverted.

A symptom you can recognize quickly

• Campaigns that target higher-intent users (better match to the app’s value) look “worse” in early ROAS.
• Campaigns that attract more impulsive clicks (lower long-term commitment) look “better” because they convert faster.

Neither is necessarily true—you’re just looking at different parts of the revenue curve.

Fix 1: Evaluate ROAS using cohorts, not rolling totals

Instead of charting ROAS from “all revenue so far,” do this:

1. Pick a cohort grain (daily install date is usually easiest).
2. For each cohort, compute:
   • Spend (CPT auction spend from ASA)
   • Revenue received within a chosen window
3. Compare cohorts on equal footing.

What “time window” should you use?

Choose windows based on your offer mechanics:

• No trial / immediate purchase: evaluate at 7 days and 14 days.
• Trial to paid conversion: evaluate at 14 days (often includes trial end) and 30+ days (covers churn + second events depending on your lifecycle).
• Annual subscriptions: start with 30/60 days for initial conversion indicators, but use longer windows for ROAS decisions because most revenue won’t be “available” early.

The key is consistency. You can start with 14 and 30, then adjust once you know your typical conversion lag.

Fix 2: Track at least two ROAS numbers (early + mature)

Make your decision framework use two ROAS metrics:

• Early ROAS (ER): revenue within the shorter window (e.g., 14 days)
• Mature ROAS (MR): revenue within the longer window (e.g., 30 or 60 days)

Then decide which to use depending on what you’re doing.

Practical rule for bid changes

• If you must act quickly (e.g., stopping a wasteful source), use ER to avoid waiting weeks.
• If you’re scaling budget or making long-term structural changes, use MR.

This prevents the classic mistake: scaling what looks good early but collapses after renewals/churn/refunds show up.

Fix 3: Make sure your purchase events are mapped consistently

RevenueCat can map purchases/renewals to an attribution token, but you still need to confirm you’re counting what you think you’re counting.

Check these items:

• Which revenue event are you using for ROAS?
  • First paid purchase only?
  • First renewal?
  • Net revenue including refunds/chargebacks?
• Are you mixing gross and net?
  • If you change reporting modes between dashboards, ROAS will “move” even if your ads don’t.
• Are upgrades/downgrades included the way you expect?

Why this matters: if one ROAS view includes refunds and another doesn’t, your “mature ROAS” can look worse for campaigns that are actually fine.

Fix 4: Separate “ad install date” from “revenue recognition date”

When you create cohorts, do not rely on a dashboard that aggregates revenue by the day it was received unless it’s explicitly cohort-aware.

You want:

• X-axis: install cohort date (the date the ASA attributed install happened)
• Y-axis metric: revenue received after N days from that cohort

Even if you export data to a spreadsheet, keep the logic consistent:

• cohort = install_date
• window = revenue_date - install_date
• include revenue rows that fall within the chosen window

Fix 5: Use a small “decision matrix” so you don’t overreact

Time-window ROAS reduces noise, but it doesn’t eliminate it. Your ads still face auction variance.

Here’s a simple decision matrix indie teams can use:

Example decision matrix (illustrative)

Evaluate on mature ROAS after enough volume; use early ROAS only for guardrails.

• If ER is bad and MR is also bad: decrease bids / clamp down keywords.
• If ER is good but MR is bad: don’t scale—investigate match quality, landing value, and offer mismatch.
• If ER is bad but MR is good: you likely have delayed conversion (trials/subscription ramp). Scale cautiously with longer windows.
• If both are indeterminate (low data): wait; don’t “fix” with aggressive bid cuts.

What to measure on the ASA side (so cohort ROAS is actionable)

Once your time-window ROAS is reliable, the next question is why it changed. For that, pair ROAS with key funnel metrics from ASA:

• TTR (taps/impressions) to catch query relevance issues
• Install conversion rate (installs/taps) to catch page/value mismatch
• CPT (auction cost) to understand auction loss vs cheap clicks

Remember: Apple’s auction is primarily influenced by keywords, bids, country, and page relevance (including custom product pages). If ROAS improves only in mature windows, it can still be true that TTR/installs were fine—the difference is downstream subscription behavior.

A quick setup checklist you can do this week

1. Pick two windows (e.g., 14d and 30d).
2. Create install cohorts by install date (at least weekly, daily if possible).
3. Compute revenue within each window per cohort using RevenueCat data.
4. Join to ASA spend by the same cohorts (or by install date if you can export).
5. Only change bids based on MR unless you’re preventing obvious waste.
6. Document the window in your experiment notes so you don’t accidentally compare apples to oranges.

Common pitfalls (and how to avoid them)

• Comparing “this week’s spend” to “last month’s revenue.” That breaks cohort logic.
• Using one ROAS number across different subscription states. (Trials vs immediate buyers.)
• Letting refund timing skew early windows. Mature windows generally behave more predictably.

Where AdsBuddy fits (lightly)

If you’re juggling multiple campaigns and ad groups, it can be hard to keep the “time window” discipline consistent. AdsBuddy reads your Apple Search Ads performance alongside your revenue signals and turns that into a short, prioritized list of what to adjust next (you approve every change). The key is that the “what to adjust” should be informed by the right ROAS window—not whatever happens to arrive first.

Closing takeaway

If your app has delayed monetization, ROAS must be evaluated as revenue after X days from install, not “revenue so far.” Once you switch to cohort-based, time-window ROAS (early + mature), you’ll stop punishing subscriptions for doing what subscriptions do—and you’ll stop scaling the clicks that only look good on day one.