Monetization Problems: From Metrics to Revenue
A developer chose a subscription model for a fitness app without checking retention. Day-1 retention — 40%, Day-7 — 8%, and only 20% of users activate the core feature. Result: subscription conversion rate of 0.3%. Monetization is a derivative of product-market fit, not an add-on. We start with numbers.
What We Actually Analyze
Retention curve. The first question — where do users drop off. If 70% leave before activating the core feature, placing a paywall on that feature kills conversion. Tools: Amplitude, Mixpanel, Firebase Analytics. We build a funnel from first open to the moment the user gets value (first value moment).
ARPU vs LTV vs CAC. Current ARPU — average revenue per user per period. If CAC (customer acquisition cost) exceeds LTV — scaling is unprofitable. The consultation includes calculating unit economics by segment: paying users vs organic, iOS vs Android (iOS users convert to subscription on average 30–50% better across most categories).
Analysis of current stores. We examine purchaseToken / originalTransactionId via App Store Server API and Google Play Developer API — what percentage of users reach the paywall, click "buy", and complete purchase. Paywall → subscription conversion below 2% indicates a pricing or presentation issue; below 0.5% indicates a value proposition problem.
Monetization Models: When Each Works
| Model |
Best For |
Risks |
| Subscription (StoreKit 2 / Play Billing 6) |
SaaS tools, content services, AI features |
High churn in first billing period |
| Freemium (limited features) |
Utilities, productivity, communication |
Feature wall too early kills activation |
| Consumables (coins, tokens) |
Games, dating, social |
High ARPU from whales, low from others |
| Paywall onboarding |
Health & Fitness, Meditation |
Review rejection under 3.1.1 with aggressive paywall |
| One-time purchase |
Professional tools |
No recurring revenue, hard to scale |
The most common mistake is choosing a subscription because a competitor has a subscription. The competitor may have an LTV of $80 at a CAC of $5 due to organic ASO traffic. Copying the model without understanding the acquisition channel leads to losses.
Technical Aspects That Impact Monetization
The paywall must load instantly. If StoreKit.Product.products(for:) takes 2–3 seconds (which can happen due to App Store Connect sandbox issues), the user closes the screen. Solution: prefetch products on app start, cache in memory, open the paywall with already loaded data.
Handling StoreKit 2 grace period and billing retry directly affects involuntary churn. If a subscription fails due to card issues, the user has a billing retry window of 6–16 days (depending on region and subscription term). The app must work correctly during this period — not block access, show a soft notification.
A/B testing the paywall — via RevenueCat Experiments or Firebase Remote Config with custom paywall rendering. We test: pricing, plan order, visual design, trial duration. Without A/B testing, "our designer thinks this looks better" is not an argument.
Consultation Process
Current metrics audit (retention, funnel, ARPU, LTV) → competitor analysis in the niche (App Store/Play Store) → unit economics calculation → monetization model selection → technical design of paywall and subscription flow → A/B testing recommendations → implementation review.
Deliverable: a document with model justification, technical implementation requirements, and a hypothesis testing plan.
What's Included
- Retention curve and funnel analysis using your analytics (Amplitude, Mixpanel, Firebase).
- Unit economics calculations: ARPU, LTV, CAC, ROI by segment.
- Competitive monetization analysis on App Store and Google Play.
- Selection of one or multiple monetization models with justification.
- Technical paywall design: StoreKit 2 / Play Billing 6 integration, product caching, grace period handling.
- A/B test plan: hypotheses, metrics, duration.
- Written report with recommendations.
Example LTV calculation: LTV = ARPU × average user lifetime. For subscriptions: churn rate = % of monthly cancellations. At 10% churn, average lifetime = 10 months. If ARPU is $5, LTV = $50. But considering discount rate and refunds, actual LTV is lower.
Our Experience and Guarantees
Over the past years, we have conducted more than 50 monetization consultations for iOS and Android mobile apps. Our experts are Apple and Google certified. We guarantee that recommendations comply with App Store Review Guidelines (Sections 3.1.1, 4.2, 5.1) and Google Play requirements. After implementation, you will see an average ARPU increase of 20–30% while maintaining retention. As shown in App Store Review Guidelines, correct paywall implementation is key to approval.
How to Choose a Monetization Model?
If Day-7 retention > 15% — subscription or freemium with reasonable limitations. If lower — consider consumables or an ad model. For utility apps with one-time use — one-time purchase. We help make a decision based on numbers.
What to Do If Paywall Conversion Is Low?
Check paywall load speed, value proposition, design. Often the issue is pricing: a discount on the annual plan instead of monthly can increase conversion by 10–20%. Also important is button order — the highest-value plan should stand out. We recommend A/B testing up to 5 variants.
How A/B Testing Is Conducted
- Formulate a hypothesis (e.g., "annual subscription with 40% discount outperforms monthly").
- Set up two paywall variants via Firebase Remote Config.
- Split traffic 50/50.
- Measure conversion, ARPU, retention after 7 days.
- Make a decision based on statistical significance.
Monetization Scenario Comparison
| Scenario |
Recommended Model |
Expected ARPU |
| Dating app with high activity |
Consumables (likes, boosts) |
$3–5 per user |
| Fitness app with long onboarding |
Subscription with trial |
$10–15 per month |
| Game with short sessions |
Ads + consumables |
$0.5–2 per user |
Time Estimates
Consultation with metrics audit and recommendations — 1–3 business days. If it includes a technical audit of the current monetization implementation (code, integrations, analytics) — up to 5 days.
Contact us for a consultation. Order a monetization audit and get a document with ready-to-use recommendations.
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.
| Network |
Ad Type |
Feature |
| AdMob |
banner, interstitial, rewarded |
Wide network, easy start |
| MAX (AppLovin) |
rewarded, interstitial |
In-App Bidding, high fill rate |
| ironSource |
rewarded video |
Best for games |
| Mintegral |
rewarded, native |
Asia, programmatic |
How We Implement Monetization: Step-by-Step Process
- Current model audit — analysis of funnel, paywall, price tiers, and identification of bottlenecks.
- Model design — choose type (subscription, consumable, non-consumable) and optimize price points.
- IAP integration — set up StoreKit 2 / Google Billing 6, receipt validation, webhooks.
- Ad mediation — connect 3-6 networks, configure waterfall or In-App Bidding, test fill rate.
- Analytics and cohorts — integrate RevenueCat, Amplitude, or Firebase for LTV tracking.
- A/B testing of paywall — use Remote Config for experiments without a release.
- 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).
Checklist of Typical Monetization Mistakes
- Missing handling of
unfinished transactions — revenue loss of 5-10%.
- No server-side idempotency for consumable processing — double crediting.
- Forgot to call
acknowledgePurchase() on Android — purchase cancelled after 3 days.
- Not handling
REFUND and DID_RENEW events — incorrect subscription status.
- Paywall without A/B testing — leaving 20-40% of monetization potential.
- Ads from a single source (e.g., AdMob without mediation) — CPM 15-30% lower.
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
| Stage |
Duration |
| Basic IAP (one store) |
1–2 weeks |
| Subscription system + RevenueCat + paywall |
3–5 weeks |
| Ad mediation (MAX + 3 networks) |
1–2 weeks |
| Full cycle (IAP + ads + analytics) |
4–8 weeks |
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.