Most monetization arguments are really arguments about who pays. Once you know how little of a free-to-play audience ever opens a wallet, the model choices stop being philosophical and start being arithmetic. This guide covers the models, the formats, the metrics that matter, and where each one fits — with a clear position on what browser-based games should run by default.

What is game monetization?

Game monetization is the process of generating revenue from a game — through advertising, selling virtual goods and consumables, recurring subscriptions, or a one-time purchase price. The goal is to cover development and operating costs and then produce profit, without degrading the experience that brought players in. Monetization is a design decision, not a post-launch bolt-on. The moment you decide that extra lives exist, that a level has a fail state, or that currency can be earned, you have made a monetization decision. Games that plan revenue during development integrate it into pacing and progression; games that add it after launch end up interrupting loops that were never built to be interrupted. If you are choosing between spending an afternoon on integration now versus after soft launch, now is cheaper.

Where the revenue actually comes from: the 2% rule

Across free-to-play games, only about 2% of players ever make an in-app purchase. That single number shapes everything else. If in-app purchases are the only revenue line in your game, roughly 98% of your audience is generating nothing — they are playing, consuming bandwidth and server time, and contributing zero. The strategic question, then, is not “how do I convert more payers?” It is “how do I earn from the non-payers without driving them away?” The answer is advertising, and players are broadly willing: around 74% of mobile gamers say they will watch a video ad in exchange for an in-game reward, and roughly 82% prefer a free game with ads to paying upfront. Those preferences carry over cleanly to the browser, where the expectation of “free to click, free to play” is even stronger than on mobile app stores. This is also why hard paywalls perform poorly on the web. A browser player has no install commitment and no sunk cost; a payment wall placed in front of progression is a tab close. Advertising that the player chooses to watch keeps them in the session.

Game monetization models compared

There are five game monetization models in common use. Most shipping games run two or more at once, which is what “hybrid monetization” means in practice.

Model	Who pays	Share of audience reached	Fit for browser games	Main risk
In-app advertising (IAA)	Advertisers	Effectively all players	Strong — rewarded video especially	Frequency fatigue if placement is careless
In-app purchases (IAP)	~2% of players	Narrow but high value	Workable; needs a payment and account layer	Pay-to-win perception; heavy build cost
Subscriptions / battle passes	Committed players	Small, recurring	Good for retention-heavy titles	Content treadmill; churn management
Premium (upfront price)	Every player, once	Only those who convert at the gate	Weak — browser traffic is discovery traffic	Kills the funnel before gameplay starts
Hybrid	Advertisers plus payers	All of it, at different rates	Strongest overall	Complexity; competing incentives

In-app currencies sit underneath several of these. Soft currencies — coins, gems, tokens — give players a flexible path to progress: free if they grind, faster if they pay, and faster still if they watch a rewarded video ad. Currencies are also a behavioural tool. Awarding coins for a daily challenge builds a login habit, and habit is what makes every other revenue line work. Keep currency-purchased items genuinely useful and slightly exclusive, or players will grind indefinitely and never convert. For the mechanics of running ads and purchases side by side without the two cannibalising each other, see AppLixir’s breakdown of hybrid monetization models for free-to-play games.

Browser game monetization: what changes on the web

Browser game monetization differs from mobile app monetization in three ways that change which tools are available to you. First, the major mobile ad networks do not serve web inventory. Unity Ads, AdMob, AppLovin and ironSource are built around mobile app SDKs. They do not fill rewarded video on a browser page or in a Unity WebGL build. Developers regularly discover this mid-integration after porting a mobile project to WebGL and finding no ad returns. AppLixir exists specifically to serve that gap: rewarded video built for the browser, not a mobile SDK wrapped in a canvas. The details of what does and does not fill are covered in this comparison of Unity rewarded ads and AdMob on WebGL. Second, there is no app store gate. Web traffic arrives from portals, search, social links and embeds. That makes acquisition cheap and commitment low. Monetization that demands anything before the first play session — an account, a price, an email — leaks most of the funnel. Third, distribution and monetization are separate layers. Portals like Poki and CrazyGames are distribution partners: they bring players to your game. AppLixir is a monetization layer that sits alongside whatever distribution and whatever display stack you already run. The two are complementary, and the additive question — what does this add to what I already have? — is the right one to ask of any new revenue line.

