Custom product pages and product page optimization are the two App Store features that let you do something to your product page other than edit it and hope. One multiplies the page — up to 70 additional versions, each with its own URL, each aimed at a different audience. The other turns the default page into a controlled experiment, up to three treatments against your original, for up to 90 days. Confusing the two is the most common mistake: teams build a dozen custom pages to "test" a screenshot, or run a 90-day optimization test on traffic they could have segmented in an afternoon.

This guide follows the order the work actually happens in: decide which tool answers your question, create the page or the test in App Store Connect, clear App Review, promote the page with its unique URL or with Apple Ads, then read the result in App Analytics and decide whether to keep it. Every number below is from Apple's official documentation, because both features are policed by the same metadata rules that get listings rejected.

1. Two tools, two different jobs

The distinction is simple once you state it plainly.

The practical rule: if you already know which audience you are talking to, use a custom product page. If you do not know which of two creative ideas converts better, run a test. A test cannot tell you whether "RPG players" respond to RPG screenshots — it only tells you whether a treatment beats the baseline across the mixed traffic that saw it.

2. What each one is allowed to change

The feature set is narrower than most teams assume, and the gap matters because it decides what you can test.

Neither feature rewrites your app name or subtitle. If your problem is the title, this is the wrong tool — that is a metadata edit reviewed as part of a version, not an experiment.

3. Step 1 — create a custom product page

Creating one starts in App Store Connect, and you begin from either a blank page or a copy of your default product page. In practice, copy — a blank page usually means re-uploading assets you already have, in every localization, and losing the layout you spent a quarter tuning.

  1. Open the app in App Store Connect and go to the custom product pages area.
  2. Choose copy default page or start blank, then name the page so the intent is obvious six months later.
  3. Replace the screenshots, promotional text and/or app previews for the audience this page serves, per localization. You can localize every language the app supports, or only the ones you need.
  4. If the page should be discoverable in search, assign keywords. Apple's rule here is specific and easy to break: the keywords must match the intent of the page, and each keyword combination must be unique to a single page — you cannot give the same keyword set to three pages.
  5. Optionally add a deep link (iOS 18 / iPadOS 18 and later) that opens the exact screen the page advertises.

Apps that are available for pre-order can use custom product pages too, which is worth knowing when you are building an audience before launch rather than reactivating an existing one.

4. Step 2 — submit the metadata for review

Custom product pages are not a live-editing surface. Any metadata included in a custom product page must be submitted for review, and the useful detail is that you can do this independently of an app update — no version bump, no binary, no new build. For teams whose release train is booked weeks ahead, that independence is the whole point.

Review is not a formality. Apple's guidance for a smooth pass is narrow and unglamorous: screenshots and previews must meet the size and format specifications, and every piece of metadata must follow the App Review Guidelines. That means the page must describe what the app actually does — a custom page is still your product page, and a claim that would fail on the default page fails here too.

If you are maintaining many pages across many locales, doing this by hand is how pages drift. The App Store Connect API supports automating metadata upload and submission for custom product pages, which is how you keep twenty pages consistent instead of twenty pages that were each true three months ago.

5. Step 3 — promote the page with its unique URL

A custom product page nobody visits is a design exercise. Each page has its own URL — the default product page URL with an additional product page ID parameter — and that URL is the entry point everywhere:

Two operational notes. First, the unique URL is a real asset — version it, store it next to the campaign it belongs to, and check that it still resolves before a paid push goes live. Second, keep the promise aligned: if the page's screenshots show a mode the app defaults away from, the visitor's first session contradicts the ad, and the conversion you bought evaporates at day seven.

6. Step 4 — read the numbers in App Analytics

Once pages are live, App Analytics in App Store Connect is the only place that credits them. On the Acquisition tab you get product page impressions, downloads, redownloads and conversion rates per page, so you can compare each custom page against your default page rather than against a feeling.

Apple's own aggregate figure is a useful sanity check on whether the effort is worth starting: developers see an average 2.5 percentage point increase in conversion when referring people to a custom product page — against an average conversion rate of about 1.6% on default product pages. Read that as a statement about referred traffic, not a promise that publishing ten pages raises your baseline: the lift comes from matching creative to audience, which is work, not configuration.

