What does "testers were not engaged with your app during your closed test" mean?

Google decided your testers didn't actually use the app enough during the test, even if 12 were opted in for 14 days. The headcount and the time aren't the problem; the usage is. Keep the test running, have testers use real features, ship updates based on what they report, then rewrite your answers.

Do I have to restart the 14-day closed test after a rejection?

Not necessarily. If your track is still running and at least 12 testers are still opted in, the headcount and time conditions still hold — Google simply asks you to keep testing. You only start the count over if you drop below 12 testers or create a new track. If the questionnaire was the only problem, you can fix it and apply again.

How long after a rejection can I reapply for production access?

Google's documentation doesn't set a waiting period. Once you meet the requirement, you can apply again. Resubmitting the same answers right away tends to get the same result, so fix what was missing and give it some days of real usage and updates first.

Will Google tell me the exact reason?

The review result goes to the account owner's email and also shows on your app's dashboard in Play Console. The wording is often general, so it's faster to check your test against each reason on this page one by one.

Is my app deleted if production access is rejected?

No. Only production access is denied. Your app, your developer account, and your closed testing track all stay as they are.

← Blog

Requirements

Google Play production access rejected? 7 reasons and fixes

Production access not approved after closed testing? It's usually fewer than 12 opted-in testers, a broken 14-day run, testers not engaged with your app, or thin questionnaire answers. Here's what each rejection means and what to fix before you reapply.

Last checked 7. okt 2026.

Why was production access rejected? The short answer

When Google Play rejects your production access request, it's almost always one of two things: the closed test didn't meet the requirement, or the test happened but your questionnaire didn't prove it. The first is about the 12 testers, the 14 continuous days, and whether testers actually used the app. The second is about the answers you submitted.

The Play Console Help Center says personal developer accounts created after November 13, 2023 must run a closed test with at least 12 testers who have been opted in continuously for at least 14 days. It gives two examples of when you'll be asked to keep testing: fewer than 12 opted-in testers, and testers who weren't engaged enough during the test.

A rejection isn't a ban. Your app isn't removed, your account isn't suspended, and your closed testing track keeps running. You fix the gap and apply again.

What the common rejection messages mean

“Testers were not engaged with your app during your closed test” — you had the headcount, but Google saw too little real use. This one has its own guide: what “testers were not engaged” means and how to reapply.
“Didn't follow testing best practices” — often comes with the message above. Google wants to see that you gathered feedback and acted on it through updates (see updating your app during closed testing).
Fewer than 12 testers, or the 14 days weren't met — the count itself fell short. Check the 14-day counting rules.

If the email doesn't make the cause obvious, go through the seven reasons below from the top. Most rejections match one of them.

1. Fewer than 12 testers stayed opted in

Google counts accounts that actually opted in to your closed test and stayed opted in — not the number of emails on your tester list. If the count drops below 12 at any point, the requirement breaks at that moment, and a tester who opts out and back in starts their own 14 days again.

How to fix it: Start with a buffer above 12. If you start with exactly 12, a single dropout puts you back at the beginning.

2. The 14 days weren't continuous

A few days of testing, a pause, and a restart don't add up. Creating a new closed track or pausing the existing one also breaks the run.

How to fix it: Leave the track and the tester list alone for the full 14 days. Adding testers is fine; removing them is what hurts.

3. Your questionnaire answers were too thin

This is the most common cause. A person reviews your answers, so a line like "Testing went well" reads as having nothing behind it.

How to fix it: Write what you checked and what you fixed, with numbers. What changed in each version you shipped during the test matters most.

4. Your app never changed during the test

The questionnaire asks what you changed based on closed testing. With a single version for the whole test, you have nothing to point to. It isn't a hard requirement, but it works against you.

How to fix it: Ship small improvements every 3–4 days during the test so you build a version history.

5. The app itself has a policy problem

Sometimes the block has nothing to do with testing: too many permissions requested, a missing privacy policy, or a content rating that doesn't match the app.

How to fix it: Separately from testing, get your App content declarations, Data safety form, and privacy policy in order first.

6. The app broke on first launch

An app that installs but closes right away on certain Android versions, or gets stuck on the sign-in screen, looks unready — and testers who can't get past the first screen can't engage with it.

How to fix it: Check that first launch works across several manufacturers and Android versions, and keep logs from any device that fails so you can fix it.

7. Your answers didn't match what happened

If you describe tester experiences that never happened, a reviewer can spot the gaps against your other answers. If that becomes an issue, it's your developer account that's at risk, not just this app.

How to fix it: Write only what actually happened. Saying you couldn't verify a feature is safer than claiming you did.

Do you have to start the 14-day test over?

It depends on which side failed. If the questionnaire was the problem and your test is still running with 12+ testers opted in, you don't need to start over — rewrite the answers and apply again. If engagement was the problem, keep the same track running and build real usage and updates before reapplying. You only restart the count if you fall below 12 testers or create a new track.

Google's Help Center says review usually takes seven days or less, sometimes longer, and the result is emailed to the account owner. It doesn't set a waiting period before you can apply again.

Checklist before you reapply for production access

Confirm that at least 12 testers are still opted in and the 14 days are actually continuous. See the 14-day counting rules.
Rewrite your questionnaire answers from facts. We collected examples for each question in How to answer the production access questionnaire.
List the versions you shipped during the test and what changed in each. This is your strongest evidence.
Make sure nothing is missing in your App content declarations, Data safety form, or privacy policy.

If you ran your closed test with DUIRE and your production application is rejected, tell us within 30 days of the test ending and we'll run another 14 days of closed testing at no extra cost. When re-running, a new track is sometimes the better choice, so we decide that with you after looking at the rejection reason.

Frequently asked questions

Why was my Google Play production access not approved?: Almost always for one of two reasons: the closed test didn't meet the requirement (12 testers opted in for 14 continuous days, with real engagement), or the test happened but your questionnaire didn't show it. Google's Help Center names fewer than 12 opted-in testers and testers who weren't engaged enough as examples of when more testing is required.
What does "testers were not engaged with your app during your closed test" mean?: Google decided your testers didn't actually use the app enough during the test, even if 12 were opted in for 14 days. The headcount and the time aren't the problem; the usage is. Keep the test running, have testers use real features, ship updates based on what they report, then rewrite your answers.
Do I have to restart the 14-day closed test after a rejection?: Not necessarily. If your track is still running and at least 12 testers are still opted in, the headcount and time conditions still hold — Google simply asks you to keep testing. You only start the count over if you drop below 12 testers or create a new track. If the questionnaire was the only problem, you can fix it and apply again.
How long after a rejection can I reapply for production access?: Google's documentation doesn't set a waiting period. Once you meet the requirement, you can apply again. Resubmitting the same answers right away tends to get the same result, so fix what was missing and give it some days of real usage and updates first.
Will Google tell me the exact reason?: The review result goes to the account owner's email and also shows on your app's dashboard in Play Console. The wording is often general, so it's faster to check your test against each reason on this page one by one.
Is my app deleted if production access is rejected?: No. Only production access is denied. Your app, your developer account, and your closed testing track all stay as they are.

Meet the requirement without recruiting testers

DUIRE joins your closed test with real Android devices and opens your app every day for 14 days. Registering your app and checking installability are free.

Check installability See how it works