Mobile Game Affiliate Offers: CPI, CPE and Revenue Share

An advertiser will pay you $1.20 for an install. The same advertiser will pay $9 if the player finishes the tutorial and reaches level ten. Choosing between those two mobile game affiliate offers is not a preference — there is a specific conversion rate above which the second is worth more, and below which you are throwing money away.

Most affiliates coming into mobile from web run the same sequence: they take the CPI offer because the number of conversions is bigger and it feels safer, they watch a chunk of those conversions get removed at the end of the month, and they never work out whether the event-based offer they turned down would have paid more.

This covers the three payout models you will actually be offered, what an event means once you get past the marketing description, how mobile attribution works and where it stops working, why your reported numbers change after the fact, and a worked comparison of a $1.20 CPI offer against a $9 CPE offer at different event rates.

The three payout models behind mobile game affiliate offers

Every mobile game offer sits somewhere on a single axis: how much of the quality risk the advertiser keeps, and how much they push onto you.

Cost per install

You are paid a fixed amount when a user installs the app and opens it for the first time. That first open matters — a download without a launch usually does not count, and this is one of the most common causes of a gap between what your tracker shows and what you get paid.

CPI is the shallowest funnel available. Your job ends at the install, which means high conversion volume and fast feedback on which placements work. The payouts are correspondingly small, they vary enormously by geo, and they attract the heaviest fraud scrutiny in the vertical precisely because the action is so cheap to fake.

Cost per engagement

You are paid when the user performs a defined in-game action. The install itself pays nothing. Payouts run several times the CPI for the same title because the advertiser is buying something much closer to a real player.

CPE moves the risk onto you. If your traffic installs and never opens the game again, you earn zero, having delivered exactly the same volume that would have paid out under CPI. That is the trade, and whether it favours you depends entirely on the quality of your placements.

Revenue share and hybrid

You take a percentage of what the player spends, sometimes forever, sometimes for a defined window. Hybrids pair a small CPI or CPE with a revenue share tail.

Revenue share in mobile gaming is dominated by a small number of very high spenders. The distribution is extreme — most installs spend nothing at all, and a tiny minority account for the overwhelming majority of revenue. That makes revenue share high-variance at low volume. At ten thousand installs a month you may get a representative outcome. At three hundred, you are essentially buying lottery tickets, and a single unusually heavy spender can distort a whole quarter's numbers in either direction.

What an event actually means

"Event" sounds precise and is not. The definition varies per offer and it determines everything about whether the payout is achievable.

Common event definitions, roughly in order of difficulty:

• Tutorial complete. Usually the easiest paid event. Reachable in a few minutes. Often 40% to 60% of installs from decent traffic will complete it.
• Registration or account link. Adds friction because it requires an email or social login, and drops the rate noticeably.
• Session two / day-one retention. The user opens the app again on a subsequent day. This is a genuine quality filter and where a lot of low-intent traffic dies.
• Level milestone. Reaching level five, ten or twenty. The rate falls sharply as the number climbs, and the time to fire the event stretches from hours to days.
• Day-seven retention. A hard event, well paid, and heavily dependent on whether the game actually suits the audience you sent.
• First purchase. The hardest and best paid. Only a small fraction of any install base ever spends, so this is a volume game.

Three details decide whether an event offer is workable, and you should ask about all three before running traffic:

1. The time window. If the event must fire within 72 hours of install, a level-ten requirement that takes most players a week is unpayable regardless of quality.
2. Whether the event is verified server-side. Client-reported events can be disputed. Server-verified events are what serious advertisers use and what you want in a dispute.
3. How the event is defined for the specific title. Level ten in a hypercasual game is fifteen minutes. Level ten in a mid-core strategy game is four days. The word is identical; the achievability is not.

A well-designed CPE offer names a single, unambiguous, server-verified event with a window that fits how the game is actually paced. Vague event definitions are a warning sign about the advertiser, not a detail to sort out later.

Why advertisers stopped buying installs

The shift from CPI toward CPE was not a fashion. It was a response to installs losing their meaning as a signal.