The deeper question is quality, and App Analytics answers it too: whether people who installed from a custom page stay engaged longer or spend more on in-app purchases, retention data and average proceeds per paying user per page. A page can raise conversion and lower revenue per user at the same time — segment-specific pages often attract a narrower, lower-intent audience. Track both, and judge the page on proceeds per impression, not on installs alone.

7. Step 5 — configure a product page optimization test

PPO lives in App Store Connect as well, and its constraints are strict enough that misconfiguring one wastes a quarter. A test runs on iOS and iPadOS 15 or later, and you can create one test at a time.

  1. Name it for future you. The reference name allows up to 64 characters. "Spring icon color test, 3 icons, EN/DE" beats "Test 4" when you are reading results in App Analytics three months later.
  2. Choose up to three treatments. Each treatment is an alternate page with its own icons, screenshots and previews; anything you do not replace stays as your original. Fewer treatments reach a conclusion faster — the more you add, the longer it takes to separate signal from noise.
  3. Allocate traffic. You pick the percentage of visitors randomly selected to see a treatment instead of your original page. Apple's own example: allocate 40% with two treatments and each treatment gets 20% of total traffic while the original keeps 60%. A visitor sees the same treatment for the whole test, so the comparison stays clean.
  4. Localize deliberately. Each treatment can be localized in every language your app supports or only in the ones you select — but more localizations means slower results, because the traffic is split further.
  5. Estimate duration, then accept reality. The optional estimator takes your desired conversion improvement and your app's existing impressions and downloads, and returns the estimated duration plus the impressions needed to reach at least 90% confidence. If the estimate exceeds 90 days, change the criteria — fewer treatments, more traffic — rather than starting a test that cannot finish.

A test runs for 90 days or until you stop it, whichever comes first, and it cannot be edited once it starts. Treat the configuration screen as a one-shot form: changing the traffic split or swapping a screenshot mid-test is not permitted, so get the design right before you press go.

8. Step 6 — clear the review gate before the test runs

PPO has its own review mechanics, and they trip up teams who assume a test is internal.

Plan the icon case backwards from your release calendar: the binary carrying the variants has to be the published version before the test opens, which usually means the icon test is scheduled alongside a version submission rather than in a quiet week.

9. Step 7 — read the result, apply the winner, close the loop

While the test runs, App Analytics shows a dashboard that says whether more data is needed or whether a treatment is already performing better or worse than the baseline. Per treatment you see impressions, conversion rate, percent improvement and confidence level, and you can change the baseline between treatments to compare them against each other.

Apple's recommendation is explicit: wait until at least one treatment is declared better or worse than the baseline with 90% confidence before acting. Applying a treatment to the original page displays it to everyone — and ends the test if it is still running. So the sequence is: reach confidence, apply, then confirm the applied assets are what you meant to ship.

One detail closes the loop and is routinely missed: if the applied treatment includes an alternate app icon, you must include that icon when you submit your next app version in App Store Connect. The store-side change and the binary need to agree, or the next submission reintroduces the old icon on devices.

10. The compliance layer nobody reads until a rejection

Both features are metadata surfaces, and metadata is reviewed against the App Review Guidelines — Guideline 2.3 on accurate metadata is the one that bites. In practice, the failures look like this:

None of this is exotic. It is the ordinary discipline of keeping store metadata true, applied to surfaces that multiply faster than a single listing does — which is exactly why the teams that run dozens of pages automate the upload and keep a single review checklist per locale.

11. Where KappS fits

KappS works on the account and release side of this: keeping developer accounts, payment and tax profiles, and store metadata in a state that survives App Review — preparing and submitting compliant material, never working around a check. For teams running custom product pages at scale that usually means:

We do not offer inflated conversion numbers, purchased installs or metadata tricks that promise what an app cannot do. Those are the fastest route to a rejected page, a rejected account, or both — and they are not services we provide. The durable version of this work is unglamorous: match the page to the audience, tell the truth on it, and measure what it actually returns.

Sources (Apple official documentation): App Store — Custom Product Pages (developer.apple.com/app-store/custom-product-pages); App Store — Product Page Optimization (developer.apple.com/app-store/product-page-optimization); App Review Guidelines, Guideline 2.3 Accurate Metadata; App Analytics — Acquisition.