App Store Optimization · Advanced

Custom Product Pages & In-App Events: The Complete Playbook

Two of the most under-used tools in App Store Connect — and the only ones that let you show a different pitch to different people without touching the listing everyone else sees.

Most indie developers set up their App Store listing once, then leave it alone. That's a reasonable default — but it means every visitor, whether they clicked a TikTok ad, followed a friend's recommendation, or typed your app's name into search, lands on the exact same page. A screenshot set written for a cold searcher rarely speaks to someone who already trusts the person who sent them.

Apple built a fix for this in 2021 and expanded it since: Custom Product Pages (CPPs) let you create alternate versions of your listing — up to 70 of them as of a limit increase in late 2025 — each with its own screenshots, video, promotional text, and even keyword emphasis, reachable only through a link you control. In-App Events are a separate tool: time-boxed happenings inside your app that Apple can surface directly in search and browse, before someone even opens what you've built.

Both are free. Both are underused by solo developers, mostly because the App Store Connect documentation describes what they are without making it obvious what to actually do with them. This is that playbook.

The mental model: doors, not renovations

Think of your default product page as the front door of a house — the one address everyone who doesn't have a personal invitation uses. A Custom Product Page is a side door you build for one specific group of guests, with its own welcome mat matched to how they found out about the house in the first place. Nobody redecorates the whole house for a side door. You're not touching your default listing at all.

This matters because of a common misconception: a Custom Product Page does not replace or affect your default listing's search ranking. It's a separate URL. Someone has to be sent there deliberately — through an ad, a link in a creator's bio, an email, a QR code — it never shows up in organic App Store search itself. Your default listing keeps doing its job for search traffic; CPPs handle everyone you're actively directing somewhere.

In-App Events work on a different axis entirely. Rather than a side door, think of it as a temporary storefront window display Apple lets you apply for. If your event fits one of Apple's defined categories and gets approved, it can appear directly in App Store search results and the Today/Games/Apps browse tabs — visible to people who've never heard of your app, for a fixed window of time.

The mechanics, precisely

Custom Product Pages

• Limit: up to 70 additional product page versions per app, per platform (iPhone/iPad) — Apple doubled this from 35 in a 2025 update. Each page counts as one slot even if you add up to 3 localized versions of it.
• What you can change per page: screenshots, app preview videos, promotional text (170 characters), assigned keywords drawn from your existing keyword field, and — on iOS 18+/iPadOS 18+ — a deep link that opens a specific screen inside your app.
• What you can't change: your app's name, subtitle, icon, or the hidden 100-character keyword field itself — those stay tied to the default listing.
• Review: each CPP's metadata goes through App Review independently of your app binary updates, so you can launch or refresh one without shipping a new build.
• What you get back: a unique, shareable URL per page, plus dedicated conversion analytics in App Store Connect so you can actually see whether a given page is working.

Apple's own published figure: apps referring visitors to a matched Custom Product Page see roughly a 2.5 percentage point higher conversion rate on average — a 156% increase over the 1.6% average conversion rate on default product pages. That's Apple's real, published number, not an estimate (source: Apple Developer).

In-App Events

• Publishing window: an event can be submitted for review and published no more than 14 days before its start date.
• Duration cap: an event cannot run longer than 31 days total.
• Before it goes live: once approved, you can still adjust region availability, priority, start time, end time, and publish date — as long as the new dates are still in the future.
• After it goes live: your editing power narrows — only the start and end dates remain adjustable.
• Once it's actually running: you can only adjust the end date (e.g. to end it early), not the start date or anything else.
• Access: managing events requires an Account Holder, Admin, App Manager, or Marketing role in App Store Connect (source: App Store Connect Help).
• Content rule: event metadata must accurately describe the event itself, not just restate your app's general pitch — Apple checks this in review, and it's also just good practice; see our companion piece on what counts as manipulative ASO for why vague or misleading event copy is a real risk, not just a style note.

