We design mobile game monetization systems embedded into gameplay from the first commit. Games where monetization was added retroactively are easy to spot: IAP offers appear without context, rewarded buttons sit on the main screen disconnected from mechanics, and conversion to paying users stays below 0.5%. A well-designed system makes players look for ways to spend money because it solves a real in-game problem. In this article, we break down key mechanics and pitfalls so you don't repeat others' mistakes.
We have designed monetization for over 30 projects — from hyper-casual to hardcore RPGs. Our approach relies on real cases and A/B tests, not templates. Contact us to discuss your project details.
How to Choose a Monetization Model for Your Genre?
Before writing code, answer three questions: what genre, what target audience, what expected LTV. Everything depends on the answers.
- Free-to-Play with IAP — the main model for casual and mid-core games. The game is free, revenue from in-app purchases. Paying conversion: 2–5% for well-optimized games. ARPPU from $5 to $50+.
- Ads (rewarded + interstitial) — works well for hyper-casual and casual games with high DAU. Rewarded gives $10–30 eCPM in peak hyper-casual, interstitial $2–8. Aggressive ads without rewarded quickly kill retention.
- Subscription — a growing model for games with regular content. Conversion 3–8%, but retention is significantly higher than one-time IAP.
- Hybrid — combination of multiple sources. A proper hybrid model segments the audience: free users monetize through ads, paying users through IAP and subscriptions. Important: do not show ads to paying users — it annoys and increases churn. Hybrid monetization increases LTV by 20–30% compared to pure ad-based.
Comparison of Models by Genre
| Genre | Primary 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 |
| Mid-core (RPG, strategy) | IAP (currency, skips) | Subscription | $0.15–0.80 |
| Hardcore (MOBA, battle royale) | Subscription + cosmetics | Battle Pass | $0.30–2.00 |
How to Design a Currency and IAP System?
IAP: Product Structure
In-App Purchases fall into three types: consumable, non-consumable, and subscriptions. Choosing the wrong type is critical: consumables cannot be restored via Restore Purchases, non-consumables can.
A common mistake is too many items. Research shows the optimal number of IAP offers in a store is 6–8 at a time. More leads to cognitive overload and lower conversion. Monetization design pricing is determined after analysis.
The price tier structure for mobile games usually follows: starter pack, mid-range bundle, whale offer, VIP. A starter pack with high value at low price is the main tool for first purchase conversion.
Soft and Hard Currency
Most mid-core games use a dual-currency system:
- Soft currency (coins, gold) — earned through gameplay, spent on basic progression.
- Hard currency (gems, crystals) — purchased with real money or earned through rewarded ads/events, spent on premium content and acceleration.
Conversion of soft currency to hard should be limited or absent — otherwise, the purpose of buying hard currency is lost. Reverse conversion is acceptable but at an unfavorable rate.
Battle Pass as a Monetization Backbone
A Battle Pass is a seasonal mechanic with two reward tracks (free and paid). Economically, it works like this: the player sees attractive rewards on the paid track and pays upfront, expecting to earn them through active gameplay.
Key design parameters:
- Season length: 28–42 days.
- Number of tiers: 50–100.
- Daily free progress: should reach tier 70–80 per season with casual activity.
- Base pass price — in the lower segment, with bonus tiers in the mid-range.
Rewarded Ads in Game Context
Rewarded ads work only where the offer organically fits a need. "Watch an ad, get 10 coins" on the main screen is poor. "You are out of lives, continue for free?" at the moment of defeat yields 30–50% conversion. Rewarded placements at the moment of defeat convert 5 times better than offers on the main screen.
Placement spots that work:
- Continue after defeat (continue button).
- Double rewards for a level.
- Open a daily bonus chest.
- Accelerate a construction/restoration timer.
Each placement should have a separate rewarded placement ID in AdMob/IronSource. This allows analytics to see which offers convert and which are ignored.
Anti-Cheat and Transaction Verification
Client-side reward delivery for IAP and rewarded ads is a vulnerability. Minimum protection set:
- Rewarded SSV — IronSource/AdMob send a callback to your endpoint with an ECDSA signature.
- IAP Verification: Receipt validation via Apple Receipt Validation API or Google Play Developer API. The client sends the receipt to your backend; backend verifies with Apple/Google, then grants the item. This blocks replay attacks with intercepted receipts.
- Rate limiting: limit daily rewarded views on the server side, not just on the client. Client-side limits are bypassed in minutes via Frida or clearing SharedPreferences.
Why Anti-Cheat Matters?
Monetization hacking can reduce revenue by 30–50%. An error in verification turns IAP into free content. With the right approach, you can save up to 50% of your user acquisition budget without losing paying user revenue.
Monetization Analytics
Metrics indispensable for monetization optimization:
- ARPU (average revenue per user) = total revenue / MAU.
- ARPPU (average revenue per paying user) = revenue from payers / number of payers.
- Conversion rate = paying users / all users.
- LTV (lifetime value) — cohort analysis over 7/14/30/90 days.
- ROAS (return on ad spend) — if you have UA campaigns.
Monetization Metrics Comparison
| Metric | Formula | What It Shows |
|---|---|---|
| ARPU | Revenue / DAU or MAU | Average revenue per user |
| ARPPU | Revenue from payers / number of payers | Average revenue per paying user |
| Conversion Rate | Paying users / All users | Share of paying users in audience |
| LTV (7/30/90) | Sum of cohort revenue / number of users in cohort | Cumulative revenue per user over period |
| ROAS | Revenue / UA spend | Profitability of ad campaigns |
We implement through Firebase Analytics (logEvent("purchase", ...)) + export to BigQuery for cohort analysis. Impression-level revenue from AdMob/IronSource is added to the same analytics for a complete LTV picture.
Case Study: Hyper-Casual Game
For one project with high DAU, we implemented a rewarded placement after every loss and an IAP no-ads. ARPU grew 2.5x in one month, and Day-7 retention increased by 15%. The key was server-side rewarded limiting — up to 10 views per day, which prevented abuse.What's Included
We provide a full documentation package:
- Monetization GDD describing models, currencies, IAP catalog.
- Technical specifications for client and server implementation.
- A/B test scenarios for key hypotheses.
- Analytics integration (Firebase, BigQuery) and event setup.
- Anti-cheat and security recommendations.
- Support during launch and first two weeks post-release.
Get a detailed proposal tailored to your project. Contact us for a consultation.
Design Stages
- Genre and competitor analysis — study top 10 similar games in the store, their IAP catalog, user reviews on monetization.
- Model selection — based on genre, audience, acquisition channels.
- Currency system design — types of currencies, sources, sinks, ratios.
- IAP catalog — price tiers, bundles, starter offers.
- Rewarded placements — integration points, offer mechanics.
- Technical requirements — what to implement on the client, what on the server.
- A/B test plan — which hypotheses to test first.
Design timeline: 2–3 days for a basic model, 5–7 days for a comprehensive system with detailed GDD and technical specs. Pricing is calculated individually.
Request monetization design for your game, and we will prepare a solution tailored to your genre and audience.
In-App Purchase Apple documentation and Play Billing Google library.