'Testers were not engaged with your app during your closed test': what it means and how to reapply

1. What this message means

If your production access request came back with the reason “testers were not engaged with your app during your closed test,” Google took issue with what happened during the test, not the headcount or the time. Even if 12 testers were opted in for 14 days, Google decided there wasn’t enough sign that they actually opened and used the app.

The Play Console Help Center article also gives two examples of when more testing is required: when fewer than 12 testers opted in, and when testers weren’t engaged enough. This message is the second case.

2. The reason that often comes with it

This message rarely comes alone. It often arrives together with a reason saying you didn’t follow testing best practices, such as gathering user feedback and acting on it through updates. Google then tells you to run more closed testing with real testers and apply again.

Put the two reasons together and you can see what Google wanted: testers used the app, and the developer looked at their response and improved the app. A test that only fills the headcount doesn’t have that story.

3. How Google looks at engagement

Google doesn’t disclose how it measures engagement. Claims that testers must open the app a certain number of times a day or for a certain number of minutes aren’t in Google’s documentation. What the documentation does let you confirm is what the production access questionnaire asks.

• Whether testers tried all the features your app offers
• Whether testers used the app the way you expect real users to, and if not, how it differed
• A summary of the feedback you received from testers, and how you collected it
• How you changed your app based on the results of the closed test

In other words, the reviewer looks at your questionnaire answers together with the record of your test period. A test that leaves you with no facts to report shows in the questionnaire too. What to write for each question is covered in production access questionnaire examples.

4. Common causes

• Testers who installed the app but never opened it. This is common with testers from swaps. They count toward the headcount but leave no usage behind (where tester swaps fall apart).
• An app that gets stuck on the first screen. If a login is required but testers can’t create an account, or the first launch is slow or crashes, testers never reach the features. If your app requires a login, you also need to provide review login details in Play Console.
• Only one version for the whole test. You can’t show what you learned and fixed during testing (updating your app during closed testing).
• No way to collect feedback. If testers had nowhere to report problems, you can’t answer the questionnaire’s “feedback received” question.
• A questionnaire that just says “it went well.” Answers without numbers, versions, or what you fixed don’t show that testing actually happened.

5. Before you apply again

1. Don’t stop the test. If you leave the track and tester list as they are, the headcount and time conditions still hold. If you create a new track, the count starts over.
2. Have testers try the features. Ask for specific tasks, like “log in, try X once, and leave one line about anything that felt off.” Google also recommends gathering testers in a messaging group so they can share feedback.
3. Ship updates based on the feedback. Even small ones — two or three, with release notes describing what changed.
4. Build up usage, then rewrite the questionnaire. The documentation doesn’t set a waiting period before you can reapply, but if you resubmit the same thing right away, you’re likely to get the same result. Build up a few days to 14 days of real use and updates first.

To compare against other rejection reasons, see 7 reasons production access gets rejected.