Subscription offers and store promotional tools
Expert: with sources and numbers. Plain: the same, without them, for beginners.
Offers that surface on the store rather than only inside the app, what each is for, and the limits.
Offers are usually treated as monetisation. Several of them surface on the store, outside the app, which makes them an ASO-adjacent lever. And the boundary is worth drawing precisely, because most of this is not ASO.
Why this page exists at all
A Up to 20 in-app purchases and subscriptions can be displayed on the product page, and promoted in-app purchases can appear in App Store search results. (Creating your product page; App Store search, verified 2026-09-19)
So IAP names and descriptions are user-visible, searchable store surfaces (10-06). Offers attach to those products. That is the connection.
The three Apple offer types
A Verified 2026-09-19.
Win-back offers, re-engage previous subscribers whose subscription expired after they disabled auto-renew. You choose eligibility based on how long they were paid subscribers and when their subscription ended. They display automatically on the customer’s Manage Subscriptions page and within the app on the win-back offer sheet, and can also be marketed through a redemption URL. (Set up win-back offers)
Promotional offers, a discounted price for a set duration, for existing and previously subscribed customers. Up to 10 active offers per subscription. (Set up promotional offers)
Offer codes: a free or discounted price for a set duration, to acquire, retain and win back subscribers. Two kinds: one-time-use codes, and custom named codes such as SPRINGPROMO. Both are redeemable through a redemption URL or in the app, and customers can redeem one code per offer. (Set up subscription offer codes)
The limits, which matter for planning:
| Redemptions per app, per quarter | 1 million, shared across all subscriptions |
| Active offers per subscription SKU | 10 |
| One-time-use codes per batch | min 500, max 25,000, multiple batches allowed per offer |
| Validity | maximum six months |
| Deactivated unredeemed codes | not returned to the quarterly limit |
What is actually ASO’s business here
Redemption URLs are a traffic source you can control. Win-back offers and offer codes both produce URLs. Those go into campaigns, partner placements, CRM, print. And, like any inbound link, they land somewhere. Decide where (97-06).
IAP names and descriptions are store copy. A 35 and 55 characters (10-06), visible on the product page, surfacing in search. They are frequently left as internal identifiers, which is a small, free improvement.
Win-back changes what “conversion” means. A Apple’s conversion rate includes redownloads (80-01). A successful win-back campaign moves that number without acquiring anyone new. Separate first-time downloads before reporting.
The quarterly cap is a planning constraint. One million redemptions per app per quarter is generous, but deactivated unredeemed codes are not returned to it. So churning through batches to fix a mistake burns the allowance permanently. Create batches deliberately.
What is not ASO
Pricing, offer economics, subscription lifecycle strategy, churn modelling, paywall design. Real work, owned elsewhere. The two conference decks on subscription renewals and CRM reviewed here are on that side of the line and are catalogued rather than mined.
The boundary that holds: if it changes what appears on the store, it is in scope here. If it changes what happens after install, it is not.
Google Play
Play’s equivalents sit in Play Console under subscriptions and promotions, and the store-facing promotional surface is promotional content (70-02), which is gated. A available for all games, and for apps meeting the Premium growth tools eligibility criteria.
Note the policy line: A Play’s Metadata policy prohibits price or promotional information in metadata (“10% off”, “free for limited time only”) including inside images (20-02). An offer can exist; advertising it in your title, icon or screenshots cannot.
The same applies on iOS: A Guideline 2.3.7 prohibits metadata that includes prices or terms not specific to that metadata type.
So the offer lives in the offer mechanism, not in the store copy. This catches people out every promotional season.
What goes wrong
Putting the discount in the screenshots. Prohibited on both platforms, graphics included.
Reporting win-back redownloads as acquisition. Apple’s conversion rate includes them.
IAP names left as internal identifiers. User-visible and searchable.
Burning the quarterly allowance on deactivated batches. Unredeemed codes from a deactivated offer do not come back.
Treating this page as the subscription strategy. It is the store-surface slice of it and nothing more.
In short
Every fact on this page in one line, with its evidence tier, source and verification date, 4 A. Generated from the claim register, so it cannot drift from the page above.
Special offers are usually treated purely as a pricing and revenue question. Several of them genuinely show up on the shopfront itself, outside the shop, which makes them worth a page here. And it's worth drawing that boundary precisely, because most of this subject genuinely isn't about being found or chosen at all.
Why this page exists at all
A meaningful number of extra shelf items and memberships can be shown right on your own page, and a featured extra item can show up directly in search answers too.
So the names and descriptions of these extra items are genuinely visible, searchable pieces of your shopfront. Special deals attach to those exact items. That's the whole connection to this job.
The three kinds of deal, on the locked side
A win-back card, aimed at re-engaging someone whose membership lapsed after they turned off automatic renewal. You choose who's eligible based on how long they were a paying member and when their membership actually ended. It shows up automatically on their own account page and inside the shop itself, and can also be marketed through its own redemption link.
A promotional card, a discounted price for a set stretch of time, for current and previous members. A generous but real cap on how many can be active per membership at once.
Offer codes: free or discounted access for a set stretch, aimed at bringing people in, keeping them, or winning them back. Two kinds: single-use codes, and custom-named ones you can choose yourself, like a seasonal word. Both redeem through their own link or inside the shop itself, and each shopper can only redeem one code per deal.
The real limits worth planning around: a generous but real cap on total redemptions per shop each season, shared across every membership; a real cap on how many deals can be active per single membership at once; a minimum and maximum batch size for single-use codes, with several batches allowed per deal; a maximum length of validity of about half a year; and unredeemed codes from a deal you switch off don't get returned to your seasonal allowance.
What's genuinely relevant to being found and chosen here
A redemption link is a real, controllable source of traffic. Both the win-back card and offer codes produce their own links. Those go into campaigns, partner placements, your own outreach, print. And like any incoming link, they have to land somewhere specific. Decide where deliberately.
Extra-item names and descriptions are genuine shopfront writing. Visible on your own page, showing up in search. And frequently left as internal-only labels nobody bothered to rewrite, which is a small, free improvement sitting right there.
A win-back campaign quietly changes what "conversion" even means. One centre's own conversion figure includes people re-downloading the shop entirely. A genuinely successful win-back push moves that number without bringing in a single new visitor. Separate first-time downloads out before you report anything.
The seasonal cap is a real planning constraint. A generous allowance of redemptions per shop each season sounds like plenty, but unredeemed codes from a deal you switch off don't come back to you. So churning through batches to fix a mistake burns that allowance permanently. Create batches deliberately, not casually.
What genuinely isn't part of this job
Pricing itself, the economics of a deal, membership lifecycle strategy, modelling who cancels, and paywall design. Real, serious work, owned by other people entirely.
The boundary that actually holds: if it changes what shows up on the shopfront itself, it belongs here. If it only changes what happens after someone's already inside, it doesn't.
On Google's side
The equivalent tools live in that centre's own back-office under memberships and promotions, and the shopfront-facing surface for it is the time-limited poster, which is itself gated to certain kinds of shops.
Worth noting the house rule specifically: that centre's own rules ban a price or promotional claim anywhere in your writing (a percentage off, "free for a limited time") including baked into an image. A deal can genuinely exist; advertising it in your sign, icon or window photos cannot.
The same applies on the locked side: its own house rule bans writing that includes a price or a term that doesn't belong in that particular piece of metadata.
So the deal lives inside the deal mechanism itself, not in your shopfront writing. This catches shop owners out every single promotional season.
What tends to go wrong
Putting the discount right into a window photo. Banned on both sides, images included.
Reporting win-back re-downloads as if they were brand-new visitors. One centre's own conversion figure includes them.
Extra-item names left as internal-only labels. They're genuinely visible and searchable.
Burning your seasonal allowance on deactivated batches. Unredeemed codes from a switched-off deal don't come back.
Treating this page as your whole membership strategy. It's only the shopfront-facing slice of it, and nothing more.