Does an Offerwall Cannibalize IAP? Start With Your Exchange Rate

Two questions decide how a publisher runs an offerwall: is the reward too generous, and will the offerwall cannibalize in-app purchase revenue? The second has a clear answer, and it's narrower than most people expect. The two are settled together, because the arithmetic that sets the reward is also what bounds the one route by which an offerwall displaces a purchase, and how much that arithmetic covers depends on who is shown the reward.

A unit of in-game currency does not have one price. It has two. They measure different things, and comparing them directly is the error that makes an offerwall look like a discount on currency you already sell.

The whole decision resolves to one setting: the ne your offerwall dashboard calls the exchange rate, or currency conversion ratio. Platform documentation defines it as the amount of virtual currency a user receives for every dollar you earn through an offerwall conversion.

That rate is the inverse of the figures below. Granting 200 gems for a $1.80 payout is about 111 gems per dollar, which is the same statement as $0.009 a gem. The two move in opposite directions: a higher exchange rate is a worse publisher price. Everything below is a way of setting that rate deliberately instead of inheriting it, and of deciding where the exceptions to it belong.

What is your offerwall exchange rate actually earning you?

Say a pack of 500 gems sells for $4.99 as an in-app purchase. The player price is what a user pays per unit, about $0.010 per gem here.

The publisher price is what you receive per unit, regardless of the channel the user used. Both channels have one. Say an offerwall offer pays you $1.80 when a user completes it and you grant 200 gems for the completion: the publisher price of that offer is $0.009 a gem. The pack has a publisher price too, and it is not $0.010.

The instinct is to set those two against each other: $0.010 a gem out of the player's pocket against $0.009 a gem into yours. So the offerwall looks like the cheaper channel and the reward looks too generous.

That comparison is wrong, because it pits a player price against a publisher price. One is what leaves the player's account at the store. The other is what arrives in yours from the offerwall. Between the player's $4.99 and anything that reaches you from that pack, store commission comes out. The store channel's value to you is its own publisher price, which the $4.99 does not state.

At a 30 percent commission, the $4.99 pack nets you $3.493. The store channel's publisher price is therefore $0.699 per 100 gems.

The offerwall offer pays you $1.80 for 200 gems, which is $0.900 per 100 gems. That is the same $0.009 per gem quoted earlier, restated per 100 so it sits beside the store figure.

Both are now publisher prices in the same unit, and the offerwall is not the cheap channel in this example. $0.900 against $0.699 is about 29 percent more per gem from the offerwall than the in-app purchase channel nets you. Leaving commission out of the arithmetic inverted the intuition.

The commission rate changes the result, so it is worth running this arithmetic at your own rate. Apple's Small Business Program sets a reduced rate of 15 percent. Apple states the eligibility test as a developer and its Associated Developer Accounts having "earned no more than 1 million USD in total proceeds (sales net of Apple's commission and certain taxes and adjustments) during the 12 fiscal months occurring within the previous calendar year, and have earned no more than 1 million USD during the current year"; that developers new to the App Store can qualify; and that a participating developer who passes the threshold in the current calendar year moves to the standard rate on future sales. There is a further reduction to 10 percent "for developers on the alternative terms in the EU in the App Store Small Business Program and for subscriptions after their first year." At 15 percent, the same $4.99 pack nets you $4.242, or $0.848 per 100 gems, and the offerwall's advantage over the store channel narrows from about 29 percent to about 6 percent.

Same offer, same reward, same pack. The conclusion moves with a rate the publisher does not set and the reward decision does not touch.

The break-even reward, and how to work it out

Once each channel is stated as a publisher price, net of any applicable commission, the two figures are in the same unit, and you can work backward from the store figure.

For a $1.80 offer against that same 500-gem pack at $4.99, the break-even reward is the point where granting currency through the offerwall earns the same per gem as selling that currency would net:

• At a 30 percent commission, about 258 gems
• At a 15 percent commission, about 212 gems

Below those numbers, you earn more per gem than the store channel nets you. Above them you earn less. The 200-gem reward in the example sits below both, so at either commission rate the offer is on the better side of the line.

One point of scope matters here, because it decides how much weight this figure carries. The break-even reward is a ceiling for currency granted to a user who would otherwise have bought. For a user who would not have bought, the store channel nets nothing, so break-even is a reference point rather than a limit. The next section is about which of those two groups your entry point puts the reward in front of.

Stated as an exchange rate, this collapses to one number per pack rather than one per offer. For a $4.99 pack of 500 gems, the break-even exchange rate is 143 gems per dollar at a 30 percent commission and 118 gems per dollar at 15 percent. Grant fewer gems per dollar earned, and the offerwall pays you better per unit than the pack nets; grant more, and it pays worse. The worked example above sits at about 111 gems per dollar, comfortably inside both.

Break-even exchange rate = pack units ÷ (pack price × (1 − commission rate))

Expressed as a reward for a specific offer, the same rate reads like this:

Offer payoutBreak-even reward at 15% commissionBreak-even reward at 30% commission$0.5059 gems72 gems$1.00118 gems143 gems$1.80212 gems258 gems$3.00354 gems429 gems$6.00707 gems859 gems

