Google Play Custom Store Listings in 2026: A Localization Tutorial

Custom store listings let one app show different names, icons, descriptions and graphic assets to different audiences: everyone in a set of countries, users who uninstalled your app, users who arrived from a specific Google Ads campaign, users who found you by searching a specific phrase. Your existing listing becomes the default store listing and keeps serving every country and audience you do not explicitly target, so nothing breaks the day you add the first custom page.

This tutorial follows the order you actually work in: decide what to localize, build the localized assets, create the listing in Play Console, add the translations that custom listings never inherit automatically, wire the unique URL or the ad campaign, respect the country rules, then measure and roll back if the numbers disappoint. One distinction runs through all of it — localized store listings are a language problem, custom store listings are a segmentation problem, and most teams need both.

Google's own documentation makes the split explicit: a custom store listing is one of two ways to deliver a differentiated experience, and if you want the listing to follow the user's language preference, the answer is translations, not a custom listing.

The difference matters because the two mechanisms override each other in a specific way. A translation swaps the text and localized graphics of your default listing for users whose language preference matches — it keeps one offer, one set of screenshots, one positioning, and changes only the language. A custom store listing replaces the whole listing for a targeted segment, and it does not come with automated translations: whatever you write is what that segment sees, in the default language you picked for that listing, unless you add translations to it as well.

Google's classic example is a video streaming app that wants to talk to English speakers in the United States and English speakers in Singapore. The default listing is en-US, with screenshots featuring US celebrities and a short description that leads with offline viewing. The Singapore listing targets that country, keeps en-US as its default language, swaps in locally familiar faces and leads with 4K playback. A second example uses a cookbook app whose Latin America listing defaults to Spanish (es-419) with a Brazilian Portuguese translation attached, so the Mexican, Argentine and Brazilian audiences each read it in their own language.

Inside a custom store listing you can customize the app name, the icon, the short and full descriptions, and the graphic assets — screenshots, feature graphic, video. Everything that is legally or operationally shared stays shared across every version of your listing: contact details, privacy policy and app category are identical everywhere, so a custom listing is a marketing surface, not a separate app.

• 50 pages. You can create up to 50 custom store listing pages per app. That ceiling is generous for market-by-market localization and tight if someone starts creating a page per campaign without a naming plan.
• A published default first. If you do not yet have a default store listing, you have to create and publish it before a custom listing can exist.
• The internal name is permanent. The name you type when creating a custom listing is for your reference only — users never see it — and Play warns that it cannot be edited once created. Adopt a convention such as DE-de-store-v1 or latam-es-419-2026H2 before you create page number one, and write the targeting rule down outside Play Console.

There is a third structure worth knowing: store listing groups. Every app starts with a "Default store listing group" built from the default listing. A listing created inside a group inherits the group's icon, screenshots, descriptions and assets, and you then override only what differs. Editing a group asset updates that asset in every listing in the group — powerful for a seasonal set of screenshots across ten countries, dangerous if you assumed each listing was independent.

When you create a custom listing, "Targeting" asks you to choose the audience segment. The full list in Play Console Help:

• Churned users — people who uninstalled your app.
• Lapsed users — people who have not opened your app in the last 28 days.
• Lapsed and churned users — the union of the two above.
• Non-buyers — installed, never purchased.
• One-time buyers — exactly one purchase.
• Repeat buyers — more than one purchase, subscription payments included.
• Lapsed buyers — bought before, but nothing in the last 180 days.
• Ads traffic — users arriving from a Google Ads campaign.
• Country/Region — users in specific locations.
• Pre-registration — users in countries where your app is still in pre-registration.
• Search keywords — users who find your app on Play using specific search terms.
• Custom audiences — groups you define yourself from behaviours or attributes.

