You show engagement by recording what really happens during the test (which features testers used, what they reported, and what you changed) and then describing it plainly in the production access form. Google doesn't publish a usage threshold, but it asks specific engagement questions and lists "insufficient tester engagement during the testing period" as a reason to require more testing. The work is mostly in keeping good notes from day 1.
This article is about evidence. For ways to keep testers active in the first place, see how to keep closed testers engaged for 14 days.
What Google actually asks about engagement
The first section of the production access form, About your closed test, asks about:
- how easy it was to recruit testers
- whether testers used all of your app's features
- whether their usage matched the behavior you expect in production, and any differences
- a summary of the feedback and how you collected it
The third section asks what you changed based on the test and how you decided the app was ready (App testing requirements).
Each of these is a question you can only answer well if you collected something during the test. Engagement you can't describe is, for the purpose of the form, engagement that didn't happen.
Five kinds of evidence worth collecting
1. A feature coverage list
Write down your main features before the test starts. As the days go by, note which ones testers have used and which they haven't. By day 14 you want to be able to say, honestly, which features got real use and which got little.
A simple table is enough:
| Feature | Used by testers? | Notes |
|---|---|---|
| Sign-up and login | Yes | Two people had trouble with password reset |
| Create and edit items | Yes | Most-used feature |
| Sharing | Some | Fewer than expected; low discoverability |
| Settings and notifications | Few | Only explored after a reminder |
If a feature got almost no use, that's useful to know and fine to say. The form asks about differences from expected production behavior, not perfection.
2. Your own analytics
If your app includes an analytics or crash reporting tool, it can show sessions, screens and events from testers. Use it to check your feature list against reality, not to produce impressive numbers. Make sure the tool is declared correctly in your Data safety form, since it collects data.
Your own figures are for your own understanding. Report them as approximate patterns ("most testers used the core feature several times a week") rather than inventing precision.
3. A feedback log
Google says: "You must summarize your testing feedback when applying for production access." Testers' private feedback appears in Play Console under Monitor and improve > Ratings and reviews > Testing feedback. Feedback from your own channels (a group chat, email, a form) counts too, and the form asks how you collected it.
Keep one running log with the date, the source, what was reported and what you did. Our article on collecting useful feedback from closed testers has a template.
4. A record of updates
Shipping updates during the test isn't an official requirement, but Google encourages it: "Continue running closed tests while resolving user-reported issues and bugs." Every update you ship to the closed track, with release notes that mention what was fixed, is evidence that testers used the app and that you listened. The mechanics are in updating your app during a closed test.
5. Notes on what surprised you
Engagement isn't only "people used it". It's also what they did differently from what you expected. Testers who skipped your onboarding, used a feature in an unexpected way or asked for something you didn't build are telling you about production behavior. Write those observations down as they happen; they make the strongest, most specific answers.
Turning evidence into answers
When day 14 has passed, you have material for every engagement question. A few rules keep the answers credible:
- Be specific. "Testers used the shopping list feature most; sharing was used less than we expected, so we moved the button" is better than "testers used all features extensively".
- Match the facts. Don't claim every tester used every feature if your notes say otherwise.
- Connect feedback to changes. For each change you list, name the feedback that led to it.
- Keep numbers honest. If you mention counts, they should come from your own logs or analytics.
Our production access guide shows example answers for each question, and how to apply for production access walks through submitting the form.
What doesn't count as engagement
Some things look like activity but aren't the real use Google asks about:
- Opt-ins alone. Twelve opted-in testers is the minimum requirement, not proof that anyone used the app.
- Install-and-forget. Keeping the app installed and using it regularly is strongly advised; an app installed on day 1 and never opened tells you nothing.
- Emulators, bots or extra accounts of your own. The requirement is about real people on real devices. Faking activity risks your account and gives you nothing useful to report.
- Paid reviews or ratings. Testers can't leave public reviews on test versions, and Google prohibits incentivized reviews and ratings.
A day-by-day habit
Engagement evidence is easy to gather in small pieces and hard to reconstruct later. A light routine:
- Day 0: write the feature list and set up a feedback log.
- Every two or three days: update the coverage table and copy new feedback into the log.
- After each update: note what changed and why.
- Day 14: read through everything and draft your answers while it's fresh.
For what Google reviews beyond engagement, see what Google looks at when you apply for production access.
Key takeaways
- Google asks about feature use, usage patterns, feedback and changes. Collect evidence for each.
- Keep a feature coverage table, a feedback log and a record of updates.
- Describe engagement honestly and specifically; don't invent figures.
- Opt-ins, idle installs and fake activity don't show engagement.
GoPlayTester's testers use your app on their own Android devices throughout the 14 days, and you can follow progress day by day. That helps you meet the testing requirement and gives you real usage to describe, but Google makes the final decision. You can order a test here.
