Production access rejected: what “testers were not engaged” means

You kept 12 testers in your closed test for 14 days, filled in the application and got an email saying your app isn't ready for Google Play production yet. It's frustrating, and it's common. The good news: the email tells you what to fix, and none of it requires starting a new developer account.

The three reasons in the rejection email

Developers who have published their rejection emails show one or more of these lines. Here is what each one means in practice.

• “Testers were not engaged with your app during your closed test.” Having 12 people opted in wasn't enough — the test didn't show real use across the 14 days. This is the most common reason, and it usually means testers installed once (or never) and moved on.
• “You didn't follow testing best practices, which may include gathering and acting on user feedback through updates to your app.” Google expects a test to change your app. If you uploaded one build on day 1 and nothing after, there's no sign you acted on feedback.
• “Your answers to the application questions … were incomplete or insufficient.” Short or generic answers (“testers liked it”, “no issues found”) don't describe a real test. Google asks nine specific questions and expects specific answers.

What Google does — and doesn't — tell you

Google doesn't publish a number for “engaged” — no minimum sessions, minutes or days of use. Be careful with anyone who quotes one. What Google's help page does say is that you should give testers clear instructions, encourage them to use as many features as possible, collect feedback and act on it, and keep a record to summarise in your application. Treat that list as the standard you're measured against.

Step by step: your second attempt

1. Don't stop the closed test. Keep the track and your testers. Removing everyone means starting from zero.
2. Look at who really tested. Anyone who never opened the app or never sent feedback isn't helping. Add people who will — remember that each new tester needs their own 14 days.
3. Give testers small, specific tasks every few days instead of “please test my app”. See the 14-day plan in our 12 testers guide.
4. Collect feedback in one place — a form, a Google Group or a chat group — so you can quote it later.
5. Ship at least one update that fixes something testers reported, and mention it in the release notes.
6. Keep a simple log: date, what a tester said, what you changed. This becomes your application answers.
7. Rewrite your answers with numbers, examples and changes. Our guide to the 9 production access questions shows how.
8. Apply again once at least 12 testers have each been opted in for the last 14 days in a row.

Mistakes that waste the second attempt

• Reapplying after 14 days with the same build and the same answers.
• Replacing silent testers with 12 more strangers who also never open the app.
• Answers that describe the app but not the test (“it's a fitness app for everyone”).
• An app that needs a login, with no working test account in the App access section.
• Claiming feedback or changes that didn't happen. Your answers should match what Google can see in your releases.

Weak vs. specific answers

The numbers above are an example for an imaginary app — use your own, and only real ones.

Source: Play Console Help — App testing requirements for new personal developer accounts. Checked on 14 October 2026; Google can change its process at any time.