Rewarded Video Ad Integration: 7 Real Examples Done Right
A code-level guide to the integration patterns that keep players — and revenue — intact.
TL;DR
A clean rewarded video integration hits five marks: explicit opt-in, a reward gated on a verified completion signal, a graceful no-fill fallback, frequency and placement discipline, and consent-aware loading. Most broken integrations fail on the second one — they hand out the reward when the ad closes instead of when it actually completes. The seven examples below show the wrong pattern, the right pattern, and what each one costs you in retention.
Rewarded video is the highest-earning format on the web, and also the easiest to break. The ad unit itself is rarely the problem. The integration around it is. A reward that fires on the wrong event, a no-fill that freezes the game, a consent gate that never resolves — these are code decisions, not media decisions, and they quietly bleed retention long after the eCPM report looks fine.
This guide is about those decisions. Not a gallery of games, but a set of concrete patterns you can check your own build against. Each example pairs the anti-pattern most integrations ship with the pattern they should ship instead. Everything here is framed for the web stack — HTML5, WebGL, and the JavaScript SDK layer — because that is where the callback contracts actually live.
Web rewarded video also behaves differently from its mobile cousin. There is no app-store SDK doing the heavy lifting for you, no native lifecycle to lean on. The browser is your runtime, the JavaScript callback is your source of truth, and consent state is something you resolve yourself before the first request. That shifts more responsibility onto the integration layer — which is exactly why getting these seven patterns right matters more on the web than anywhere else.
The ad unit is rarely the problem. The integration around it is.
The Clean Integration Scorecard
Before the examples, here is the rubric they map to. Five marks. A rewarded integration that misses any one of them is leaking either revenue or players, usually both. Score your own build against it before you ship.
Mark
What it means
Failure symptom
1. Explicit opt-in
The player chooses to watch — never auto-played or forced.
Rage quits, negative reviews, low completion.
2. Verified completion
Reward fires on a confirmed completion signal, not on ad-close.
Reward exploits, or players who feel cheated.
3. Graceful no-fill
No ad available? The game continues without penalty.
Frozen UI, stuck loading spinners, hard locks.
4. Frequency & placement discipline
Offers appear at natural decision points, capped per session.
Fatigue, churn, banner-blindness to the offer.
5. Consent-aware loading
Init respects TCF / GDPR state before requesting an ad.
Compliance risk, empty fills in the EU.
The 7 Examples
1. Gate the reward on completion, not on ad-close
This is the single most common integration bug, and the most expensive. A player opens the ad, the ad renders, and the developer wires the reward to the ‘ad closed’ event. The problem: a player can open and immediately dismiss the ad, or a network hiccup can close it early, and the reward still fires. Worse, some developers do the opposite — they only reward on close and miss legitimate completions.
The right pattern keys the reward to an explicit status object. In the AppLixir v6.1.0 contract, that means checking status.type === “complete” inside the callback before granting anything. Ad-close is a UI event. Completion is a business event. Never conflate them.
2. Handle no-fill without punishing the player
There will not always be an ad. Fill rates on the web are healthy but never 100 percent, and a player who opts in expecting a reward should never be left worse off when no ad returns. The broken pattern shows a spinner that never resolves, or blocks the reward entirely while offering no path forward.
The right pattern treats no-fill as a first-class outcome. Detect it in the callback, restore the game state instantly, and — where your design allows — grant a small fallback reward or simply let the player continue. The player opted in good faith. Do not tax them for your ad server’s inventory.
A useful design principle: the no-fill path and the completion path should both return the player to a playable state within the same frame budget. If your success path is instant but your failure path stalls, players learn to distrust the button entirely, and your opt-in rate erodes across the whole session — not just the moment that failed to fill.
3. Place the opt-in at a natural decision point
Where you offer the ad matters as much as how you wire it. The anti-pattern interrupts active play with an unprompted offer. The right pattern surfaces it at a moment the player already wants something: a revive after death, a currency top-up at a store, a bonus at level-end. This ties directly to the six placement zones in the Rewarded Video Ad Placement Playbook — the integration code is only as good as the moment it fires in.
4. Cap frequency in code, not in hope
An unbounded reward offer trains players to grind ads instead of playing, and it flattens your eCPM as impressions inflate. The broken pattern relies on the player to self-limit. The right pattern enforces a per-session and per-placement cap in your own state layer, tracks offers shown, and hides or greys the button once the cap is hit. Frequency discipline is a code responsibility. Do not outsource it to player restraint.
Caps also protect the value of each impression. Advertisers pay more for engaged, non-saturated audiences, so a disciplined cap tends to lift eCPM rather than depress total revenue. The counterintuitive result is that showing fewer, better-placed offers frequently earns more than showing every offer you technically can.
5. Initialize consent-aware, especially in the EU
On the web, a rewarded request that ignores consent state is both a compliance risk and a revenue leak. The anti-pattern requests an ad before the TCF string is resolved, producing empty fills or non-compliant impressions in GDPR regions. The right pattern reads consent state first, initializes the SDK once it is known, and only then requests. Privacy-first is not a tax on revenue here — a clean consent flow is what unlocks premium European demand in the first place.
6. Preload deliberately — do not lazy-load at the tap
If you request the ad only at the instant the player taps the button, you have designed a delay into your best monetization moment. The player waits, momentum dies, some walk away. The broken pattern lazy-loads on demand every time. The right pattern preloads the next ad in the background after the previous outcome resolves, so the offer is ready the moment the player wants it. Preloading is the difference between an instant reward and an awkward pause.
7. Restore game state cleanly after the ad returns
A rewarded ad hands control to another surface and then hands it back. Everything the player left — audio, physics loop, input focus, pause state — must return exactly as it was. The anti-pattern resumes with muted audio, a stuck pause overlay, or a dropped input handler. The right pattern snapshots state before the ad, and restores it inside the completion callback. The reward is the point, but a broken return is what the player remembers.
This matters more on the web because the ad often takes over the same tab and shares the same audio context as your game. Pausing the game loop and suspending audio before the request, then resuming both once the callback fires, is not optional polish — it is what makes the ad feel like a seamless part of the game rather than a jarring detour. Test the return path on the completion, no-fill, and early-close outcomes separately; they do not always resume identically.
What Each Anti-Pattern Actually Costs
Integration bugs rarely show up as errors. They show up as retention drift and revenue that underperforms the format’s potential. Here is the mapping.
Anti-pattern
Immediate cost
Retention cost
Reward on ad-close
Reward exploits or cheated players
Trust erosion; loop feels rigged
Ungraceful no-fill
Frozen UI, stuck sessions
Session abandonment
Interruptive placement
Low opt-in rate
Fatigue-driven churn
No frequency cap
Inflated, low-value impressions
Grind fatigue, eCPM decay
Consent-blind init
Empty EU fills, compliance risk
Lost premium demand
Lazy-load at tap
Latency at the reward moment
Drop-off before completion
Dirty state restore
Broken audio / input on return
Perceived instability
Retrofitting an Existing Integration
Most teams reading this already have rewarded video live and cannot rebuild it from scratch. You do not need to. Work the scorecard in priority order, because the marks are not equally expensive to get wrong.
Start with verified completion. Audit exactly which event grants the reward, and move it onto the completion signal if it is anywhere else. This is a small code change with the largest payoff, because it closes both the exploit path and the cheated-player path at once. Next, harden the no-fill and state-restore paths — these are the two failure modes players feel most directly, and they are usually a few lines of callback handling. Only then tune placement and frequency, which are design decisions you can iterate on with live data. Consent-aware init should already be in place for EU compliance; if it is not, treat it as urgent rather than optional.
The Pattern Behind the Patterns
Look across all seven and one theme repeats: the reward must be earned by a real, verified signal, and the game must survive every path around it. That is why the completion callback is the spine of a clean integration. A web-first SDK like AppLixir exposes an explicit status contract precisely so the reward can be gated on complete and nothing else — the rest of the scorecard falls out from getting that one contract right.
If you build against the scorecard, most of these bugs never ship. If you retrofit an existing integration, start at mark two — verified completion — and work outward. It is the one that quietly costs the most.
FAQ
How do I verify a rewarded video was actually completed?
Gate the reward on the SDK’s completion signal, not on the ad-close event. In the AppLixir contract, that means confirming status.type === “complete” inside the callback before granting anything. Ad-close means the surface went away; completion means the player earned it.
What should happen if there’s no ad to show?
Treat no-fill as a normal outcome. Detect it in the callback, restore game state immediately, and let the player continue — ideally with a small fallback or a retry option. Never leave the player on a spinner that cannot resolve.
Where should I place the rewarded video offer?
At a natural decision point where the player already wants something: a revive, a currency top-up, or a level-end bonus. Avoid interrupting active play with an unprompted offer, and cap how often the offer appears per session.
Does consent handling reduce my rewarded revenue?
The opposite. A consent-aware init that resolves the TCF/GDPR state before requesting an ad is what unlocks premium European demand. Requesting before consent is known produces empty fills and compliance exposure.
Should I preload the rewarded ad or load it on demand?
Preload. Request the next ad in the background once the previous outcome resolves, so the offer is instant when the player taps. Lazy-loading at the tap builds a delay into your highest-value moment.
Build rewarded video the right way
AppLixir is a web-first rewarded video platform built for HTML5, WebGL, and browser-based games — with an explicit completion contract, privacy-first consent handling, and clean no-fill behavior baked in. See the integration reference and start monetizing without breaking retention.
The post Rewarded Video Ad Integration: 7 Real Examples Done Right appeared first on AppLixir – Rewarded Video Ad Monetization.