Worked example: matching three traffic sources to three CPPs

Say you run PlantFit, a plant-care reminder app. You're sending traffic from three places this month: organic App Store search (your default listing), a paid Instagram Reels campaign, and a link a gardening creator is putting in her bio. Here's a plausible, clearly illustrative breakdown of how you'd treat each one differently — the numbers below are made up for this example, not measured data:

Source	Page used	Illustrative conv. rate
Organic search	Default listing	3.1%
Instagram Reels ad	CPP: fast-motion demo, bold "Never kill a plant again" hook	5.4%
Creator bio link	CPP: screenshots featuring the exact plants she covers in her content	7.9%

The organic searcher already had intent — they typed something related to plant care. The ad viewer needs a hook fast, because they weren't looking for you. The creator's follower already trusts her judgment, so a page that visually confirms "yes, this is what she was talking about" converts best of all three. Same app, three different five-second pitches, zero effect on each other.

A decision framework: is a CPP or event actually worth building?

1. Do you control the traffic already? A CPP only helps if you have a link to put it behind. If you're not running ads, sharing links with creators, or sending emails, build the default listing well first — a CPP with no traffic pointed at it does nothing.
2. Is the audience meaningfully different? If your Instagram audience and your organic search audience would respond to the same pitch, one good default listing already covers both. Build a CPP when the story genuinely needs to change, not by default for every channel.
3. For events: does it fit a real category? Apple's event types (competitions, live events, challenges, new content drops, and similar) are specific. If what you're promoting doesn't fit one honestly, it likely won't get approved — and forcing a fit risks exactly the "event metadata doesn't match the event" rejection Apple explicitly checks for.
4. Can you actually staff the 14/31-day window? An event needs someone watching it — ready to end it early if something breaks, ready to have the in-app experience genuinely live for the dates promised. Don't schedule one you can't attend to.

Practical tool: check your promotional text before you submit

Every CPP's promotional text has a hard 170-character limit. Draft it here first — this counter matches what App Store Connect enforces.

Illustrative: conversion lift by how well the CPP matches its traffic

Watch an event's lifecycle unfold

Common mistakes

• Sending organic search traffic to a CPP by accident. A CPP has no bearing on search ranking, but if you accidentally link your own website's "Download on the App Store" button to a CPP URL, you've disconnected your best organic-intent visitors from the listing your keyword work is aimed at improving.
• Letting a CPP go stale. A page built for a campaign that ended six months ago, with screenshots referencing a promotion that's long over, actively hurts the source it's still receiving traffic from.
• Treating In-App Event metadata as more marketing copy. Apple reviews events for whether the description matches the actual event — padding it with general app-marketing language rather than event-specific details is a real rejection risk, not just weak writing.
• Scheduling an event you can't finish. Once live, you can only adjust the end date, not extend functionality or fix a broken in-app experience tied to the event. Test the actual in-app side before submitting.
• Building 20 CPPs for 2 real traffic sources. More pages isn't the goal — matched pages are. An unused CPP is just unreviewed effort sitting idle.

Quick self-check

TL;DR

• Custom Product Pages are separate URLs — up to 70 per app — that let you show different screenshots, video, and text to different traffic sources without touching your default listing or its search ranking.
• Apple's own figure: matched CPPs convert about 2.5 percentage points higher on average than the default listing's 1.6% baseline — a 156% relative lift.
• In-App Events can appear directly in App Store search and browse for a window you control — but only within strict limits: 14 days advance publishing, 31 days max duration, and shrinking editability once live.
• Build a CPP only when you have real traffic to send it and a genuinely different story to tell that audience — not one per channel by default.
• Both tools are free and reviewed independently of app binary updates, so there's no reason to leave them completely unused once you have a real traffic source to test with.

Sources cited inline: Apple Developer — Custom Product Pages, App Store Connect Help — Manage Events. Worked example figures are illustrative, not measured data.