Mobile Game Monetization Design: IAP, Ads, Subscriptions

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

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

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.

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

1. Genre and competitor analysis — study top 10 similar games in the store, their IAP catalog, user reviews on monetization.
2. Model selection — based on genre, audience, acquisition channels.
3. Currency system design — types of currencies, sources, sinks, ratios.
4. IAP catalog — price tiers, bundles, starter offers.
5. Rewarded placements — integration points, offer mechanics.
6. Technical requirements — what to implement on the client, what on the server.
7. 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.

Mobile App Monetization: IAP, Subscriptions, and Ad Mediation

An app with poorly implemented purchases loses money not because users don't want to pay, but because a StoreKit transaction hangs, Receipt Validation fails with an error, or restore purchases doesn't work — and the user writes to support or leaves a 1-star review. Our experience (over 7 years in mobile development) shows that proper monetization increases LTV by 30–60% within the first three months after implementation. Get a consultation on monetizing your app — we'll analyze the current model and find growth points.

Why StoreKit 2 is the Best Choice for IAP?

StoreKit 2 (iOS 15+) is a modern API with async/await and device-side verified transactions without a server. Transaction.currentEntitlements returns all active purchases. Key change compared to StoreKit 1: JWS signature verification on device via VerificationResult<Transaction> — no need to send receipt to server for basic validation.

But server-side validation is still needed for consumable purchases and fraud prevention. App Store Server API replaces the old /verifyReceipt endpoint. Webhooks via App Store Server Notifications v2 provide real-time events: SUBSCRIBED, DID_RENEW, EXPIRED, REFUND — without polling.

A typical mistake: not handling paymentQueue(_:updatedTransactions:) in the background for unfinished transactions. User bought a consumable, app crashed before finishTransaction — purchase remains in queue, restores on next launch and requires reprocessing on server. Without server idempotency — double crediting.

How Not to Lose Revenue on Subscriptions?

The subscription model requires tracking states: trial → active → grace period → expired → refunded. RevenueCat is the de facto standard for managing subscriptions in production. It abstracts StoreKit and Google Play Billing, providing a unified API, webhooks, cohort analytics, and A/B testing of paywalls.

Alternatives to RevenueCat include custom implementations with Adapty or Qonversion. Fully custom only if data must not leave the infrastructure or there is non-standard logic. We guarantee that webhook setup and subscription lifecycle event handling is done without losses — verified on projects with over 500k DAU.

Google Play Billing Library 6+ requires handling PurchasesUpdatedListener and explicitly calling acknowledgePurchase() or consumePurchase() within 3 days — otherwise Google automatically cancels the purchase and refunds. The average cost of such an error is a significant loss per user per month (based on our project data).

Ad Mediation: Boosting CPM via Bidding

Showing ads from a single source means losing revenue. Mediation (waterfall or bidding) requests ads from multiple networks and displays the best bid. Google AdMob is the foundation for banner, interstitial, rewarded ads. Mediation via AdMob Mediation or MAX (AppLovin) is the second de facto standard. MAX uses In-App Bidding — a real-time auction without waterfall. In practice, MAX yields significantly higher CPM than classic waterfall (depending on geo and audience). For example, for rewarded video in the US, the improvement can be substantial. With 100,000 rewarded video impressions per day, switching from waterfall to In-App Bidding can generate additional daily revenue.

ironSource (Unity Ads) has a strong position in the gaming segment, especially rewarded video. Mintegral covers the Asian audience well.

Setting up mediation requires ATT (App Tracking Transparency) on iOS 14+. Without requestTrackingAuthorization, ad CPM drops by 3-5 times for non-consenting users. SKAdNetwork and Privacy Manifest (iOS 17) are mandatory requirements; without them, review fails.

How We Implement Monetization: Step-by-Step Process

1. Current model audit — analysis of funnel, paywall, price tiers, and identification of bottlenecks.
2. Model design — choose type (subscription, consumable, non-consumable) and optimize price points.
3. IAP integration — set up StoreKit 2 / Google Billing 6, receipt validation, webhooks.
4. Ad mediation — connect 3-6 networks, configure waterfall or In-App Bidding, test fill rate.
5. Analytics and cohorts — integrate RevenueCat, Amplitude, or Firebase for LTV tracking.
6. A/B testing of paywall — use Remote Config for experiments without a release.
7. Launch and monitoring — 2 weeks of free support after launch, bug fixes by 24-hour SLA.

How to Design a Freemium Model and Paywall?

Freemium works when the boundary between free and paid is properly drawn. Too strict a paywall at the start — users delete. Too generous a free tier — no incentive to pay.

A technically sound pattern: server-side feature flags (Remote Config in Firebase or LaunchDarkly) control access to features. This allows A/B testing of paywall without a release, changing trial conditions, and running promotions.

Implementation at the code level: EntitlementManager — a single point for checking access to features, aware of subscription status, flags, and promos. No scattered isPremium checks throughout the code. Experience shows this approach reduces paywall-related bugs by 80% (confirmed on 30+ projects).

Scope of Monetization Work

• Current model audit — analysis of funnel, paywall, price tiers.
• IAP integration — StoreKit 2 / Google Billing 6, receipt validation, webhooks.
• Ad mediation — configure MAX / AdMob, connect 3-6 networks, test fill rate.
• Analytics setup — RevenueCat, Amplitude / Firebase, cohort analysis.
• Documentation — description of entitlements, restoration procedure, review checklist.
• Team training — analysis of typical mistakes, support recommendations.
• Guarantee — 2 weeks free support after launch, bug fixes by 24-hour SLA.

Estimated Timelines

Cost is calculated individually. We have been working in this field for over 8 years and have implemented monetization in over 40 projects — many of which passed App Store Review without a single rejection. Contact us for an audit or order a consultation — we'll tell you what growth points exist in your app.