Rewarded Video Earns 39% of Casual Ad Revenue From 21% of Impressions. A Licensed Build Can't Serve It.

Rewarded video earns more revenue per impression than any other ad format in a casual games catalogue, and most licensed HTML5 builds cannot serve it at all. The reward has to exist inside the game's own state — an extra life, a continue, a skipped timer — and that code is not what a catalogue licence sells you.

This is the gap between the monetization deck and the integration ticket. The deck says rewarded is the priority. The ticket says there is nowhere to put it.

📊 The Format That Earns the Most From the Fewest Impressions

TopOn's H1 2025 Global Mobile Games Monetization Report, aggregated across the games running on its mediation layer, splits casual game ad revenue by format. Rewarded video took 39.35% of revenue from 21.25% of impressions. Banner ran the other way entirely: 37.01% of impressions returning 6.50% of revenue.

The line people skip is the one above it. Interstitial, not rewarded, was the largest single revenue share in casual at 44.25%. So rewarded is the most efficient format per impression, and interstitial is still the biggest cheque, because you can serve far more of it.

Both facts matter, and they point in different directions. Rewarded is where the per-impression economics live. Interstitial is where the volume lives. A catalogue that can only serve the second one is not broken — it is capped, and the cap is roughly the difference between those two efficiency ratios.

Worth holding onto the trend from the same report: Android casual rewarded eCPM was down 7% year on year and interstitial down 11%, close to three-year lows, while iOS rewarded rebounded 18%. Nobody should be modelling a rising floor here.

One caveat before anyone lifts those numbers into a web portal model: TopOn measures in-app mobile inventory. That is the benchmark most portal decks quietly import, and it is the wrong one. More on that below.

🔩 A Rewarded Ad Is Two Systems. You Bought One of Them.

An interstitial is an ad placement. A rewarded ad is an ad placement plus a game mechanic, and the mechanic is the half that decides whether the format works.

Look at what the ad libraries actually require. Google's Ad Placement API — the H5 Games Ads path for web titles, documented at developers.google.com/ad-placement — exposes one function, adBreak(). Pass it type: 'next' and you get an interstitial. Pass it type: 'reward' and you get a chain of callbacks the game has to hold: beforeReward() hands your code a showAdFn reference which the game must store and fire only on a direct user action; adViewed() fires when the ad completes and is where you grant the reward; adDismissed() fires when the player bails and is where you don't. Google's documentation is explicit that adBreak() has to be called as part of a user action or the API will not request an ad at all.

The portal SDKs are the same shape. Poki's SDK splits commercialBreak() from rewardedBreak(), with the rewarded call described as firing "with user prompt in exchange for an in-game reward" — revival after death, unlocking gold, bonus items. CrazyGames' SDK draws the same line between a midgame ad and a rewarded one, where the rewarded ad is "requested by the user in exchange for a reward."

Read those requirements as a shopping list and it becomes obvious what you need to own:

• A moment in the game loop where a reward is meaningful — death, a locked level, an exhausted lives counter, a hint.
• A UI element rendered inside the game canvas at that moment, offering the trade.
• Game state you can write to when adViewed() fires, and must not write to when adDismissed() does.
• Pause, mute and resume handling wired to the ad lifecycle callbacks.

Every one of those lives in the compiled build. A catalogue licence typically grants you the right to host, display and distribute that build. It does not grant you the right to alter its object code, and even where it does, you are patching a minified WebGL bundle you did not compile.

🧱 What the Shell Can Serve, and Why It Earns Less

The portal shell — your page, your header, your account layer — can serve rewarded ads. It just cannot serve the good ones.

Shell-level rewarded placements that genuinely work:

• Watch to remove ads for 30 minutes. Real value to the player, entirely under your control. It also cannibalises the interstitial revenue you were about to earn, so measure it net rather than gross.
• Watch to unlock a gated title. Requires you to have built a locked-content tier in the first place, which most catalogue portals have not.
• Watch for daily portal currency. Requires an account system, a currency, and somewhere to spend it. That is a product, not a placement.