Every row is the same exchange rate. Divide any break-even reward by its payout, and you get 143 at 30 percent and 118 at 15 percent, which is why you set the rate, not the reward, once and audit it. The two columns differ by a constant ratio, 0.70 to 0.85, because commission is the only thing that changes between them.

The table is specific to one pack, so the formula matters more than the figures. Put your own pack price, pack size, and commission rate in, and both the rate and the column rebuild themselves.

Run this calculation per offer and per pack, not once for the whole economy. Publishers sell tiered packs at different effective rates, so the break-even depends on which pack a grant displaces, and a single blended per-gem figure hides the cases that matter.

Does an offerwall cannibalize IAP?

Here is the part that gets skipped. An offerwall can directly displace a purchase only when a purchase would have happened anyway.

Split the population into two groups. For users who would have bought a gem pack, an offerwall can substitute for the purchase: they take the free path, and the sale doesn't happen. For users who were never going to buy, there is no purchase of their own to displace.

This reframes the design problem. The question is not what the reward is worth in the abstract. It is which group sees the reward, and when.

Compare two configurations.

Entry point inside the purchase flow. The offerwall sits in the gem store, beside the packs, visible at the moment of purchase intent. This is the arrangement most likely to convert a payer into a non-payer, because it offers a free substitute to the very user who had already decided to spend.

Entry point at the constraint. The user hits a wall, has no currency, and won't buy any. The offerwall appears as the way forward. That user had no purchase of their own to displace, because the alternative was closing the app. Granting currency can still reach payer revenue indirectly, which "What this does not settle" covers.

Much of an offerwall's economics depends on which of these you build, and the decision is often made as a user-experience choice by someone not focused on revenue. Placement is the lever. Reward value is the adjustment you make after the lever is set.

Three more levers after placement

Placement decides who sees the reward. Three further levers set how much a grant can cost you, and each traces back to the displacement argument or to the economy effects below.

Choosing which currency you grant. If you grant the same premium currency you sell, every grant is a candidate substitute for a purchase. If you grant a soft currency you do not sell, or an item you have never offered for money, there is no pack for the grant to substitute for directly. Two caveats keep that from being absolute: a soft currency users can buy with premium currency still has a path back to a purchase, and the economy effects below apply whether or not the thing granted is for sale. This is still the cleanest way to narrow the substitution path, but it costs the reward some of its pull, and that is the trade.

Capping what one user can earn. A daily or lifetime cap bounds how much currency enters the economy through the offerwall. That ceiling reduces substitution risk for a payer who would otherwise grind to a free pack, and it reduces the devaluation risk covered below, since both scale with volume rather than the exchange rate alone. A cap is the only lever here that limits the tail, where a small number of heavy earners can account for a large share of the currency granted.

Suppressing the offerwall for proven payers. This is the operational form of the argument above. If only users who would have paid can have a purchase displaced, then proven payers are the users whose exposure is worth questioning. Purchase history is the only observable proxy for that group, and an imperfect one, since it misses the user who was about to buy for the first time. Hiding or de-emphasizing the entry point for anyone who has bought recently converts the placement argument from a single design decision into a rule that runs per user. It costs you offerwall revenue from payers who would have bought a pack and completed an offer, so it is worth testing rather than assuming.

A cap and a payer suppression rule don't change the arithmetic; they change how many users you have to be right about. Granting a currency you don't sell removes the store-side figure the arithmetic compares against, so you can't compute a break-even exchange rate.

Which offers to surface, and why the highest payout is not the answer

Publishers do not choose the qualifying event. Advertisers do, and that event can be a simple sign-up, an install, a purchase, or a multi-step in-app event. Edge226's rewarded solution lists matching pricing structures: CPL, CPI, CPA, CPE, and multi-event.

A publisher chooses which offers to surface and which reward to attach to each. The temptation is to lead with the highest payout. What matters is payout multiplied by completion rate.

Take an offer paying $1.80 that 20 percent of starters complete: that returns $0.36 per start. An offer paying $6.00 and completed by 4 percent of starters returns $0.24 per start. Note the change of denominator: these figures are revenue per start, not revenue per gem. On those illustrative rates the smaller payout is worth half again as much per start, and the larger one spends more of your users' patience to produce less. Whether higher payouts actually perform worse is a question your data will answer; the method is the same either way.

So scale the reward to the effort the offer demands, not to what it pays you. A deep multi-step event asks more of the user and deserves a larger reward. But if you set the reward based on your payout rather than the user's effort, offers that pay well but complete poorly get the largest rewards and the most prominent slots, and users learn to ignore the offerwall.

How do you tell cannibalization from incremental revenue?

Not from the dashboard. In-app purchase revenue falling after an offerwall launch is consistent with cannibalization, and equally consistent with a content update, a seasonal dip, or a change in who installed that month. The dashboard cannot separate them, and readers tend to read the direction of the number as confirmation of what they already believed.

The clean read is a holdout. Withhold the offerwall from a random share of users, run the test long enough to clear normal week-to-week variance, and compare the two groups.

