Bandwidth monetization for Unity games: a developer guide

Indie Unity developers ship great games and earn almost nothing from them. The standard monetization stack — rewarded ads, interstitials, IAP — either hurts the play experience or barely converts at indie scale. This guide describes a different model: an opt-in background bandwidth revenue layer integrated into a Unity build, with no impact on frame rate, no interstitials, and no consumer-facing UI.

It is not a replacement for IAP in a game that converts well. It is a complementary layer that earns on idle time, runs in the background, and respects the parts of game design that ads tend to break.

Why ads break Unity games

The economics of mobile ad networks were built around hyper-casual games where the entire loop is designed to interrupt the player and serve an ad. For everything else — narrative games, simulation games, puzzle games with long sessions, anything with an art direction the developer cares about — interstitial ads are a hostile guest in your own product.

The data is unforgiving: ads suppress D7 retention, reduce session length, and produce review backlash that follows the title across stores. Players who complete a tutorial sequence and immediately get an interstitial tend to never open the game again. The CPM is real, but the lifetime value lost to churn is usually larger than the ad revenue gained. For indie games at small scale, the maths almost never works.

Rewarded video is gentler, and it has a place in some game loops. But it still requires a moment where the player accepts an interruption, and the relationship between “ad watched” and “dollar earned” for an indie scale audience is far weaker than networks imply.

What background bandwidth revenue actually is

Background bandwidth revenue is a different category of monetization. The model: with explicit consent, the player’s device contributes a small portion of idle network capacity to a network of business demand. The developer earns based on what the device does over time, not based on what the player clicks. There is no on-screen UI, no interruption to gameplay, no impressions to chase.

For a Unity game specifically, this matters because the game itself is unchanged. The player runs the title, plays the game, exits to the launcher; the SDK runs in the background, on its own thread, contributing to the network for the hours the device is online. The integration does not affect gameplay because it is not part of gameplay.

The model is consent-bound, which is non-negotiable. The disclosure is bundled into the Terms and Conditions the player accepts at first launch, and a clear settings toggle lets the player revoke at any time. We cover the consent pattern in detail in our ethical consent guide.

Integration footprint in a Unity project

The integration is small. For Android-target builds, the SDK ships as a Unity package with an Android plugin underneath. A simplified C# sketch from a bootstrap script looks like this:

// GetPassiveBootstrap.cs
using UnityEngine;
using GetPassive.SDK;

public class GetPassiveBootstrap : MonoBehaviour {
  void Start() {
    GetPassiveSDK.Initialize(apiKey: "YOUR_KEY");
    if (PlayerPrefs.GetInt("terms_accepted", 0) == 1) {
      GetPassiveSDK.Start();
    }
  }
}

For desktop targets — Windows, macOS, and Linux builds out of a Unity project — the SDK ships as a native plugin per platform with the same C# entry point. The same call site works across platforms.

The footprint at rest is small: a single background thread, modest memory, no heavy native dependencies, and explicit yielding when the device is under sustained load. Frame rate is unaffected because the SDK does not touch the Unity main loop or render thread.

How this fits alongside IAP and Unity Ads

If your game has a working IAP loop, keep it. Bandwidth revenue is complementary, not a replacement. The players who would never have bought anything are the ones the background layer monetizes. For a typical indie game with a low IAP conversion rate, the background layer can match or exceed IAP revenue over time without any further work on the IAP funnel.

If your game uses Unity Ads, the two can coexist if you are careful about player experience. The combination most teams settle on is rewarded video at the player’s explicit request (for a specific in-game benefit), no interstitials, plus the background bandwidth layer. This produces stable revenue without the retention damage of forced ads.

If you have neither IAP nor ads — a paid indie game on itch or Steam, for example — the bandwidth layer can be the only revenue source after the initial sale, providing a small but durable tail of income from the players who keep the game installed.

Realistic earnings for Unity games

The honest ranges depend on three things: monthly active users, average session and idle time, and country mix. For a Unity title:

• 5,000 MAU, mobile-mixed regions, short sessions: roughly $100–$500 per month.
• 50,000 MAU, mobile-mixed regions, normal usage: roughly $1,000–$5,000 per month.
• Desktop indie game with 10,000 MAU on Steam: often higher per-user than mobile because PCs are online longer; expect roughly $400–$2,000 per month.
• Android TV port of a casual title: per-device earnings can be 2–4x the phone equivalent, because TVs are mains-powered and online for the evening hours.

These are ranges, not promises. The same install base in a higher-demand regional skew sits at the top of the range; in a lower-demand skew, the bottom. We cover the variables in the bandwidth monetization earnings guide.

Rollout pattern for a Unity title

The rollout is straightforward:

1. Apply for a developer key. Test mode is issued on approval.
2. Add the GetPassive Unity package to your project. Drop the bootstrap script onto a persistent scene object.
3. Update your T&Cs and privacy policy with the plain-English disclosure block. Make it a clearly headed section, not buried.
4. Add a settings toggle that calls GetPassiveSDK.Stop() on revoke and Start() on re-accept. Persist the user preference.
5. Ship a test-mode build to a small cohort for two weeks. Confirm reporting in the developer console matches what the cohort is doing.
6. Promote to live and monitor the first month.

The whole sequence usually fits inside a single sprint. The hard work was making the game; this is a small bolt-on.

The takeaway

Unity games do not need to choose between ads that damage retention and IAP that converts at a fraction of a percent. An opt-in background bandwidth revenue layer earns on idle time, integrates in a small Unity package, respects the player’s experience, and works across mobile, desktop, and Android TV targets out of the same project. For indie teams especially, it is the lowest-friction additional income lever available.

For related reading, see our ad-free monetization guide and our deep dive on SDK performance impact. For the platform-specific integration notes, see our desktop SDK page.

FAQ

Will a bandwidth monetization SDK affect game performance?

The SDK runs on a background thread, not on the Unity main thread, and yields when the device is under sustained load. The CPU footprint while idle is negligible. When the game is not running, the background process continues earning if consent is granted. The integration does not affect frame rate or input latency during gameplay.

Can I add bandwidth monetization to mobile Unity games and desktop Unity games?

Yes. The SDK supports Android, Windows, macOS, and Linux builds out of a Unity project. iOS coverage depends on platform restrictions. The earnings curve favours desktop and Android TV builds because the device is online for longer sessions.

Does this affect store certification on Steam, itch.io, or app stores?

The model is consent-based, disclosed in your Terms and Conditions, and has no consumer-facing UI of its own. Store policies that ban background mining or hidden traffic do not apply because the disclosure is explicit and the feature is opt-in. Stores that bar unrelated background processing of any kind require additional review case by case.

How do I disclose this to players?

Bundle the disclosure into the Terms and Conditions the player already accepts at first launch, with a short plain-English summary in the privacy policy. The SDK reads the consent state and starts only when consent is granted. A clear settings toggle lets players revoke at any time.

How much can a Unity game earn from this?

A small indie game with 5,000 monthly active users might see $100 to $500 per month. A 50,000 MAU game can see $1,000 to $5,000. Long-session desktop games and Android TV ports earn more per device than short-session mobile games. Country mix is the biggest single lever.