Offerwall Advertising for Advertisers: What You Are Actually Buying
Almost everything written about offerwalls is written for publishers. This is the buy side: what an offerwall campaign actually is, how to choose the billable event, why comparing offerwall retention to search-intent retention is the most common analytical mistake, how to measure incrementality, and when an offerwall buy is the wrong call.
Search for anything about offerwalls and you will find material written for publishers. How to place one, how to price the currency, how much eCPM to expect. Almost nothing is written for the advertiser on the other side of the same transaction, which is odd, because the advertiser is the one paying and the one most likely to misread what they bought.
This is the buy side. What an offerwall campaign is, what triggers a charge, how to pick the billable event, how to measure the result without drawing the wrong conclusion, and when not to run one at all.
What is offerwall advertising?
Offerwall advertising is a form of rewarded performance marketing in which an advertiser lists an offer inside another app's reward catalogue and pays only when a user completes a defined action. The user browses a list of available offers in an app or game they already use, picks one, completes the required action, and receives virtual currency or a reward in the host app. The advertiser is billed for the verified completion, not for the impression, the click, or the browse.
The three parties are the advertiser buying users, the publisher hosting the wall and paying out rewards, and the network sitting between them handling matching, verification, reward crediting and payment. If you want the plainer version of the mechanic, we wrote an explanation without the jargon.
What makes it structurally different from every other way of buying mobile users is the direction of intent. In a feed or an in-game ad break, an algorithm decides you might want to see an offer. On an offerwall, the user reads a list and chooses. That choice is a weaker signal of product affinity than a Play Store search, and a much stronger signal of willingness to complete the specific action you asked for.
What happens between your bid and a billed action
The sequence matters because it explains where things go wrong.
You define the offer. The action, the reward-triggering event, the price you will pay, the geographies, the platforms, and any targeting or exclusions.
The network distributes it. Your offer appears in publisher catalogues that match your targeting. Which publishers, and in what position on the wall, depends on your bid relative to other advertisers competing for the same attention.
A user selects it. They see the action required and the reward on offer, and decide the trade is worth it. Nothing has been billed yet.
They complete the action. Install and open, reach a level, register, subscribe, buy.
Your systems confirm it. A postback from your MMP or server tells the network the event fired for that click identifier.
The network verifies and credits. Fraud checks run, the publisher is credited, the user gets their reward, and your account is billed.
Step five is where most integration problems live. If your postback fires on the wrong event, or fires late, or does not fire for users who arrive without a resolvable identifier, then users complete actions and do not get rewarded. They then contact the publisher's support, the publisher escalates to the network, and your offer gets deprioritized on the wall because it generates complaints. Getting the event definition and the postback right before launch is not paperwork. It is the campaign.
Choosing the billable event: the decision that determines everything
This is the single most consequential choice you will make, and most advertisers make it by default rather than deliberately.
The rule: bid on the deepest event you can measure reliably and that occurs often enough for the network to optimize against. Both halves bind.
Bid too shallow, on install-and-open alone, and you will buy volume you do not want. Users complete the minimum, collect the reward, and never return, and your cost per meaningful user ends up far above what the CPI implied. Bid too deep, on an event that fires a handful of times a week, and the network has nothing to learn from and publishers cannot forecast their payout, so your offer will not get good placement.
Practical guidance by app type:
Games. A progression milestone usually beats an install. Level five, tutorial completion, or first session past a set duration filters out reward-only users while still firing often enough to be a usable target.
Subscription apps. Trial start is the standard event, and it is a trap if your trial-to-paid rate is weak, because you will pay for trials that never convert. Where the network supports it, bidding on the paid conversion and accepting lower volume is usually better economics.
E-commerce. First purchase, with a minimum basket value if the network can enforce one. Registration alone attracts users who register and leave.
Fintech. Account funding or verification completion, not sign-up. The gap between those two events is where almost all of the wasted spend sits.
Write the event definition down precisely, including what does not count, and get the network to confirm it in writing before launch. "Registration" means at least four different things depending on who is reading it.
What offerwall users are actually like
Here is the part most vendor material skips.
Offerwall users are motivated in part by the reward. That is the mechanism, not a defect, and it has consequences you should plan for rather than discover. Day-30 retention on a rewarded cohort typically looks different from an organic install or a Play Store search install, because the two populations arrived for different reasons. A user who searched for your category wanted your product. A user who completed your offer wanted currency in a game and was willing to try your product to get it.
The mistake almost every first-time offerwall advertiser makes is comparing those two retention curves side by side, seeing the gap, and concluding the traffic is bad. The comparison is invalid, because you did not pay the same price for the two cohorts and you were not exposed to the same risk. On search you paid for clicks regardless of outcome. On the offerwall you paid only for users who completed the action you specified.
The valid comparison is cost per user who reaches your value event, measured against your other paid sources at the same point in the funnel. Run that comparison and rewarded traffic often looks materially better than the retention curve suggested, because you never paid for the users who did not get there.
Two things that genuinely follow from the reward motivation:
Set the billable event past the reward. If your event fires before the user has done anything you value, the reward motivation is all you are buying. If it fires after, you have filtered.
Expect a different LTV curve, and model it separately. Blending rewarded users into a single LTV assumption with your search traffic will make both numbers wrong.
How to measure an offerwall campaign properly
Three methods, in increasing order of how much they will tell you.
Attributed reporting. Your MMP tells you how many billable events came from the network and what you paid. This is the floor, and it answers only whether the network delivered what it invoiced for. It says nothing about whether those users would have arrived anyway.
Cohort comparison at the value event. Track the rewarded cohort to your real value event, whether that is a purchase, a subscription, or day-7 retention, and compute cost per user who reaches it. Compare that number against the same number for your other paid sources. This is the comparison most teams should be running and most are not, because it requires you to have defined a value event and to be able to segment by source.
Incrementality testing. A geo holdout or a randomized holdout tells you how many of those users were genuinely additional. This matters more for offerwall than for most channels, and in an encouraging direction: rewarded inventory does not compete in the same auctions as your Google and Meta campaigns, so it is structurally more likely to add users rather than reallocate them. That is a claim worth verifying rather than believing, which is exactly what a holdout does. Ask any network whether they will support one. A network that will not is telling you something.
Where the traffic comes from, and how to control it
Offerwall supply is not uniform, and the difference between good and bad placement is the difference between a campaign that works and one that quietly does not.
What to ask for and act on:
Publisher-level reporting. You should be able to see which apps your budget reached and how each performed against your value event, not just an aggregate.
Publisher-level bidding and exclusions. The ability to bid up a source that converts and cut one that does not. Without this you are dependent on someone else noticing.
Geography-level pricing. A blended global CPA hides enormous variation. Ask for country-level numbers for the countries you actually care about.
How rewards are presented. If a publisher's wall is misleading about what the user has to do, the user completes the action feeling tricked, and that lands on your product. Deceptive patterns on the publisher side become your brand problem eventually, so it is worth asking how the network polices them.
On the RevU side, bids can be set by publisher ID, geography and audience segment, and an account manager handles source curation as part of running the campaign rather than as an upsell. That is the model we think is right, and you should hold any network to the same standard.
Fraud, clawbacks, and who carries the cost
Performance pricing changes where fraud risk sits, which is one of the underrated arguments for it.
On impression-based buying, invalid traffic has already been paid for by the time anyone notices, and remediation is a credit negotiation you may or may not win. On verified-action pricing, an invalid action should never generate a charge in the first place, which puts the network's incentives on the same side as yours. The network loses money when it credits fraud, so it has a direct reason to catch it.
Questions to ask, in specifics rather than adjectives:
What do you detect, and how? Server-to-server verification, device and behavioral signals, manual review, and what triggers each.
What is the clawback window, and who absorbs a reversal after the publisher has already been paid?
What happens to my invoice when you find something after billing?
Can I reject conversions that pass your checks but fail mine, and on what basis?
Our longer treatment of offerwall fraud prevention goes through the detection layers and what each one actually catches.
What determines your price
There is no standard offerwall CPA, and anyone quoting you one without asking questions first is guessing. The price is set by:
How deep the event is. A purchase costs multiples of an install, because far fewer users get there.
Geography. Tier 1 markets cost more per action and generally deliver more value per user. Demand and supply are both strongest in the US, UK and EU.
Platform. iOS and Android price differently, and desktop and web differently again.
How much work you are asking for. The reward the publisher must pay out scales with the effort, and your bid has to cover it plus the network's and publisher's margin. An offer requiring twenty minutes of play needs a bigger reward than one requiring a sign-up.
Competition for placement. Your bid determines where you sit on the wall relative to other advertisers targeting the same users.
The useful way to sanity-check a quoted price is to work backward from your own numbers. Take the value of a user who reaches your billable event, apply your target payback period, and see whether the quote fits inside it. If it does not, the answer is a deeper billable event rather than a lower bid.
When offerwall advertising is the wrong buy
Five cases where we would tell you not to bother:
You need awareness, not action. Offerwalls convert existing willingness into completed actions. They do not build category demand or brand recognition. Buy reach from a walled garden for that.
You cannot measure a post-install event. Without a reliable event to bill against, you lose the entire advantage of the model and end up buying installs with extra steps.
Your product needs high-intent users specifically. Some products only work for people who came looking. Enterprise tools, medical products, and anything with a long considered purchase cycle generally fall here.
Your audience is almost entirely outside Tier 1. Ask for country-level supply numbers before assuming the inventory exists for your markets.
Your retention is broken. Paid acquisition on an app users leave is an expensive diagnostic. Fix the product first. We have written about how that math fails from the publisher side, and it fails the same way from the buy side.
How to run a first test that produces a real answer
Most failed offerwall tests were designed to fail. A test that produces a usable answer has these properties:
A billable event past the reward, agreed in writing, with the postback confirmed in a staging environment before spend starts.
Enough volume to read. Pick a budget that will produce a few hundred billable events at your quoted price, not a few dozen. Below that, you are measuring noise.
Long enough to see the value event. If your value event happens on day 14, a seven-day test cannot answer the question you are asking.
One or two geographies, not everything. Blended results across mixed markets are close to uninterpretable.
A predefined success threshold. Cost per user reaching your value event, compared against a named existing source. Decide the number before you see the data.
A holdout if you can run one. It converts "we got users" into "we got users we would not otherwise have had."
If a network resists any of this, that is information. The ones confident in their inventory tend to be comfortable being measured precisely.
Where RevU fits
RevU has run offerwall inventory for more than twenty years, reaches over six million active users, and carries more than 2,500 live campaigns at a time across gaming, e-commerce, subscriptions and fintech. Billing is CPI, CPA or CPE on verified actions only. Postbacks integrate with AppsFlyer, Adjust, Singular, Kochava, Everflow, Impact Radius and Commission Junction. Because the integration is web-based rather than SDK-based, the inventory covers desktop and web storefronts alongside iOS and Android, which is unusual in this category. If you want to see how it works for advertisers, that is on the advertiser page.