When I used to consult developers on user acquisition, the very first question I asked was always the same: "What is your ROAS target?"

The range of answers I got told me almost everything I needed to know about the maturity of a studio's UA operation. Some founders would name a number confidently. Most couldn't. Here's how it typically went:

1. "What should it be?" — They genuinely don't know, and they're asking me to set it for them.
2. "It depends." — Technically correct. Also completely useless without knowing what it depends on.
3. "Whatever the algorithm optimizes for." — They've delegated the question entirely to the ad network.
4. "We're hitting X% right now, so we set it to X%." — Circular reasoning dressed up as empiricism.

Most early-stage developers have no idea what the right ROAS target should be — and the ones who think they do are often not much better off.

What is a ROAS payback period? The ROAS payback period is the number of days it takes for a user cohort to return 100% of its acquisition cost in net revenue. It is a foundational metric in any user acquisition financing framework, the threshold that determines how aggressively a studio can deploy marketing spend capital.

The Three Ways Studios Actually Set ROAS Targets (And Why They're Incomplete)

In practice, I see studios land on their ROAS target in one of three ways:

1. Whatever their campaigns have historically returned. They run campaigns, observe D7 or D30 ROAS, and anchor on that as the target. The problem: this confuses outcome with objective. Your historical ROAS reflects the campaigns you've run, the audiences you've targeted, and the bids you've set. It tells you nothing about what you need to hit to sustain the business.
2. Industry benchmarks. Someone read a report saying top-quartile brain puzzle app hit D30 ROAS of 45%, so that becomes the target. Benchmarks are useful for sanity-checking. They are catastrophically misused as substitutes for first-principles analysis. Your cost of capital, your LTV curve shape, your payment cycle, and your cash position are not the same as the benchmark company's.
3. Arbitrary recoup intuition. "We should get our money back in 90 days, so 90-day ROAS of 100%." This is actually closer to correct — at least someone has thought about cash flow — but the number is still pulled from thin air. Why 90 days? Why not 75 or 120?

None of these approaches are wrong in the sense of being irrational. But none of them give you a defensible, data-backed reason for your target. That matters more than you might think: without a principled ROAS target, you cannot know whether you're underinvesting (leaving growth on the table) or overinvesting (burning cash on cohorts that won't return). This is the core problem in mobile app user acquisition financing, the threshold that governs your entire spend strategy is often set by feel.

Here's the process that actually works.

Step 1: Set Your Recoup Period Threshold

This is a finance and policy decision, not a UA team decision. It sits upstream of everything else.

The question to answer: "Given our cash position, our payout cycle, and our cost of capital, what is the maximum number of days we can wait before a cohort fully pays back its acquisition cost?"

A concrete example: "Considering our bank balance and our app's payment cycle, we need to hit 100% ROAS within 120 days for all UA campaigns."

This threshold is typically set by finance and revisited quarterly. The inputs that drive it are:

• Cash balance and runway. A studio with 18 months of runway can afford a longer recoup window than one with 6 months.
• Cash conversion lag by revenue channel. Apple pays out approximately 30–45 days after the end of the fiscal month. Google is approximately 30 days, with regional variance. But for many apps today, the app store is only one of several revenue channels — each with its own lag. Web payments processed directly through Stripe settle in as little as 2 business days for established accounts. External web stores like Xsolla, Appcharge, and Paddle operate on monthly payout cycles. For in-app advertising (IAA), the lags are the longest: AppLovin and Unity Ads posts earnings monthly and processes on a net 30-60 cadence. These lags compound: a user who converts on Day 1 doesn't generate cash in your bank account for up to 10-12 weeks. This is not a trivial delay — it directly affects how long your effective payback period is, regardless of what your ROAS curve shows.
• User purchase cycle. Do users monetize heavily in the first session, or does revenue accrue slowly over months? An IAP-heavy hyper-casual game has a completely different shape than a subscription app.
• Cost of capital. If you're financing UA spend with external capital — whether that's recently raised equity capital, a term loan, or cohort-based financing — the cost of that capital has to factor into your recoup math.
• Growth ambition. A studio that needs to hit aggressive user growth targets to qualify for the next funding round has a different risk tolerance than one optimizing for profit.