A user acquisition manager is measured on return on ad spend, and ROAS is driven by a small number of players who spend heavily. Installs correlate with that only if the installs are real people who wanted the game. Once incentivised traffic, click-spamming and device farms made installs cheap to manufacture, the correlation broke, and CPI budgets started producing install counts that looked excellent and revenue that did not move.

Event-based payouts fix this cheaply. Faking a tutorial completion is possible; faking a day-seven return with realistic session patterns across thousands of devices is expensive enough to stop being worth it. The advertiser pays more per conversion and gets a population that actually behaves like players.

There is a version of this that benefits you. Because the advertiser's risk is lower on CPE, they can pay a genuinely generous multiple of the CPI. If your traffic is good, that multiple is money that CPI would never have given you — the CPI rate is priced for average traffic, including everyone else's bad traffic. CPE lets quality traffic escape that averaging.

Attribution, and where it breaks

Mobile attribution works differently from web tracking and the differences cause most of the disputes affiliates get into.

The basic flow: your click goes to an attribution provider, which records the click along with device signals. When the app is installed and opened, the app's embedded SDK reports the install to the same provider, which matches it against recent clicks and credits the winning source. That match is what generates your conversion.

The matching is not always deterministic:

• Deterministic matching uses a stable device identifier. When available, it is reliable.
• Probabilistic matching — sometimes called fingerprinting — uses IP address, device model, OS version and timing to guess. It is a guess. It is right often enough to be useful and wrong often enough to cause arguments.
• Privacy-framework attribution on iOS returns aggregated, delayed and sometimes coarsened conversion data with no user-level detail at all. You may receive a count without knowing which click produced it.

Practical consequences you will run into:

Attribution windows are shorter than web affiliates expect. A seven-day click window is common; view-through windows are shorter still. A user who clicks today and installs in two weeks is unattributed.

Last-touch usually wins. If a user clicks your link and then sees a paid ad from the advertiser before installing, that ad frequently takes the credit.

Self-attributing networks report their own conversions and are matched with priority in many setups, which quietly takes conversions away from third-party sources.

Deferred deep linking matters if your funnel promises something specific — a bonus, a starting item, a particular game mode. Without it, the user lands on a generic first-open experience, the promise breaks, and your event rates fall.

None of this is theoretical. If your reported numbers and the advertiser's disagree, it is almost always one of the above. Getting your own postback layer configured properly is the only way to argue from data rather than from feeling, and our S2S postback tracking guide walks through the setup.

Scrubbing: why your numbers move

Scrubbing is the removal of conversions after they were reported. Every affiliate in mobile experiences it and most take it personally. Some of it is legitimate and some of it is margin management, and telling them apart is a skill worth developing.

Legitimate reasons a conversion gets removed:

• Duplicate device identifiers across multiple conversions
• Click-to-install times that are physically implausible, such as an install completing two seconds after the click
• Emulators, rooted or jailbroken devices, or traffic originating from datacentre IP ranges
• Geo mismatches between click and install
• Installs from users with no post-install activity whatsoever
• Click flooding patterns, where enormous click volume from one source produces installs by coincidence rather than causation

Less legitimate reasons that also happen:

• Flat percentage scrubs applied uniformly with no per-conversion explanation
• Retroactive scrubs applied weeks after payment was expected
• Quality thresholds that are announced only after your traffic misses them

What to establish before you send volume: the scrub window, whether reason codes are provided per rejected conversion, whether the rate is applied per conversion or as a flat percentage, and what the historical scrub rate has been for traffic like yours. An advertiser who cannot answer those has told you something.

Protect yourself with granular sub-IDs. When a scrub arrives, per-placement sub-IDs let you identify which source produced the rejected conversions, cut it, and demonstrate that the rest of your traffic is clean. Without that granularity you have one number and no argument. The structure for doing this properly is covered in sub-ID tracking and optimisation.

Worked example: $1.20 CPI against $9 CPE

Here is the comparison that decides which offer to take, using the same traffic on the same game.

Setup. 10,000 clicks. Click-to-install rate of 4%, giving 400 installs. The CPI offer pays $1.20 on install. The CPE offer pays $9 when the player completes the tutorial and reaches level ten.

