Offerwall Monetization: You Are Selling Currency, Not Ad Space
Every guide to offerwall monetization makes the same promise. You have a large population of players who will never buy anything, an offerwall lets them pay with effort instead of money, and the revenue is largely additive. Most of that holds up.
What those guides leave out is the price. An offerwall does not pay you cash for inventory the way a banner does. It pays you cash in exchange for your own currency, which you then hand to the player. That makes the reward amount a pricing decision inside your economy, and a badly set one funds the offerwall out of your in-app purchase revenue.
Here is how to run one without that happening.
What an offerwall actually is, and what it is not
An offerwall is a browsable list of third-party offers inside your app. The player picks one, completes a defined action in the advertiser's product, and a server-to-server postback confirms it. You get paid for the completed action, and you pay the player in your own currency.
Two things get called the same name, so it is worth separating them. Google made Offerwall generally available in Ad Manager in June 2025, after testing with more than a thousand publishers. That product is a content-access choice for web publishers, letting a visitor watch a short ad, take a survey, or pay a micropayment to access content. A promotional graphic in Google's announcement states an average revenue uplift of 9 percent among publishers who implemented it, with no methodology, baseline, or time window given anywhere on the page. Read it as a signal that the reward-for-access model is mainstream now. Google's product is not the same thing as a rewarded offerwall inside a mobile game, and the economics do not transfer.
This post is about the second one.
The exchange rate is the whole decision
Do this arithmetic before you evaluate a single partner.
Take your most common currency pack and figure out what a dollar buys. If a $4.99 pack gives 500 gems, your store sells gems at roughly 100 per dollar of player spend.
Now take a typical offerwall payout, net of your partner's revenue share, because gross offer value is not what reaches you. If a completed offer nets you $1.20 and you reward the player 300 gems, you are issuing gems at 250 per dollar of revenue. Measured per gem, that currency costs you about 60 percent less than the currency your store sells.
Be precise about what that comparison is and is not. The store figure is gems per dollar of player spend; the offerwall figure is gems per dollar of your revenue. The player never sees the $1.20, so nobody works this out consciously. What the comparison measures is how much you earn per gem you mint, and when that falls well below your store rate you are minting cheap currency at scale. Players do not notice the arithmetic. They notice that gems feel easy to get, and the perceived value of the pack quietly falls.
The fix is not to underpay the offer, which makes the wall look bad and kills completion. Set the reward so the gems-per-dollar you issue sits at or near the gems-per-dollar your store sells, and let the wall compete on effort against money rather than on price. A player choosing the wall is trading twenty minutes for what a dollar would buy. That is a real trade and it devalues nothing. A player choosing the wall because the currency is simply cheaper there has been handed a discount you did not plan.
Two corollaries. Soft currency and hard currency are not interchangeable here: rewarding hard currency puts the wall in direct competition with your store, while rewarding soft currency, energy, or cosmetic items usually does not. That rule holds only if your store does not also sell the soft currency, which builder, farming and 4X titles frequently do, and in those games soft currency competes exactly as hard currency would. Second, the rate needs rechecking every time you run a sale, because a storewide discount moves your benchmark and the wall does not move with it.
What to measure instead of eCPM
Asking an offerwall partner for their eCPM is asking the wrong question, and a high answer should increase your suspicion.
Nobody has standardized what an offerwall impression is. A button render, a screen view, a wall open and an offer view are four different denominators, and the choice is a convention, not a measurement. Divide revenue by the impressions of an entry-point button and you can produce almost any eCPM you like depending on where the button sits. With engagement as low as it is on this format, changing the definition moves the number several-fold. The result is not comparable to a rewarded video eCPM, and it is not comparable across partners either.
What to look at:
ARPDAU across the whole audience. This tells you whether the wall added revenue or moved it. Watch it alongside your in-app purchase ARPDAU, because the failure mode is total ARPDAU staying flat while the mix shifts from purchases to offer completions.
Revenue per engaged user and engagement rate, reported separately. Collapsing them into one figure hides which half is moving, and on this format the two numbers tell opposite-looking stories.
In-app purchase conversion in the cohort that used the wall. Compare it against a matched cohort that did not. If offerwall users convert to payers at a lower rate afterward, you have found the cannibalization, and the reward rate is the first place to look before blaming the format.
Fill by geography. Rewarded demand is bought on CPA with geo targeting and payout caps, so coverage is uneven by design. A wall that performs well in the US but surfaces three offers in Southeast Asia is two different products for two parts of your audience, and a blended fill rate hides that. We have not seen independently published fill-rate data by region, which is a good reason to ask any partner for theirs before you sign.
The counter-case, and why the reward rate still governs
The strongest public data on offerwall engagement runs against the argument above, and leaving it out would be convenient.
Kongregate published an analysis on Game Developer reporting that engagement with the offerwall averaged between 0.5 and 1.0 percent of users, that 93 percent of players who engaged were non-payers, and that the revenue was "almost all additive." It also found that non-payers whose first transaction came through the offerwall went on to buy at several times the rate of players who never engaged. That is a single title, the author worked for the company running the wall, and it was published in 2016, so treat it as directional. It remains the only substantial public figure on offerwall engagement.
Both things can be true. At 0.5 to 1 percent engagement, a wall priced sensibly is nearly all upside, because it is reaching a sliver of your audience that was never going to pay. The cannibalization risk does not come from the format reaching too many people. It comes from the reward rate teaching the people it does reach what your currency is really worth. That is why the rate, not the decision to run a wall, is the thing to get right.
Where the entry point goes
Placement does more for offerwall revenue than partner selection does, and the right moment is narrow.
The out-of-currency moment is the one that works, and it works for a pricing reason. The player wants something, cannot afford it, and is already comparing what your store charges against what the alternative costs in effort. That is the only moment at which the wall and the store are being weighed against each other, which is exactly when you want the wall to appear. The same wall on a permanent home-screen button is furniture, and it earns like furniture.
A few things follow:
Put it next to the store at that decision point and let the player pick effort or money. Hiding the store behind the wall and hiding the wall behind three menus both cost you.
Label the reward in the entry point. "Get 300 gems" earns more than "Free rewards," and it sets an expectation the wall can meet, which keeps completion honest.
Do not interrupt with it. An offerwall that surfaces mid-session, unprompted, reads as an ad break in a game the player was absorbed in, and the cost lands in session length, not in your revenue report.
Where it sits relative to mediation
An offerwall is not a waterfall line item and it does not behave like one. It is a persistent surface with its own entry point, integrated through a webview or an API, not bid into an ad slot against rewarded video. That has two consequences worth planning for.
It does not compete with your rewarded video inventory for impressions, so adding it does not split demand across the two. The competition is for the player's attention at the moment they need currency, which is a product decision, not an auction one.
And because it sits outside mediation, its revenue will not appear in your mediation reporting. You need the partner's reporting reconciled against your own event data, and somebody has to own that reconciliation before the first invoice arrives.
Who should not see it
A position worth stating plainly: suppress the offerwall for players who have purchased recently.
The argument against is real. Payers are the most engaged users, they convert on offers at a higher rate, and the Kongregate analysis above found payers who engaged with the wall showed higher average revenue per paying user, not lower. The argument for is the exchange rate. A player pays $4.99 for 500 gems. Show them a path to 300 gems for twenty minutes of effort and you have given them a reason to regret the purchase, and the revenue you collect on that offer is frequently smaller than the next purchase you lose.
A defensible default is to show the wall to players with no purchase in the last 30 days, and to test the window rather than assume it. Whatever you choose, attach a number to it instead of inheriting a default from the SDK.
What it costs you to run
Four costs teams underestimate. None of them is a reason to skip the format.
Integration. Not just an SDK. You need a server-side reward endpoint, idempotency on that endpoint so a retried postback does not pay twice, reconciliation against the partner's reporting, and a way to claw back a reward when an offer is reversed for fraud. Retry behavior is standard in server-side reward verification: Google's own rewarded-ads documentation notes that callbacks are re-attempted up to five times at one-second intervals when a success response is not returned, which is precisely the double-pay scenario an endpoint has to be built against.
Support triage. Players who completed a task and did not get credited will blame your game first, whatever the cause. Good offerwall partners run their own end-user support flow for missing credit, so the work on your side is triage and a clear escalation path into theirs. Agree in advance who answers the first ticket and what evidence settles it.
Economy monitoring. Once the wall is live, your currency faucet has a new inlet whose size you do not control. A successful offer campaign can inject more currency in a week than a planned event, so the sink side of the economy needs watching.
Experience for nonpaying players. The wall exists for them, and if it is badly placed it is also the thing that makes your game feel like an ad product. That cost does not show up in ARPDAU for several weeks.
What Apple and Google allow
Both permit incentives and restrict the form they take. Read the current text before launch.
Apple's App Store Review Guidelines state at 3.2.2(x) that apps "must not force users to rate the app, review the app, download other apps, or other store-related actions in order to access functionality, content, or use of the app," and that apps "may otherwise incentivize users to take specific actions within apps (such as by completing a level or watching an ad)." Two more clauses in the same section matter to a publisher integrating a wall: 3.2.2(i) prohibits "creating an interface for displaying third-party apps, extensions, or plug-ins similar to the App Store or as a general-interest collection," and 3.2.2(iii) prohibits "artificially increasing the number of impressions or click-throughs of ads, as well as apps that are designed predominantly for the display of ads."
Google's User Ratings, Reviews, and Installs policy prohibits inflating ratings, reviews or install counts "by illegitimate means, such as fraudulent or incentivized reviews and ratings," and names "incentivizing users to install other apps as the app's main functionality" as a violation.
The restriction most likely to catch a publisher out is neither of those. Google Play's Families ads and monetization policy names offerwalls directly. Where children are the sole target audience, it prohibits "monetization and advertising that are not clearly distinguishable from your app content, such as offerwalls and other immersive ads experiences." Apps serving ads to children or to users of unknown age must use only Google Play Families Self-Certified Ads SDK versions and must not serve interest-based advertising or remarketing to those users, and the policy requires the app and every SDK in it to comply with the US Children's Online Privacy Protection Act. Apple applies comparable advertising restrictions to apps in the Kids Category.
So: if your app is child-directed, or if a meaningful share of your audience is of unknown age, an offerwall is not a format to optimize. It is a format to leave out.
The practical reading for everyone else: never accept an offer that rewards a store rating or review, keep the wall as one feature among many rather than the point of the app, and look at how the partner renders the offer list before you ship it.
Who should skip it
Child-directed apps and anything in Apple's Kids Category, for the reasons above. This is a compliance answer, not a judgment call.
Beyond that: apps with a small or highly monetizing audience, where the engaged population is almost entirely payers and the wall has nobody new to reach. Apps with no meaningful currency or consumable, since there is nothing to reward with and a cash-equivalent reward is a different and harder product. And apps in the middle of an economy rebalance, where adding an uncontrolled faucet will make the rebalance unreadable.
Everyone else with a large nonpaying population and a currency sink worth filling has a real line of revenue here, provided the exchange rate is set on purpose.
Edge226's rewarded inventory sits in the Adscend Media Offerwall. Adscend was founded in 2009 and Edge226 acquired it in July 2025. The advertiser's view of the same mechanism is in our posts on buying offerwall traffic that retains and why offerwall buyers pay for finished outcomes, both worth reading if you want to know what the demand side is optimizing for when it bids on your placement. To walk through the exchange-rate arithmetic against your own pack pricing, get in touch.
FAQ
What is offerwall monetization?
Offerwall monetization is a method where players complete defined actions in third-party apps in exchange for your in-app currency. The publisher is paid per completed action, confirmed by a server-to-server postback, and pays the player in currency, not cash. It targets the nonpaying population, which is usually the large majority of an app's audience.
How much does an offerwall pay?
There is no single rate. Payouts are per completed action and vary by offer, geography, and the depth of the action, and your partner's revenue share sits between the advertiser's payout and what reaches you. The more useful question is what your revenue per daily active user becomes once the wall is live, and whether your in-app purchase revenue held while that happened.
Does an offerwall cannibalize in-app purchases?
It can, and the cause is almost always the reward rate, not the format. If the currency a player earns through the wall costs you far less per unit than the currency your store sells, you are minting cheap currency and the perceived value of your packs falls with it. Set the reward against your pack pricing and recheck it whenever you run a sale.
Is eCPM the right metric for an offerwall?
No. There is no standard definition of an offerwall impression, so the denominator is a convention set by whoever is reporting, and with engagement this low a change in definition moves the number several-fold. It is not comparable to a rewarded video eCPM or across partners. Track ARPDAU across the whole audience, with engagement rate and revenue per engaged user reported separately.
Are offerwalls allowed by Apple and Google?
Yes for general-audience apps, within both platforms' rules on incentivized activity, and no for child-directed ones. Google Play's Families policy names offerwalls as prohibited where children are the sole audience, and Apple restricts advertising in the Kids Category. For everyone else, Apple permits incentivizing actions inside apps while barring forced store actions and App Store-like catalog interfaces, and Google bars incentivized ratings and reviews, along with apps whose main function is incentivizing installs of other apps.
