Prepare Your Google Play Store Listing Before Closed Testing

Preparing your Google Play store listing before closed testing means finishing the Main store listing fields and the App content declarations before you roll a release onto your closed test track, rather than after the 14-day clock has started. In practice that is the app title, short and full description, app icon, feature graphic and screenshots, plus the privacy policy, Data safety form, content rating questionnaire, ads declaration, target audience and sign-in details that sit on the App content page.

Google treats this as an ordering rule, not a suggestion. Its release guide opens with: "Before you begin, ensure you have set up your app's store listing, prepared your app for review, and configured app pricing." Play Console enforces it mechanically as well: while setup tasks are outstanding on your Dashboard, the Create new release button is disabled, so the closed test cannot be rolled out at all. This guide walks the fields in the order Play Console presents them, gives Google's stated limit for each asset, and separates hard requirements from the guidance that only affects your eligibility for promotion.

Why your store listing has to be ready before the test starts

Three separate statements in Google's documentation connect your store listing to the closed test you are about to run, and they are worth reading in order.

Setup gates the release. In Prepare and roll out a release, Google's first instruction is the quote above, and the same article explains what happens when you skip it: "If Create new release is disabled, complete any outstanding setup tasks listed on your Dashboard page." A greyed-out release button is therefore usually not a permissions problem or an account problem. It is a listing or App content task that has not been ticked off.

Closed testing follows setup, and only closed testing. In App testing requirements for new personal developer accounts, Google writes plainly: "You can start a closed test after completing your app setup." The same article states the rule you are working towards, that at least 12 testers must be opted in to your closed test for the preceding 14 continuous days when you apply for production access (see our 12 testers requirement breakdown). The contrast Google draws in its testing article is the useful part: "You can start an internal test before completing app setup." Internal testing is the one track that tolerates an unfinished setup. Closed testing is not.

Testers meet your listing, not your repository. Google states that "Users can join tests from your store listing", and because the app is not public yet, it adds: "If you run an internal or closed test prior to open testing or production rollout, testers cannot find your app by searching Google Play. You must share the app's Play Store URL with testers so they can download it." Your listing is the only surface a tester sees, so an empty or half-filled one is what 12 invited people are being asked to judge.

The clock is why this stops being cosmetic. Google's requirement is written in terms of testers who are opted in continuously for 14 days, not testers who were sent an email address. A tester who cannot get as far as installing has not started their 14 days, and the count does not move for them.

Based on our internal records from the 1,500+ closed-testing campaigns we have handled, the delays we see at the start of a test are configuration problems far more often than policy problems: a country left off the track, a release still processing, or a tester list that was saved but never selected on the track. Those are observations from the campaigns we run ourselves. We do not see other developers' consoles, and Google publishes no figures on how often each cause occurs, so treat this as our experience rather than a platform statistic.

The Main store listing fields and Google's exact limits

Your editable listing lives on the Main store listing page in Play Console, and the preview assets live beside it. Google groups the assets into requirements, which are mandatory, and highly recommended guidance, which affects whether Play promotes your app. Google is explicit about the difference: "Requirements listed on this page are mandatory; failure to meet requirements may result in removal or suspension from Google Play", while the recommended items "will not impact your store listing page, but may result in changes to how your preview assets appear on Google Play or limit promotional opportunities."

The trap in that table is the word "alpha". The app icon is the only standard asset Google asks to be exported with transparency: "32-bit PNG (with alpha)". The feature graphic and the screenshots are the opposite, "JPEG or 24-bit PNG (no alpha)". Guides published elsewhere routinely get this backwards and tell readers the icon must have no transparency, which is how people end up with a flat white box behind their logo or a feature graphic that Play Console silently refuses. Export twice, from two settings, not once with the same preset.