Route A — CPI at $1.20. 400 installs × $1.20 = $480 gross. Apply a 12% scrub, which is unremarkable for install-based offers: $422 net.

Route B — CPE at $9. Same 400 installs. Say 22% of them reach level ten: 88 events × $9 = $792 gross. Event offers scrub lighter because the event itself filters most junk — call it 8%: $729 net.

On identical traffic volume, the event offer pays 73% more.

Now find the break-even. The CPE offer matches the CPI offer when:

event rate × $9 = $1.20, so event rate = $1.20 ÷ $9 = 13.3%

Above 13.3% of installs reaching the event, CPE wins. Below it, CPI wins. Adjusting for the different scrub rates moves the true break-even to roughly 14.5%.

That single number should drive the decision, and it varies sharply by traffic source:

A third comparison. Suppose there is a revenue share offer on the same title at 25% of player spend for twelve months. Of 400 installs, perhaps 2% ever spend — 8 payers. If average lifetime spend among payers is $45, that is $360 in player spend, giving you $90. Far worse than either alternative.

But that average conceals the distribution. If one of those eight is a high spender who puts $2,000 into the game over the year, total spend becomes $2,315 and your share becomes $579 — competitive with the CPE offer, and it arrives slowly over twelve months instead of within a fortnight. That is the real character of revenue share on mobile games: the expected value can be attractive, the variance is severe, and at low volume you cannot rely on it. Sample size is the whole argument, which is why understanding the underlying KPIs matters more here than in verticals with tighter distributions.

Matching mobile game affiliate offers to your traffic

The break-even calculation gives you a rule, but a few situational judgements sit on top of it.

Take CPI when you are testing a new placement and need fast signal, when your traffic is broad rather than intent-driven, when cash flow requires quick payment, or when the game's event window is too short for how the game is actually paced.

Take CPE when you have historical event-rate data for similar traffic that clears the break-even, when your audience is genuinely interested in the specific genre, or when your funnel pre-qualifies users before they ever reach the store.

Go revenue share or hybrid when you are running real volume, when the game monetises deeply, and when you can wait months to find out how it went. A hybrid that pays a small CPI plus a revenue tail is often the sane middle ground: the CPI covers your traffic cost, the tail is upside. The general logic of that trade-off is the same one we set out in revenue share versus one-time CPA.

One tactic worth using regardless: run CPI first on a new source purely to measure the event rate, then switch that source to CPE once you know it clears the break-even. You are paying for information with the first campaign, and it is usually cheap information.

Terms to check before you send a click

• The exact event definition and whether it is server-verified
• The event window from install
• The attribution window for clicks, and whether view-through is counted
• Scrub policy: window, reason codes, flat rate or per-conversion
• Geo and device restrictions, including OS version floors
• Whether incentivised traffic is permitted — sending it where it is banned voids everything, retroactively
• Payment terms and any hold-back, since a 10% hold released after 90 days is a real cost
• Daily and monthly caps, and what happens to conversions delivered above them

The last one catches people constantly. Traffic delivered over an undisclosed cap is often unpaid, and finding that out after a good day is an expensive lesson. If you are working across several gaming offer types at once, the wider context is in our gaming affiliate marketing guide.

Working with Shazam on mobile game offers

Mobile game offers punish affiliates who cannot see their own data. We build and maintain the tracking for partners — postbacks configured properly, sub-IDs structured so that every placement is separable, event-level reporting so you can see your actual event rate per source rather than one blended number at the end of the month. That is what turns the break-even calculation above from a thought experiment into a decision you can make weekly.

We hold direct relationships with advertisers, which means 50% revenue share, caps that rise with volume, custom payout bumps on traffic that performs, and a real conversation when a scrub looks wrong. Sites and landing pages are built for partners at no cost, including pre-qualifying pre-landers that lift event rates before the user ever reaches the store. If you want to see how we work across verticals, that is set out here.

Onboarding runs on Telegram. Message the Telegram bot with your traffic sources and geos and a manager will tell you which model fits your numbers, or drop into the community chat and ask the partners already running it.