Custom Product Page and Store Listing Test Programme

A Product Page Optimisation test needs roughly 15,000 impressions per treatment before its result is worth acting on. That is the arithmetic for detecting a five per cent relative change against a thirty per cent baseline conversion rate at conventional confidence. Apps below that threshold still watch the chart in App Store Connect move. None of that movement is real. If your product page sits under it, we say so on the first call and there is nothing here to buy. What we build: Custom Product Pages on iOS and custom store listings on Google Play, run as one programme together with the campaign structure that feeds them. Apple permits 35 Custom Product Pages per app version and three treatments per Product Page Optimisation test. Google Play permits 50 custom store listings. Those are ceilings, not plans. The apps we work with usually keep four to six live pages and one running test, because a page whose result nobody can read is review overhead with no decision attached to it. How pages get assigned: By acquisition intent, never by demographic segment. A food delivery app bidding a competitor's brand name on Apple Search Ads exact match gets a page that settles the substitution question in the first screenshot and its caption. The same app's generic category term gets a different page, because that visitor has decided nothing yet. Local services apps get a page per supply density tier, since the promise in the first frame has to be one the market underneath it can keep. Fashion clients get pages split by catalogue entry point rather than by season. What we instrument before anything goes live: Custom Product Page IDs against named Apple Search Ads ad groups, listing IDs against the Google Ads App campaign, and the page identifier carried through to your MMP so a page can be judged on day-seven retention and first purchase instead of install rate. This matters more than the creative does. We have killed pages that lifted install rate by double digits and cost a fifth of week-one retention, and that decision only exists if the plumbing was done first. What we refuse: We do not research or write keyword sets inside this engagement; that is separate work and mixing the two makes both unreadable. We do not touch the default page's screenshots or metadata while a Product Page Optimisation test is live, because it voids the comparison, and we will hold your marketing team to that for the full window. We do not build a page per creative concept so a monthly deck has more slides. We do not localise into a storefront your support desk cannot answer in that language. Who this is not for: Pre-launch apps. Apps whose paid traffic cannot fill a test arm inside a month. Teams who want variants shipped and then left running unread. How it runs: Week one is instrumentation and a decision about what the first test is allowed to be about: one variable, named in advance, with the metric and the stopping rule written down before traffic starts. Weeks two to five run it. We read the result against the rule as written, not against whichever cut looks best afterwards. Losing tests are reported as losses with the reasoning left intact. Around half of them are losses, and a shop showing you only winners is showing you a selected sample. What you receive: The built pages and listings, the campaign-to-page mapping, a test log carrying every hypothesis and outcome, and a written recommendation on which pages stay live and which come down. Everything sits in your own App Store Connect and Play Console accounts. We hold no assets and no logins you cannot revoke.