Multi-Event Offers: Paying for Deep Game Milestones

What are multi-event offers?

A multi-event offer is a pay-per-result campaign split into several steps, where each step is a separate in-app event with its own payout. In a mobile game the steps usually climb from an early action, such as finishing the tutorial, to deep milestones like reaching level 25 or making a first purchase. You pay only when your server confirms each step, so you buy players in proportion to how far they actually get. The same idea is sold as multi-reward offers, milestone-based payouts, or CPE offers for games.

This guide assumes you know the basics of cost per engagement and focuses on designing the ladder: which events, what prices, and how to track them.

How multi-step offers work

A user finds your game on an offerwall, sees the list of steps with a reward next to each one, and installs it. From then on, every time the user reaches a step, your game server (or your MMP) sends a server-to-server postback for that event. The network credits the user for that step, and you are charged that step’s payout. A user who stops after step two earns, and costs, only the first two payouts.

That is the main difference from the two single-event models it replaces:

For the wider trade-off between paying per install and per action, see CPI vs CPA for apps, and for how the channel fits a growth plan, rewarded user acquisition.

Choosing events that predict retention and payers

The point of a ladder is that each step filters for players who are worth more. So pick steps from your own data, not from what other games use. You need cohort data with three numbers for every candidate event: how many new users reach it, how long it takes them, and how users who reached it behave afterward.

Run the comparison on your own cohorts

1. Take new users from the last few complete months, from all sources, and list the events your game already records. If you use Google Analytics, its recommended events for games include tutorial_complete, level_up (with a level parameter), level_end and unlock_achievement, which map neatly to steps.
2. For each event, compare day 7 and day 30 retention, and the share of users who make a purchase, between users who reached it within a set time (for example their first 3 days) and users who did not.
3. Keep the events with a large gap that a meaningful share of users still reaches. A milestone that only 1% of players ever see is a poor step even if those players are great.
4. Check the time to reach each event. That number becomes the starting point for each step’s time limit.
5. Repeat the check on any rewarded cohort you already have. Rewarded players may push through early levels faster than organic players, so the event that separates good players in organic traffic is not always the one that separates them in rewarded traffic.

This is correlation, not cause, and that is fine: you are paying for evidence of engagement. App retention benchmarks explains how day 1, 7 and 30 retention are calculated and what each one tells you.

Good and weak candidates

• Good: tutorial complete, a level or stage number, a building or account level, joining a guild, first purchase of any size, a day 3 or day 7 session.
• Weak: first open (that is just an install), “play for 10 minutes” (easy to fake by leaving the app running), anything the player can buy their way past cheaply, and anything your server cannot see.
• Never: rating or reviewing the game. Google Play’s User Ratings, Reviews, and Installs policy prohibits inflating ratings, reviews, or install counts by illegitimate means, including incentivized reviews and ratings, and says not to offer rewards or incentives for them (checked on October 20, 2026). Can you pay for app reviews? covers both stores, and Incentivized installs and Google Play policy covers the rest of the rules.

Designing the step ladder and payout curve

Most good ladders have three to six steps. Fewer than three and you lose the filtering; more than six and the offer becomes hard to read on a wall. A useful shape:

1. A quick first step that a new player reaches in their first session, such as finishing the tutorial. Its job is to get people started and to prove the tracking works.
2. One or two middle steps that mark real play, often on day 1 to day 3.
3. One or two deep steps that your data links to day 30 retention or payer conversion. Most of the money sits here.
4. Optionally, a purchase step, such as a first in-app purchase. It can sit beside the level steps rather than after them, so a player can complete it in any order.

The payout curve should rise steeply. Early steps are cheap because almost everyone reaches them and they say little about value; deep steps are expensive because they are where your return comes from. A common mistake is the reverse: generous early payouts that attract players who collect them and leave.

Pricing each step

Price the whole ladder against what the cohort is worth, then split it. Start from the predicted value of a user who reaches each step (from your LTV model, or revenue per user at day 90 or day 180 for past users who reached it), and divide by your target ROAS. That is the most you can afford to have paid in total by the time a user reaches that step, across all earlier steps. CAC vs CPA vs LTV walks through the bid math, and the LTV calculator helps with the first number.

Then check the ladder as a whole: users who stop early still cost you their early payouts, so total spend on a cohort, divided by the cohort’s predicted revenue, is the number that has to work. The cost per result calculator turns spend and completions into the cost of each player who reaches a given step.

