"Your testers were not engaged with your app": what Google Play actually publishes about tester engagement

There is no published threshold. Google denies production access for tester engagement without ever stating how much engagement is enough, and no number exists that you can hit and be certain. Anyone who tells you it is "at least 3 sessions per tester" or "20 minutes each" invented it.

Below is everything Google actually publishes, and then what is left to work with.

What Google says, in full

The denial reason appears in one sentence of Google's documentation, as an example rather than a definition:

"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."

That is the whole published definition of the failure. "Not being engaged with your app."

The nearest thing to a standard sits in the production access application form. You must "Provide information about the engagement you received from testers during your closed test", and what you are asked is:

"Whether testers used all of your app's features"

"Whether your testers' usage was consistent with how you would expect a production user to use your app"

Then:

"Finally, summarise the feedback that you received from testers and let us know how you collected this feedback."

Elsewhere the page says testers should use "as many of your app's features as possible in order to receive holistic feedback".

That is it. Read the four quotes above and you have read the requirement.

What is missing, stated plainly

Google publishes no metric. No session count, no session length, no active tester figure, no minimum number of screens visited, no crash-free rate, no feedback volume.

Google publishes no threshold. There is no number at which engagement becomes sufficient.

Google publishes no exit condition. If denied, you are told you "may be required to continue testing", with no stated duration and no defined test you can pass. You reapply and hope the picture looks different.

Google publishes no per-tester report. Play Console does not show which testers opened the app, how often, or for how long. The data the reviewer sees is not exposed to you, so you cannot audit your own test.

Those gaps are not getting filled with invented figures here. With numbers in it, this page would rank better and be worse.

A warning about the rest of the results

Search this phrase and most of what you get is written by companies that sell testers. Tester farms, "guaranteed 14 day closed test" packages, tester-swap communities with a paid tier. They have a commercial interest in the requirement sounding stricter and more mysterious than it is, because that is what makes 12 strangers look worth buying.

They also cause the exact failure you are reading about. Purchased testers opt in, satisfy the count, install the app, open it once or never, and generate no feedback. That is what "not being engaged" describes. Buying testers reliably converts a count problem into an engagement problem, and engagement is the harder of the two to get out of.

Treat any specific number you see about this with suspicion, including one attributed to a Google employee in a forum thread.

Why applications get denied for engagement

Working backwards from the form, these are the cases where the honest answer to Google's questions is "no".

• Testers installed and never opened the app. The most common shape by far.
• Testers opened it once, on day one. One launch across fourteen days does not look like production use.
• Only a few of your twelve did anything. Twelve opted in, three used it. The count passes and the picture does not.
• Nobody reached the main feature. If your app needs an account, a permission and a data import first, testers who stopped at signup have not tested it.
• You collected no feedback, so the summary question has no answer and you are inventing a paragraph.
• You shipped one build and never updated it, so there is nothing to say about what you changed.
• The app crashed at launch on common devices and testers gave up silently.
• You bought the testers.

What to do about it

The only strategy available is to make the honest answers to Google's four questions good ones.

1. Recruit people who want the app to exist. Twelve interested users beat thirty obliged ones. Look in the community your app is for, your own users on another platform, a relevant subreddit or Discord.
2. Write a one-page test brief. Five to eight specific things to try, each phrased as a task rather than a feature. "Add three items and set a reminder for tomorrow" gets done. "Please explore the app" does not.
3. Remove every obstacle between install and the point of the app. If signup, permissions and onboarding stand in the way, a tester who bounces there costs you the run.
4. Give people a reason to return. A weekly message asking them to try one new thing. Not payment, just contact.
5. Ship two or three updates during the fortnight, each announced with what changed and what to look at. That produces returning sessions and a real answer to the readiness questions.
6. Collect feedback in one place and keep it. A short form, a group chat, or an email thread. You will be asked how you collected it, so use a method you can describe in a sentence.
7. Add your own analytics if you have none. Play Console will not tell you whether testers are using the app; Firebase or any event tracker will. Knowing before you apply is the difference between evidence and hope.
8. Answer the application questions with specifics. Name the features testers used, quote a piece of feedback, name the change you made because of it, say how you decided the app was ready. Generic answers about engagement read as an absence of engagement.

Appeal, or keep testing?

There is no appeal for this. It is not a policy enforcement, so no strike is recorded and nothing is held against your account. It is an application that was not approved, and the only route forward is to reapply.

Do not reapply the next morning with the same test. Nothing the reviewer sees will have changed. Run another fortnight with better instructions, fixed onboarding, and at least one update shipped, then reapply with different answers. Review "usually takes seven days or less, but may occasionally take longer".

If you believe the reviewer was wrong, reapply with evidence in your answers: session counts from your own analytics, dated feedback, a changelog. You cannot force a reconsideration, but you can make the next reading unambiguous.

This is a judgement call made by someone at Google, on evidence you cannot see, against a standard that is not written down. That is worth naming as a bad experience. What you control is whether your test was real, and a real test with twelve interested people usually passes.

AppSubmit tracks opt-in dates and build history on a closed track, so the dates and changelog are to hand when the application asks for them. It cannot see tester session data, because Google exposes that to nobody.