App bandwidth revenue calculator: estimate your earnings

Most bandwidth monetization estimates are guesses dressed up as calculators. This post is the opposite: the full formula GetPassive uses, with the inputs and ranges spelled out, plus three worked examples you can adapt to your own app. Use it to model honest expectations before you integrate.

If you want a number for your app and you want the number to mean something, the only way to get there is by understanding the inputs. Here they are.

The formula

Monthly revenue for an app participating in a background bandwidth layer is approximately:

monthly_revenue = active_devices
                  * opt_in_rate
                  * active_hours_per_day
                  * 30
                  * country_rate
                  * developer_share

The pieces:

• active_devices: monthly active devices that have your app installed and consented.
• opt_in_rate: fraction of installs that accept the in-app disclosure.
• active_hours_per_day: average hours per day the device is online and contributing.
• 30: days in a month (give or take).
• country_rate: per-active-device-hour rate set by demand. Varies by region.
• developer_share: the share you keep. 0.80 on GetPassive.

Note that the rate is per active device hour, not per gigabyte. This produces more predictable revenue for developers and removes the incentive to push aggressive volume through user devices. We cover the reasoning in the ethical bandwidth network checklist.

Honest ranges for each variable

These ranges are honest. The country rate band is wide because regional demand differs significantly. A US-heavy audience sits near the top; a low-demand-region audience sits near the bottom. Plan against the bottom of the range. If the bottom number covers a meaningful goal, the model is worth integrating. If only the top makes the maths work, you are gambling.

Worked example 1: a 10,000-MAU Android utility app

Inputs:

• active_devices: 10,000
• opt_in_rate: 0.30 (clean consent UX)
• active_hours_per_day: 4 (phone usage)
• country_rate: 0.0025 (mixed regions, middle of band)
• developer_share: 0.80

Calculation: 10,000 × 0.30 × 4 × 30 × 0.0025 × 0.80 = $720/month.

At the bottom of the range (opt-in 0.15, country rate 0.0010): 10,000 × 0.15 × 4 × 30 × 0.0010 × 0.80 = $144/month. At the top (opt-in 0.45, country rate 0.005): 10,000 × 0.45 × 4 × 30 × 0.005 × 0.80 = $2,160/month.

So this app should expect somewhere between $144 and $2,160 per month, with $720 as the central estimate. Plan around $144–$300 for the first three months while the consent UX stabilizes.

Worked example 2: a 50,000-install desktop utility

Inputs:

• active_devices: 50,000
• opt_in_rate: 0.25 (desktop apps often see lower opt-in than mobile)
• active_hours_per_day: 10 (desktop)
• country_rate: 0.0030 (slight US/EU skew)
• developer_share: 0.80

Calculation: 50,000 × 0.25 × 10 × 30 × 0.0030 × 0.80 = $9,000/month.

At the bottom of the range (opt-in 0.10, country rate 0.0010): 50,000 × 0.10 × 10 × 30 × 0.0010 × 0.80 = $1,200/month.

So $1,200–$9,000 with $4,000–$5,000 as a reasonable middle. Desktop economics significantly outperform phone economics because uptime dominates.

Worked example 3: a 5,000-device Android TV channel

Inputs:

• active_devices: 5,000
• opt_in_rate: 0.40 (TV onboarding sees higher acceptance because the user expects setup steps)
• active_hours_per_day: 14 (mains-powered, always on)
• country_rate: 0.0025
• developer_share: 0.80

Calculation: 5,000 × 0.40 × 14 × 30 × 0.0025 × 0.80 = $1,680/month.

Per-device, this works out to about $0.34/month per active device, which dominates phone-app per-device numbers (often $0.03–$0.07/month). Long-uptime devices are the highest-leverage audience for this model.

What moves your number

Once you have a central estimate, focus on the lever with the most upside for your specific app:

• If opt-in rate is below 0.20: the consent UX is the lever. Plainer language, clearer placement, less friction.
• If active hours are low: usage characteristics dominate. Consider whether a wider platform footprint (desktop or TV port) is feasible.
• If country mix is unfavourable: targeting changes are slow. Plan around the lower end and treat anything above as upside.
• If active devices are low: growth is the lever. The model is multiplicative, so a doubling of active devices roughly doubles revenue.

For most teams, opt-in rate is the single biggest controllable variable. A move from 0.15 to 0.35 doubles the revenue without any change to the audience or product.

What this model does not capture

The formula is a central estimate, not a prediction. Things it does not capture:

• Month-to-month demand variance. June and November tend to be busy; some months are quieter.
• Demand mix shifts as the network grows. New developers, new business customers, new regions.
• Carrier-level network conditions on the user’s device. Cellular vs Wi-Fi changes the contribution profile.
• Anti-abuse filtering. Devices that look suspicious are excluded from earnings.

The honest framing: this is a central estimate. Use the bottom of the range for planning. Treat the top of the range as upside if the audience and product cooperate.

The takeaway

You can model your app’s realistic bandwidth revenue with five numbers and a calculator. The point of doing it is to set honest expectations before you integrate, so the model can be evaluated on its merits and not its hype. If the bottom of the range covers a goal worth your time, integrate. If not, work on a different lever first.

For related reading, see our bandwidth monetization earnings guide, the realistic passive income guide, and the ethical bandwidth network checklist.

FAQ

What variables go into the bandwidth revenue calculation?

Five variables: active devices, opt-in rate, average active hours per device per day, country mix, and the per-active-device-hour rate. The first four are properties of your app and audience; the last is set by the network and varies with demand.

Is the rate per gigabyte or per device hour?

Per active device hour. GetPassive pays based on device uptime contributed, not bytes consumed by the end customer. This produces more predictable earnings for developers and removes the perverse incentive to push high-bandwidth traffic through user devices.

What is a realistic opt-in rate?

Clean apps with trusted reputations see opt-in rates of 35-50 percent on the in-app disclosure. Apps with weak trust see 10-15 percent. The single biggest lever is disclosure UX clarity, not the SDK choice. Plain language plus an easy revocation path in settings outperforms aggressive default-on framing every time.

What rate does the developer earn?

Partners earn between $0.10 and $0.50 per active user per month from qualifying active device hours, depending on country tier, uptime, and live demand. Higher-demand countries earn more. Paid monthly via Stripe Connect (or USDC through CoinGate where Stripe Connect is not supported). The published rate is transparent, not per-GB bounties.

How accurate is this estimate compared to real earnings?

The calculator gives a central estimate based on published assumptions. Real earnings vary by month, by region, and by demand. Use the bottom of the range for honest planning. If the bottom-of-range estimate covers a meaningful goal, the model is worth integrating. If only the top makes the numbers work, you are gambling, not planning.