Rewarded video for app publishers

A rewarded video is a full-screen video ad that a player starts on purpose. In exchange, the app gives something of value: extra lives, coins, a hint, a continue, or a piece of content that would otherwise be locked. The player can refuse. If they leave before the required watch time, they should not get the reward.

That exchange is why the format usually earns more than a banner or a forced break. A demand-side platform is not paying for “a video somewhere in the app.” It is paying for a person who opted in and, in most campaigns, stayed until the end. If your placement looks like a rewarded ad but behaves like an interstitial the player can skip, the bid falls.

This guide is about the ad itself. Which integration to use — OpenRTB or Prebid — is covered in OpenRTB vs Prebid for gaming publishers. The fields below matter on either path.

What the player actually sees

A clean rewarded placement has four beats. Miss one and both the player and the buyer notice.

1. The offer. The game says what the player gets, in the game’s own language. “Watch a short video for 1 continue” is clear. “Watch ad” with no reward named is not.
2. The choice. There is a way to say no. A continue screen that only has “Watch” and no “End run” is not an opt-in. It is a gate.
3. The ad. The video plays full screen. The player knows how long it is, or at least that it will end. A close control that appears before the reward is earned must be honest: leaving means no reward.
4. The payout. When the video finishes, the game grants exactly what it promised, immediately. A reward that arrives on the next session, or not at all, trains players to stop tapping.

The industry shorthand is simple. The user opts in. The creative plays. The reward is granted only after the required view. IAB’s rewarded-video guidance is built on that sequence. You do not need a protocol document to explain it to a product manager. You do need the sequence in the build, because buyers cannot see your UI. They see completion, close rate, and whether the same user keeps opting in.

Rewarded video is not an interstitial

An interstitial appears between levels, on a pause, or at app open. The player did not ask for it. They wait, or they close it. Many interstitials are skippable after a few seconds. They are useful inventory. They are a different product.

Rewarded inventory is scarce on purpose. You cannot show it every thirty seconds without cheapening the reward. Players who feel tricked stop opting in. When opt-in falls, so does the one thing buyers liked: a high chance the video plays through.

Publishers sometimes label a forced video as rewarded because the eCPM in a test was higher. Demand partners catch this. A placement with a rewarded flag and a skip rate that looks like an interstitial gets bid down, then blocked. The flag is a promise. Break it once in the data and the seat remembers.

Why a skipped placement pays less

Three different buyers can sit on the same impression. They do not punish a skip for the same reason, but they all pay less.

• A buyer who pays on completion. Cost per completed view only counts if the VAST complete event fires. Close the ad at second five and that buyer owes nothing for the play. Your report may still show an impression. Their report will not show a conversion of the video.
• A buyer who pays on the impression but optimizes to completion. They look at historical completion on your app and placement. If 40% of “rewarded” plays end early, the expected value of the next bid drops. The CPM follows. They do not need to catch one user skipping. They need a week of closes.
• A brand buyer who wanted the message seen. A rewarded opt-in is attractive because attention is voluntary. An early close means the logo might have flashed and nothing else. They will not pay a rewarded price for a two-second glimpse. How those two seconds relate to a viewable impression is a separate count, covered in how viewability is counted on video.

There is a fair version of skip. Some games let the player leave and forfeit the reward. That is acceptable if the bid request said the ad was skippable, and if you do not grant the reward. It is not acceptable to tell the DSP the video is non-skippable, then show a close button at five seconds and still fire a complete event. That is how a good placement becomes traffic a DSP rejects. The broader pattern is in why DSPs reject otherwise good traffic.

Duration has to match the skip rule. If the buyer sends a 30-second creative and the player can leave at 5 seconds without losing anything they care about, you do not have a rewarded ad. You have a short interstitial with extra steps.

What to promise, and what to grant

The reward is a product decision, not an ad-server setting. Buyers rarely need the name of your currency. Players do.

• Name the reward before play. Coins, a life, a hint, a chapter, a streak save. One reward, not a vague “bonus.”
• Keep the amount stable for that button. Changing “1 life” to “maybe a chest” after the tap feels like a bait.
• Grant it only after the required watch. If your rule is “full video,” do not grant it at the quartile.
• Grant it even when the game is offline after the complete event, or tell the player you cannot. Silent failure is the fastest way to kill opt-in.
• Do not grant it on a click-through alone if the offer was “watch.” A click is a different campaign.

OpenRTB’s standard signal is that the impression is rewarded. It does not have a required field for “50 coins” or “1 life.” Some exchanges add an extension for the reward name and amount. Send that only if the buyer asked for it. Do not invent a value in the bid request that the game will not honor.

The OpenRTB fields a DSP needs

A bidder decides in well under a second. If the request does not say this is a rewarded, full-screen, opted-in video, the bidder treats it as ordinary in-app video or does not bid. These are the fields that carry that story in OpenRTB 2.5 and 2.6.

Say it is rewarded

• video.rwdd set to 1. This is the standard flag: the user can receive something of value for watching. 0 means it is not rewarded. Omitting it is not a safe substitute for 1.
• video.plcmt for the kind of placement. Rewarded videos are usually 3 (interstitial) or 4 (standalone, no content stream). Do not mark a rewarded opt-in as instream. There is no content stream. The player stopped the game to watch.
• imp.instl set to 1 when the ad is full screen. Rewarded videos almost always are.

Say how long it plays, and whether they can leave

• video.minduration and video.maxduration in seconds. A common rewarded length is 15 to 30 seconds. If you only have a 15-second slot, do not advertise a 30-second max and then cut the creative.
• video.skip. Use 0 if the player must watch to the end to earn the reward. Use 1 only if leaving early is possible.
• video.skipmin and video.skipafter when skip is allowed. skipafter is when the close control may appear. If the reward requires a full watch, do not tell the DSP the ad is skippable at five seconds.
• video.linearity set to 1 for a linear ad that takes over the screen.