The two graphics also fail for different reasons. The icon has a file ceiling of 1024KB and must meet Google's icon design specifications, and it must not carry badges or text suggesting ranking, price or Play categories. The feature graphic has no size range at all: Google states 1024px by 500px as the dimensions, so 1024px by 500px is what you export, with no scaled variant accepted. A preview video is genuinely optional, and when you add one, the feature graphic becomes its cover with a play button overlaid, which is one reason Google asks you to keep key elements away from the cutoff zones at the edges.

Screenshot rules that Play Console enforces

Screenshots are where the numeric rules live, and they are more specific than most checklists suggest. Two screenshots is enough to publish; it is not enough to be considered for the recommendation surfaces Play reserves for apps with stronger asset sets.

The proportion rule is the one that catches people. A set of 1080x1920 portrait screenshots passes every number above, while a single very wide banner screenshot next to a tall one can break the "twice as long as" limit even though each image sits inside the 320px to 3840px window. When Play Console rejects an image, check the ratio before you check the file size.

Content rules matter as much as dimensions. Google wants screenshots that "demonstrate the actual app or in-game experience, focusing on the core features", captured from the app itself rather than photographs of someone holding a phone, which it lists among the elements to avoid. Taglines are allowed but "should not take up more than 20% of the image". The same banned categories from the metadata policy apply here: no ranking or award claims such as "Best" or "#1", no price or promotional copy, and no call to action such as "Download now". Google also asks you to edit the notification bar before submitting, so no carrier names or stray notifications appear, and to add alt text of 140 characters or less to each image, which it frames as accessibility guidance rather than a publishing condition.

Title and description rules under the metadata policy

The text fields are where an otherwise compliant listing gets flagged, because Google polices wording rather than just length. The Metadata policy applies to the title, icon and developer name first: no emojis, emoticons or repeated special characters in those three elements, no ALL CAPS unless it is part of your brand name, no misleading symbols such as a new-message dot when there are no messages or a download badge for an app that is not about downloading, and a title of 30 characters or fewer.

The same policy bans text that indicates store performance or ranking, price or promotional information, or an association with Google Play programmes. Google's store listing best practices article spells out the phrases it means, including "App of the year", "No. 1", "Best of Play 20XX", "Popular", award icons, and price signals such as "10% off" or "free of charge for a limited time only". None of these belong in your title, your short description, your feature graphic or your screenshots, and Google notes that the rules apply to every translation of your listing, so a compliant English listing with a promotional German one is still a problem.

Google also bans unattributed or anonymous user testimonials in the description, and asks that the listing stay suitable for a general audience no matter what content rating your app receives. On structure, the guidance is specific rather than vague: the short description should carry your core message in 80 characters or less, the full description allows 4,000, and you should not repeat the short description inside the full one. In the short description, Google lists "download now", "install now", "play now" and "try now" as call-to-actions to avoid, and it asks you to skip emojis, line breaks, repeated punctuation and capitalization used for emphasis. Those formatting rules are stated for the short description; the separate screenshot guidance bans call-to-actions outright on images.

The App content declarations that sit next to your listing

The App content page is not part of Main store listing, but it is part of the setup Google means when it says "prepared your app for review", and several of its items are prerequisites for each other. Google states that order in its content rating article: "Before filling in the 'Target audience and content' section, you must have declared whether or not your app contains ads and provided instructions for app access. You must also add a privacy policy." Working in that sequence avoids discovering the dependency halfway through the form.

Two of those rows deserve a note. First, the Data safety scope is explicit and easy to misread: "All developers that have an app published on Google Play must complete the Data safety form, including apps on closed, open, or production testing tracks", while apps exclusively on internal testing are exempt. A closed test therefore triggers the form even though nothing is public. Our Data safety form guide covers what to declare, including third-party SDKs and account deletion.

Second, content rating is a policy requirement rather than a listing nicety. Google's content ratings policy states "We don't allow apps without a content rating on Google Play", and its Help Center adds that "Apps without a content rating will be removed from the Play Store." Google's 15 July 2026 policy announcement then spelled out what it had been enforcing: "We're clarifying the content ratings policy to indicate that we don't allow unrated apps on Google Play." So this is current, not legacy, guidance. Fill the questionnaire in once, at setup, and re-submit it only when your content changes in a way that would change the answers.