Worked example: a five-step game offer

A fantasy strategy game builds this ladder. The “reached” column shows how many of 1,000 players who installed from the offer complete each step.

How to read it:

• The 1,000 installs cost $975, about $0.98 each. But the useful view is per engaged player: $975 ÷ 180 players at castle level 12 is about $5.42 each.
• The 300 players who never finished the tutorial cost nothing. Under a $0.98 CPI deal, they would have cost about $293.
• Suppose the game’s LTV model predicts $1,350 of 180-day net revenue from this cohort. Spend of $975 then means a predicted ROAS of about 138%. If the target is 150%, the team trims step 2 or step 5 rather than step 1, so the offer still starts easily.
• Steps 4 and 5 hold 75% of the ladder, so most of the spend follows players who stayed for weeks or paid.

Compare this with a single CPI deal and a single level 18 deal at the same total spend, and track the three cohorts on day 30 retention and revenue, not on the number of completions.

Time limits and conversion windows per step

Each step needs its own time limit, counted from the moment the user starts the offer. Set it from your data: long enough that most users who will reach the step do so in time, short enough that the step still reflects early engagement rather than a player who came back months later.

• Make the limits rise with the steps, as in the example: hours or a day for the tutorial, weeks for the deep milestone.
• Show each limit next to the step, in plain words, so users know before they start.
• Your attribution or conversion window in your MMP has to be at least as long as your longest step, or deep events will not be credited to the campaign at all. What is a conversion window? explains how these windows work.
• Judge a cohort only after its last step’s limit has passed. A ladder with a 21-day deep step looks expensive in week one, because deep conversions have not arrived yet.

One postback per event, and handling reversals

Every step is a separate conversion, so it needs a separate server-to-server postback. Each one should carry the network’s click ID, an identifier for the step, and a unique transaction ID for that event, so a duplicate can be rejected. What is a postback URL? covers macros and setup, and click IDs and sub IDs explains the IDs.

Rules that keep step tracking clean

• Fire from the server, on the real event. Send the postback when your game server records the milestone, not when the client says it happened. A client-side event can be faked.
• Once per user per step. A user who reinstalls should not trigger the tutorial step again. MMPs support this: Adjust’s Add events help page lets you mark an event as unique so it is recorded only once per device, and gives each event its own token. Map one event token, or one event name, to each step.
• Decide on order. If a player hits level 12 before the tutorial step fires (it happens with skipped tutorials), agree whether the earlier step is paid too. Writing this down up front avoids disputes.
• Test every step. Run a test device through the whole ladder before launch and confirm each postback arrives with the right step ID. A silent step 4 is the most expensive bug a ladder can have, because users complete it, complain, and stop trusting the offer.

Reversals

A purchase step can be refunded, and an audit can show that some completions came from fraud. Agree with your partner which events can be reversed, how a reversal is reported, and how long after the conversion you can send one. Keep reversals for real problems, not for honest players who later churned.

How users see the steps on an offerwall

On an offerwall, a multi-event offer usually appears as one card, often headlined with the total reward, which opens a list of steps with a reward and time limit next to each one. Users decide in a few seconds, and they judge three things: is the first step worth the effort, is the total worth the time, and do they understand exactly what to do.

Write the steps the way the game shows them. “Reach level 12” is unclear if your game has a player level, a castle level, and stage numbers. “Upgrade your Castle to level 12 (shown at the top of the main screen)” is not. State that only new players qualify, and that the steps must be done on the same device. How to advertise on offerwalls covers the offer title, image and description, and why users start offers but don’t finish shows the publisher side of the same problem.

Common mistakes with multi-event offers

• Too-hard first step. If step 1 needs a long session, the offer gets few starts and you never learn whether the deep steps work. Keep it within the first session, and do not make it worth almost nothing next to a large total, or users will not trust it.
• Farmable steps. Any step that a script, an emulator, or a fresh account can reach cheaply will be found. Use server-confirmed milestones, once-per-device events, and check for clusters of identical completion times. Ad fraud and bot traffic lists the warning signs.
• Unclear wording. Ambiguous steps create support tickets and reversal disputes, and both cost more than rewriting the text.
• Judging by completions. A ladder with fewer completions can still be the better campaign if those players retain and pay. Measure day 7 and day 30 retention and revenue by cohort.

Frequently asked questions