Compare total revenue per user, not in-app purchase revenue per user. The offerwall is supposed to add a revenue line, not defend the purchase line, and judging it on the line it partly replaces all but guarantees that the offerwall looks like a loss. That is how a working offerwall gets switched off. Total revenue per user also absorbs an effect the purchase line misses. Time a user spends on offers comes partly out of attention you were already monetizing, so a completion can quietly cost you rewarded video and other ad revenue from that same user. A holdout nets that loss out of the result instead of leaving it uncounted.

Two conditions make the test worth running: a read date fixed before launch, and agreement, also before launch, that the result outranks the dashboard. Without the second, the test produces a number that loses an argument to a chart.

What this does not settle

Reward pricing does not fix a reward that nobody wants, an entry point nobody finds, or an offer mix that does not match your audience. It also assumes you have already decided the format is worth running, which is a separate argument and one we made in the case for offerwall advertising. It is the arithmetic layer under those decisions, not a substitute for them.

The arithmetic also stops at the edge of the economy itself. Injecting currency into the free population devalues that currency and can erode the value of what a paying user was buying, particularly where progression is competitive or scarcity-driven. A large enough reward also moves the balance between what players earn and what they spend. Those are game-design questions rather than pricing questions, and the effects they describe can reach payer revenue indirectly, without any single payer ever taking the free path.

It also says nothing about who handles a user who completes an offer but isn't credited. That typically falls to the offerwall operator: Adscend's publisher page lists dedicated user support alongside the webview and API integration paths, and that support matters more to a help queue than anything in this post.

Nor does it reach the advertiser's side of the same trade. If you are buying this inventory rather than selling it, the pricing question inverts, and that case is the subject of buying offerwall traffic that retains.

Where to start

Calculate your net revenue, after commission, per 100 units of currency for every pack you sell. Then state each offer you are considering in the same unit: payout divided by the reward granted, multiplied by 100. Put both columns next to each other. Finally, look at where your entry point sits, and ask whether it is positioned in front of users who were going to pay or users who weren't.

One afternoon of arithmetic and one product decision settle more than a reward-value debate ever has.

FAQ

How do you work out what a unit of in-game currency is worth?

It depends on which of two prices you mean, and they are not interchangeable. The player price is what a user pays through an in-app purchase, divided by the units received. The publisher price is what you receive per unit, regardless of the channel: for a pack, the price minus store commission, divided by the units; for an offerwall offer, the payout divided by the reward granted. Only publisher prices are comparable with each other. No store commission comes out of an offerwall payout. The offerwall network takes its share before quoting the payout, so the quoted figure is already net and is the one to use.

Does an offerwall cannibalize in-app purchase revenue?

It can displace a purchase directly only among users who would have bought anyway. For a user who never would have purchased, there is no purchase to displace, though granting currency can still reduce payer revenue indirectly by devaluing the currency itself. Because of that, much of the cannibalization risk is decided by where the entry point sits: inside the purchase flow, it offers a free substitute to the very user who had already decided to spend; at a point of constraint, it offers a path to a user whose alternative was closing the app.

What is a break-even reward?

The amount of currency you can grant for a given offer payout before the offerwall earns you less per unit than selling that currency would net. For an offer paying $1.80 against a 500-gem pack at $4.99, it is roughly 258 gems at a 30 percent commission and roughly 212 gems at a 15 percent commission. Grant fewer gems and the offerwall pays you more per gem than the store channel nets; grant more, and it pays less. The figure is a ceiling only for a user who would otherwise have bought that pack.

Should you lead with the highest-paying offers?

No. What matters is payout multiplied by completion rate. On illustrative rates, an offer paying $1.80 completed by 20 percent of starters returns $0.36 per start, against $0.24 for one paying $6.00 completed by 4 percent. High-payout offers that get abandoned also spend more of your users' patience, and over time users learn to skip the offerwall.

Does the offerwall exchange rate need to match the IAP price?

No, and matching a pack's player price is usually the wrong target. Giving the player the same perceived value in both channels and maximizing your revenue per unit are different goals because store commission comes out of the in-app purchase channel, not the offerwall payout. Work out the publisher price of each channel first, then decide how much of the gap between them you want to hand to the user as a larger reward.

Should the exchange rate vary by country or by player progression?

By country, usually yes, but not for the reason people assume. Payout differences aren't the driver because the rate is stated per dollar you earn, so payout cancels out. What varies is the store side: local pack prices and purchasing power change what your in-app purchase channel nets per unit, which moves the break-even exchange rate market by market. The major dashboards support per-country rates or multipliers for this reason. Progression is a separate question. A reward that matters early may be trivial at level 50, and because the grant is the offer payout multiplied by the rate, raising it for late-game users means raising their rate and accepting a worse break-even. Surfacing higher-payout offers to those users is the cheaper answer.

How do you tell cannibalization from incremental revenue?

Use a holdout rather than a report. Withhold the offerwall from a random share of users, run the test long enough to clear normal week-to-week variance, and compare total revenue per user between the groups. Comparing in-app purchase revenue alone will almost guarantee the offerwall looks like a loss, because the offerwall is there to add a revenue line, not to defend the purchase line.