Custom Product Page Metrics: Why Apple's 156% Isn't Yours

App Store Connect reports product page views, total downloads, conversion rate, and downstream revenue for each custom product page, and none of it appears until that page has taken at least five first-time downloads [2]. Conversion rate is the metric most developers reach for first. It's also the one that misleads, because it isn't measured against the same traffic your default page sees.

The comparison table in the fifth section maps each metric to the question it can answer and the question it can't, which is the part Apple's documentation leaves you to work out yourself.

TL;DR:

• Apple's headline number is a cross-developer average, not a benchmark. Its exact wording: "Developers see a 2.5 percentage point increase on average when referring people to a custom product page. This is a 156% increase compared to the 1.6% average conversion rate on default product pages" [1].
• Conversion rate is downloads divided by unique device impressions [3], and impressions include App Store tab views that never became a visit. Your default page carries a lot of those. A link-referred custom product page carries almost none.
• Source type is a filter dimension on every custom product page metric [2]. It's the single control that turns an unfair comparison into a fair one.
• Only Product Page Optimization gives you a baseline. It shows treatments to a percentage of users and compares them against your original page "during the same timeframe" at 90% confidence [4]. Custom product page reporting has no equivalent.

Table of contents

• What does App Store Connect report for a custom product page?
• Why isn't a custom product page's conversion rate comparable to your default page?
• What does Apple's 156% increase actually measure?
• Do keyword-assigned custom product pages change the comparison?
• Should you test screenshots with custom product pages or Product Page Optimization?
• How do you read custom product page data without fooling yourself?
• What to fix once the numbers are honest

What does App Store Connect report for a custom product page?

Analytics in App Store Connect measures "each page across the full customer journey, including product page views, downloads, and conversion rate, along with downstream metrics like subscription performance and sales" [2]. The dashboard leads with Product Page Views, Total Downloads, and Conversion Rate, then adds a proceeds graph and average proceeds per paying user across retention milestones.

Two mechanics matter more than the metric list itself.

There's a reporting floor. Apple's documentation is explicit: "Data for a particular Custom Product Page will appear once it receives at least five first-time downloads" [2]. Below five, the page shows nothing. If you've published 12 pages to cover 12 ad variants and most of them are running small budgets, a good number of them are reporting blank, and blank is not the same as bad.

Everything is filterable by source. You "can filter all of these metrics by dimensions like territory, source type, and device" [2], and the metrics drop-down exposes "over 100 metrics." That source-type dimension is the whole game, and the rest of this post is mostly about why.

Why isn't a custom product page's conversion rate comparable to your default page?

Because the denominator changes shape depending on how people arrive. Apple defines Conversion Rate as "Total downloads and pre-orders divided by unique device impressions" [3]. It defines Impressions as "The number of times your app was viewed on the Today, Games, Apps, and Search tabs of the App Store for more than one second. Includes product page views" [3].

Read those two definitions together and the problem falls out. An impression is earned when someone sees your app in a tab for over a second, whether or not they ever tap through. Your default product page accumulates enormous numbers of those: every search result someone scrolled past, every Today-tab placement they ignored. All of it lands in the denominator.

A custom product page reached by a link from outside the App Store collects almost none of that. Someone taps your Instagram ad and arrives directly on the page. Because impressions include product page views, the arrival itself is the impression. The denominator is close to one impression per genuinely interested visitor.

So a custom product page "beating" your default page by a wide margin is partly a statement about visitor intent, not page design. Both numbers are correct. They just aren't answering the same question, which is the same denominator trap that makes published conversion benchmarks disagree by category and the same two-stage split behind diagnosing which half of your funnel leaks.

One honest limit: Apple publishes the definitions above but does not publish a denominator breakdown per source type, so you can't decompose the blend yourself. What you can do is compare like with like, using the filter.

What does Apple's 156% increase actually measure?

It measures the gap between referred traffic and blended traffic, averaged across developers. Apple's wording is precise and worth reading literally: a "2.5 percentage point increase on average when referring people to a custom product page," which is "a 156% increase compared to the 1.6% average conversion rate on default product pages" [1].

Three things follow from that sentence.

The base is 1.6%. The 156% is 2.5 points on top of 1.6, not a multiplier you can apply to your own rate. If your default page already converts at 6%, 156% of it is not a forecast of anything.

It's an average across developers, which means it bundles apps with disciplined ad-to-page matching alongside apps that published one page and pointed everything at it. Averages of that shape have wide spreads, and Apple doesn't publish the distribution.

