Integrating Rewarded Ads in Mobile Apps
We implement Rewarded — the only ad format users voluntarily watch. Conversion rates where it is organically woven into the game mechanics (extra life, bonus currency, level unlock) reach 40–70% of button impressions. Unsurprisingly, eCPM for rewarded is 3–10x higher than interstitial, and the app's LTV with proper integration grows by 25% while reducing time to first purchase by 15%. Our experience: 50+ monetized projects, Google AdMob and App Store certifications.
But this format has a nuance: locking the moment the reward is granted. If implemented incorrectly, users either get rewards without watching the ad or receive nothing after honest viewing. Both scenarios break trust, reduce revenue, and can lead to app removal from stores.
Where Exactly Reward Logic Breaks
Mistake #1: Granting reward in onAdDismissed.
// WRONG rewardedAd?.fullScreenContentCallback = object : FullScreenContentCallback() { override fun onAdDismissedFullScreenContent() { giveReward() // user could close at second 3 } } onAdDismissedFullScreenContent fires on any close — both after full view and pressing the close button early. Reward should only be in onUserEarnedReward:
rewardedAd?.show(activity) { rewardItem -> // This callback = user watched to end val rewardAmount = rewardItem.amount val rewardType = rewardItem.type giveReward(rewardType, rewardAmount) } Mistake #2: Client-side verification.
Granting the reward directly in onUserEarnedReward is fine for simple cases (adding a life in memory). But if the reward affects server-side state (virtual currency, premium content) — you need server-side verification (SSV).
How Server-Side Verification (SSV) Works
SSV guarantees the reward is credited only after confirmation from the ad network. Workflow:
- The app requests a rewarded ad with
customData— a string containing userId and nonce. - After the view, the ad network (AdMob/IronSource) makes a GET request to your verification endpoint.
- The request parameters are signed with the network's ECDSA key (public key available at gstatic.com).
- Your server verifies the signature and grants the reward.
- The client receives confirmation via WebSocket or polling.
// Pass userId in customData when loading val serverSideVerificationOptions = ServerSideVerificationOptions.Builder() .setCustomData("userId:${currentUser.id};nonce:${UUID.randomUUID()}") .build() val adRequest = AdRequest.Builder().build() RewardedAd.load(context, AD_UNIT_ID, adRequest, object : RewardedAdLoadCallback() { override fun onAdLoaded(ad: RewardedAd) { ad.setServerSideVerificationOptions(serverSideVerificationOptions) rewardedAd = ad } }) SSV is critical for any app where currency converts to real value or affects PvP balance. Clients save an average of 30% of the refinement budget by implementing SSV from day one.
Ad Format Comparison
| Format | Opt-in | Opt-out | eCPM | Conversion |
|---|---|---|---|---|
| Rewarded | Yes | No | High (3–10x interstitial) | 40–70% |
| Interstitial | No | Yes | Low | ~10% |
| Rewarded Interstitial | No | Yes (but with reward) | Medium | 20–30% |
Rewarded Interstitial is a hybrid: doesn't require explicit opt-in but rewards the view. eCPM is 50% higher than regular interstitial.
Server-Side vs Client-Side Verification
| Feature | Client-Side Verification | SSV |
|---|---|---|
| Tamper protection | No | Yes (ECDSA cryptography) |
| Additional server load | No | Yes (milliseconds) |
| Risk of granting without view | High | Zero |
| Integration time | 1 day | +2 days |
UX for Ad Display
The "Watch Ad" button should only be shown when the ad is loaded — i.e., when rewardedAd != null. A grayed-out disabled button is worse than a hidden one. Start preloading early: immediately after the previous show or when the screen opens where the button might appear.
If loading fails — hide the button, do not show an error to the user. Retry with exponential backoff (1 → 2 → 4 → 8 sec) quietly in the background.
Why Correct Reward Granting Matters
Faulty reward granting leads to financial losses and negative reviews. Our clients save an average of 30% of the refinement budget by implementing SSV from day one. We ensure correct reward logic and document each integration stage.
Typical SSV Scenarios
- Granting premium currency convertible to real money.
- Unlocking PvP endgame after a view.
- Subscription access (time-limited bonuses).
What's Included
- Analysis of reward requirements and app economy
- Selection and configuration of ad network (AdMob, IronSource, Unity Ads)
- Implementation of Rewarded Ad display with UX considerations
- Server-side verification (SSV) integration if needed
- Documentation and commented code
- Testing all scenarios (successful show, error, limit exceeded)
- Training the client's team on tools
Timeline and Cost
Basic rewarded implementation without SSV — 1–2 days. With server-side verification and game economy integration — 2–3 days. Cost is calculated individually after project analysis. Request a consultation — our engineers will evaluate your project and propose a turnkey solution. Get a validated integration that boosts revenue and user satisfaction.