The behavioural segments are the ones most teams ignore, and they are often the cheapest win. A lapsed-and-churned page that leads with "what's new since you left" and a non-buyer page that leads with a trial or a limited-time offer speak to a different decision than a cold acquisition page does. Just remember that a segment that cannot exist yet cannot be targeted: the churned, lapsed and lapsed-and-churned options do not apply to new apps.

The mistake that burns the most time is creating the listing first and then hunting for assets. Prepare everything in a folder per market:

1. Text. App name within 30 characters, short description within 80 characters, full description within 4,000 — and the short description is where localization usually dies, because 80 characters of translated text either says one clear thing or says nothing.
2. Screenshots. Real UI, with the caption text translated, not a screenshot of your English build with a local flag pasted on top.
3. Icon and feature graphic. Only if the market genuinely needs a different icon — a localized icon that looks like a different app is worse than a consistent one.
4. The default language decision. Pick the language the majority of the targeted countries actually read; Play shows the listing in that language to everyone in those countries unless a translation exists.

Marketing copy that is merely machine-translated into a market is easy to spot and reads like a template. If a market matters enough to deserve its own listing, it matters enough to have its short description written by someone who speaks the language.

The console path is stable: open Play Console → select your app → Grow users → Store presence → Custom store listings, then Create custom store listing.

