Pricing the Reward: What a Unit of Your Currency Is Actually Worth

The question publishers ask before running an offerwall is usually some version of "Is the reward too generous?" It is the wrong question, and seeing why explains most of what follows.

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 something you were already selling.

The two prices of the same gem

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, here about $0.010 a gem.

The publisher price is what you receive per unit, whichever channel the user took. 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. What the store channel is worth 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 a 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 having "earned no more than 1 million USD in total proceeds ... during the 12 fiscal months occurring within the previous calendar year, and ... 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.

Working backward to a break-even reward

Once each channel is stated as a publisher price, net of whatever commission applies, 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.

Running it across a range of payouts, against that same $4.99 pack of 500 gems:

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

The table is specific to one pack, so the formula matters more than the figures:

Break-even reward = offer payout × pack units ÷ (pack price × (1 − commission rate))

Put your own pack price, pack size and commission rate in and the column rebuilds itself. Note that the two columns differ by a constant ratio, 0.70 against 0.85, because commission is the only thing changing between them.

This is also a calculation to run 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.

Cannibalization is a placement problem, not a pricing problem

Here is the part that gets skipped. An offerwall can directly displace a purchase only where a purchase was going to happen.

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 does not 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 is being shown the reward, and at what moment.

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 is not going to 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 is decided by which of these you build, and the decision is often made as a user-experience choice by someone who is not looking at revenue. Placement is the lever. Reward value is the adjustment you make after the lever is set.

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 the matching pricing structures as CPL, CPI, CPA, CPE, and multi-event.

A publisher does choose which offers to surface and what 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 is completed by 20 percent of starters: 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 complete worse is a question your own data answers; 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 the reward is set from your payout rather than from the user's effort, then the offers that pay well and complete badly get the largest rewards and the most prominent slots, and users learn to ignore the offerwall.

How to know whether any of this worked

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 the direction of the number tends to be read as confirmation of whatever the reader 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 captures an effect the purchase line misses: time spent on the offerwall displaces rewarded video and other ad revenue you were already earning from the 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 says nothing, either, about who handles a user who completes an offer and does not get 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. Last, 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 were not.

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 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, whichever channel the user took: 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's share is taken before the payout is quoted to you, 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 otherwise have bought. For a user who was never going to purchase, there is no purchase of their own to displace, although granting currency can still reach 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.

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 all but guarantees the offerwall looks like a loss, because the offerwall is there to add a revenue line, not to defend the purchase line.

‍