A custom store listing shows different screenshots and descriptions to a chosen group of users. You can create up to 50 of them, targeted by country, search keyword, custom URL, Google Ads campaign or user status. They do not get automated translations, which is the trap that catches most people.
The short answer
Most developers have exactly one listing and never look again. That's a lot of wasted room. A user arriving from a running ad and a user searching your app name by name are not the same person, and they don't need the same five screenshots. I read Google's current documentation for this, because the targeting options have grown.
What it actually is
A custom store listing is a second version of that page, shown only to a segment you pick.
The app underneath doesn't change. Same build, same price, same package. Only the app name, the short description, the full description and the graphics differ. So this is a marketing lever, not a release lever, and it needs no new build.
The segments you can target
You can also target by a unique custom listing URL, or by a Google Ads campaign.
Google's own examples cover lapsed and churned users, and users who installed the app but never bought anything. Each of those is a different conversation, and each one justifies a different first screenshot.
The 50 page limit
The real limit is production. Every listing needs its own screenshot set, and every screenshot set needs maintaining when the app changes.
I'd start with two. One default and one for your largest non default market. Prove it moves installs before building the other forty eight, because a stale listing is worse than no listing at all.
Groups save you from yourself
A listing inside a group inherits the icon, the screenshots, the descriptions and the other assets from that group.
Then you override only what needs to differ. Updating a group asset pushes the change down. That is the difference between maintaining fifty listings and drowning in them, so set the groups up before you set up the listings.
The translation trap
Your default listing does. A custom one does not.
So if you target Singapore with an English listing, a Malay speaking user in Singapore sees it in English. They fall inside your targeting, and there is no fallback to the translated default. Unless you add the translation yourself, the default language is what they get.
Targeting by country
So you cannot layer two listings over the same market.
Google's own example is a streaming app with a United States default and a Singapore custom listing, each showing content people in that country recognize. That is the right shape. Same app, different proof. Our localization guide covers the language side of it.
Targeting by search keyword
Somebody searching "expense scanner" and somebody searching your brand name want different things.
The first needs proof the app does the job. The second already decided and needs reassurance it's the right app. Play Console also offers to draft descriptions for these listings using Gemini, built from your published default text and your chosen search terms. Treat those as a first draft, not a finished one.
Targeting by custom URL
This is the version I'd reach for first, because it needs no Play targeting rules at all.
Google's fitness app example splits the same app into swimming, running and cycling listings, then puts each link on the matching page of the marketing site. The visitor keeps reading about the same activity instead of landing on a generic page.
Targeting a Google Ads campaign
Then the creative in the ad and the screenshots on the listing tell one continuous story.
One caveat is worth knowing before you plan a campaign around it. Ads targeted listings do not yet support every Google Ads app campaign format. Google says to expect the custom assets when the user arrives from its AdMob network on Android, with more formats coming later.
Targeting lapsed and churned users
Lead with what changed since they left. Not with what the app has always done.
One restriction applies. The returned, lapsed and churned options don't apply to new apps, since there is no history to segment on yet. Your distribution and testing settings can also remove options from the list.
What each listing lets you change
The content rules stay the same across every listing you create.
So a custom listing is not a place to try language the metadata policy bans elsewhere. Same rules on ranking claims, price claims and testimonials, fifty times over.
The naming mistake you cannot undo
So do not call it "test" or "new one".
Name it after the audience, not the campaign of the month. "Latin America" survives. "October push" is embarrassing by December. I opened a console with eleven listings named after dead campaigns, and nobody remembered which one served which market.
How this compares to Apple
Our post on custom product pages covers that side.
The useful overlap is the thinking. Both platforms let you match the page to the reason somebody arrived. Both punish you for building variants you then never update.
Where to start
Then duplicate rather than starting blank.
Duplicating an existing listing gives you a working set of assets to edit, which is faster and stops you shipping a listing with a missing feature graphic. Build the new screenshots in the mockup editor so the sizes come out right the first time.
The check before you publish
No country is claimed by two listings. Names describe audiences, since you cannot rename them later.
Assets follow the same content rules as the default listing. Every listing has a full screenshot set, not a half finished one inherited by accident. Then track installs per listing, and delete the ones that don't earn their maintenance. Our asset checklist covers what a complete set contains.
Frequently asked questions
How many custom store listings can I create on Google Play?
Up to 50 pages. The practical limit is lower, because each one needs its own screenshots and its own upkeep. Two or three well maintained listings beat twenty that show last year's interface. Groups help here, because a listing inherits its group's assets and you override only the parts that need to differ.
Do custom store listings get translated automatically?
No, and this is the most common mistake. Your default store listing gets automated translations, but a custom one does not. Users you target who speak another language see your custom listing in its default language unless you add the translation yourself. Budget the translation work at the same time you plan the listing, not after somebody reports the wrong language.
Can two custom store listings target the same country?
No. Once a country or region is used by one custom store listing, it becomes unavailable to the others. Plan your country groups before you start creating listings, because the targeting cannot overlap.
Can I rename a custom store listing later?
No. The name is fixed when you create the listing or the group. Name it after the audience it serves rather than the campaign that prompted it, so it still makes sense a year from now.
Do I need a new app build to change a custom store listing?
No. Store listings are separate from your app binary, so the assets and text can change at any time without a release. Build the new [screenshots and frames](/frames) first, then swap them in and publish the listing. That is what makes custom listings cheap to test. A weak variant costs you an afternoon rather than a release cycle.
Build the mockup in your browser.
Drop a screenshot into a real device frame and export at the exact store size — free, no signup.