App monetization without ads: what actually pays, and what it costs your users

Every monetization decision is the same trade: revenue per user against experience per user. The reason "just add ads" feels bad is not that ads pay badly — it is that the payment comes out of the product.

Here is the honest version of the menu.

Advertising

Interstitials and rewarded video are the highest-revenue ad formats and the most expensive in retention. Banner ads cost less experience and pay accordingly. Across all of them, revenue depends on fill rate and eCPM, both of which are someone else's numbers, and both of which move without warning. An ad blocker or an OS privacy change can take a third of it overnight.

Pays: highly variable. Costs: attention, session length, and a permanent negotiation between your designers and your revenue.

Subscriptions

The best revenue per user of anything on this list, and the hardest to earn. It works when your app is a habit and the alternative is worse. For a utility, a game, or anything used weekly rather than daily, the conversion rate usually does not clear the support burden.

Pays: a lot, from very few users. Costs: you now run a retention business.

In-app purchases

Excellent for games with a progression loop. Close to useless for a VPN, a photo tool, or a TV app. IAP does not generalise — the mechanic has to already be in the product.

Bandwidth sharing

The user opts in, and a small, capped share of bandwidth their device is not using gets relayed for public web data collection. No ad renders. No paywall appears. The session is exactly the session they had before.

That last sentence is the whole pitch, and it is also the thing you should be most skeptical about — so here is what has to be true for it to hold.

The caps have to be real, and not yours to change

If a monetization SDK lets you turn its limits up, then its limits are a suggestion and its behaviour on a user's phone is your liability. The Cash Raven caps — a bandwidth ceiling, daily and monthly data caps (tighter on mobile data than WiFi), a CPU and RAM budget, and a port and network denylist — are enforced inside the compiled Rust core, and there is no API to loosen them. The relay enforces the same limits from its side.

It must not be "idle-only", and it must not merely throttle

"Only runs when idle" sounds reassuring and is usually a lie, because deciding what "idle" means on a phone is a hard problem that most implementations solve by ignoring it. The honest design is the other one: run continuously inside hard limits as a background task that yields to the app it lives in, and when a limit is reached — a data cap, or sustained load on the device — opt the device out entirely and check back later.

Consent has to be the only code path

Not a settings toggle defaulted on. Not a line in a EULA. The SDK should be incapable of sharing anything until the user has accepted an agreement they were shown, and your build should be reviewed for a working opt-out control before your device cap lifts.

You should be able to find out where the traffic goes

Ours goes to public web data collection: price and availability monitoring, flight and hotel search, SEO and ad verification, market research, AI training data. A permanent blacklist blocks .gov and .edu, banks and financial institutions, card processors, login endpoints, sensitive APIs, any reported-abuse domain, and the user's own local network.

What it pays

Up to $0.40 per average DAU per month, at per-country rates. Average DAU is the time-weighted mean number of your devices online across a calendar month — a device online for half the month counts half.

A worked example: 2,000 devices online for days 1–15 and 1,000 for days 16–30 is (2,000×15 + 1,000×15) / 30 = 1,500 average DAU, which is $600 that month at the top rate.

That is not subscription money. It is also money you collect without changing a single screen in your app, and it stacks on top of whatever else you already do.

How to evaluate one in an afternoon

1. Read the consent screen the SDK will actually show. If you cannot see it before integrating, that is the answer.
2. Ask which limits you can change. The correct number is zero.
3. Ask what happens when a device is under sustained load. "Throttles" is a worse answer than "opts out".
4. Ask who buys the traffic and what is blocked. Vagueness here is the whole risk.
5. Integrate it behind a flag, ship to 1% of users, and watch your crash rate and your retention curve for a week.

Cash Raven's first 100 devices go live with no sales call, which exists precisely so that step 5 costs you nothing but an afternoon.