Country availability and where testers find your listing

Two settings decide whether the people you invite can reach the listing at all, and neither is visible from the Main store listing page.

The first is country targeting. Google's article on distributing releases to specific countries says "When you roll out your app release to production, open testing, or a closed testing track, you can target your release in each track to users in specific countries", and that "By default, your testing releases match the country availability that you've set up for production." For a brand-new app that has never reached production, that default needs checking rather than assuming. The detail that surprises people is Google's clarification that "Country targeting is based on the user's Play country (that is, where their account is registered), not their current location." A tester whose Google account is registered in a country you have not selected will not be covered by adding the country they happen to be living in.

The second is the link itself. Your opt-in link has a publication condition attached: "The opt-in link displays only when an app status is 'Published'. Apps in 'Draft' or 'Pending publication' status do not display an opt-in link." Google also warns that "After publishing an open, closed, or internal test for the first time, the test link can take several hours to become available to testers", and that first submissions are reviewed, with Google's managed publishing article giving a review window of "a few hours or up to seven days (or longer in exceptional cases)". Plan the start of your 14 days around that, not the other way round.

When a tester tells you the listing will not load, work the list in our testers see app not available guide rather than re-sharing the link: it separates the opt-in link from the store listing link, and both are involved in a successful install.

Checklist to complete before you share the opt-in link

Work down this list once. Every item below is something Play Console either blocks on or a tester notices immediately.

1. App title written and under 30 characters, with no ranking, price or promotional wording.
2. Short description of 80 characters or fewer that states the app's purpose without repeating the title.
3. Full description drafted within 4,000 characters, with the first two lines doing the work, because they show before the expansion.
4. App icon exported at 512px by 512px as a 32-bit PNG with alpha, under 1024KB.
5. Feature graphic exported at exactly 1024px by 500px as a JPEG or 24-bit PNG without alpha.
6. At least two phone screenshots inside the 320px to 3840px window, with no side more than twice the shortest side, and ideally four or more at 1080px or higher so the app is eligible for recommendation surfaces.
7. Alt text added to each image, 140 characters or less.
8. Category and tags chosen to match what the app does, and a contact email that Play Store users can reach.
9. Privacy policy published at an active URL and linked from the App content page, covering exactly the data your app and its SDKs handle.
10. Data safety form completed, content rating questionnaire completed, ads declared, sign-in details provided if anything is behind a login, target audience declared last.
11. Countries and regions on the closed track reviewed against where your testers' Google accounts are registered.
12. A release created and rolled out on the closed track, sent for review, and confirmed as published, then a single end-to-end check with one tester before you send the link to the other 11. Our closed testing setup walkthrough covers each click in that step.

The last item is the one people skip, and it is the cheapest test available. Open the opt-in link yourself in a browser that is not signed in to Play Console to confirm the link resolves, then have one real tester account join and install on a physical device before the rest of the group goes through the same path.

Frequently Asked Questions

Do I need a complete store listing before I can start a closed test?

You need your app setup completed before a closed test can be started, and Google's release documentation tells you to set up your store listing, prepare your app for review and configure app pricing before you begin creating a release. Play Console keeps the Create new release button disabled while Dashboard setup tasks are outstanding, which is the practical gate you will hit first.

What are the Google Play store listing image sizes?

The app icon is 512px by 512px as a 32-bit PNG with alpha, maximum 1024KB. The feature graphic is exactly 1024px by 500px as a JPEG or 24-bit PNG with no alpha. Screenshots take a range instead of a fixed size: between 320px and 3840px on each side, with the longest side no more than twice the shortest, in JPEG or 24-bit PNG with no alpha.

Is the Data safety form required for a closed test?

