If you’re running Apple Ads without testing your custom product pages first, you’re guessing with a paid budget. That’s the easy part to say. The harder part, the part most teams skip, is that custom product page testing isn’t one test you run once and call it done. It’s a program that runs across placements, across the funnel and across the user journey outside the App Store entirely. Treat it as a single A/B test and you’ll leave most of the value on the table.
Here are the five pillars I use to structure a custom product page program with clients.
Key takeaways
- A custom product page testing program runs across placements, funnel stages, and traffic sources, while a single A/B test only shows which page performs
- Organic App Store search can show custom product pages through keyword assignment (since July 2025), so organic results can validate creative before paid budget moves
- As of October 2026, Apple allows up to 70 custom product pages per app, which leaves room for a continuous program instead of one experiment
- Today tab ads are built entirely from a custom product page, and Search tab ads can use one too, so each placement needs its own test
- Tap-to-install conversion rate and tap-through rate show whether a page converted, not whether the right user did, so post-install events from a mobile measurement partner (MMP) should be broken out by placement
- Custom product pages can also act as landing pages for social and display traffic, keeping the message consistent from the ad to the App Store page
Pillar one: let organic prove it before paid pays for it
Smarter Apple Ads lean on insights gleaned from ASO, and in no place is this clearer than your custom product pages.
The App Store currently allows up to 70 custom product pages per app, double the previous limit. Ad variations for your Apple Ads campaigns are created from these custom product pages in App Store Connect, so that’s real room to build a program instead of running one experiment.
And since July 2025, custom product pages surface organically in App Store search, so before a single penny of paid budget moves, assign keywords to specific CPPs and watch what organic traffic does with them. If a page isn’t converting for free, then what does that say about your creative? Let organic set the agenda for what paid does next.
Check out our guide to custom product pages for step-by-step instructions on getting started.
Pillar two: the test menu I put in front of clients
Once organic has shown you which creative is worth backing, paid is where you validate it in a controlled way, on traffic you define by budget, audience, and keywords. You get a clear read on what works before that creative goes anywhere near your default product page.
- Competitor intelligence on the ad. Understand what messaging is appearing alongside yours in relevant search results, then test your CTA and creative against that context. This isn’t about winning a fight with the app next to you, it’s about knowing whether your message actually stands out when it’s shown alongside similar apps.
- Search term linked to creative. The keyword that triggered the ad and the screenshots/copy the user lands on need to tell the same story. Test relevance, not just aesthetics.
- Offer-led vs. benefit-led messaging. If your app runs promotional offers, test a custom product page that leads with the offer against one that leads with the core product benefit. The lift is often not where teams assume it is. See our best practices for custom product pages.
- Incremental installs impact. The question isn’t “did this custom product page get installs,”; it’s “Did it get installs I wouldn’t have gotten anyway?” Structure the test to understand incrementality, not just raw volume.
- Brand search relevance. On brand campaigns, the role of the custom product page is message consistency rather than discovery. I measure this through Share of Voice alongside efficiency metrics across the campaign.
Pillar three: test across every placement, then follow it past the install
Custom product pages aren’t limited to search results ads. Today tab ads have no default-listing option, they’re built entirely from a custom product page, and Search tab ads can send users to one as well. Most teams still test only their custom product pages in search results ads, but each placement puts you in front of a different user with different intent in a different context, which is exactly why it’s worth testing across all of them.
And then I push further: for alternative placements especially, don’t stop measuring at conversion rate (CVR) and tap-through rate (TTR). Those are top-of-funnel numbers and they’ll tell you a page converted, not whether it converted the right user.
Instead, follow the install into the app. This is exactly where mobile measurement partner (MMP) integration and post-install event optimization earn their place in the program: sending post-install events back from your MMP means you can see whether, for example a Today tab install actually retains, activates, or pays, broken out by placement, not just judged on a single top-line number.
A user discovered through browsing behaves differently from one who searched with intent, and if your custom product page program only optimizes for the tap, you’re optimizing for the wrong outcome on most of your placements.
I hold search results ads to the same standard once a solid testing method is in place: a strong CVR off a search click that churns in week one isn’t a win; it’s a slower-burning problem.
Pillar four: your custom product pages should be landing pages for more than Apple Ads
Use custom product pages as landing pages dedicated to your paid and organic user acquisition outside of Apple Ads: social, display, whatever’s driving the click.
When a user clicks on a paid ad or organic post on another platform and lands on a generic product page, you’ve broken the story they were just told. Route that traffic to the custom product page that matches the creative they clicked and the message stays consistent from the platform where you found them straight through to the App Store page and into the app itself. That continuity is the difference between a user journey and a series of disconnected touchpoints.
Pillar five: test it properly, or the results lie to you
Apple’s native product page testing, Product Page Optimization, in App Store Connect gives you a controlled way to test product page variants. On top of that foundation, AppTweak’s Campaign Manager for Apple Ads has introduced CPP A/B Testing. It adds controlled A/B testing to identify which custom product page converts your Apple Ads traffic better, with statistically validated results. Both pages run at the same time on mirrored ad groups, so seasonality and traffic swings affect them equally, and a winner is named only when the difference is real.
The bottom line
A single custom product page test tells you which page performs. A custom product page testing program tells you which page performs, for which user, on which placement, and whether that user does anything valuable once they’re inside your app. Build the program, not the one-off test. That’s how you learn what actually drives value.
FAQs
What is a custom product page testing program?
A custom product page testing program is a continuous, structured series of tests on your custom product pages, run across placements, funnel stages, and traffic sources. A single A/B test tells you which page performs, while a program tells you which page performs for which user, on which placement, and whether that user does anything valuable inside the app. In practice, a program combines organic testing, paid testing in Apple Ads, post-install measurement, and traffic from outside the App Store. Each test feeds the next one, so results compound instead of ending with a single winner. Programs are possible at scale because Apple now allows up to 70 custom product pages per app.
Which placements can use custom product pages, and should I test each one?
Custom product pages can be used in search results ads, Search tab ads, and Today tab ads in Apple Ads. Test each placement separately, because each one reaches a different user with different intent in a different context. Today tab ads are the clearest case: they have no default-listing option and are built entirely from a custom product page. Search tab ads can send users to a custom product page as well. Many teams still test custom product pages only in search results ads, which means the other placements run on untested creative. A page that wins on a high-intent search may not win on a browsing placement, so read results per placement and avoid blending them into one top-line number.
How does AppTweak help test custom product pages in Apple Ads?
AppTweak’s Campaign Manager for Apple Ads includes CPP A/B Testing, which compares two custom product pages by duplicating your ad group into two mirrored ad groups that run in parallel, while the original ad group is paused and kept as a clean rollback point. Tap-to-install conversion rate decides which page wins. Campaign Manager shows progress through weekly checkpoints, and once a winner is clear, applying it is a confirmed action you take, not something that happens automatically. CPP A/B Testing is available on the Enterprise plan. It covers the paid testing step of a program. Organic testing, placement-level reads, and post-install measurement through your MMP still need to be planned alongside it, since MMP data isn’t yet part of the results.
More articles in Apple Ads
Micah Motta
Georgia Shepherd
Sukanya Sur
