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.

Verified 2026-09-19 · 38 days ago both targeting analytics

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.

A App Analytics reports impressions, downloads and conversion rate per custom product page, available only after a page receives at least five first-time downloads.
IOS-CPP-003 · verified 2026-09-18
A Apple states developers see a 2.5 percentage point increase on average when referring people to a custom product page, described as a 156% increase compared to the 1.6% average conversion rate on default product pages.
IOS-CPP-005 · verified 2026-09-19
A From July 2026 Google Play store listing performance reports focus on clicks rather than acquisitions. The primary metric is Unique user Install Clicks: the number of unique users who clicked the Install button from the store listing. Legacy acquisition data remains available in Statistics and exports.
PLAY-ACQ-002 · verified 2026-09-18
A A country can be targeted by only one custom store listing at a time. Custom store listings have no automatic translation. Ad-targeted listings currently show only on AdMob, not on Google Play search ads. Performance reporting requires sufficient visitor volume.
PLAY-CSL-003 · verified 2026-09-18

Think your app deserves better?

Send the App Store link.
The audit comes back within two working days, whether you hire us or not.

Free, and we mean it. No card, no call required.