Getting 12 people to opt in is the easy part. Keeping them using your app for two weeks is harder, and it matters: Google says it may require more testing because of "insufficient tester engagement during the testing period." The best way to keep testers engaged is to give them a reason to come back. That means a clear plan, small tasks, quick replies, and an update that shows you're listening.
Why engagement matters, in Google's words
The official requirement is about opt-ins: 12 testers opted in continuously for at least 14 days. But when you apply for production access, Google asks about engagement directly. The form asks whether testers used all your features, whether their usage matched what you expect in production, and what feedback you got.
Google's text doesn't say testers must open the app every day, so don't tell anyone it's a rule. Still, keeping the app installed and using it regularly is strongly advised. It protects you from an "insufficient engagement" outcome and gives you real answers for the application form. If you're unsure whether installs matter, see do testers need to keep your app installed?
Before day 1: set expectations
People stay engaged when they know what's expected. Send a short kickoff message with:
- How long: at least 14 days, starting from the day they opt in.
- What to do: open the app regularly, try the main features, and report anything broken or confusing.
- How to report: one channel only (see below).
- What not to do: don't opt out or uninstall before you tell them the test is over.
Keep it short enough to read on a phone. A long document gets skimmed and forgotten.
Give testers small, concrete tasks
"Please test my app" is vague. "Today, try creating a list and sharing it with someone" is a task. Plan a few tasks across the two weeks so each feature gets used:
| Period | Example focus |
|---|---|
| Days 1–3 | Install, sign up or sign in, first impressions, onboarding |
| Days 4–7 | Core features, one per message |
| Days 8–10 | Edge cases: offline use, notifications, settings |
| Days 11–14 | The update you shipped, plus anything still unclear |
Small tasks also help when you apply. You'll be able to say which features were tested and by roughly how many people, honestly.
Use one place to talk
Google itself suggests a messaging group for testers in its best-practice advice. A group chat or community channel works well because:
- testers see that others are active, which makes it normal to keep going
- you can answer one question once, for everyone
- reminders don't feel like personal nagging
Keep messages useful: a task, a fix announcement, a thank-you. Two or three messages a week is plenty. Daily messages turn into noise.
Ship an update during the test
Nothing shows testers that you're listening like an update that fixes what they reported. Google recommends that you "Continue running closed tests while resolving user-reported issues and bugs." The application form also asks what changes you made based on the closed test.
Shipping an update isn't an official requirement, but it's good practice. Upload the new build to the same closed track, send it for review, and tell testers what changed and what to try. That gives them a fresh reason to open the app in the second week, when attention usually drops.
Reply fast, and close the loop
When a tester reports a bug, acknowledge it the same day if you can, even if the fix takes longer. When it's fixed, tell them. People who feel heard keep testing. People whose reports vanish stop reporting, and often stop opening the app.
Watch for quiet testers
Check your opted-in tester count a couple of times a week (here's how). If someone opts out, replace them right away: a new tester starts their own 14 days. Our article on what happens if a tester drops out covers the maths.
For testers who are still opted in but have gone quiet, a friendly, specific nudge works better than a general reminder. "Could you try the new export button in today's update?" is easier to act on than "Please keep testing."
What not to do
Some "engagement" tactics put your account at risk:
- Don't pay or reward people for reviews or ratings. Google prohibits "incentivizing feedback" and fraudulent or incentivized reviews and ratings. Testers can't leave public reviews on test versions anyway.
- Don't use emulators, bots or extra accounts of your own to fake activity. The requirement is about real people on real devices.
- Don't pressure testers into using features they don't care about for hours. Honest, light usage is better data than forced usage.
A simple engagement checklist
- Kickoff message sent with dates and one reporting channel
- A task planned for each few days
- Group chat or channel set up
- Bugs acknowledged within a day
- At least one update shipped and announced
- Tester count checked twice a week
- No one asked to opt out until production access is decided
When the 14 days are up, you'll need to describe all of this in the application. Our production access guide has example answers you can adapt. If recruiting and keeping 12 people active isn't realistic for you, GoPlayTester's testers use your app on their own devices every day of the 14-day test. You can order here.
