Monetization without ads: the honest math
What a bandwidth-sharing SDK actually pays, why every headline rate you've seen assumes 100% opt-in, and how to model revenue for your own audience.
Every bandwidth-SDK landing page shows you a number. A big one, usually with a slider that only goes up. What almost none of them show is the arithmetic underneath — and that arithmetic is where the honesty lives or dies.
This post is the arithmetic. No slider tricks, no “up to”, no asterisks pointing at nothing.
The three numbers that actually matter
Revenue from bandwidth sharing is a product of exactly three factors:
Active devices. Not installs, not MAU — devices that are actually online daily. Sharing happens only while the device is in use conditions (on Wi-Fi, charging, idle), so a dormant install contributes nothing.
Opt-in share. The fraction of users who see the consent dialog and tap Allow. This is the number most calculators quietly set to 100%. Real opt-in is a fraction of that, and it depends heavily on how honestly the dialog is written.
Price per gigabyte. What vetted buyers pay for routed traffic. It moves with demand across the year and differs by geography — US and EU capacity is in higher demand than emerging markets.
Everything else — platform, seasonality, audience quality — is a coefficient on one of those three. If a projection can't tell you which of the three factors it's assuming, it isn't a projection.
Where optimistic calculators cheat
Three moves, always the same:
100% opt-in. The single biggest inflation. If a realistic opt-in share is a third of the audience, the headline is instantly three times too high.
Top-geography pricing for the whole world. Your users are where they are. Pricing a global audience at US rates flatters the result and has nothing to do with your payout.
Peak-hour rates as the annual average. Demand for bandwidth is not flat. A rate that was real for one week of one quarter is not a rate — it's a screenshot.
None of these are lies, exactly. They're assumptions that were chosen for you, then hidden. Our position is simple: if the assumptions aren't published, the number isn't a rate — it's an ad.
The honest version of the model
Take your daily active users. Apply an opt-in share you actually believe — our calculator defaults to 30% and lets you change it, because your audience isn't our audience. Multiply by the monthly traffic an average opted-in device shares in your main geography. Price it at a range, not a point, because demand moves.
That produces a corridor, not a promise. The corridor is less exciting than a big green number. It's also the one that will still be true in March.
Why a range beats a point estimate
A point estimate answers the question “what will I earn?” with false precision. A range answers a better question: “what does the realistic corridor look like, and what moves me inside it?” The answer to the second question is actionable — grow the audience, improve consent UX, understand your geography mix. The answer to the first is a disappointment scheduled for later.
What this means in practice
Bandwidth sharing is a complement, not a replacement. For most apps it makes sense as a second or third monetization layer: it doesn't consume screen time, doesn't compete with your ads or subscriptions, and its revenue scales with audience size rather than engagement tricks. Apps with large, stable, Wi-Fi-heavy audiences see the best economics; apps with small or highly transient audiences should run the numbers before integrating anything.
Run your own inputs through the calculator with published assumptions — every coefficient is visible and editable. If the corridor looks meaningful for your scale, the integration page shows what the path from application to first payout looks like.
RELATED
First in, best terms.
A limited set of founding partners get elevated rates, a direct line to the team, and a say in the SDK roadmap.
Request access