Choose custom product pages or product page optimization
A custom product page is an additional listing reached through its own URL or eligible assigned search keywords. Apple's product page optimization instead compares treatments against an original using randomly allocated traffic. Choose a custom page when a known audience needs a different feature story. Choose the experiment workflow when you need to compare alternative assets for the tested population. Sending different audiences to different custom pages does not create a randomized experiment.
Write the decision before exporting assets. For a fictional recipe app, a page about saving family recipes serves a different task from planning weekday meals. Two competing headline treatments for the same meal-planning audience belong in a comparison plan. Keep the intended reader, current feature, proposed promise and measurement method in the ASO experiment brief. This makes it possible to explain why the page exists even if the first results are inconclusive.
Assign relevant App Store keywords to the page
In App Store Connect, open the custom page and select keywords from the latest approved app version, separately for each localization, then publish the assignment. Search visibility requires an approved page set to visible. Apple recommends distinct keyword sets across pages. This is keyword routing for a relevant feature story, not a replacement for researching accurate terms or validating the version's metadata.
Build a small intent map before selecting terms: customer task, supported feature, matching screenshot, destination and locale. Mark candidate terms as unvalidated until you have checked your actual console choices and research. For example, the fictional phrase family recipes should lead to screenshots of saving and finding those recipes, rather than a generic dashboard. If the app only saves personal recipes, remove family sharing from the promise. A keyword assignment does not establish ranking, demand or traffic.
Prepare the custom page and submit the right draft
Apple reviews custom pages and associated metadata, including deep links, before customers can use them. An approved app can submit a page with or without an app version. For a first app approval, the page belongs in the same submission as the initial iOS version. The submission workflow uses Add for Review followed by Submit for Review; fields are unavailable for editing during review.
Keep a dated local copy of the page's screenshots, promotional text and intended destination. Review the screenshots at phone size and check that a fresh reader can name the main task. Record who owns submission and who will verify the released page. An uploaded asset or saved draft is an intermediate state. Make the launch checklist depend on the actual approved, visible page, with its working public URL and correct language, before using that link in acquisition material.
Test the deep link and the first useful action
An optional app deep link can direct the Open action to specific content on iOS 18 and iPadOS 18 or later. Apple accepts universal links or a custom URL and recommends universal links; the deep link also requires approval. Preserve the custom page URL and the in-app destination as separate entries in your plan. One points to the store page, while the other points to the promised experience inside the app.
Use harmless sample data to test opening the destination with an existing session and after signing out. Record the device, OS, build and account state. Does a necessary login preserve the intended task? Does a permission request explain why it is needed? Check the experience on the versions you support instead of assuming the same journey everywhere. If the route fails, keep that issue attached to the page's launch record. A successful link tap is not proof that someone completed the advertised task.
Compare results using the same population and definition
App Store Connect provides page-level impressions, downloads, redownloads and conversion reporting, together with engagement and proceeds views. Separate the page, locale, source and time period before comparing results. A page sent to returning customers may receive a different audience from the default listing. A higher observed rate can reflect that difference. Use the store's experiment results when your question requires a tested asset comparison.
Keep a record of counts and the report definition, not only a screenshot of a percentage. Our conversion calculator distinguishes absolute percentage-point change from relative change. Neither number proves causation. For a fictional comparison, 10% and 12% differ by two percentage points and 20% relative; the interpretation still depends on the audiences and periods. Pair the report with a private comprehension task: ask a fresh reader what the page promises and what they expect after opening the app. Preserve disagreement as an observation to investigate.
Diagnose a page that does not appear as expected
Check approval and visibility first, then review the assigned keyword and localization in App Store Connect. Test the exact public page URL separately from an App Store search. Record which path failed: opening the listing, seeing the intended assets, finding it for a query or reaching the in-app destination. These observations narrow the next check without treating every issue as a ranking problem.
For a small team, maintain one launch record with page name, locale, customer task, selected terms, screenshot filenames, public URL, deep-link destination, approval status and baseline report scope. Save a fresh observation when any field changes. Use RateMyApp to request focused private feedback on the promise and first journey, with tester availability determined by participation. Community ratings are optional; paid credits fund approved private reports. Publish the next page when another supported audience needs it, rather than multiplying near-identical listings.
Working example
Fictional planning example: Pantry Notes already lets people save their own recipes and build a shopping list. Its owner drafts one custom page for finding a saved recipe. The intent map records personal recipe collection, an eligible keyword selected from the approved version, two screenshots showing search and the saved result, and the recipes destination. It excludes family sharing because that feature is not released. A private tester says the first caption suggests collaboration, so the owner revises the caption before submission. After approval, the owner verifies the exact URL, locale and route on a supported device, then records the page's own report scope. This example illustrates a workflow, not measured demand, an actual customer outcome or a promised ranking increase.
Your next steps
- Choose one supported customer task and distinguish a custom page from a randomized store experiment.
- Map eligible approved-version keywords, locale, screenshots and destination to the same promise.
- Verify approval, visibility, the exact page URL and the first useful in-app action before launch.
- Record page-specific metrics and audience context; use private feedback to investigate misunderstandings.
Official sources
Sources checked October 5, 2026. Review the current provider documentation before acting on requirements.
Turn the next test into something useful.
Publish a focused brief on RateMyApp. Credits fund approved private reports; public store reviews are voluntary and unrewarded.
List your app for feedback