Yes. Google states that all developers with an app published on Google Play must complete the Data safety form, including apps on closed, open or production testing tracks, and that only apps exclusively active on internal testing are exempt. Apps that collect no user data must still complete the form and provide a privacy policy link.

Why is the Create new release button greyed out in Play Console?

Google's answer is that outstanding setup tasks remain on your Dashboard. Work through the tasks shown there, which usually means the Main store listing fields and the App content declarations, and the button becomes available. It is rarely a permissions issue unless your account role genuinely lacks the release permission.

Can I change my store listing during the 14-day test?

Nothing in Google's testing documentation freezes your listing while a test runs, and store listing changes are ordinary Play Console edits. Keep in mind that submitted changes may need review before they appear, and that any change to content that would alter your content rating questionnaire answers means submitting a new questionnaire.

Do testers search for my app during closed testing?

No. Google states that if you run an internal or closed test before open testing or production rollout, testers cannot find your app by searching Google Play, and that you must share your Play Store URL with them. That is why the listing has to exist and be complete before you send anything out: the link is the only route your testers have.

Sources

Prepare and roll out a release - Google Play Console Help. The primary source for the instruction to set up your store listing, prepare your app for review and configure app pricing before you begin, for the note that Create new release is disabled while setup tasks are outstanding, and for the statement that users join tests from your store listing.

App testing requirements for new personal developer accounts - Google Play Console Help. Where Google says a closed test can be started after app setup is complete, and where the 12 testers opted in continuously for the preceding 14 days requirement and the production access application are stated.

Set up an open, closed, or internal test - Google Play Console Help. Source for the rule that internal tests can start before app setup, that closed and internal test apps cannot be found through search so the Play Store URL must be shared, that the opt-in link only displays when the app status is Published, and that a first publication can take several hours to reach testers.

Add preview assets to showcase your app - Google Play Console Help. The specification sheet for every graphic asset: icon dimensions, bit depth and 1024KB ceiling, the 80-character short description, the 1024px by 500px feature graphic with no alpha, screenshot quantities, the 320px to 3840px window and the twice-as-long-as proportion rule, the recommendation thresholds, the content rules for screenshots and taglines, alt text guidance, and the distinction between mandatory requirements and highly recommended guidance.

Metadata policy and Best practices for your store listing - Google Play Console Help. The 30-character title limit, the rules against emojis and ALL CAPS in title, icon and developer name, the ban on store performance, ranking and price claims, the example phrases Google lists such as "App of the year" and "10% off", the ban on unattributed testimonials, the 4,000-character full description, and the request not to repeat the short description inside it.

Prepare your app for review - Google Play Console Help. Source for what the App content page holds: the privacy policy conditions for apps handling sensitive data and apps targeting children, the ads declaration, sign-in details and the five-instruction limit, target audience, and the content rating questionnaire.

Content rating requirements for apps, games, and the ads served on both, Content ratings policy and the 15 July 2026 policy announcement - Google Play Console Help. The requirement to complete the questionnaire for new apps, the dependency order stating that ads, app access instructions and a privacy policy must exist before the target audience section, the statement that Google does not allow apps without a content rating, the removal of unrated apps from the Play Store, and the dated clarification that unrated apps are not allowed.

Provide information for Google Play's Data safety section - Google Play Console Help. The scope of the Data safety form, including that apps on closed, open and production tracks must complete it while internal-testing-only apps are exempt, and that developers collecting no data still complete the form and link a privacy policy.

Distribute app releases to specific countries - Google Play Console Help. Source for per-track country targeting on closed testing, the default that testing releases match production availability, the ability to unsync a track, and the clarification that targeting follows the user's registered Play country rather than their current location.

Control when app changes are reviewed and published - Google Play Console Help. Where Google gives the review window of a few hours up to seven days, or longer in exceptional cases, and lists which changes are held for review. Google revises these pages, so verify the current wording on the linked articles before relying on a specific detail under a deadline.