Say what creative can play

• video.mimes, almost always including video/mp4.
• video.protocols for the VAST versions you can play. Supporting VAST 2.0, 3.0, and 4.x covers most programmatic video demand.
• video.w and video.h for the player size in pixels. Full-screen phone video should match the orientation you actually show. A landscape game that plays a portrait creative in a tiny box will not hold the completion rate you sold.
• video.playbackmethod so the buyer knows the ad starts on the tap, not as a muted autoplay in a corner.

Say which app, and which user you are allowed to name

• app.bundle and app.storeurl. Buyers check the store page and app-ads.txt on the developer domain. A missing bundle is a common no-bid on in-app video.
• app.name and a stable publisher or app identifier your exchange already gave the buyer.
• device.os, device.make, and device.model. Rewarded creatives are built for phones. A request that looks like a desktop browser will not match.
• device.ifa only when you have a lawful basis to send the advertising ID. If the player opted out, or the app is child-directed, omit it. Do not send a zeroed ID and hope. Consent strings for Europe and US state laws are covered in GPP and TCF in the bid request. India’s DPDP duties for a foreign DSP are a separate note.
• regs.coppa set to 1 when the app is directed at children under 13 in the United States. Rewarded ads in a kids’ app are still possible. They are not an excuse to attach an advertising ID.

Also send a real imp.bidfloor in the currency you agreed, and a source.tid so the same chance to watch is not auctioned five times. Duplicate requests waste the buyer’s QPS and can make one opt-in look like fraud.

How the ad is served and how you get paid

The bid response carries a VAST document, or a URL that returns one. Your player loads the media file, plays it, and fires the tracking events: start, quartiles, and complete. The complete event is what a completion buyer waits for. It is also the right moment for your game to grant the reward. Tie those two together in code. If complete fires and the reward does not, you will see opt-in fall over the next week. If the reward is granted and complete never fires, you will see revenue fall and the buyer will think the placement is broken.

Win and billing notices are separate from VAST quartiles. Which URL should add spend — the win notice or the billing notice — is explained in nurl, burl, and lurl. Do not add a second bill when the complete pixel fires unless the contract says you sell on completion and the buyer expects that event to be the invoice.

Where this sits next to mediation and Prebid

Most mobile games do not call every DSP from the app. A mediation platform runs a waterfall or an in-app bidding auction, and one or more of those networks speak OpenRTB on the server. Prebid is the usual tool when the game is on the mobile web, or in a WebView that already runs a header-bidding wrapper. Native games with a high volume of rewarded impressions are usually happier on server-to-server OpenRTB, because the auction does not have to finish inside the tap that opened the ad.

The player does not care which pipe you used. They care that the video starts quickly after the tap. A rewarded offer can wait a little longer than a surprise interstitial, because the player asked for it. It cannot spin for several seconds. Timeouts, and what to do with a slow bidder, are in Prebid timeouts that still let demand compete. If you are still on a single JavaScript tag inside a WebView, read when a JS tag is enough before you scale rewarded traffic. Tags hide the fields in this guide. Buyers cannot bid on a flag they never receive.

Publishers choosing a partner in India should ask how rewarded traffic is declared, not only what the headline CPM was last month. A checklist for that market is in SSPs for app publishers in India.

How often to offer it

Rewarded video is a pressure valve, not a slot you refresh. A few rules keep the eCPM from eating itself:

• Cap opt-ins per user per session, and per day. Unlimited continues funded by ads train buyers to expect low-quality loops.
• Offer it at a moment of need: out of lives, out of moves, end of a level, a locked chest. A button on every menu looks like leftover inventory.
• Do not stack a rewarded video and an interstitial on the same transition. The player experiences one long ad. The second impression’s completion collapses.
• Keep a no path that is real. If “no” still forces a video, you have removed the opt-in that justified the CPM.

Frequency caps also protect the advertiser. The same user watching ten rewarded ads in one session is not ten attentive viewers. It is one person farming a reward. DSPs that frequency-cap on their side will stop bidding. Your fill will look mysteriously soft.

A build checklist

• The button names the reward before the ad starts.
• The player can decline.
• The reward is granted only after the watch you promised, in the same session.
• The bid request sets video.rwdd to 1, full-screen, with an honest skip flag and a duration you can actually play.
• VAST complete and the in-game grant happen together.
• Early close does not grant the reward and does not fire complete.
• The app bundle, store URL, and app-ads.txt match.
• Advertising IDs are omitted when consent or a child-directed flag says they must be.
• One opt-in produces one auction, not a fan-out of identical requests.

FAQ

Do I have to make rewarded video non-skippable?

No. You have to match the request to the UI. If the reward requires a full watch, tell the DSP it is not skippable, and do not show a close button that keeps the reward. If you allow an early exit, mark it skippable and withhold the reward.

Is rewarded video only for games?

Games are the usual home, because they have a currency. News apps, streaming apps, and utilities use the same shape when they unlock an article, an episode, or a feature. The bid still needs rwdd=1 and a real opt-in. A video that merely plays before a screen is not rewarded.

What if the DSP does not read video.rwdd?

Some older bidders still look for a private extension or a placement name. Send rwdd anyway. Ask the buyer which extra field they still require during integration, and do not drop the standard flag to satisfy a legacy one.

Why is my rewarded eCPM close to my interstitial eCPM?

Usually the data says players are not finishing, the reward is not obvious, or the request is not marked rewarded. Compare completion rate, opt-in rate, and whether rwdd is present on the sample the buyer logged. The integration path is the next place to look, not the first.

← All posts · OpenRTB vs Prebid for gaming · Video ads · What is OpenRTB? · Publisher monetization