What the shell cannot serve is the placement that actually prints money: continue after death. The shell has no idea the player died. The game runs in a cross-origin iframe with no event contract back to the parent, and a licensed build almost never ships one. You are outside the room where the reward moment happens.

That constraint also explains why the shell placements underperform. A rewarded ad's value comes from the player wanting something specific at a specific moment of friction. "Watch a video for 50 coins" on a portal homepage is a coupon. "Watch a video to keep your 41-level streak" is a rescue. The eCPM is set by the demand side, but the opt-in rate is set by which of those two you are able to offer.

💵 Web Rewarded Does Not Pay Mobile Rewarded Rates, and Sources Disagree by 4×

Here the published numbers stop agreeing, and the spread is the useful part.

AppLixir, a rewarded-video network built specifically for web and WebGL, published a mid-2026 review of its own network covering January to June 2026. Its web rewarded eCPMs: $3.62 global, $6.20 across tier-1 geos, $6.98 US-only. Alongside that it reports a 97% opt-in rate, 93.8% global completion, and 95.1% fill.

Playgama's 2026 web monetization breakdown, cited in Cinevva's web game monetization guide, puts web rewarded at $15–$28 in the US, $8–$15 in the EU, and $1–$3 in India and Brazil.

That is a four-fold disagreement on the US figure for the same format on the same medium in the same year. Some of it is genuine: rewarded eCPM varies enormously by vertical, by consent state, and by whether the inventory clears through premium demand or remnant. Some of it is selection — a single network's average reflects that network's demand mix, and vendor-published benchmarks skew toward the flattering end in both directions depending on what they are arguing.

The defensible reading is a range, not a point. Web rewarded in tier-1 markets plausibly clears somewhere between $6 and $20, with a wide band, and materially below the $15–$20 that in-app mobile rewarded fetches in the US. Anyone handing you a single number for this without naming the network and the period is guessing.

The practical consequence: build the model on the low end, treat the high end as upside, and never import a mobile in-app eCPM into a web portal forecast. The revenue model for a portal breaks in month three when it was built on somebody else's inventory type.

📉 The Platform Rules Cap the Upside Before Your Catalogue Does

Even with a build that supports rewarded, the format is deliberately rate-limited by everyone downstream.

CrazyGames' advertising requirements are a fair proxy for industry norms: midgame ads capped at one every three minutes with the SDK enforcing the cooldown; rewarded ads not offered "too often," with a visible timer telling the player when the next one is available; and an explicit ban on chaining — a player may not be made to watch more than one rewarded ad for a single reward. Requesting too early throws an adCooldown error rather than serving.

Two more rules from the same page have direct commercial consequences. Rewarded request buttons may not appear during active gameplay — in a racing game, not during the race. And games must stay fully playable for users with ad blockers, without penalty beyond the reward itself being temporarily unavailable. That second one quietly rules out the design most operators reach for first: gating progression behind an ad.

So the ceiling on rewarded impressions per session is set by design rules, not by demand. Adding more rewarded placements works up to a point, and past that point you are trading retention for a marginal impression.

✍️ Three Clauses That Decide Whether You Ever Serve Rewarded

This belongs in the licence, not in the sprint backlog.

1. A right to modify, named as such

"The right to publish, host and display" is not "the right to alter." Ask for an express right to modify the build for the purpose of ad integration and localisation, and make it survive renewal. Without it, integrating a rewarded hook is a breach even when it is technically trivial.

2. Who integrates, whose SDK, and what happens at the next build

Name the network. Name who does the work. Then handle the failure nobody plans for: the licensor ships an updated build at renewal and it lands without your patch. Either the licensor commits to carrying your integration forward, or you accept that every refresh costs you the integration again. Price that as recurring engineering, not a one-off.