The word "referring" is doing quiet work. The lift is described for referred traffic specifically. That's consistent with the denominator mechanic above rather than evidence against it.

None of this makes custom product pages a bad investment. Apple lets you publish "up to 70 additional versions of your product page" [1], and matching a page to the promise an ad made is sound practice for reasons that have nothing to do with the reported rate. It does mean the 156% is marketing copy about a category, not a target for your dashboard.

Do keyword-assigned custom product pages change the comparison?

Yes, and this is the carve-out that keeps the rest of this post honest. Custom product pages are not link-only surfaces. Apple states they "can also appear in relevant search results," and that you "can assign keywords to your custom product page to make them even more discoverable," which lets the custom page "appear in search results for those selected keywords, rather than your default product page" [1].

A keyword-assigned custom product page therefore does accumulate search-tab impressions, including from people who scrolled past. Its denominator starts to look like your default page's denominator. The confound described above applies to pages fed by outside links, not to every custom product page you publish.

Practically, that splits your pages into two populations that should never be averaged together:

• Link-fed pages (social ads, email, Apple Search Ads, StoreKit-rendered ads in other apps): high reported rates, denominator mostly visitors.
• Keyword-assigned pages competing in search: lower reported rates, denominator includes passers-by, directly comparable to your default page.

If a single dashboard view mixes both, the average is a number describing neither.

Should you test screenshots with custom product pages or Product Page Optimization?

Use Product Page Optimization when the question is whether the page is better, and custom product pages when the question is whether a campaign converted. The difference is a control group, and only one of the two features has one.

Product Page Optimization shows "different treatments of your product page" to "a percentage of users so their performance can be compared to the performance of your original product page during the same timeframe" [4]. Same timeframe, split traffic, one original acting as baseline. Apple applies "Bayesian techniques designed specifically for App Store product page data," labels a treatment "Performing Better or Performing Worse" once it "reaches 90% confidence," and reports Estimated Relative Lift as "the estimated relative increase in conversion rate for a variant as compared to the selected baseline" [4].

Custom product page reporting has none of that machinery. There's no randomized split, no baseline, no confidence label, because a custom product page isn't a variant of an experiment. It's a separate destination with its own audience.

The failure mode is using the first column to answer the second column's question. A custom product page with a 9% rate against a default page at 3% is not a screenshot test that returned a result, and shipping your default page's screenshots over to match it is a change made on no evidence. If the screenshots are the hypothesis, run it through a real product page test with a control, which means producing two genuine treatments worth testing rather than one page and a copy of it. Generating the variant set is the cheap part of that loop: describing the change and refining it against the original in the screenshot builder takes a fraction of rebuilding both sets by hand.

How do you read custom product page data without fooling yourself?

Filter by source type before reading anything, compare each page only against pages fed the same way, and treat any page under five first-time downloads as unreported rather than underperforming [2]. Then judge the design question with a controlled test and leave the campaign question to the campaign.

A workable order of operations:

1. Set the source-type filter first. Every custom product page metric supports it [2]. Reading an unfiltered rate is the error that produces every other error downstream.
2. Group pages by how they're fed. Link-fed and keyword-assigned pages belong in separate comparisons, per the section above.
3. Check the five-download floor before concluding a page failed. Blank is blank.
4. Compare each page to its siblings, not to your default page. Two link-fed pages running against each other is a fair fight, and it's the comparison that tells you which ad-to-page match is working.
5. Follow the downstream metrics. Apple exposes retention and average proceeds per paying user per page [2]. A page with a lower conversion rate that brings users who stay is usually the better page, and conversion rate alone hides that entirely.
6. Escalate design questions to Product Page Optimization, where a baseline exists [4].

Step 4 is where most of the value sits. Sibling-to-sibling comparison is the only read in the custom product page dashboard that isn't confounded by arrival method, because both pages were reached the same way. It's also the read that tells you something actionable: which of your per-channel screenshot patterns is actually paying off the promise its ad made.

What to fix once the numbers are honest

Once you've filtered by source and compared siblings, the number that moves is usually a frame, not a page. The pages that win their group tend to be the ones whose first frames restate the specific promise the ad made, which is a design decision you can act on rather than a rate you can only watch.

The complete custom product page guide covers the setup and channel strategy around that decision, and the conversion-focused screenshot workflow covers where those first frames sit in the wider funnel. Filter by source first, though. Every design conclusion you draw before that is a conclusion about your traffic mix wearing a screenshot's clothes.