Custom product pages are one of those App Store Connect features that sound more complicated than they are, and also a bit less powerful than the marketing framing suggests. If you've never shipped one, the mental model is short: you're making alternate front pages for the same app, aimed at different people who arrive from different places. The app itself, the binary, the reviews, the name in search results, none of it moves. Only the shopfront moves.
At Olnesta Ltd we've used them mostly to stop arguing with ourselves about screenshots. The default product page has to work for everyone who lands on it from search or from a category browse, which usually means the first screenshot is trying to communicate the broadest possible value in one frame. That's a fine constraint for the default page. It's a bad constraint when you already know who's clicking, because you paid to send them, or because the link came from a post that already framed the app a certain way.
What you actually get
Each app can have up to 35 custom product pages alongside the default one. On each of those pages you can swap the screenshots, the app previews, and the promotional text. What you cannot swap is the app name, subtitle, description, keywords, icon, category, or ratings and reviews. Those come from the default listing, always. So if someone clicks through your custom page and scrolls down, they'll see the same star rating and the same written description as everyone else. The custom page is the top of the listing, not a separate app.
Each custom product page gets its own URL. That URL is what you hand to a Search Ads campaign, drop into an email, or use as the destination of a social post. Apple attributes traffic that arrives through that URL to that page, and you can see impressions, downloads, and conversion rate for each variant in App Analytics. That last part is the reason to bother: without the separate URL, you have no honest way to know whether the audience-specific screenshots you spent an afternoon designing actually did anything.
Where they fit in a release
Custom product pages are submitted for review, and in our experience they're reviewed relatively quickly compared to a full binary submission, though we'd never treat that as a guarantee for a specific release. Practically, this means you can iterate on presentation without rebuilding the app, which is the whole point. If a campaign is underperforming and you suspect the creative is the problem, you can queue a new variant, get it approved, and swap the campaign's destination URL without touching your build pipeline.
A few things we've found worth knowing before you commit to a set of them. The default page is still doing most of the work for organic search traffic, so tuning custom pages is not a substitute for tuning your default screenshots and subtitle. Rejections on custom pages tend to hit the same rails as any other metadata review, so promotional text that overpromises, or screenshots that show features the current build doesn't have, will get pushed back the same way. And because reviews and description are shared, you cannot use a custom page to present the app as a fundamentally different product. If the audience needs a genuinely different app, that's a different app.
How we decide whether to build one
Our rough test is whether we can point at a specific, repeatable traffic source, and describe in one sentence how the ideal screenshots for that source differ from the default. If we can't, we skip it. Building a custom page for a hypothetical audience you're not actually sending traffic to just gives you another asset to keep in sync when the app changes. Thirty-five slots sounds generous, but each one is a small ongoing maintenance cost the next time you redesign a screen and need to reshoot marketing frames.
When the answer is yes, we usually start with one variant per real campaign, keep the promotional text tight and specific to what that audience was promised in the ad or the post, and give it a few weeks of traffic before deciding whether it earned its keep. Conversion rate against the default page is the honest comparison. If a variant isn't beating the default for its own audience, the audience-specific framing wasn't as sharp as we thought, and it's better to retire the page than to leave it running out of sunk-cost politeness.
That's really the whole feature. Same app, same reviews, different top of the listing, one URL per version, measurable. Useful when you have somewhere specific to send people, quietly pointless when you don't.