Google Play 12 Testers for 14 Days: The Rule Explained

What is Google Play’s 12-tester rule?

If your Google Play developer account is a personal account created after November 13, 2023, you must run a closed test with at least 12 testers who stay opted in for at least 14 days in a row before you can apply for production access. Until Google approves that application, Production and Pre-registration stay disabled in Play Console. The rule does not ask for numbers alone: the application asks how your testers used the app and what you learned from them.

We checked the requirement on Google’s Play Console Help page “App testing requirements for new personal developer accounts” on October 1, 2026. Google can change it, so check Play Console and that page for the current numbers before you plan your launch date.

The rule in Google’s words

Play Console Help states that “developers with personal accounts created after November 13, 2023, must run a closed test for their app with a minimum of 12 testers who have been opted in continuously for at least 14 days.” The details that trip people up:

• At the moment you apply. Google says at least 12 testers must be opted in to your closed test continuously for the preceding 14 days when you apply for production access.
• Continuous means continuous. “Testers who opt in, test for fewer than 14 days, and then opt out do not count toward the requirement.” If a tester opts out and opts back in later, their 14 days must be consecutive to count.
• Closed test, not internal. The requirement is a closed testing track. Internal testing is useful for your own team, but it is not what this rule asks for.
• Who it applies to. Personal developer accounts created after the cut-off date. Organization accounts are not named in the requirement.

How to set up the closed test

1. Create a closed testing release in Play Console with a build that is ready for real people to use.
2. Add testers. Google’s help page on testing tracks describes two ways: email lists, or a Google Group, entered in the format [email protected]. A Google Group is easier when testers come from outside your contacts, because people join the group themselves and you do not need to collect their email addresses.
3. Share the opt-in link. Google says that after clicking it, testers see an explanation of tester responsibilities and a link to opt in. Testers need a Google Account or a Google Workspace account.
4. Give testers a feedback channel. Testers cannot leave public reviews on Google Play for test versions, so Google recommends a direct channel, such as email, a website, or a message forum.
5. Count the days. Note the date each tester opted in. Your 14 days start when your twelfth tester has opted in, and they restart for anyone who leaves.

What the production access application asks

When you meet the criteria, you apply for production access from the Dashboard in Play Console. According to Google’s help page, the form has three parts:

Google says review usually takes seven days or less but can take longer. If the app needs more testing, you may have to keep the closed test running. Google lists two reasons for that: fewer than 12 opted-in testers, or insufficient tester engagement during the testing period. So 12 names on a list are not enough. You need 12 people who opened the app, used it, and told you something.

How to recruit 12 genuine testers

Google’s own advice is that “the most common way to recruit testers is to use personal and professional networks.” Start there, and aim for 15 to 20 people, because some will forget, switch phones, or opt out before day 14.

Wherever testers come from, the job is the same: use the app as a real user would and tell you what happened. Our guide to finding playtesters covers more sources and how to write a feedback form people actually fill in, and How to get beta testers for your app covers TestFlight and beta testing beyond this rule.

Keep testers engaged for 14 days

Google advises giving testers clear instructions on how to test and report bugs, saying what kind of feedback you want, and encouraging them to use as many features as possible. In practice, a simple two-week plan does that:

• Day 1: a welcome message with the opt-in link, what the app does, and three things to try.
• Days 3 to 5: a short form with three to five questions: what was confusing, what broke, what they would change.
• Around day 7: ship an update that fixes what they reported, and tell them what changed.
• Days 8 to 13: a second round of tasks on features nobody touched yet.
• Day 14: a thank-you and a final question about whether they would keep using the app.

Save everything: the feedback, the bugs you fixed, the version notes. That record is exactly what the application asks you to summarize, and writing it from real notes is far easier than from memory.

What not to do

• Do not buy tester accounts or opt-ins. Testers who never open the app give you no engagement and no feedback, which is one of the two reasons Google gives for asking you to test longer.
• Avoid tester-swap groups that only trade installs. Groups where everyone opts in to everyone else’s app and never uses it produce the same empty result. Swapping genuine testing with other developers is different: you both use the apps and send real feedback.
• Do not ask testers for ratings or reviews. They cannot review test versions, and rewarding reviews of your public app later breaks Google Play policy. See Can you pay for app reviews?
• Do not invent answers in the application. Describe the test you actually ran.

Once you have production access, the next step is choosing where to launch. How to soft launch a mobile game covers releasing in a few countries first, and app retention benchmarks help you judge the first real cohorts.

Frequently asked questions