Measuring custom pages
Expert: with sources and numbers. Plain: the same, without them, for beginners.
What each platform reports per page, the thresholds that hide small pages entirely, and why a CPP comparison is not a test.
Both platforms report per-page performance. Both suppress it below a volume threshold, which is exactly where most custom pages sit.
iOS
A In App Analytics you can view App Store metrics per custom product page, impressions, downloads and conversion rate. The metrics become available after a page receives at least five first-time downloads. The reference name you set identifies the page in Analytics reports. (Configure multiple product page versions, verified 2026-09-18)
The five-download threshold is the practical constraint. With up to 70 pages available, it is easy to create pages that never cross it. So they generate traffic, cost maintenance, and report nothing. A page below the threshold is not a failed page; it is an unmeasured one, and those are indistinguishable from the outside.
Reference names are your reporting schema. They are how pages appear in Analytics. Naming them for the audience and message rather than sequentially is the difference between a readable report and an archaeology exercise.
Google Play
A Custom store listing performance requires sufficient visitor volume to appear in performance reports, and Google notes that ad-targeted listings typically generate fewer visitors than broader campaigns because they are limited to specific ad networks. (Create custom store listings, verified 2026-09-18)
A Play’s listing reporting splits traffic into Google Play search, Google Play explore, ads and referrals, and reports search terms that led to the listing. (Understand and grow your app’s user base, verified 2026-09-18)
A Since July 2026 the primary store listing metric is clicks, not acquisitions. Unique user Install Clicks. Same source. Any custom listing comparison spanning mid-2026 is comparing two different events. See CONFLICT-013.
Apple’s own figure, and what it is worth
A Apple states developers see a 2.5 percentage point increase on average when referring people to a custom product page, describing it as a 156% increase compared to the 1.6% average conversion rate on default product pages. (Custom Product Pages, verified 2026-09-19)
Tier A because Apple states it. Not because you should expect to hit it. Apple publishes no method, sample or period; the baseline varies enormously by category and market; and traffic referred to a custom page is self-selected, since someone building a CPP is already targeting a specific audience.
Use it as evidence that the mechanism works. Do not use it as a target, and do not put it in a forecast.
A custom page comparison is not a test
This is the most common reasoning error in this section.
Two custom pages receiving traffic from two different sources differ in audience as well as content. If page A is fed by a search campaign and page B by a display campaign, a difference in conversion tells you about the traffic at least as much as about the page.
A Custom product pages cannot be tested with product page optimization (Overview of product page optimization, verified 2026-09-18), so there is no native randomisation available.
To compare pages meaningfully, hold the traffic source constant (same campaign, same audience, same period, split between pages) and even then you are measuring paid traffic, not organic (50-06).
What to report
For each page: reference name, audience or campaign it serves, impressions, downloads, conversion rate, and the traffic source. Without the last one the conversion rate is uninterpretable.
And state whether the page cleared the reporting threshold. “No data” and “poor performance” are different findings and get confused constantly.
What goes wrong
Pages below the reporting threshold. Five first-time downloads on iOS; unspecified volume on Play. They report nothing and look like failures.
Comparing pages fed by different sources. Measures the traffic, not the page.
Sequential reference names. Unreadable reports later.
Comparing across the July 2026 Play metric change. Different events.
Counting custom page downloads as incremental. Users who would have converted on the default page are in that number (90-12).
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.
Both centres report performance per alternative version. Both also quietly hide that reporting below a certain amount of traffic, which is exactly where most alternative versions actually sit.
On the locked side
You can see, per alternative version: how often it was seen, how many people walked in, and the resulting rate. But only once a version has crossed a small minimum number of first-time walk-ins. The reference name you gave it is what identifies it in your own reports.
That small minimum is the real practical constraint. With a genuinely large allowance of possible versions, it's easy to create ones that never cross it. So they quietly generate traffic, cost upkeep, and report absolutely nothing. A version below that line isn't a failed version; it's simply an unmeasured one, and from the outside those two look exactly the same.
Your reference names are your entire reporting system. They're how versions show up in your own reports. Naming them for the audience and the message, rather than just numbering them in sequence, is the whole difference between a report you can actually read and one that turns into an archaeology project.
On the other centre
An alternative listing's performance only shows up in reports once it's crossed some minimum amount of visitor traffic, and the centre itself notes that a listing aimed specifically at paid traffic typically pulls in fewer visitors than a broader campaign would, simply because it's limited to one specific outside ad network.
This centre's own listing reports split traffic by source (its own search, its own browsing, ads, and referrals) and separately report the actual words that led someone to a given listing.
The main measurement itself changed recently, shifting from counting genuine new visitors to counting a specific kind of click instead. Comparing any listing result from before that change to one measured after it is comparing two genuinely different events.
One centre's own headline figure, and what it's actually worth
The locked side states that shopkeepers see a real average improvement when sending people to an alternative version, describing it as a striking-sounding percentage increase over the ordinary conversion rate on a default page.
Worth taking seriously because the centre itself states it. Not because you should expect to personally hit that exact number. The centre publishes no method, no sample, and no time period behind that figure; the underlying baseline varies enormously by category and by market; and traffic sent to an alternative version is inherently self-selected, since anyone building one is already targeting a specific audience on purpose.
Use it as evidence that the underlying mechanism genuinely works. Don't use it as a personal target, and don't put it into a forecast.
Comparing two alternative versions is usually not a real test
This is the single most common reasoning mistake in this whole area.
Two alternative versions receiving traffic from two different sources differ in who's actually looking, not just what they see. If one version is fed by a search campaign and another by a display campaign, a difference in how well they convert tells you at least as much about the traffic as it does about the version itself.
These alternative versions can't be run through the centre's own proper randomised testing tool at all, so there's no built-in way to fairly split traffic between them.
To compare two versions meaningfully, hold the traffic source completely constant (the same campaign, the same audience, the same time period, simply split between the two versions) and even then, you're only measuring paid traffic, not your normal, unpaid visitors.
What to actually report
For each version: its reference name, which audience or campaign it serves, how often it was seen, how many people walked in, the resulting rate, and where that traffic actually came from. Without that last piece, the rate itself can't really be interpreted at all.
And state plainly whether the version actually crossed the reporting threshold. "No data yet" and "performing poorly" are two completely different findings, and they get mixed up constantly.
What tends to go wrong
Versions sitting below the reporting threshold. A small minimum of walk-ins on the locked side; an unstated amount on the other. They report nothing at all and quietly look like failures.
Comparing versions fed by different sources. Measures the traffic, not the version itself.
Sequentially numbered reference names. An unreadable report months later.
Comparing across the point where the measurement itself changed. Genuinely different events being counted.
Counting every walk-in through an alternative version as a brand-new visitor. Some of those people would have converted on the default page anyway, whether the alternative version existed or not.