1. Choose the starting point. Create a new listing (you supply all assets), Duplicate an existing listing (start from a copy of any listing, including the default), or Create a new listing within a group (inherit the group's assets).
2. Name it for yourself. Internal name only — and permanent, as covered above.
3. Set targeting. Select the audience segment. Some options will be greyed out and the console tells you why, which is covered in section 8.
4. Set the default language. In the App details section, choose Manage translations → Change default language. This is the language every targeted user sees when no translation applies.
5. Fill app details. Name, short description, full description.
6. Upload graphics. Screenshots and video for that market.
7. Click Create, then publish through your normal release flow.

This is the single most common failure in a localization project: the team builds a beautiful German custom listing, publishes it, and German-speaking users in Austria and Switzerland see it in whatever default language was chosen — because custom store listings do not inherit or generate automated translations.

Play's guidance is direct: choose a default language when you create the listing, and add translations for all the languages spoken in the countries you targeted. In practice:

• Your own translations are supported across the full Play language list — including zh-CN, zh-TW, zh-HK, en-GB, en-AU, en-SG, es-419, pt-BR and the rest — and you add them under Manage translations, either by editing each language or by importing the translated text.
• Paid human translation can be ordered inside Play Console: Grow users → Translations → Store listings and products → Create order, choose Paid human translation, set source and target languages, then pick what to translate. Google states ordering takes minutes, costs as little as USD 0.07 per word, and translations are completed within seven days. You work directly with the vendor, and not every source-target pair is available.
• Automatic translation with Gemini exists for app strings when you opt in — it is a different surface from store listing text, so do not assume it covers your listing copy.

Any change to listing text or assets, translations included, goes through Play review before it is visible to users. Budget for that: a market launch is a review cycle, not an instant publish.

Two targeting modes do not depend on who the user is, but on how they arrived.

The unique URL. Each custom listing can be reached at:

https://play.google.com/store/apps/details?id=YOUR_PACKAGE&listing=YOUR_PARAMETER

The parameter must be unique across all of your custom listings, and valid characters are lowercase alphanumerics plus period, hyphen, underscore and tilde. That URL is how you point a landing page, a QR code, a newsletter or a partner link at a listing that matches the message the user just read. It is also the cleanest way to test a positioning idea: two URLs, two listings, one app.

Ads traffic. Choose Ads Traffic as the audience segment, and once the listing has been reviewed and approved, go to Google Ads and select it as a landing page for a Universal App Campaign, pasting the AdGroupID when the console asks for it. Two honest caveats from Google's own documentation: ad-targeted custom listings currently appear on the AdMob network on Android and exclude Play search, so they will always show fewer visitors than the campaign total and will never match UAC numbers; and if an ad-targeted listing shows zero visits and installs, the usual causes are that the listing is not fully approved or that it was never selected as a landing page in Ads.

Country targeting is where a well-planned set of listings collapses into an error message. The rule is asymmetric on purpose:

• You can target several countries with one custom listing.
• You cannot target the same country from two custom listings. If a listing covers the United States and Canada, no other custom listing can include either of them.

The console also greys out segments, with the reason printed next to the option:

• Used in another custom store listing — that country is already claimed.
• App not yet released to production or testing there — you cannot target a country where you do not distribute the app, and if the app is only on internal, open or closed testing, it is discoverable only by users on those tracks.
• Pre-registration — applies only to countries where the app is genuinely in pre-registration; countries where it is already live in production or testing will not see that listing.
• Churned, lapsed, lapsed and churned — not available for new apps.
• Unavailable in Google Play — you do not distribute in that country at all.

Plan the map on paper before you create anything: countries grouped into markets, one listing per country, a default language per market, and translations listed per market. Retrofitting that structure after ten pages exist means deleting and rebuilding listings.

Publishing is not the finish line. Three things decide whether the work paid for itself.

1. Review. A custom listing is reviewed like any other listing change, and ads-targeted listings only start serving after approval. Check the listing's status in the console before you blame the campaign.
2. Measurement. Custom listing performance appears as a breakdown in the store listing performance report — but Google notes the breakdown only shows a listing once it has received a sufficient number of visitors. A brand-new page with forty visits is noise; give each listing enough traffic to mean something before you judge it.
3. Rollback. There is no "delete the experiment" button in the sense people expect. Your fastest safe rollback is to change the targeting or swap the assets on the existing page, because the internal name and the URL parameter cannot be edited. If a market underperforms, retarget or rewrite rather than leaving a stale page live.

Keep one written record: which listing targets which countries, in which default language, with which translations, created on which date, for which hypothesis. In six months that record is the difference between a managed portfolio of listings and fifty pages nobody dares to touch.

1. Creating the page before deciding the default language — every targeted user then reads the wrong language until you fix it.
2. Assuming translations come free with a custom listing. They do not; they are a separate step on that listing.
3. Targeting a market with a listing whose short description is a machine translation of your English copy.
4. Reusing the same screenshots with a flag badge, which reads as a template to exactly the users you were trying to impress.
5. Overlapping countries across two listings and losing an afternoon to a greyed-out option.
6. Giving an internal listing a name like "test2" that cannot be changed later.
7. Building an ads-targeted listing and judging it by UAC totals it can never match.
8. Editing a shared asset inside a listing group and unintentionally changing it for every listing in the group.
9. Localizing the listing while leaving the in-app first-run experience, pricing and support language in English.
10. Never looking at the store listing performance breakdown, so nobody learns whether any of it worked.

Custom store listings are a marketing feature, but they sit on top of an account that has to be in good standing: a published default listing, a verified developer identity, a payments profile that matches the legal entity, and a compliance posture that survives review. KappS works on that layer — preparing and submitting compliant material, keeping accounts and releases reviewable, and auditing metadata for the policy problems that turn a localization project into a rejection thread.

• Listing audits. Names, short descriptions and screenshots checked against Play's metadata and impersonation rules before a market goes live, not after.
• Account readiness. Verification, payment profile and tax records aligned with the entity behind the account, so a store listing review is not blocked by an unrelated account issue.
• Multi-market operations. A repeatable per-market checklist: assets, default language, translations, targeting map, review window, measurement.

What we do not do is manufacture a listing that misrepresents the app, reuse another developer's identity, or push a page past review by disguising what it is. Custom listings exist to make a genuine offer legible to a specific market — that is the version of this feature that keeps working.

Sources (Google official documentation): Play Console Help — Create custom store listings to target specific user segments; Translate and localize your app; Store listing groups; Store listing performance report (support.google.com/googleplay/android-developer).