3. A per-title ad-hook schedule, attached to the deal

Get the catalogue sheet to state, per title, whether a rewarded hook already exists and which SDK it calls. This is the single most valuable column you can add to a catalogue negotiation and almost nobody asks for it. "Ad-ready" on a spec sheet usually means the build tolerates a banner around it. It rarely means adBreak({type: 'reward'}) is wired to anything.

🔍 An Audit You Can Run on a Sample This Week

You do not need the licensor's cooperation to find out where you stand. Take twenty representative titles and do this:

1. Grep the bundle. Search the shipped JavaScript for adBreak, adConfig, PokiSDK, CrazyGames, initializeAndOpenPlayer and the usual aggregator globals. A hit tells you a hook exists.
2. Check whose hook it is. A build wired to another portal's SDK is worse than a clean build — it may call a domain that isn't yours, fail silently, or leak inventory. Note the network, not just the presence.
3. Count real reward moments. Independent of code: does this game have a continue, a life, a hint, a locked item? An endless runner has one. A jigsaw has close to none. A title with no reward moment will never earn rewarded revenue regardless of integration.
4. Test the dismiss path. Where a hook exists, stub the network and confirm the game withholds the reward on dismissal. A build that grants on request rather than on completion is a fraud liability, not a feature.
5. Confirm the adblock path. Load with a blocker on. If the game becomes unplayable or soft-locks at a reward prompt, you have a support ticket queue and a distribution problem.

Twenty titles, an afternoon. The output is a percentage — the share of your catalogue that can serve the highest-value format — and that percentage should be in the model before you sign anything.

🚫 Five Ways Operators Get This Wrong

• Modelling web rewarded revenue on in-app mobile benchmarks. The TopOn figures at the top of this post describe app inventory. Web clears lower. Using one for the other overstates the line by a multiple, not a margin.
• Reading "ad-enabled" on a catalogue sheet as "rewarded-enabled." These are different capabilities with different code behind them. Ask which one you are buying.
• Bolting a shell rewarded button onto a portal with nothing worth unlocking. The reward has to be something the player wants at that moment. Coins with no shop are not a reward.
• Patching builds without the right to. Cheap engineering, expensive contract exposure, and it evaporates at the next build refresh anyway.
• Over-serving because it pays best. Rewarded has the highest eCPM and the strictest frequency rules for the same reason. Chaining ads or pushing the prompt into live gameplay breaks platform requirements and player tolerance at once.

🌲 Where a Licensed Catalogue Fits

None of this argues against licensing. It argues for asking a specific question during due diligence that most buyers do not ask: which titles carry a rewarded hook, and what may you do to the ones that don't.

Forestry Games licenses a catalogue of 1,049 HTML5 and Android titles and develops HTML5 games in-house, which is the part that matters here — where a build is developed rather than resold, the ad integration question has an answer rather than a shrug. If you are sizing a catalogue for an ad-funded portal, the questions to put to any licensor, us included, are the ones in the clause section above. Teams working through the arithmetic can start at monetization; the Google H5 path specifically is covered under H5 games ads; and where modification rights are the blocker, source code deals are a different transaction with a different price.

🧭 What to Do Before the Next Catalogue Deal

Run the twenty-title audit first, because it converts an argument into a number. Then take that number into the negotiation: if 15% of the catalogue can serve rewarded, your ad revenue model is an interstitial-and-banner model with a small rewarded tail, and it should be built that way rather than aspirationally.

Then ask for the ad-hook column on the catalogue sheet and an express modification right. Both are cheap to grant and neither is standard, which means asking costs you nothing and marks you as a buyer who has done this before. The licensors who can answer quickly are the ones worth shortlisting.

And build the forecast on the low end of the published web rewarded range. The format is genuinely the best-performing one per impression. It is also the one you are least likely to actually own, and a revenue model that assumes otherwise fails in the quarter after launch, when the interstitials are running fine and the rewarded line is still zero.