Mobile Game Monetization Design
Monetization isn't "add buy button." It's a system designed simultaneously with game design, not bolted on after beta. Games where monetization was added afterward are easily recognized: IAP offers appear without context, rewarded buttons hang on main screen without game mechanic connection, and paying user conversion doesn't exceed 0.5%.
Well-designed monetization system is when player actively seeks where to spend money because it solves their real game problem.
Choosing monetization model
Before writing code—answer three questions: what genre, what target audience, what LTV expected. Answers determine everything.
Free-to-Play with IAP is primary model for casual and midcore games. Game free, income through purchases. Paying user conversion: 2–5% for well-optimized games. ARPPU (average revenue per paying user): from $5 to $50+.
Ads (rewarded + interstitial) works well in hyper-casual and casual games with high DAU. Rewarded gives $10–30 ARPDAU in peak hyper-casual, interstitial $2–8. Aggressive ads without rewarded quickly kills retention.
Subscription growing model for games with regular content. Conversion 3–8%, but retention significantly higher than one-time IAP.
Hybrid combines multiple sources. Correct hybrid distribution: free players monetized via ads, paying via IAP and subscription. Important: don't show ads to paying players—irritates and increases churn.
Model comparison by genre
| Genre | Main model | Secondary | Typical ARPDAU |
|---|---|---|---|
| Hyper-casual | Ads (interstitial) | Rewarded, IAP no-ads | $0.02–0.08 |
| Casual (puzzle, match-3) | IAP (extra lives, boosters) | Rewarded | $0.05–0.20 |
| Midcore (RPG, strategy) | IAP (currency, passes) | Subscription | $0.15–0.80 |
| Hardcore (MOBA, battle royale) | Subscription + cosmetics | Battle Pass | $0.30–2.00 |
Monetization system architecture
IAP: product structure
In-App Purchases divide into consumable, non-consumable, and subscriptions. Wrong type choice is critical: consumable can't be "restored" via Restore Purchases, non-consumable can.
Common design mistake: too many IAP positions. App Store research shows optimal simultaneous IAP offers in store—6–8. More creates cognitive overload, worse conversion.
Price tier structure for mobile games usually: starter pack ($0.99–1.99), mid-range bundle ($4.99–9.99), whale offer ($19.99–49.99), and VIP ($99.99). Starter pack with high value at low price is main first-purchase conversion tool.
Soft and hard currency
Most midcore games use dual-currency:
- Soft currency (coins, gold)—earned in gameplay, spent on basic progression
- Hard currency (gems, crystals)—bought for real money or earned via rewarded/events, spent on premium content and acceleration
Soft-to-hard currency conversion should be limited or absent—otherwise purchasing hard currency loses value. Reverse conversion (hard to soft) allowed but at unfavorable rate.
Battle Pass as monetization core
Battle Pass is seasonal mechanic with two reward tracks (free and paid). Economically works: player sees attractive paid track rewards and pays upfront expecting to earn them through active gameplay.
Key parameters:
- Season length: 28–42 days (too short—can't finish, too long—lose interest)
- Level count: 50–100
- Daily progress without payment: should reach 70–80 levels per season with casual activity
- Cost: $4.99–9.99 basic, $14.99–19.99 with bonus levels
Rewarded ads in game context
Rewarded works only where offer fits need organically. "Watch ad, get 10 coins" on main screen—bad. "You need 1 life to continue, want free continue?" at loss moment—30–50% conversion.
Working placement points:
- Continue after loss (continue button)
- Double level rewards
- Open daily bonus chest
- Accelerate build/recovery timer
Each placement is separate rewarded placement ID in AdMob/IronSource. Allows seeing which offers convert and which players ignore.
Cheat protection and transaction verification
Client-side reward issuing for IAP and rewarded is vulnerability. Minimum protection:
IAP verification: Receipt validation via Apple Receipt Validation API or Google Play Developer API. Client sends receipt to your backend, backend verifies with Apple/Google, only then issues goods. Blocks replay attacks with intercepted receipts.
Rewarded SSV: IronSource/AdMob callback to your endpoint with ECDSA signature.
Rate limiting: server-level rewarded limit per day, not just client. Client limit bypassed in 5 minutes via frida or SharedPreferences reset.
Monetization analytics
Metrics essential for optimization:
- ARPU (average revenue per user) = total revenue / MAU
- ARPPU (average revenue per paying user) = paying revenue / paying count
- Conversion rate = paying users / all users
- LTV (lifetime value)—cohort analysis 7/14/30/90 days
- ROAS (return on ad spend)—if UA campaigns exist
Implement via Firebase Analytics (logEvent("purchase", ...)) + export to BigQuery for cohort analysis. Impression-level revenue from AdMob/IronSource added to same analytics for complete LTV picture.
Design stages
- Genre and competitor analysis—study top-10 similar games in store, their IAP catalogs, user reviews on monetization
- Model selection—based on genre, audience, acquisition channels
- Currency system design—currency types, sources, sinks, ratios
- IAP catalog—price tiers, bundles, starter offers
- Rewarded placements—integration points, offer mechanics
- Technical requirements—what to implement client-side, what server-side
- A/B test plan—which hypotheses to verify first
Timeline: 2–3 days for basic model, 5–7 days for complex system with detailed GDD on monetization and technical specs. Cost calculated individually.