Blended ARPU as the Ceiling for How Aggressive Your CPI Can Be

If you run Apple Search Ads as an indie (or a small studio), it’s easy to get trapped in a loop: “CPI goes up, ROAS looks fine, let’s bid higher,” until it suddenly isn’t. A cleaner approach is to anchor your bid aggressiveness to a financial ceiling you can defend: blended ARPU (average revenue per user across your whole product mix and customer lifetime window).

The core idea: your CPI can’t be sustainably higher than the revenue you expect to earn per new user, and ARPU gives you a usable ceiling. Then you adjust for timing (payback window) and for how effectively ad-attributed installs convert into revenue.

Why ARPU is the right ceiling (and why “ROAS at any cost” breaks)

Apple Search Ads optimizes through auctions around cost-per-tap (CPT) and your bids, while your end goal is revenue. Apple does not give you “revenue per keyword” directly; you’ll usually connect installs to purchases/subscriptions via attribution (Apple AdServices token) and tools like RevenueCat to map revenue to installs.

Because of that chain, you need a number on the revenue side that translates to a defensible bid limit.

What “blended ARPU” should mean for you

Blended ARPU is your average revenue per user across the user population you actually get—including differences in plan types (if relevant), churn behavior, and any mix of free-to-paid conversions.

You should compute it for the same horizon you care about, for example:

Payback window ARPU: expected revenue per user within 30 days, 60 days, etc.
Longer-horizon ARPU: revenue per user over the full expected lifetime window you trust.

The reason this matters: if you base bids on lifetime ARPU but your business needs cashflow back within 30–45 days, you’ll overbid.

The ceiling formula: ARPU → max CPI

Once you have blended ARPU for the time window that matches your decision, the math becomes straightforward.

Basic ceiling

Max sustainable CPI (ceiling) ≈ Payback-window ARPU

If a user is expected to generate $5 in revenue within your payback window, paying $6 per install will, by definition, lose money on that window.

Practical adjustment: margin and risk buffers

In real life you’ll want to be conservative because:

not every install becomes a payer
revenue mapping can lag (attribution resolves within ~24h, but subscription events and measurement can be noisy early)
Apple Search Ads includes users from different intent levels depending on placement and keyword match

So you typically use:

Max CPI ≈ (ARPU × expected gross margin) × safety factor

Even if you don’t do margin-by-line-item accounting, a simple safety factor (a smaller fraction of ARPU) prevents “close enough” bids from slowly wrecking you.

The conversion-gap version (often more useful)

ARPU is an outcome. What bids influence is the path: impressions → taps → installs → revenue.

So you can also express the ceiling as:

Max CPI ≈ ARPU × (install→revenue conversion rate)

But since ARPU already assumes an install→revenue outcome across your current mix, you can skip this double-counting if your ARPU is already computed from actual cohorts.

How to compute ARPU that matches Apple Search Ads outcomes

To avoid misleading yourself, compute ARPU in a way that aligns with how Apple Ads attribution works.

Step 1: pick a payback window

If you’re deciding whether to increase bids today, a window like 30 or 45 days is usually more actionable than “lifetime,” because your current cohort behavior is closer to what you’ll see next.

Step 2: compute ARPU from cohorts that include ad-attributed users

If you already use RevenueCat or an equivalent layer, you can filter revenue by attribution source (ad-driven installs) and calculate:

total revenue from those installs within the window
divided by total installs (or total users) for that same cohort

This produces blended ARPU for your ASA-driven install population, not your entire organic user base.

Step 3: keep it “blended,” not “perfectly segmented”

Your goal is not to predict every keyword’s exact future revenue. Your goal is to stop overbidding by anchoring to a stable ceiling.

So blend where it makes sense:

blended across campaigns for the same app and subscription offer
blended across ad-attributed installs in the relevant country/region

If you strongly separate offers or pricing by region, compute ARPU separately per region (because Apple Search Ads is structured by country/region at the campaign level).

Using the ceiling to control CPI bids (the bidding workflow)

Here’s a workflow that keeps you in control without turning bidding into guesswork.

1) Measure your current CPI and revenue outcome

For the same cohort window as your ARPU, track:

installs
spend
CPI (spend ÷ installs)
revenue attributed to those installs within the window
ROAS (revenue ÷ spend)

Remember: Apple’s install attribution is resolved via AdServices and linked through your mapping layer. Treat early numbers carefully and rely on the window you chose.

2) Compute your CPI ceiling

Let:

ARPU t = your blended ARPU in the payback window
safety factor = 0.7–0.9 (choose a level that matches your risk tolerance)

Then:

CPI ceiling = ARPU t × safety factor

(If you explicitly track gross margin, you can incorporate it too.)

3) Compare actual CPI to the ceiling

If CPI is well below ceiling, you may have room to bid more aggressively.
If CPI is near ceiling, be cautious—any shift in intent mix (or seasonality) can flip performance.
If CPI is above ceiling, do not scale bids. Fix targeting/intent first.

4) Adjust bids in small steps, based on the biggest lever you have

Since Apple Search Ads auctions are CPT-based and you bid caps for keywords, you’ll typically adjust:

keyword bids (exact and broad on Search Results)
or restructure so Search Match runs in its own ad group when you want discovery without contaminating your “known intent” set

A good rule of thumb: raise bids only when spend efficiency is consistently under your ceiling for at least one full attribution window, not after a single day.

Why match type changes “what your CPI really buys”

On Search Results keywords, exact and broad differ in intent precision.

Exact generally brings higher intent but less volume.
Broad can expand reach but may include lower-intent queries.
Search Match (Discovery/Search Match) uses Apple’s automatic matching to find users; it can be great for incremental volume, but it will change your install mix.

All of these affect the average “revenue per install,” which is what ARPU is capturing.

So if you expand using broad/Search Match and your CPI drifts upward, you might still look “okay” on CPA until the ARPU ceiling gets violated. That’s exactly why CPI should be governed by revenue-derived ceilings.

Don’t forget placement and country/region constraints

Even though many indie budgets start on Search Results, placements can behave differently:

Search Results is usually the most directly intent-driven.
Today and Search tab can introduce discovery-like audiences.
Product Pages (browse) can create additional incremental installs but may dilute intent.

Also, because one campaign targets one country/region, your blended ARPU ceiling should match that same scope. Don’t apply a US ARPU ceiling to a different region campaign.

Quick checklist: “Is my CPI ceiling logic actually working?”

I computed ARPU for the same payback window I’m using to judge bids.
My ARPU is for ad-attributed installs, not generic app users.
I included blended revenue across my actual offer/payment mix.
I’m comparing current CPI to the ceiling over a window large enough to smooth noise.
My bid increases are paired with monitoring install→revenue outcome, not just CPT/TTR.
I didn’t ignore match type changes (exact/broad/Search Match) that alter user mix.

Closing takeaway

Treat blended ARPU as your financial ceiling and CPI as the bid lever you must not break. When you cap CPI (instead of chasing ROAS moment-to-moment), you gain a stable way to decide when it’s safe to be more aggressive—and when it’s time to fix targeting.

If you want this operationalized daily, tools like AdsBuddy can read your ASA performance plus your revenue mapping and hand you a prioritized set of changes—so you’re not manually deriving ceilings and hunting for the one lever that’s actually moving the numbers.