If your personal Play Console account was created after 13 November 2023, you must run a closed test with at least 12 testers opted in continuously for 14 days before you can apply for production. A rejection (“Your app isn’t ready for Google Play production yet”) usually means Google saw too little real tester engagement, or your questionnaire answers didn’t show a genuine test. To fix it: keep the closed test running, recruit 15–20 real testers, give them tasks, ship 2–3 updates based on their feedback, record that feedback in writing, then reapply with specific answers. Review usually takes seven days or less.
Key takeaways
- Twelve is the minimum, not the target. Recruit 15–20 testers so drop-outs never take you below 12.
- Engagement matters as much as headcount. Google names insufficient tester engagement as a reason apps need more testing.
- Updates are your evidence. Two or three releases during the test show you acted on feedback, and give you concrete answers for the questionnaire.
- Answers must match the data. Vague or copy-pasted answers that don’t fit what Play Console shows are a common reason developers report for rejection.
- Make the app reviewable. Working test login, privacy policy, data safety form and a clean pre-launch report before you apply.
The rules in plain terms
| Rule | What Google requires | What it means in practice |
|---|---|---|
| Testers | At least 12 testers opted in to a closed test | Count only people who opted in and installed the app with the same Google account. |
| Duration | Opted in continuously for the 14 days before you apply | Testers who opt out before 14 days don’t count. Opt out and back in, and their 14 days start again. |
| Track | A closed test | Internal testing has no requirements but doesn’t count. Open testing only unlocks after approval. |
| Locked features | Production and Pre-registration are disabled until you qualify | You can’t launch a pre-registration campaign before production access. |
| Application | Dashboard → Apply for production, then a questionnaire in three sections | Answers in each section save only when you click Next or Apply. Write drafts offline first. |
| Review time | Usually seven days or less, occasionally longer | Plan about three to four weeks from first closed release to production. |
Source: Google Play Console Help, App testing requirements for new personal developer accounts.
Who has to do the 12-tester test
| Account | 12 testers / 14 days? | Notes |
|---|---|---|
| Personal account created after 13 Nov 2023 | Yes | Applies to every new app on the account until it has production access. |
| Personal account created on or before 13 Nov 2023 | No | Not covered by this requirement. |
| Organisation account | Not covered by this requirement | Needs organisation verification (D-U-N-S number). Only worth it if you are a genuine business. |
Why production access gets rejected
Google’s help page gives two official reasons an app may need more testing: fewer than 12 opted-in testers or insufficient tester engagement. Developers who have been turned down report three more causes that often sit behind the engagement message:
| # | Cause | How you can tell | Fix |
|---|---|---|---|
| 1 | Fewer than 12 testers for 14 continuous days (official) | The tester count in Play Console dipped, or testers opted in but never installed. | Recruit a 15–20 person buffer; remind testers not to leave the program. |
| 2 | Low engagement (official) | Few sessions or no crash/ANR data in Android vitals; testers opened the app once. | Give daily tasks, run check-ins, use real devices. |
| 3 | Thin or inconsistent answers (reported) | One-line answers; claims of “lots of feedback” with no specifics; no updates shipped. | Describe exact features, bugs, versions and numbers. |
| 4 | App not reviewable (reported) | Login wall with no test account, crashes in the pre-launch report, missing privacy policy. | Fix before applying; Google says review is not troubleshooting. |
| 5 | Testers not genuine (reported) | Swap-group installs that were never opened, emulator-only installs, all testers joining in one batch and going quiet. | Recruit people who match your audience and actually use the app. |
Google doesn’t publish an engagement threshold, so any number you see quoted online (sessions per day, minutes per tester) is a guess. Aim for usage that looks like real users of your app would behave.
Before day 1: preparation checklist
Most failed tests were lost before they started. Do these first, ideally with an internal test for a few days:
- Run an internal test on your own devices and fix crashes. Builds reach internal testers within seconds.
- Run the pre-launch report and fix every crash and accessibility warning you can.
- Complete the store listing, content rating, data safety form, target audience and a live privacy policy URL.
- If the app has a login, add working test credentials under App access.
- Prepare a feedback form (Google Forms works) and one channel for bug reports (WhatsApp, Telegram, Discord or email).
- Write the tester instructions (template below) and a list of 5–7 tasks covering every main feature.
- Create the closed testing track, add testers by email list or Google Group, and copy the opt-in link.
Tester instructions you can copy
Subject: Help me test [App name] for 14 days
Thanks for helping! Please:
- Open this link on your Android phone, signed in with [the Gmail you gave me], and tap Become a tester: [opt-in link]
- Install the app from the Google Play link on the same page.
- Use it for a few minutes on most days for the next 14 days, and please don’t leave the test before [date].
- This week, try: [task 1], [task 2], [task 3].
- Send bugs or ideas to [channel], and fill in this 2-minute form on day 7: [form link].
Three more messages to send during the test
Day 3–4: update released
New version is live: [version]. Thanks to your reports we fixed [bug 1] and [bug 2]. Please update from Google Play and try [new task] today.
Day 7: check-in
We’re halfway! Please take 2 minutes for this form: [form link]. Most useful: what confused you, what you’d change, and any crash or freeze.
To a quiet tester
Hi [name], just checking the app is working for you. Could you open it today and try [one specific task]? Please stay in the test until [date]. It really helps.
Where to find 12+ real testers
| Source | Engagement | Cost | Watch out for |
|---|---|---|---|
| Friends, family, colleagues, classmates | Medium–High if you give tasks | Free | They must have Android phones; enthusiasm fades after day 3, so check in. |
| Existing customers, website visitors or email list | High: they match your audience | Free | Best source for a business app; makes the questionnaire easy to answer. |
| Niche communities (subreddits, Discord, Facebook or Telegram groups for your topic) | High when the app solves their problem | Free | Follow each community’s self-promotion rules. |
| Tester-swap groups | Low–Medium | Free (you test their apps) | Many testers install and never open; supplement, don’t rely on them. |
| Paid testing services | Varies by provider | From about $15 upward | Check that testers use real devices and send written feedback you can quote. |
Google’s own advice is to recruit through personal and professional networks and to look for a diverse group that resembles your target audience.
Can’t find 12 testers?
- Ask existing customers or followers. A short post on your website, newsletter or social pages often brings in the most engaged testers.
- Go where your players already are. Puzzle, fitness or study communities welcome a free app that solves their problem; follow each community’s rules.
- Use local networks. Colleges, coding clubs and co-working spaces have plenty of Android users.
- Offer something small. Early-access perks, credits in the app or a thank-you note keep testers active.
- Combine sources. Mix a few friends, a community and a swap group or paid service rather than relying on one source.
- Don’t fake it. Fake or duplicate accounts don’t produce the engagement Google looks for and risk your developer account.
The 14-day playbook, day by day
| Day | Do this | Evidence you collect |
|---|---|---|
| Day 1 | Send instructions; confirm each tester has opted in and installed. Chase anyone who hasn’t. | Tester list with join dates. |
| Day 2–3 | Reply to first bug reports within a day. Thank testers publicly in the group. | Bug list with dates and reporters. |
| Day 3–4 | Release update #1 fixing the first bugs. Post release notes to testers. | Version number + what changed. |
| Day 5–6 | Send new tasks for features nobody has tried yet. | Which features each tester used. |
| Day 7 | Send the feedback form. Message quiet testers individually. | Form responses (ratings, quotes). |
| Day 8–9 | Pick the top 2–3 improvement requests and build them. | Feedback → change mapping. |
| Day 10 | Release update #2 with those improvements. | Release notes. |
| Day 11–12 | Ask testers to try the new features and confirm fixes. | Confirmations, screenshots. |
| Day 13 | Release update #3: final polish, then draft your questionnaire answers. | Final version, answer drafts. |
| Day 15 | Check 12+ testers are still opted in with 14 continuous days, then Apply for production. | Submitted application. |
Tip: keep testers in the program until you hear back. Your closed test may need to keep running if Google asks for more testing.
How to answer the production access questionnaire
The questionnaire has three sections: about your closed test, about your app or game, and about your production readiness. Answer from your records, not from memory. The examples below use a fictional word-puzzle game; replace every detail with your own.
| Topic | Weak answer | Strong answer (example) |
|---|---|---|
| How you recruited testers | “Friends and family.” | “We recruited 18 testers: 7 colleagues, 6 members of a word-game Discord community and 5 existing newsletter subscribers. All were Android users aged 18–45, our target audience.” |
| How testers engaged | “They used the app a lot.” | “Testers played daily challenges and the level map over 14 days, tried hints and the settings screen, and 14 of 18 completed at least 20 levels. Six testers used it on low-RAM phones.” |
| Feedback and how you collected it | “Good feedback.” | “We collected feedback in a Discord channel and a day-7 Google Form (15 responses). Main points: hint button hard to find, level 12 too difficult, slow first load on older phones.” |
| Target audience and value | “Everyone.” | “Adults who enjoy short daily word puzzles. The game offers a new themed puzzle every day, plays offline and has no forced ads between levels.” |
| Changes made | “Fixed bugs.” | “v1.0.2 moved the hint button and fixed a crash on Android 10; v1.0.3 rebalanced levels 10–15 and cut first load from about 6 to 3 seconds; v1.0.4 added a sound toggle testers asked for.” |
| Why you’re ready | “It works now.” | “No crashes in the pre-launch report or from testers since v1.0.3, all main features were tested on 9 device models, and the last feedback round raised no blocking issues.” |
For the expected installs question, pick an honest range. A modest, realistic estimate is better than an inflated one you can’t explain.
Keep an evidence log
A simple spreadsheet turns your questionnaire into copy-and-paste work. Log every piece of feedback and what you did about it:
| Date | Version | Tester | Feedback | Action taken |
|---|---|---|---|---|
| Day 2 | 1.0.1 | Tester 4 | Crash when opening settings on Android 10 | Fixed in 1.0.2 |
| Day 5 | 1.0.2 | Testers 2, 7, 9 | Hint button hard to find | Moved and enlarged in 1.0.2 |
| Day 7 | 1.0.2 | Form (15 replies) | Levels 10–15 too hard | Rebalanced in 1.0.3 |
Example rows from a fictional word-puzzle game.
What the rejection message means
| What you see | What it usually means | What to do |
|---|---|---|
| “Your app isn’t ready for Google Play production yet” (wording varies; games may see “requires more testing”) | The review found too few opted-in testers or too little engagement. | Keep the closed test running and follow the second-attempt plan below. |
| Apply button greyed out | You don’t have 12 testers opted in for 14 continuous days yet. | Check the tester count and dates on the Dashboard. |
| No reply after 7 days | Reviews occasionally take longer. | Wait for the email; keep testers opted in. |
| A policy rejection on a release (not production access) | A separate app review issue, e.g. metadata, permissions or data safety. | Fix the policy issue named in the email and resubmit. |
Rejected: your second-attempt plan
- Read the email carefully. It tells you the app needs more testing. Your closed test track stays in place, so don’t delete it or start a new app.
- Diagnose with the four checks in Figure 1: tester count, engagement, answers, app readiness.
- Re-engage or replace quiet testers. Message each one with specific tasks; add new testers from a better-matched source.
- Ship an update that fixes something testers reported, and tell them what changed.
- Run another genuine testing stretch with regular use, a fresh feedback form and at least one more update.
- Reapply with new, specific answers describing what changed since your first application.
Common mistakes
| Mistake | Why it hurts | Do this instead |
|---|---|---|
| Recruiting exactly 12 testers | One opt-out drops you below 12. | Recruit 15–20. |
| Testers opt in but never install | Opted in, but no real use to show. | Confirm installs on day 1. |
| Using internal testing | Doesn’t count towards production access. | Use a closed testing track. |
| No updates during the test | Nothing to show for “changes made”. | Ship 2–3 updates based on feedback. |
| Copy-pasted answers from the internet | Generic, and may contradict your test data. | Write from your own records. |
| Login wall with no test account | Reviewers can’t use the app. | Add credentials under App access. |
| Applying on day 14 with 11 testers left | Doesn’t meet the requirement. | Check the count on the Dashboard first. |
Final checklist before you click “Apply for production”
- 12 or more testers opted in continuously for the last 14 days (ideally 15+).
- Most testers installed and used the app across the period, not just on day 1.
- At least two updates released during the test, with release notes.
- Written feedback saved (form responses, chat messages, bug list).
- Answers drafted offline with names of features, versions and numbers.
- Pre-launch report clean; no known crash on popular devices.
- Store listing, content rating, data safety, target audience and privacy policy complete.
- Test login credentials added if the app needs an account.
- Your developer account and package name registered for Android developer verification.
Glossary
- Closed testing
- A Google Play testing track limited to testers you invite by email list or Google Group. Required before production for new personal accounts.
- Internal testing
- A quick testing track for up to 100 testers with no requirements. It doesn’t count towards production access.
- Opted in
- A tester has accepted your invitation through the opt-in link with the Google account they use on Google Play.
- Production access
- Permission to publish your app publicly on Google Play, granted after the closed-test questionnaire is reviewed.
- Pre-launch report
- Automatic tests Google runs on real devices when you upload a build, reporting crashes and issues.
- Android vitals
- Play Console’s stability and performance data, including crash and ANR rates.
- App access
- The Play Console section where you give reviewers working login details for apps that require an account.
- Google Group
- A mailing list you can add to a test track so everyone in the group becomes eligible to test.
Frequently asked questions
Why was my Google Play production access rejected?
Google sends apps back for more testing when there were fewer than 12 opted-in testers or when testers weren’t engaged enough during the closed test. Developers also report rejections when questionnaire answers are vague or contradict the test data, and when the app can’t be reviewed properly, for example because a login screen has no working test account.
How many testers do I need for Google Play closed testing?
At least 12 testers must be opted in to your closed test, and they must have stayed opted in continuously for the 14 days before you apply. Recruit 15 to 20 so a few drop-outs don’t put you below 12.
Who has to do the 12-tester closed test?
Developers with personal Google Play Console accounts created after 13 November 2023. Until they meet the requirement, the Production and Pre-registration pages stay disabled.
Does the 14-day clock restart if a tester leaves?
A tester who opts out before completing 14 days doesn’t count towards your 12. If a tester opts out and back in, their 14 days must be consecutive again. Keep a buffer of extra testers so your count never depends on one person.
Can I use internal testing instead of closed testing?
No. Internal testing has no requirements and is useful for quick builds, but only a closed test counts towards production access.
How long does the production access review take?
Google says review usually takes seven days or less, but it can occasionally take longer. You’ll be told by email.
What should I do after a rejection?
Keep the closed test running, work out which cause applies (tester count, engagement, answers or app readiness), push an update that fixes real tester feedback, re-engage your testers with specific tasks, collect fresh written feedback, then reapply with concrete answers once you have another solid stretch of testing.
Is it allowed to use paid testers or tester-swap groups?
Google’s guidance is to recruit people who resemble your target audience and to collect real feedback. Paid services and swap groups are widely used, but testers who install and never open the app are a common cause of engagement rejections. If you use them, make sure testers actually use the app and give feedback you can act on.
How do I answer the production access questionnaire?
Be honest and specific. Say exactly how you recruited testers, how many took part, which features they used, what feedback you received and how you collected it, what you changed in which version, and why you believe the app is ready. Your answers should match what Play Console and your feedback records show.
Do organisation accounts need 12 testers?
Google’s testing requirement applies to personal accounts created after 13 November 2023. A genuine business can register an organisation account with a D-U-N-S number, but that has its own verification steps; don’t create a company just to skip testing.
Do testers need to open the app every day?
Google doesn’t publish a usage threshold. It looks for real engagement, so ask testers to use the app regularly through the 14 days and give them small tasks so their usage reflects how real users would behave.
Can several Google accounts on one phone count as separate testers?
Each tester is a Google account that opts in, but Google also looks at engagement. Several accounts on one device rarely look like genuine testing, so recruit real people on their own phones.
Can I avoid the 12-tester rule?
Only if your account isn’t covered by it: the requirement applies to personal accounts created after 13 November 2023. A genuine business can use an organisation account, which needs a D-U-N-S number and organisation verification. Don’t create a company just to skip testing.
My app needs a login. What do reviewers need?
Provide working test credentials in Play Console’s App access section. Google notes that review is not troubleshooting, so an app reviewers can’t get into is likely to be sent back.
Resources
- App testing requirements for new personal developer accounts (Play Console Help)
- Google Play Console
- Android developer verification guides (Android Developers)
Related MobileMerit guides: Android Developer Verification · How to publish an app on Google Play · Android app submission checklist
Stuck in closed testing?
MobileMerit builds and publishes Android apps and games on Google Play. We can review your app before you apply, plan your 14-day test, fix crashes and policy gaps, and help you get to production.
Talk to MobileMerit.comUpdate log
- : Added key-numbers panel, testing-tracks and opt-in diagrams, extra message templates, evidence log, rejection message table, a section on finding testers, glossary and two new FAQs.
- : First published, checked against Play Console Help.