无付费墙变现：用激励广告替代内购的完整配置指南

My wife knows very well that I’m someone who is determined to find the best parking spot in a lot. We started talking, as I circled parking lots, about some of my criteria for a great spot, and I thought: “This would make a great game.” So I built it. It's called Curb Appeal. You get 10 rounds, a parking lot, a timer, and one job: pick the best spot.

But the interesting part isn't the game. It's how it makes money. There's no paywall, no subscription, no in-app purchase (IAP). There's one button that says 'Watch Ad to Play', and behind that button is RevenueCat Ads.

Keep in mind that although I used this to make a game, RevenueCat Ads can also work for an app you’re building, such as a Photo Editing app that lets you watch an ad to unlock a premium filter, or a Messaging app that unlocks premium sticker packs with ads.

Watch on YouTube

RevenueCat Ads does two things right now

Ad revenue tracking ties ad money to the same user as your purchases

The obvious pitch is that you stop bouncing between AdMob and RevenueCat to figure out what your app actually made. True, and nice. But the better pitch is underneath that: your ad revenue gets tied to the same user as your subscription and IAP data.

That means ad revenue folds into your revenue chart and into realized LTV. You get blended revenue per user instead of two disconnected numbers you're eyeballing across two tabs. There's also a dedicated ads section in RevenueCat Charts and an ads tab on individual customer profiles, so "is this free user actually worth anything?" becomes a question you can just look up.

Francie wrote the full breakdown of the tracking side when it went into public beta: every metric, what shows up where, and how the SDK integration works. If you're on AdMob, it's mostly swapping your ad loading calls for RevenueCat's loadAndTrack methods. Make sure to turn on ‘Impression-Level Ad Revenue’ for it to track correctly.

Start there if tracking is what you came for. The rest of this post is the other half.

Ad rewards grant virtual currency or a timed Entitlement (this is new)

A user finishes a rewarded ad, AdMob fires a server-side verification (SSV) callback to RevenueCat, and RevenueCat verifies it and grants the reward. You don't build the verification layer. You don't build the granting layer. You just configure it in the dashboard.

Two kinds of rewards:

• Virtual currency: coins, credits, gems, tokens, whatever your economy uses
• Entitlements: actual RevenueCat Entitlements, granted for a duration

That second one is the interesting part. An Entitlement is just a level of access. Normally you get one by paying, but now, you can earn one by watching an ad. Same Entitlement check in your code either way.

Before you start: what you need in place

Three prerequisites:

• An AdMob account with a rewarded ad unit, connected to your RevenueCat project so your ad units sync to the dashboard.
• Server-side verification enabled on that ad unit in the AdMob console, pointing at RevenueCat's SSV callback URL. It's one shared endpoint for every ad unit, and RevenueCat works out which unit and which user from what the SDK attaches at show time.
• The RevenueCat SDK (purchases-ios 5.80.3 or later (iOS 15+), or purchases-android 10.12.0 or later).

The AdMob adapter that makes this a two-line change is iOS and Android only. On Flutter, React Native, Unity, or Kotlin Multiplatform, you take the manual path: generate a verification token, attach it to your ad's SSV options, then poll for the result. That needs purchases_flutter 10.6.0+, react-native-purchases 10.5.0+, purchases-unity 9.8.0+, or purchases-kmp 3.5.0+.

Ad revenue also doesn't count toward Monthly Tracked Revenue right now, which means the feature is free to use.

The ad monetization docs walk through every step. Point your agent at them: it can read the docs, do the implementation, and debug it when something's off (that’s what I did!).

How to set up RevenueCat Ads Entitlements in your dashboard

1. Create the Entitlement: Product catalog → Entitlements → new Entitlement. I called mine play_game, because that's what it does.

One thing worth knowing: you do not need to attach a product to that Entitlement for ad rewards to work. But you also don't have to choose between ads and purchases for the same Entitlement — you can attach both. A user gets access either by subscribing or by watching an ad, and your code only ever checks one thing: is play_game active.

Say you're running a Pro tier that gates your whole app behind a subscription. Attach an ad reward to that same pro Entitlement, and now a non-payer can earn Pro access for 30 minutes by watching an ad, on the exact same Entitlement your subscribers already have.

For an ads-only Entitlement with no purchase path at all, you can skip the product entirely.

2. Create the reward: Ads → Rewards → 'Add entitlement reward'. Pick your synced rewarded ad unit, pick the Entitlement, set a duration.

I went with 30 minutes, which is the lowest amount of time allowed. Watch one ad, play for the next half hour.

3. Wire up verification, then check the Entitlement: On the ad itself you call enableRewardVerification() after it loads, then present it with a rewardVerificationCompleted callback. That callback is where you react to the verified reward. The rewards docs have the full Swift and Kotlin versions.

Gating the game is the same check you'd write for a subscription:

let customerInfo = try await Purchases.shared.customerInfo()

let canPlay = customerInfo.entitlements["play_game"]?.isActive == true

You don't have to refresh anything yourself. Before it hands you the result, the SDK already refreshes customer info for an Entitlement reward and invalidates the virtual currencies cache for a currency reward. We’ll just want to make sure we check this value each time before we allow the user into the game.

That's it! Watch ad → Entitlement active → button goes live → 30 minutes of aggressive parking decisions.

Or, grant virtual currency instead of a timed Entitlement

Duration-based isn't always the right shape. If 30 minutes of access doesn't map to how your app works, use virtual currency instead: 10 coins per ad, 10 coins per game. Users can stack up a balance, spend it how they want, and you're not fighting a timer to model something that isn't time-based.

An ad unit can have one virtual currency reward and multiple Entitlement rewards at the same time, and completing the ad grants all of them together. So you can hand out coins and open up access from a single view if that's your design.

When rewarded ads are the wrong call

A rewarded ad only helps you if it's not replacing a sale you'd have made anyway. If someone would have subscribed or paid specifically for the perk behind the ad, don't let them earn that same perk for free by watching thirty seconds of video. However, a subscriber who watches an ad for something extra — bonus currency, a one-time boost, a perk they wouldn't otherwise pay for, is pure upside. More engagement, more ad revenue, nothing cannibalized.

RevenueCat's State of Subscription Apps 2026 found only about 10% of apps run a true hybrid monetization model that mixes IAP, ads, and subscriptions, and it's concentrated in gaming at roughly 4x the average. That's where adoption is today, not where it has to stay. The rewarded ad pattern maps cleanly into non-gaming apps too, and most haven't tried yet. This gap is an opportunity.

Execution is what decides whether it pays off. The reward has to be valuable: earn something people actually want. It has to be discoverable: if it's buried two menus deep nobody finds it. And it has to be repeatable: a reward users come back for compounds, which is where you find the incremental dollars.

Quick tangent… enter Shipaton to win the Catvertising Award!