Play Console asks a small question when you set up a closed test that turns out to matter for the next two weeks: who is allowed in, and how do you tell Google about them? You can paste addresses into an email list, or point the track at a Google Group.
Both work. Both can get you to 12 opted-in testers. The difference is how much typing you do, how fast new testers can join, and how much control you keep when someone needs to be removed.
How email lists work
On your closed testing track, open the Testers tab and create an email list. You give it a name and add addresses, either one by one or by uploading a CSV file. Every address needs to be the Google account the tester uses for the Play Store, usually a Gmail address.
The list lives inside Play Console, so you are the only person who decides who's on it. If a tester sends you the wrong address, or uses a different account on their phone than the one they gave you, the opt-in page won't let them in until you fix the list.
Lists can be reused across tracks and apps in the same developer account, which is handy if you test more than one app with the same group of people.
How Google Groups work
With a Google Group, you create the group in Google Groups first and then enter the group's email address on the track instead of individual testers. Anyone who is a member of that group can opt in.
The big advantage is that testers can join on their own. If you set the group so anyone can join, you share two links: the group link and the opt-in link. You don't have to collect addresses in a chat or a spreadsheet and copy them into Play Console, which removes the most common typo problem.
Two settings are worth checking before you share it. Set who can see the member list to owners or managers only, so testers can't see each other's email addresses. And decide whether people can join directly or have to ask, depending on how open you want the test to be.
Which one fits your test
Use an email list when you know every tester personally and the group is small: a few friends, colleagues, or developers you swapped testing with one by one. You have the addresses anyway, and you get exact control.
Use a Google Group when you're recruiting more widely, posting the test in a community, or expect people to come and go. Letting testers join themselves saves you hours of copying addresses, and it scales if you decide to recruit 20 people to keep 12 active.
You can also attach both to the same track. Some developers keep a core email list of people they trust and a Google Group for everyone else.
Mistakes that cost testers with either method
Being on the list or in the group is not the same as being opted in. The tester still has to open the opt-in link while signed in with that same Google account, accept the invite, and install the app from the Play Store. Check the opted-in count in Play Console, not the size of your list.
Account mismatches cause most of the confusion. A tester joins the group with a work account but their phone uses a personal one, and the Play Store says the app isn't available. Ask testers which account their phone's Play Store uses before they join anything.
Removing someone also works differently. With a list you edit it in Play Console; with a group you remove them from the group. I'm not certain how quickly Play reflects a group change in every case, so don't make last-minute membership edits right before you apply for production.
Keeping the count steady for 14 days
Neither method keeps testers active. That part is people, not settings. Recruit a few more than 12, remind people mid-way through, and watch the opted-in count every few days so a drop doesn't surprise you.
I built PeerPlay after hitting this wall with my own app. Developers test each other's apps in tracked 14-day rounds, PeerPlay checks that a tester really opened the app for a real session, and testers who go quiet get removed from a round, so you find out about a drop while there's still time to replace someone.
Top comments (0)