The output of Step 1 is a single number: your recoup period, in days, and a corresponding full-recoup ROAS target (almost always 100%, sometimes higher if you're building in a margin buffer).

Step 2: Translate the Recoup Threshold Into an Operational ROAS Target for Your UA Team

Your UA team cannot manage to a 120-day ROAS target in real time. By the time you know whether a cohort hit 120-day ROAS, you've already been spending for four months. You need an early-day proxy — a D7, D14, or D30 ROAS target that is mathematically consistent with hitting your 120-day threshold.

This is where the work gets technical, and it's where most studios fail.

A concrete example of what the output looks like: "Hit D30 ROAS of 40%. If you're hitting it, spend as much as you want. If you're not, immediately scale back."

The math underneath this is predictive LTV (pLTV) modeling: you forecast the full revenue curve of a cohort from early behavioral signals, then invert that curve to find the early-day ROAS that is statistically consistent with hitting your recoup threshold at Day N.

The mechanics:

1. Fit a revenue curve to historical cohort data. The most common functional forms are power law, logarithmic, or Weibull distributions. For many mobile games, a log curve fits well: revenue scales quickly early and then decelerates. The key is fitting this curve separately by channel, creative type, and geo — ROAS curves are not uniform across traffic sources.
2. Estimate the ratio of D30 revenue to D120 revenue. If your fitted curve suggests that, on average, a cohort that generates $1.00 by Day 30 will generate $2.60 by Day 120, then to hit $1.00 at Day 120 (100% ROAS), you need to hit $0.385 at Day 30 — call it 38-40% D30 ROAS.
3. Apply confidence intervals, not point estimates. This is the part studios almost universally skip. Your pLTV model has uncertainty. A cohort at exactly 40% D30 ROAS might ultimately land anywhere between 85% and 115% at D120, depending on the variance in your curve fit. You should be setting your proxy target at the lower confidence bound — the D30 ROAS where you're confident that even the pessimistic scenario clears your threshold. This is how you build downside protection into your UA strategy.
4. Revisit the model quarterly. Your revenue curve shape changes as your app ages, as your UA mix shifts, and as your monetization evolves. A model built on 6-month-old cohort data may be systematically wrong. Cohort performance benchmarks should be refreshed regularly, not treated as static.

The operational rule that falls out of this: spend as much as you can, as long as your UA team is hitting the proxy ROAS target. The moment they miss it, cut spend immediately. This sounds simple. It is extraordinarily difficult to execute because most studios don't have the data infrastructure to monitor proxy ROAS in near-real-time, and because the political pressure to "keep spending" is intense when growth is the top priority.

Step 3: Size Your UA Budget Against Your Recoup Capacity

This is the step most frameworks leave out entirely.

Knowing your ROAS target tells you which cohorts are worth acquiring. It does not tell you how much total capital you can deploy. Those are different questions.

Your maximum deployable UA budget in any given period is constrained by:

• How much cash you can put at risk before the recoup cycle returns it

• The lag between spend and cash-in (your payout cycle, as discussed above)

• The variance in your ROAS curve — if there's meaningful uncertainty, you need a buffer

For most studios, this produces a hard ceiling on organic UA spend that is much lower than their growth ambition. This is precisely the gap that non-dilutive UA funding is designed to fill — not to let studios spend recklessly, but to let studios whose proxy ROAS targets are being hit consistently deploy more capital than their cash position would otherwise allow, without giving up equity.

UA financing is not a substitute for a working ROAS framework. It's an accelerant for studios that already have one. If you don't know your recoup threshold, don't know your pLTV curve, and aren't monitoring proxy ROAS in real time, more capital will not save you. It will just help you fail faster.

If your ROAS math is sound, the constraint is purely capital — and that's a much better problem to have.

The Summary: ROAS Payback Period Framework

Most studios operate with a vague intuition about one of these three pieces. The studios that compound efficiently have all three locked in, revisited regularly, and connected to each other in a coherent model.

The ROAS payback period calculation is not a UA question. It's a capital structure question. Answer it that way, and your UA team will finally have a target that means something.

Frequently Asked Questions

What is a ROAS payback period?

The ROAS payback period is the number of days required for a user acquisition cohort to return 100% of its acquisition cost in net revenue. It is the central metric in any UA financing or user acquisition financing framework — the threshold that determines how aggressively a studio can deploy marketing spend capital without jeopardizing cash flow.

How do you calculate a ROAS payback period?

The calculation has three components: (1) set a recoup period threshold in days, based on your cash position, app store payout cycle, and cost of capital; (2) fit a revenue curve to historical cohort data to find the ratio of early-day ROAS to your target recoup ROAS; (3) set a proxy ROAS target at the lower confidence bound of that curve — not the point estimate — to build downside protection into the model. This is the core of any data-backed mobile marketing payback period framework.

How does non-dilutive UA funding relate to ROAS targets?

Non-dilutive UA funding — also called cohort financing or user acquisition financing — is sized by a financing partner based on whether a studio's early-day ROAS signals are hitting a defensible proxy target. Studios with a working ROAS framework can access more app growth capital, and deploy it faster, because the cohort data provides the underwriting basis. Studios without one are not fundable — and should not be spending at scale regardless.