Google Play closed testing: it is 12 testers, not 20, and they must stay opted in for 14 days
The requirement is 12 testers, opted in continuously for 14 days. Not 20. If you read otherwise, you read a page that has not been updated, and there are a lot of them. Google's live documentation says a minimum of 12, and the production access application checks against 12.
This applies to personal Google Play developer accounts created after 13 November 2023. Organisation accounts are not subject to it, and if your account predates that date you can publish to production without any of this.
What the rule actually says
Google's requirement, verbatim:
"run a closed test for your app with a minimum of 12 testers who have been opted in for at least the last 14 days continuously"
And on the timing:
"At least 12 testers must be opted in to your closed test when you apply for production access, and they must have been opted in continuously for the preceding 14 days."
The word doing the work is continuously. Google's FAQ spells out what that excludes:
"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, the 14 days must be consecutive to count toward the minimum requirement of 12 continuous opted-in testers."
The clock is per tester, and it resets. Twelve people who each tested for a week are not twelve testers. Twelve opted in on day one and still opted in on day fourteen are.
Why everyone says 20
Because it was 20. The original November 2023 rule required 20 testers for 14 consecutive days, and Google later reduced the count to 12. Almost every blog post, forum answer and video explaining this was written against the old number and never revised, which is why the top of the results is still wrong.
The academic record shows the same lag. A peer-reviewed study of this requirement, "No Country for Indie Developers: A Study of Google Play's Closed Testing Requirements for New Personal Developer Accounts" by Grishma Shrestha, Shristi Shrestha and Anas Mahmoud of Louisiana State University, in ACM Transactions on Software Engineering and Methodology (doi 10.1145/3736578), describes the mandate as 20 testers. Read it anyway: it is the only serious evidence base on how the requirement lands. From an analysis of developer discussion on Reddit and a survey of 14 indie developers, the authors found the requirements are "commonly perceived as discriminatory, imposing logistical and bureaucratic barriers on small-scale creators".
That finding is not a complaint you can appeal with. But if you are a solo developer feeling like this rule was not designed with you in mind, that is a documented position rather than a personal failing.
How the block is worded
There is no rejection email for this, which is part of why it confuses people. What you get is a Play Console state: the production track is unavailable, and the Dashboard shows the requirement with a tester count and a day count. When you apply and are denied, the reason is thin:
"Examples include not having 12 testers opted in to your closed test or your testers not being engaged with your app during your closed test."
Review "usually takes seven days or less, but may occasionally take longer".
Why applications fail
- The count is below 12 on the day you apply. The check is at application time, so a tester who leaves on day 13 costs you the run.
- Testers were added late. Adding someone on day 10 of a 14 day window does not give you a tester with 14 days.
- You counted invitations, not opt-ins. An invitation is nothing until the person opens the link and accepts. Opt-in rates from a list of willing friends are routinely under half.
- Testers opted in on a Google account they do not use on their phone. The account that accepts must be the one signed in on the device, or the app never appears.
- You used a tester-swap group or a paid service and the accounts opted in, installed nothing, and never opened the app. That is the second failure mode: insufficient tester engagement.
- You switched closed track mid-run, or someone opted out to free device space and you did not notice, because Play Console does not tell you.
How to get through it
- Recruit 16 to 18 people, not 12. You will lose some. Overshoot deliberately so a departure does not restart your fortnight.
- Use an email list rather than a Google Group unless you already run one. Email lists in Play Console are simpler to audit. Either is allowed.
- Send the opt-in link with one instruction: which Google account to accept on, and that it must be the one on their phone. That single sentence prevents most of the failures above.
- Confirm each opt-in individually. Ask people to reply once they see the app in Play. Do not assume.
- Start the clock only when your full list is opted in, and write the date down. Day one is the day the twelfth qualifying tester accepted.
- Ship two or three updates during the fortnight. The production readiness questions ask what you changed as a result. A real answer is easier than an invented one.
- Give testers something to do and somewhere to say it. A short list of things to try and one feedback channel: a form, an email address or a group chat.
- Ask them to open the app more than once. Install without use is what triggers the engagement denial.
- Apply on day 15, not day 14, with Play Console showing 12 or more.
The application itself
You apply from the Play Console Dashboard, via "Apply for production". Three parts: details of the closed test, information about the app, and production readiness. The questions are specific and not a formality. You will be asked whether testers used all of your app's features, whether their usage "was consistent with how you would expect a production user to use your app", to summarise the feedback and say how you collected it, what you changed as a result, and how you decided the app was ready.
Answer with real detail. Vague answers are the difference between approval and another fortnight.
If you are denied
There is no appeal in the usual sense. You continue testing and reapply. Read the denial for which problem you have: a count problem is arithmetic, an engagement problem is harder because Google publishes no threshold for it.
Do not buy testers. Paid services solve the count and cause the engagement failure, and they are why so much material about this requirement is written by people selling something.
AppSubmit tracks the opt-in date of each tester on your closed track and tells you the earliest date you can apply, which is the arithmetic Play Console leaves you to do yourself. Recruiting the humans is still your problem.