A playable makes a promise, and the store page is where the viewer goes to check it. If the ad showed a sorting puzzle and the first screenshot on the store is a city builder, the viewer who tapped with intent hesitates at the last step: the page in front of them does not look like the thing they just played. The install is lost after the creative has already done its job, and nobody attributes the loss to the creative.
Both app stores now let an advertiser fix this directly, by sending ad traffic to an alternative version of the store page built to match the ad.
The drop-off that belongs to nobody
Creative teams optimise to the tap, because the tap is what their dashboards report. The store page is owned by whoever does app store optimisation, and it is designed for organic visitors: people who searched, and who arrive with no particular expectation. Paid visitors from a playable arrive with a very specific expectation, set seconds earlier. Tap-to-install conversion happens on a page neither team designed for them, and the mismatch shows up only as a conversion rate lower than it should be, on a report neither team reads with the creative in mind.
Apple: custom product pages
On the App Store, custom product pages are additional versions of an app's product page, each with its own screenshots, app preview videos and promotional text. Since 29 October 2025 an app can publish up to 70 of them, double the previous 35. Each has a unique URL (the normal App Store link with a ppid parameter identifying the page) and each goes through App Review before it can be used.
Two changes during 2025 made them more than an ads feature. Apple allowed keywords to be assigned to individual custom product pages, so they can surface in organic search, and every custom product page can be used in Apple Ads variations. On iOS 18 and later a page can also carry a deep link, so a viewer who already has the app is taken straight to specific content inside it.
Google Play: custom store listings
Google Play's equivalent is the custom store listing: up to 50 per app, each with its own graphics and text, and each targeted in one of several ways (by country, by pre-registration status, by a unique URL, or, for App campaigns for installs on Google Ads, by linking the listing to specific ad groups so their clicks land on it). The unique URL is the normal Play Store link with a listing parameter added, of the form details?id=your.package&listing=your-listing-name.
Where a playable can use them
It depends on who controls the click. On networks that open the URL you give the creative (Unity, AppLovin, ironSource and the other MRAID-based networks) putting the custom page URL in the store link fields is all it takes: the playable's call to action opens that page instead of the default one.
On networks that decide the destination themselves (Google Ads, Meta and Mintegral) the creative cannot choose, because it passes no URL. There, whether a custom page is used is a setting in that platform's campaign, not something the playable file can do. For Android on Google Ads, the ad-group link described above is that setting.
One page per concept, not per variant
Seventy sounds like a lot until variants multiply. Map custom pages to creative concepts (the sorting-puzzle page, the merge page, the story page) rather than to each colour or copy variant within a concept. A page that matches the mechanic does almost all of the work; a page that matches the exact shade of the button does not.
What goes on the matching page
- The first screenshot shows the mechanic from the ad, in the same art style and ideally in the same state the viewer just saw.
- The app preview opens on the moment the ad was built around, because it autoplays and is the first moving thing on the page.
- The promotional text echoes the ad's call to action, so the page reads as its continuation.
- For a non-gaming app, the page leads with the product, offer or feature the playable demonstrated, not the brand's general pitch.
Measuring whether it helped
The number that moves is conversion on the store page itself: installs per product page view, reported per custom page in App Store Connect's analytics and per custom listing in the Play Console. The clean test is the same creative, running at the same time, split between the default page and the matching one. A custom page changes where the click lands; it does not change how installs are attributed, so the rest of your measurement carries on as before.
Keeping pages and creatives in step
The failure mode is drift. Creatives refresh every few weeks as they fatigue; store pages are updated when someone remembers. A custom page built for a concept retired a month ago is no better than the default page, and one showing an old version of the game is worse. Name each page after the concept it serves, record which live creatives point to it, and review the list whenever a concept is retired.
Setting it up with an exported playable
- Create the custom product page in App Store Connect and the custom store listing in the Play Console, and wait for both to go live.
- Copy each page's URL: the App Store link with its ppid parameter and the Play Store link with its listing parameter.
- In Playable Ads Maker's export modal, paste those URLs into the iOS and Android store fields in place of the default links.
- Export for the networks that honour a creative's URL, and configure the custom page in campaign settings on the networks that do not.
- Open the exported ad on a real iPhone and a real Android device and tap through, confirming the custom page loads rather than the default one.
For a second concept, duplicate the project, change the mechanic or the art, and point its store fields at that concept's page.
Create playable end cards in minutes—no code required.
Open Playable Ads Maker