A Game Advertiser's Guide to Buying Offerwall Advertising: Pricing Models, Event Payout Design, Vendor Questions, and a Pilot Plan
As of September 2026, offerwalls have become a channel that most game UA managers end up putting on their evaluation list at some point. In its 2025 ROI Index, mobile measurement company Singular found that almost a third of the fast-growing class of ad networks sit in the rewarded or incentivized space, and AppsFlyer's 2025 Performance Index, which analyzed 16.2 billion non-organic installs from 39,000 apps across 88 media sources, noted that rewarded platforms posted major gains in the Android gaming rankings. More suppliers means more options, but what is sold under the same "offerwall campaign" label varies widely from one supplier to the next.
Singular points to a low barrier to entry as the reason so many new companies are moving into the space: if rewards are paid out outside the game, a supplier can launch without an SDK inside any game. For an advertiser, that means the same price can buy very different players depending on who you buy from. In offerwall buying, structural design and supplier vetting come before price negotiation.
Most of the offerwall coverage on this blog so far has been from the publisher side, about adding an offerwall to a game to earn revenue. The publisher-side numbers are covered in How Much Do Offerwalls Really Lift Retention and Revenue? 2026 Benchmarks and the Conditions That Cannibalize IAP. This piece is for the other side of the table: the advertiser buying campaigns on offerwalls. It follows the order of a purchase decision, from pricing models and how to split payouts across events, to quality and fraud control, the questions to send vendors, and the design of a first pilot.
What are you actually buying when you buy offerwall advertising?
On an offerwall, the advertiser buys a performance placement: a spot for your game in a list of rewarded offers inside other apps, paid for only when a player meets the conditions you set. The key difference from other formats is that players do not install after seeing an ad. They choose a task after seeing a reward.
In this structure, the advertiser's payout does two jobs at once. It is the price, and it is also the creative. AppsFlyer explains that the reward shown to users on an offerwall is usually based on how much the advertiser is bidding. Lowering your payout does not just reduce cost. It makes your offer look less attractive in the list and, depending on how the supplier sorts offers, can push it further down. That is why on an offerwall, adjusting the payout is a creative test.
Pricing falls into four broad models.
Pricing model | When you pay | What the advertiser gets | What to watch |
|---|---|---|---|
CPI | Install confirmed | Largest volume, lowest unit price | Highest share of players who claim the reward and uninstall |
CPA | One defined in-game action completed | Cost only for players who reach the action | A single action makes it hard to balance volume and quality |
CPE | Engagement condition met (playtime, repeat logins, etc.) | Players with confirmed engagement | Confirm the definition and verification of the condition in writing |
Multi-event (multi-reward) | Each of several events completed, with a payout per event | Cost and reward split across stages | Total payout, per-event split and completion windows all need to be designed |
The most common form on offerwalls is the last one. An easy first step such as install or tutorial completion brings players in, and larger payouts sit on deeper steps such as reaching a level or making a first purchase. It splits the logic of CPA across several stages, so the core concepts are the same as in Buying CPA Advertising for Mobile Games: What to Pay For, How Much, and From Whom, but it adds a new design problem: how to distribute the payout between stages.
Which events should a multi-event offerwall offer pay for?
A good multi-event offer makes the first step easy, places the last step at the point where your game's long-term value starts to split, and connects the two so that players pass through the core of the game along the way. Three to five steps is typical, and each step has a completion window.
The criteria for choosing steps are the same as for a single CPA action. In your own cohort data, find the point where the gap in D30 retention and cumulative revenue between players who completed an event and those who did not begins to widen, and put that point near the last step. What is different is the role of the middle steps. For players, they are intermediate rewards that keep them from giving up before the final step. For the advertiser, they are diagnostic checkpoints that show where players drop out.
Below is an example for a hypothetical mid-core RPG. All steps, windows and payouts are assumptions for illustration.
Step | Event | Completion window (after install) | Event payout (assumed) | Cumulative payout | Why this step is here |
|---|---|---|---|---|---|
1 | Install + tutorial complete | 1 day | $0.80 | $0.80 | Lowers the threshold to join the offer |
2 | Reach level 10 | 3 days | $1.50 | $2.30 | Confirms entry into the core loop |
3 | Reach level 25 | 7 days | $3.00 | $5.30 | Confirms repeat play in week one, where long-term value starts to split |
4 | First purchase | 14 days | $5.00 | $10.30 | Selects players who turn into revenue |
Three design mistakes come up often. The first is setting the last step too deep. A step almost nobody reaches within the window is a reward players never see and a signal the supplier's optimization never receives. The second is overpaying for the first step. An expensive first step produces volume, but you are effectively buying expensive CPI. The third is letting every reward end at a single event. If there is no reason to keep playing after the last reward point other than the reward itself, players leave right there.
Whether to include first purchase as a step depends on your revenue model. For games where ad revenue carries a large share, a retention event such as a D7 login may be a better final step than first purchase.
How do you set each event's payout from LTV and payback?
Per-event payouts are validated at the cohort level: take the step-by-step completion funnel per 1,000 installs and the LTV by depth reached, and check whether the whole cohort's payback-window ROAS hits your target. The sum across the cohort matters more than any single event price.
Applying an assumed completion funnel and D90 net revenue to the example ladder gives the following. Here LTV means the D90 net revenue of a player who reached that step and stopped there.
Segment | Players (per 1,000 installs, assumed) | D90 net revenue per player (assumed) | Total revenue | Payout for that event |
|---|---|---|---|---|
Did not complete step 1 | 300 | $0.05 | $15 | $0 |
Stopped at step 1 | 350 | $0.30 | $105 | 700 players × $0.80 = $560 |
Stopped at step 2 | 200 | $1.50 | $300 | 350 players × $1.50 = $525 |
Stopped at step 3 | 110 | $6.00 | $660 | 150 players × $3.00 = $450 |
Completed step 4 | 40 | $25.00 | $1,000 | 40 players × $5.00 = $200 |
Total | 1,000 | $2,080 | $1,735 |
Under these assumptions, D90 ROAS is 2,080 ÷ 1,735 ≈ 120%, and the cost per install equivalent is about $1.74. If your target ROAS is 120%, this ladder is set at break-even against that target. The figures are illustrative, and real values vary widely by game and region. The method for calculating LTV by depth is the same as in the pricing section of the CPA guide.
What to read in this table is less the single ROAS line than the distribution of cost and revenue. In the example, about 62% of total payout ($1,085) goes to steps 1 and 2, while about 80% of revenue ($1,660) comes from players who reach step 3 or beyond. With a distribution like that, it is worth testing a shift that lowers the early payouts and raises step 3. Push the early payouts too low, though, and the offer loses its appeal in the list, which can shrink the number of players who ever reach step 3. Make the shift in small increments inside a pilot rather than all at once.
One more thing to confirm when setting the total payout is how much of it the supplier shows to players as a reward. The same $10.30 can drive different participation depending on how large the visible reward is and how it is displayed, and that changes every number in the funnel above.
How do you manage quality and fraud in offerwall traffic?
Quality control for offerwall traffic means looking at what happens after the reward ends. Meeting the reward condition and continuing to play are two different things. The advertiser pays for the first, but revenue comes from the second.
The quality gap has been documented for a long time. AppsFlyer's analysis of rewarded advertising, first published in 2017, put average D30 retention for gaming apps at 2.4 to 4.4% versus 1.1% for incent-heavy networks, and noted that most users do only the minimum steps required to get the reward and then delete the app. Google stated in a 2017 policy post that incentivized users generally have lower retention and make fewer in-app purchases than users from paid or organic channels. Both observations come from a period when install-based rewards dominated, so the first way to close the gap is to move the weight of payout and reward from the install to in-game events.
The second is keeping your metrics clean. A 2020 study of incentivized installs on Google Play, presented at ACM IMC, found that campaigns requiring in-app tasks after install can artificially inflate engagement metrics such as DAU and session length. For an advertiser, that means blending offerwall cohorts with other channels can distort your game-wide retention and session metrics and your LTV models. Always measure offerwall traffic as a separate media source and campaign.
The third is transparency at the sub-publisher level. The volume from one offerwall supplier actually comes from dozens or hundreds of publisher apps. AppsFlyer has ad networks identify publishers through the site ID parameter in the attribution link, and notes that traffic arriving with an empty site ID can signal either a technical issue or an attempt to bypass fraud detection. If you cannot see results by sub-source and block problem sources individually, the only quality lever left is turning the whole supplier on or off.
The last is store policy. Google Play prohibits manipulating store placement through means such as incentivizing installs of other apps as an app's main functionality or rewarding ratings and reviews, and has said it may filter incentivized installs used to game rankings and remove apps from top charts. Apple's App Store Review Guideline 3.2.2(x) says apps must not force users to take store-related actions such as downloading other apps, while allowing incentives for actions within apps, such as completing a level or watching an ad. The advertiser's rules are simple: never put a reward on ratings or reviews, never buy concentrated volume to move chart rankings, and tie rewards to in-game actions.
General fraud controls, such as the distribution of time from install to event completion, retention after the event, and contractual rejection terms, are covered in How to Prevent Offerwall Fraud in Mobile Games and in the CPA guide. Multi-event offers add one more check: time to completion for each step separately. A cluster that reached step 3 faster than any human could costs more the deeper the step.
What should you ask an offerwall or rewarded engagement vendor?
The core of vendor evaluation is not the rate card but where players come from and why, and whether you as the advertiser can check and control quality yourself by step and by source. The questions below are written so you can send them as-is in an RFP or a first meeting.
Area | Question to ask | What you are checking |
|---|---|---|
Supply | Which apps and placements show the offer? Is the reward in-game currency or something used outside the game? | Whether players come because they care about games or for the reward itself |
Sub-source transparency | Can you report results by sub-publisher (site ID) and let us block sources individually? | Ability to manage quality by source |
Reward conversion | How much of our payout is shown to players as a reward, and in what form? Is the reward shown per event? | Offer appeal and motivation at each step |
Ranking | What determines the sort order of offers on the wall? | How payout changes affect volume |
Event verification | Are billable events confirmed only through MMP in-app event postbacks? | Whether your data and the billing basis match |
Completion windows | Can the advertiser set a completion window per event? How are completions after the window handled? | Flexibility in payout ladder design |
Caps and pacing | Can we set daily, total and per-event caps? | Preventing early overspend |
Rejections | If a player is found fraudulent, how are payouts already made for earlier steps reconciled? | Grounds for post-campaign reconciliation |
Reporting | Can we see the step-by-step completion funnel, time to each step, and retention after the final event, by source? | Access to the data needed to judge quality |
Targeting | Do you choose which players see the offer using data such as genre preference and play history, or show the same list to everyone? | Final-step reach and likelihood of retention afterward |
Policy compliance | How do you prevent rewarded ratings and reviews, and campaigns aimed at chart manipulation? | Store policy risk |
Supply and sub-source transparency are the items to ask about first and in the most detail. With the same payout ladder, traffic from a place where people who love games gather and traffic from users hopping between apps for rewards draw completely different curves after step 3. A broader evaluation framework and RFP structure for comparing advertising platforms, offerwalls included, is covered in How to Choose a Mobile Advertising Platform for Your Game in 2026: Evaluation Criteria, RFP Questions, and Pilot Design.
How should you design your first offerwall campaign pilot?
Design the first offerwall campaign not to produce volume but as a pilot that produces evidence about both the payout ladder and the supplier. The key is to document the duration, total volume, baseline and decision rules before launch.
Item | Recommended design |
|---|---|
Duration | Final-event window plus a retention observation period. If the final window is 14 days, at least four weeks |
Scope | One or two countries, one OS. Too many variables make results hard to read |
Payout ladder | Three or four steps, with the final step at the point where long-term value splits in your own cohorts |
Budget | Fixed with a total cap, with per-event caps to prevent early-step overspend |
Measurement | Separate media source and campaign, sub-source reporting collected from day one |
Baseline | An existing CPI channel or organic cohort over the same period |
Evaluation metrics | Step completion rates, cost per player reaching step 3, D7 and D30 retention after the final event, D30 ROAS and projected payback |
When the pilot ends, summarize the result as one of four outcomes. If final-step players match or beat existing channels on retention and projected ROAS, raise the caps and scale. If quality is good but volume is short, raise the early rewards slightly to increase participation. If volume is there but drop-off after step 3 is heavy, shift payout toward the later steps and redesign the middle. If spend concentrates in particular sub-sources whose later retention is low, block those sources and read the results again.
If you test offers aimed at re-engaging existing players at the same time, you also need to check whether those players would have come back without the offer. For holdout design and sample size, see How to Design an Incrementality Test for Mobile Game UA: Holdouts, Geo-Lift, Sample Size, and Reading the Result.
How does Playio run offerwall-style campaigns?
Playio is a platform that runs campaigns combining an offerwall-style list with in-game action-based rewards, inside a community of five million gamers, on CPI, CPA or CPE terms as the campaign requires.
Here is how Playio answers the supply and targeting questions that the checklist above says to ask first. The user base is a gamer community where people talk about games as part of their daily routine, and AI analyzes genre preference, play history and in-game behavior data to show each offer to the players who fit the campaign's game. Rewards are given when the in-game action the advertiser defined, such as reaching a level or completing specific content, is confirmed, so the process of earning the reward is the process of experiencing the core of the game. Acquisition campaigns for players who have not yet installed the game can be designed together with campaigns that drive the next action from players who already have. The user base is Android-centric globally.
If you are evaluating offerwall campaigns for the first time, we recommend starting the way this guide describes, with a pilot of limited scope. Send your candidate payout events (or the list of in-game events you currently track in your MMP), your target payback window or target ROAS, and your target countries to [email protected]. From those, we will first send a pilot proposal covering the step structure, payout ranges per step, expected volume, and the pilot duration and caps. The questions in the vendor checklist are all fair to ask as-is during that first conversation.
You can find more details here. (https://playioadsen.oopy.io/bizdeck)
Key Takeaways
As of September 2026, the rewarded and incentivized space has grown to almost a third of fast-growing ad networks, and what is sold under the offerwall label varies widely by supplier. On an offerwall, the advertiser's payout is both the price and the reward players see, so adjusting it is a creative test. The most common structure, the multi-event offer, makes the first step easy, puts the last step where long-term value splits, and gives each step a completion window. Set per-event payouts by validating the whole cohort's payback-window ROAS against a per-1,000-install step funnel and LTV by depth reached, and adjust the split by comparing where payout goes with where revenue comes from. Quality control means looking at retention after the reward ends, and the basics are measuring offerwall cohorts separately, sub-publisher transparency, and compliance with store policies such as never rewarding ratings or reviews. When choosing a vendor, check supply and sub-source transparency before price, and start with a pilot whose duration, caps, baseline and decision rules are set in advance.
For inquiries about Playio's advertising solutions, reach out at: [email protected]
Sources
Singular, ROI Index 2025 (almost a third of the growth class of ad networks are in the rewarded or incentivized space; out-of-game rewards mean no SDK is needed in a game, lowering the barrier to entry; based on Singular client data, not the entire ecosystem): https://www.singular.net/roi-index-2025/
AppsFlyer, 2025 Performance Index press release, December 3, 2025 (16.2B non-organic installs, 39,000 apps, 88 media sources; rewarded platforms posted major gains in Android gaming): https://www.appsflyer.com/company/newsroom/pr/performance-index-2025/
AppsFlyer, Rewarded advertising: The good, the bad, and the ugly (first published 2017, updated June 2026; offerwall rewards usually based on the advertiser's bid; average gaming D30 retention 2.4 to 4.4% vs 1.1% for incent-heavy networks; most users do the minimum steps and delete the app; the underlying data period is not stated): https://www.appsflyer.com/blog/mobile-marketing/rewarded-advertising-good-bad-ugly/
Android Developers Blog, Google Play's policy on incentivized ratings, reviews, and installs, June 5, 2017 (incentivized users generally have lower retention and fewer in-app purchases; incentivized installs used to manipulate placement may be filtered and removed from top charts): https://android-developers.googleblog.com/2017/06/google-plays-policy-on-incentivized.html
Google Play Console Help, User Ratings, Reviews, and Installs policy (no incentivizing installs of other apps as an app's main functionality; no rewards for ratings or reviews): https://support.google.com/googleplay/android-developer/answer/9898684?hl=en
Apple, App Store Review Guidelines 3.2.2(x) (apps must not force users to rate, review, download other apps or take other store-related actions; incentives for in-app actions such as completing a level or watching an ad are allowed): https://developer.apple.com/app-store/review/guidelines/
Farooqi et al., Understanding Incentivized Mobile App Installs on Google Play Store, ACM IMC 2020 (incentivized campaigns requiring in-app tasks can inflate engagement metrics such as DAU and session length; lax enforcement of Google Play policy): https://arxiv.org/abs/2010.01497
AppsFlyer Knowledge Base, About link structure and parameters (af_siteid identifies publishers; an empty site ID can signal a technical issue or an attempt to bypass fraud detection): https://support.appsflyer.com/hc/en-us/articles/207447163-About-link-structure-and-parameters