Running a sale in a subscription app should be simple. Pick a discount, decide who gets it, decide when it ends. In practice, most teams discover that “who gets it” and “when it ends” are the hard parts — because the paywall is baked into the app, and the app is behind a review queue.
If you already use RevenueCat, you have the right primitive for this: an Offering. And if you connect RevenueCat to WinWinKit, you get the missing half — a way to hand that Offering to specific users, gated behind a code, for a specific window of time, and take it back automatically when the sale is over.
Here’s how to run that campaign end to end.
Why Offerings Are the Right Unit for a Sale
An Offering in RevenueCat is a set of products with a paywall configuration attached. Your app asks RevenueCat for the current Offering and renders whatever comes back. That indirection is the whole point: you can change what a user is offered without shipping a new build.
Most teams use this for pricing experiments and never take the next step. But a sale is just a targeted Offering with an expiry date. A “Black Friday” Offering with the same products at 40% off is a first-class thing you can create in RevenueCat in a few minutes.
The problem is scope. Swapping your default Offering applies the sale to everyone — including users who were about to convert at full price, and including users who will now see a discount they never earned. What you usually want is narrower: this discount, for people who came in through this creator, or claimed this code, or referred a friend. That’s not something RevenueCat is designed to orchestrate on its own.
What WinWinKit Adds
WinWinKit treats a RevenueCat Offering as a reward type. You create a reward that points at one of your Offerings, attach it to a promo code, referral program, or affiliate campaign, and WinWinKit handles the rest.
When a user earns the reward, WinWinKit sets that Offering as the current Offering override for their RevenueCat customer, server-side. When the reward expires, WinWinKit resets the override and the user falls back to your standard Offering.
Two consequences worth sitting with:
Your app code doesn’t change. It just starts getting a different answer for the users in the campaign.
The sale ends on its own. You configure the duration when you set the reward up. You do not have to remember to turn anything off, and you don’t have to ship a build to end a sale that ran long.
WinWinKit connects to RevenueCat in a few clicks — Settings → Integrations → RevenueCat → Connect. See the revenue tracking docs to learn more.
Step by Step
1. Build the sale Offering in RevenueCat
Create a new Offering — call it something you’ll recognize later, like blackfriday2026 or winback40. Add the discounted products, attach a paywall, and make sure the Offering is published. Don’t make it your default.
A note on discount mechanics: an Offering points at real store products, so the discount comes from the products you put in it — an introductory offer, a cheaper product, a longer trial. Decide this deliberately. A product that’s discounted forever will follow those subscribers through every renewal; a product with a discounted first period and a standard renewal rate protects your LTV. Whatever you choose, make the price change explicit on the paywall.
2. Create the reward in WinWinKit
In your project dashboard, go to Rewards → New Reward and pick RevenueCat Offering as the type. WinWinKit reads your Offerings straight from RevenueCat, so your new sale Offering will be in the dropdown.
3. Pick how the sale is distributed
This is the decision that shapes the campaign. The same reward can hang off any of three distribution mechanisms:
A promo code — one code, published widely. BLACKFRIDAY40 in a newsletter, a push notification, a social post, a podcast read. Set a limit if you want to cap redemptions, or leave it unlimited.
An affiliate campaign — a unique code per creator. Each partner gets their own code, their audience gets the sale, and the partner earns commission on the revenue they drive. You get per-creator attribution instead of one undifferentiated redemption count.
A referral program — the sale becomes the reward for referring, being referred, or both. This is how you turn a sale into acquisition rather than just a discount on demand you already had.
4. Set activation and deactivation
Attaching the reward is where you decide when it turns on and how long it lasts.
Activation for promo codes and for invited users in a referral program happens on claim — the user enters the code, and the Offering is theirs. For referring users, you can also activate on conversion, meaning the referrer only gets the sale once the person they invited actually becomes a paying subscriber. Both variants let you require more than one claim or conversion — reward the referrer after three friends convert, not one.
Deactivation is either Never or an interval — a duration you specify. For a sale campaign, the interval is the important one. Set it to the window in which you actually want the user to decide: 48 hours creates real urgency, 7 days is a comfortable default, 30 days is generous enough that it stops being a sale.
This interval is per user, counted from when they earned the reward. Someone who claims your code on the last day of the campaign still gets their full window. That’s usually what you want, but it means your discounted cohort tails off after the campaign ends rather than stopping dead — worth knowing before you look at the revenue chart.
5. Distribute the code
Every code in WinWinKit gets a hosted code link on your project subdomain — something like yourapp.wwk.link/BLACKFRIDAY40. It’s a real URL you can put in an email, a bio link, a QR code on a conference banner, or a YouTube description. It handles the App Store or Play Store handoff and the code claim on the other side, so a creator can share one link instead of explaining a redemption flow.
Inside the app, you can surface a claim field wherever it fits, or trigger the claim automatically from a deferred deep link.
6. Let it run, then read the numbers
Because the sale rides on your existing RevenueCat integration, revenue from discounted subscribers flows back into WinWinKit the same way all other revenue does. You can see how many users claimed, how many converted, and — for affiliate campaigns — which partner drove what.
Three Campaign Recipes
The seasonal public sale. One promo code, one discounted Offering, a 7-day deactivation interval, unlimited redemptions. Announce it by push and email on day one, remind on the last day. The value over just switching your default Offering: only users who acted on the campaign get the discount, and you know exactly how many did.
The creator sale. One discounted Offering, an affiliate campaign per creator, each with their own code and commission. The creator’s audience gets a real, exclusive-feeling deal — not the same banner everyone else sees — and the creator gets paid on the revenue rather than on clicks or views. Run it as an always-on program rather than a one-week event; the Offering is the perk that makes their code worth sharing.
The two-sided referral sale. The invited user gets the discounted Offering on claim, with a short interval so the invite has urgency. The referrer gets their reward on conversion — an extended entitlement, credits, or a discount of their own — so you’re only paying for referrals that actually become subscribers. This is the version that keeps producing installs after the campaign week is over.
Things to Get Right
Keep the Offering published in RevenueCat for the whole campaign. WinWinKit deactivates a reward if its Offering stops existing in RevenueCat. Don’t clean up the Offering until every reward window has closed.
Check your claim code eligibility window if you’re targeting existing users. By default, WinWinKit only lets users claim a code within 7 days of when they were first seen — a sensible rule for referral programs, and exactly wrong for a win-back sale aimed at users who installed months ago. Set it to 0 (unlimited) or a longer window under Settings → General → Configurations → Claim Code Constraint in Days before you launch.
Be careful with permanently discounted products. An Offering can quietly become your most expensive acquisition channel if the products inside it renew at the discounted rate forever. Prefer a discounted first period with a standard renewal.
Make sure user identity lines up. The override is applied to a RevenueCat customer, which means the app user ID WinWinKit knows must be the one RevenueCat knows. If you log users in and out across identities, verify this before the campaign, not during it.
The Short Version
A sale campaign has three moving parts: an offer, a way to give it to the right people, and a way to take it back. RevenueCat Offerings give you the first. WinWinKit’s promo codes, affiliate campaigns, and referral programs give you the second. The deactivation interval gives you the third — automatically, without a build.
If you’re already on RevenueCat, connecting WinWinKit takes a minute and integrating the SDK is a one-time app update — every sale after that ships from the dashboard.