Google Play's 12 Testers for 14 Days Rule, Explained
If you opened a personal Play Console account recently, you have probably found Production greyed out. Google wants a closed test before a new personal account can publish: at least 12 testers, opted in for 14 days in a row, then an application that asks what you learned. This guide covers who the rule applies to, what counts, what the application asks, and how to find testers worth having. Google's details below come from its own Play Console Help pages as of 4 September 2026.
The short version
- The rule applies to personal developer accounts created after 13 November 2023.
- You need a closed test with at least 12 testers who have been opted in continuously for the 14 days before you apply.
- A tester counts once they are on the track's tester list and have opted in. Teammates in your internal test are not in your closed test.
- The production access application has three sections: your closed test, your app, and your production readiness. Google says review usually takes seven days or less.
- Recruit more than 12, tell them to stay in for the full 14 days, and keep a record of their feedback, because you will have to summarise it.
Who the rule applies to
As of 4 September 2026, Google's page App testing requirements for new personal developer accounts says that personal accounts created after 13 November 2023 must test their apps before those apps can be distributed on Google Play. Until you meet the requirement, Production and Pre-registration in Play Console stay disabled.
The page is written for new personal accounts. Organisation accounts are not part of it, and nor are personal accounts created on or before 13 November 2023. If you are still choosing an account type, our guide to the Google Play developer account compares the two.
The rule itself
Google's wording, as of 4 September 2026, is that you must run a closed test with a minimum of 12 testers who have been opted in continuously for at least 14 days. When you apply, at least 12 testers must be opted in, and they must have been opted in for the preceding 14 days.
Two things follow from that wording:
- The count is taken when you apply. Twelve people who joined on day one and left on day ten do not meet it. Twelve who are still in on day fourteen do.
- The 14 days are continuous for each tester. Read literally, someone who opts out and back in starts their own 14 days again. That is why Google tells you to remind testers to stay opted in for the whole period.
Where closed testing sits among the tracks
Play Console has four tracks, and for a new personal account they unlock in order:
| Track | What it is for | What you need to use it |
|---|---|---|
| Internal testing | Quick builds for a small group of trusted testers | Nothing; it works before you finish app setup |
| Closed testing | A group of testers you control, to fix issues and check policy compliance before launch | Complete your app setup |
| Open testing | A test version anyone can join from Google Play | Production access |
| Production | Your app on Google Play for everyone | A closed test that meets the rule, then an approved application |
Source: Google's testing requirements page, as of 4 September 2026. Our guide to Google Play testing tracks covers each one in more depth.
What counts as opted in
As of 4 September 2026, Google's page Set up an open, closed, or internal test says that to be eligible for a test track a user must meet two conditions: be included in the track's tester configuration, and actively opt in to the test. Being on your list is not enough on its own.
Adding people to the track
For a closed test you add testers by email list or by Google Group. Google allows up to 200 email lists, each with up to 2,000 users, and up to 50 lists per track. With a Google Group, people have to join the group before they can opt in to the test.
Getting them to opt in
Your closed test is not searchable on Google Play, so you share a link. Google's page says the opt-in link appears once the release's status is Published, not while it is in Draft or Pending publication. Each tester opens the link, reads an explanation of what testers agree to, and opts in. Then they install the app from Google Play.
The internal testing trap
Google says a user who opts in to your internal test cannot receive an open or closed test until they opt out of the internal one and opt in to the other. If your partner, your co-founder and three friends are already on your internal track, they are not in your closed test. Move them across, or recruit others.
Applying for production access
Once 12 testers have been in for 14 days, open the Dashboard in Play Console and choose Apply for production. As of 4 September 2026, Google's testing requirements page describes three sections:
About your closed test
- How easy it was to recruit testers.
- How engaged they were: whether they used all of the app's features, and whether their use matched what you expect from production users, with details of any differences.
- A summary of the feedback you received, and how you collected it.
About your app or game
- Your target audience, as specifically as you can.
- How your app provides value to users.
- An estimated install range for the year after launch.
Google says these answers are not shown publicly and do not affect your app's visibility.
About your production readiness
- What you changed in the app based on the closed test.
- How you decided it was ready for production.
Google warns that leaving a section without clicking Next or Apply discards your answers. After you apply, Google emails the account owner when the review is complete. It says review usually takes seven days or less, but can take longer. If you had fewer than 12 opted-in testers or Google judges engagement too low, you may be asked to keep testing.
Google also says review is not a troubleshooting step. Check the policy basics before you apply: content and features, target age group, a stable app with no broken screens, and working test login details in Play Console if the app needs an account. Our guide to Google Play developer policy covers the policies themselves.
Finding testers who actually test
Google's advice is to start with personal and professional networks (friends, family, colleagues, classmates), then the communities where your future users already are, and social media. Recruit people who look like your audience: a hiking app tested by hikers gets better answers than one tested by developers.
Some practical additions:
- Ask the people who asked for Android. If you already ship on iOS, the users who asked when the Android version is coming are your best candidates. So are newsletter readers and anyone on a waiting list.
- Recruit 15 to 20. Someone always drops out, changes phone or forgets. A margin over 12 saves you from restarting the clock.
- Be wary of opt-in swaps. Groups where developers join each other's tests can get you to 12, but those testers rarely use your app, which leaves little to say when the application asks about engagement.
- Say what to test. Google recommends clear instructions and a stated feedback channel. A specific task, such as "download an offline map on a slow connection", gets better reports than "let us know what you think".
- Mark the dates. Write down when your twelfth tester opted in, and count 14 full days from then before you apply.
Collecting feedback during the 14 days
Google's set-up page notes that testers cannot leave public reviews on a test version, so give them another channel. You can add a feedback email address or URL, which appears on the tester opt-in page, and testers on a closed test can send private feedback through Google Play, which you read under Testing feedback in Play Console. Google suggests keeping a record of the feedback you receive and reviewing it regularly, because you summarise it in the application. Our guide to feedback from Google Play testers covers those channels.
If you also ship on iOS, the equivalent there is TestFlight. Our TestFlight beta testing guide covers it.
How FeedbackKit fits in
Bug reports and crashes belong in Play Console. Feature requests need somewhere else. Testers tend to say what is missing in their opening days with an app, and an email inbox loses those requests fast. An in-app feedback board gives your testers a place to post requests during the 14 days, and to see and vote on what the others asked for.
That helps with the application too: when Google asks how you collected feedback and what you changed, you have a list of requests with vote counts, not a memory of a few emails. The FeedbackKit Kotlin SDK has Jetpack Compose screens for the request list, the detail view and the submit form (Kotlin docs, and our Android setup guide). There are SDKs for Flutter and React Native as well.
FeedbackKit's six statuses are Pending, Approved, In Progress, TestFlight, Completed and Rejected. The beta status is called TestFlight, after Apple's service, and Android users see that same label. Many teams use it to mean "in testing", whichever store's beta it is, so when a tester's request lands in a new closed test build, moving it to TestFlight tells everyone who voted that it is ready to try. Here is how voting looks in FeedbackKit, with sample data from a fictional hiking app:
Testers vote inside the app
Twelve testers for fourteen days is a hurdle, but it is also a beta you would want to run anyway. Recruit a few more than you need, give them a clear place to post requests, and start free with FeedbackKit before the clock starts.