Rewarded Ads Implementation for Mobile Games

A player just lost on level 10 — spent 15 minutes, frustration, and the urge to quit. Properly placed Rewarded Ads turn that frustration into revenue without loyalty loss. But incorrect integration breaks game economy and reduces retention. We have been doing rewarded integrations for 5+ years, delivered 30+ projects for iOS and Android — from hyper-casual to RPG. One case: after configuring continue-after-fail, retention grew by 12%, and eCPM increased by 25%. Average eCPM growth after our tuning is 25-40% (e.g., from $6 to $9 for one project). Let's break down the technical nuances and pitfalls.

How to choose placements for Rewarded Ads?

Placement is a point in the game loop where the player has a need they are willing to "pay" for with an ad view. The most effective:

• Continue after fail — 30–50% conversion provided the player hasn't seen an ad on that screen before. Show after onGameOver, before the results screen. Limit: 1–2 per attempt.
• Daily bonus multiplier — "watch ad — get x3 daily reward". Doesn't break balance, conversion is consistently high.
• Extra currency / chest unlock — a specific offer: "+50 gems" instead of "bonus". Works in the main menu or after a level.

How to technically integrate rewarded on Unity?

We use AdMob (Google Mobile Ads) or IronSource (LevelPlay) SDK. For AdMob initialization:

private RewardedAd rewardedAd;

public void LoadRewardedAd() {
    var adUnitId = Application.platform == RuntimePlatform.Android
        ? "ca-app-pub-xxx/yyy" : "ca-app-pub-xxx/zzz";
    RewardedAd.Load(adUnitId, new AdRequest(), (ad, error) => {
        if (error != null) { Debug.LogWarning($"Rewarded load failed: {error}"); return; }
        rewardedAd = ad;
        RegisterRewardedAdEvents(rewardedAd);
    });
}

private void RegisterRewardedAdEvents(RewardedAd ad) {
    ad.OnAdFullScreenContentClosed += () => {
        LoadRewardedAd();
    };
}

public void ShowRewardedAd(System.Action<int> onRewarded) {
    if (rewardedAd == null || !rewardedAd.CanShowAd()) {
        Debug.Log("Rewarded not ready");
        return;
    }
    rewardedAd.Show(reward => {
        onRewarded?.Invoke(reward.Amount);
    });
}

IronSource (LevelPlay) requires calling IronSource.Agent.loadRewardedVideo() beforehand, and show the button only when IronSource.Agent.isRewardedVideoAvailable() == true.

void Start() {
    IronSource.Agent.loadRewardedVideo();
}

public void OnShowRewardedClicked() {
    if (IronSource.Agent.isRewardedVideoAvailable()) {
        IronSource.Agent.showRewardedVideo();
    }
}

private void OnRewardedVideoAdRewarded(IronSourcePlacement placement) {
    int rewardAmount = placement.getRewardAmount();
    // grant reward
}

Why is server-side verification (SSV) mandatory?

If rewarded gives hard currency (gems, crystals) — without SSV, rewards are cheated with tools like Frida in minutes. AdMob SSV processes callback faster than IronSource, reducing grant delay by 200 ms. Scheme:

1. Client passes userId and a unique nonce in customData when requesting an ad.
2. AdMob/IronSource include them in the SSV callback to your backend with ECDSA signature.
3. Server verifies signature, nonce uniqueness (so one callback cannot pass twice), and grants currency.

Client implementation — 0.5 day, server part — 1 day with testing.

from flask import Flask, request
from ecdsa import VerifyingKey
import json

app = Flask(__name__)

@app.route('/ssv_callback', methods=['POST'])
def ssv_callback():
    data = request.json
    signature = data['signature']
    payload = data['payload']
    vk = VerifyingKey.from_pem(open('public_key.pem').read())
    if vk.verify(signature, payload.encode()):
        # Check nonce in Redis
        return 'OK', 200
    return 'Invalid signature', 400

What impression limits to set?

Limits must be on the server, not just on the client (PlayerPrefs resets). In an MMO project, we set limits via Redis to guarantee nonce uniqueness even at high RPS. Typical: 5-10 rewarded/day for currency, 1-2/day for continue. A hard limit kills revenue, a soft limit destroys economy. We recommend starting with 8 rewarded/day and A/B test steps of ±2. A/B testing helps balance revenue and economy without risk.

How we integrate rewarded ads: step-by-step process

1. Audit current integration (if any) and recommendations to increase eCPM.
2. Select placements for your game economy.
3. Implementation on Unity (AdMob, IronSource) or native SDKs (iOS/Android).
4. Set up SSV backend (any stack: Node.js, Python, Go).
5. A/B test placements and limits.
6. Documentation and 1 month support.

What you get as a result

After completion, you receive:

• Working rewarded placements with optimized show timing.
• Server-side SSV verification with cheat protection.
• Documentation for key scripts and configs.
• Access to backend code for self-modification.
• 1 month of technical support and consultation.

Estimated timelines

Basic integration with 2-3 placements and limits — from 2 days. With SSV and server-side reward logic — from 3 days. Cost is calculated individually.

Order a free audit of your current integration — we will assess your project. Contact us for a consultation.

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.