Ad monetization formats, ranked for web games

Ad monetization is the practice of earning revenue by showing advertising against gameplay or page content, priced per thousand impressions. Not all formats earn or behave the same way, and on the web the spread between them is wide.

Rewarded video: the default for web games

A rewarded video ad is an opt-in video the player chooses to watch in exchange for a specific in-game benefit — an extra life, a currency bundle, a continue, a hint, a skin unlock. It is the highest-value web ad format AppLixir serves, delivering $4+ CPM on web rewarded video against roughly $0.50–$2 for typical web display. AppLixir runs 100M+ monthly impressions on that format. Rewarded video is the right default for browser and HTML5 games for structural reasons, not just pricing. The player initiates it, so it never interrupts a loop. The reward is a design lever you control, so the ad becomes part of progression rather than a tax on it. And completion rates are high because the viewer wants the outcome. Practical placement rules:

• • Offer at natural pauses and decision points: level end, fail state, shop, daily bonus, pre-run boost.

• • Make the reward something players actually want — extra lives, currency, a run continue, a cosmetic — and state it before the ad plays.

• • Cap frequency. Unlimited rewarded views devalue the reward and fatigue the player.

• • Never gate required progression behind an ad. Opt-in means the player must have a free path.

Interstitials: use sparingly, or not at all

Interstitials are full-screen ads shown at forced breaks, without player consent. They earn less per impression than rewarded video and cost more in retention, because they take the session hostage at exactly the moment the player wanted to keep going. On the web, where closing the tab costs nothing, that trade is worse than on mobile. AppLixir’s position is that interstitials are a supplementary format at most for browser games, and that rewarded video should carry the ad line. The revenue and eCPM comparison is laid out in rewarded video ads vs interstitial ads.

Banner and display: low ceiling, low friction

Banner ads remain a legitimate supplementary line. They are simple to implement, do not interrupt gameplay, and earn on impressions — but at typical web display rates of roughly $0.50–$2 CPM, they cannot carry a game on their own. Place them at the top or bottom of the frame where they are visible but out of the play area, monitor engagement metrics after launch, and treat them as a floor under your rewarded revenue rather than the main event.

The metrics that tell you whether monetization is working

Every monetization model has its own scoreboard. Advertising models live on impression-priced metrics; purchase models live on spend-per-user metrics; all games should watch blended ones.

• • CPM (cost per mille) — what an advertiser pays per 1,000 impressions. A $5 CPM means $5 per thousand views. From the publisher side it sets your revenue per thousand ads served.

• • eCPM (effective CPM) — actual revenue earned per 1,000 impressions across all demand sources, after fill rate and pricing. eCPM, not headline CPM, is the number to optimise.

• • CPC and CPI — cost per click and cost per install. Mostly buy-side metrics, but they matter to you because they drive what advertisers are willing to pay for your inventory.

• • ARPU and ARPPU — average revenue per user, and per paying user. ARPPU rising while ARPU stalls means you are squeezing the same 2% harder.

• • ARPDAU — average revenue per daily active user, blending ads and purchases. The single best day-to-day health metric for a live game.

• • LTV — lifetime value per player, which only becomes meaningful when paired with retention.

You cannot set CPM directly — advertisers and networks do — but you can lift eCPM. The levers are audience geography (tier-1 markets carry higher advertiser demand), ad viewability and placement, opt-in rates on rewarded placements, and fill rate. Practical steps for moving ARPDAU are in this guide to improving ARPDAU. One rule overrides the rest: read monetization metrics next to retention. A frequency increase that lifts eCPM 15% and drops day-7 retention 10% is a net loss you will only see six weeks later. Run monetization changes as experiments with retention as a guardrail metric.

Game monetization strategies by genre, stage and audience

Genre sets the revenue mix more than anything else. As a rough shape of the market: hyper-casual runs close to 95% advertising, casual and puzzle land near a 50/50 split between ads and in-app purchases, and midcore skews roughly 80% toward in-app purchases. Sessions are short and shallow in hyper-casual, so there is no time to build purchase intent; midcore players invest tens of hours and buy accordingly. Where rewarded video is the strongest fit:

• • Session-based web games with fail states, lives, timers or run-based progression — every one of those is a natural reward moment.

• • IO-games and HTML5 titles with large, mostly non-paying audiences.

• • Content sites and tool pages that want to trade an opt-in video for premium access, extra credits or an ad-light session instead of leaning entirely on display.

• • Studios already running IAP that need a revenue line for the ~98% who never purchase.

Where it is a weaker fit, and worth saying plainly: narrative or atmospheric games where a video break destroys tone; games with no economy, no consumables and no fail state, where there is nothing to reward; and titles below meaningful scale, since AppLixir’s minimum publisher threshold is 5,000 DAU. Games with very deep midcore economies may earn more from a well-tuned battle pass than from ads, though rewarded video still usually adds a layer on top for the free cohort. Player behaviour should drive the details. Watch which reward types get taken up, at which points in the session, and by which cohorts — then move placements toward the moments players actually choose. For observed rates on web inventory, see how much rewarded video ads pay on web games.

How to choose an ad network for a web game

The best ad network for a game depends on rates, fill rate, available formats, targeting, reporting transparency and — first of all — whether the network serves your platform at all. For browser games that last point eliminates most of the well-known names: the mobile networks are app-SDK products and do not fill web inventory. A short evaluation checklist for web publishers:

• • Platform coverage. Confirm the network serves browser, HTML5 and Unity WebGL builds in production, not just mobile apps.

• • Format. Rewarded video should be a first-class product, with server-side reward verification to prevent abuse.

• • Privacy compliance. European traffic needs a consent framework. AppLixir has TCF 2.3 and GDPR compliance built in via Didomi, so publishers do not assemble a consent layer themselves.

• • Eligibility. Check the traffic threshold before you integrate — AppLixir’s minimum is 5,000 DAU.

• • Integration cost. A JavaScript rewarded video ads SDK that drops into an existing HTML5 build should be an afternoon of work, not a sprint. The steps are documented in this HTML5 rewarded video SDK guide.

• • Additive fit. The right question is what a network adds to the display stack and portal distribution you already run, not what it replaces.

Two constraints sit outside your control and should be planned for: platform and portal policies on ad placement, and regional privacy regulation. Both change. Building on a rewarded format with a managed consent layer reduces how often those changes become your engineering problem.

FAQ

What are the main game monetization models?

The main game monetization models are in-app advertising, in-app purchases, subscriptions and battle passes, premium upfront pricing, and hybrid combinations of these. Advertising reaches effectively the entire audience, while in-app purchases reach roughly 2% of free-to-play players at much higher value per user. Most successful free-to-play games today run hybrid: ads for the many, purchases for the few, subscriptions for the committed.

What is the best way to monetize a browser game without hurting UX?

Opt-in rewarded video is the best default for browser game monetization because the player chooses when to watch and receives something concrete in return. Place it at natural pauses — fail states, level ends, shops, daily bonuses — cap frequency, and never gate required progression behind an ad. Forced interstitials and hard paywalls do more retention damage on the web than on mobile, because closing a browser tab costs the player nothing.

How much do rewarded video ads pay on web games?

AppLixir delivers $4+ CPM on web rewarded video, compared with roughly $0.50–$2 CPM for typical web display inventory. Actual earnings depend on audience geography, opt-in rate, ad frequency per session and fill rate, which is why eCPM rather than headline CPM is the number to track. Multiply your eCPM by impressions per daily active user to model revenue against your own DAU.

Do Unity Ads and AdMob work for WebGL and browser games?

No. Unity Ads, AdMob, AppLovin and ironSource are mobile app SDK products and do not serve web inventory, including Unity WebGL builds and HTML5 games in a browser. Web publishers need a network built for the browser; AppLixir serves rewarded video directly to web games and content sites and runs 100M+ monthly impressions on that inventory. Distribution portals such as Poki and CrazyGames are complementary — they bring players, and a rewarded video layer monetizes them.