A tester drops off. It happens in almost every closed test. Someone changes phones, loses interest, switches Google accounts, or simply never installs the app.
The important thing is not to panic and not to fix it in a way that creates a bigger problem. Replacing a tester is manageable if you understand one rule: each tester's 14-day clock starts when that tester opts in, not when the test itself started.
Why a replacement is different from a reset
If your test began on 1 November and a tester opts in on 8 November, that tester has not been opted in for the first seven days. They can still be a useful tester, but they do not magically inherit the earlier days.
That is why a group of exactly 12 is fragile. If one person leaves on day 10, a replacement who joins on day 10 will not have 14 days by day 14. The original group may still have 11 people with a long window, which is below the minimum.
The practical fix is a buffer. Start with 14 or 15 testers so one or two drop-offs do not put the whole application at risk.
First, confirm what actually happened
Before you remove anyone, find out which of these is true:
- The tester never opted in.
- The tester opted in but never installed.
- The tester installed but opted out.
- The tester changed to a different Google account.
- The tester's device or country is not supported.
- The tester is still opted in but the Console has not updated.
The answer changes what you do. Removing a tester who is actually still opted in can make the count worse. Ask for a screenshot of the testing page or the Play Store account, and check the Console before editing the list.
A clean replacement process
- Confirm the drop-off. Check the tester's status and the Console count.
- Ask the tester to opt out or confirm they have. This keeps the list honest.
- Remove the inactive tester from the list if they are no longer participating. Do not leave dead emails in the list and assume they count.
- Add the replacement using the same method as the rest of the group: email list or Google Group.
- Send the opt-in link and tell the replacement exactly what to do.
- Confirm the install from the testing page, not the public listing.
- Record the opt-in date in your tracker.
- Check the Console after the change. Give it time to sync.
If you use a Google Group, adding someone to the group is not the same as them opting in. They still need to open the opt-in link and accept.
Timing matters more than effort
A replacement on day 2 is useful. A replacement on day 12 is unlikely to help the current 14-day window, because they have not been opted in long enough.
If you are close to the end and the group is below the minimum, you have a few options:
- Keep the existing testers opted in and extend the test until the replacements have their own 14 days.
- Ask someone who dropped off to rejoin, but understand that their continuity may have been broken.
- Delay the production-access application rather than submit with a gap you cannot explain.
What you should not do is submit and hope the reviewer does not notice. The Console data is visible, and a mismatch between your answers and the test data is a bad look.
Do not replace people with accounts you control
This is the line that matters. Twelve accounts you created, twelve emulators, or one person using twelve email addresses are not twelve real testers. Google's review is designed to catch that pattern, and it can put the app or account at risk.
A replacement should be a real person with their own Google account and their own Android device.
A short message that works
Hi [name], thanks for helping with the closed test. I noticed the app is not showing as opted in on your account. Are you still able to test? If not, no problem — just let me know so I can plan around it. If you are still in, could you open this link and send me a screenshot of the testing page?
That is direct without being pushy. It also gives you a clear answer.
Keep a simple tracker
You do not need a dashboard. A spreadsheet with these columns is enough:
| Tester | Opt-in date | Installed? | Still opted in? | Notes | |
|---|---|---|---|---|---|
| A | a@example.com | 1 Nov | Yes | Yes | Pixel 7 |
| B | b@example.com | 1 Nov | Yes | No | Changed phone |
| C | c@example.com | 3 Nov | Yes | Yes | Replacement for B |
The tracker is for you, not for Google. It helps you see the real shape of the group before the Console catches up.
The short version
- Replacements start their own 14-day clock.
- Confirm the drop-off before removing anyone.
- Start with a buffer so one loss does not break the minimum.
- Use real people with their own accounts and devices.
- Track opt-in dates, not just email addresses.
- If the window is short, extend the test rather than submit a gap.
Next: how to keep testers opted in, or a realistic 14-day timeline.
Our team’s note
If this answered the question but your situation still feels messy, send us the screenshot or the rejection email. Some things are easier to solve in a two-minute conversation than another article.