Explainer
Google Play has three testing tracks and they are not versions of each other. Internal is for your own quick checks, closed is where a named list of testers opts in through a link, and open is public. Only one of them satisfies the requirement before production access.
The tracks differ in who can join, how they join, and whether anyone outside your team can see the app. That combination is what makes them distinct rather than a naming convention. Internal testing is restricted to people you add by email address. Closed testing is restricted to people who opt in through a link you share. Open testing can be joined by anyone who finds your app.
The mistake is treating them as stages of one ladder. An app in open testing is not more thoroughly tested than one in closed testing, it is differently visible. An app in internal testing is not a smaller closed test either, because internal testers are people you already know rather than independent users, and that difference is exactly what the requirement turns on.
Internal testing exists so you can confirm that a build installs, launches and does not immediately crash, without waiting for anything. A release in internal testing becomes available to testers within minutes, which makes it the right lane for checking a Play App Signing setup, a newly requested permission, or a build that fails to install for an environmental reason.
It is not the lane for the requirement. Internal testers are people you know, added by email address, and they never opt in through a link. That makes the track useless as evidence of independent testing, and it is why completing a thorough internal test leaves a new personal developer account exactly where it started.
Closed testing is where a defined set of testers opt in through a shareable link and remain opted in. You control membership by tying the track to a Google Group or a list of email addresses, and Play Console generates the opt-in link you share. Anyone who opens that link and opts in becomes a genuine tester in the track, with their opt-in date recorded.
That record is the entire point. A closed test shows who opted in and when, which is what turns continuous opt-in over a period of days into something you can point at rather than assert. Testers who uninstall partway never reach the threshold, so continuity is the property the track is built to capture, and the roster has to stay at or above the count you are claiming for the whole period.
Open testing makes your app available to anyone who finds it, and it can be listed publicly in Google Play. It is the right lane for a soft launch into a new market, for testing at a scale you could not roster by hand, or for an app that benefits from being findable in search before you commit to a full release.
It is not a substitute for the closed testing requirement. Anyone can opt in at any moment and then leave, so continuity across a period of days is precisely what an open track cannot guarantee. Some accounts are separately required to run an open test before production access, which is a different condition from the closed one and is named in your own Play Console rather than assumed.
Most first-time publishers use all three in sequence, and for good reason. Internal testing verifies the build. Closed testing runs the requirement and produces the record behind it. Open testing is optional, and is only worth doing when you want public visibility before committing to a full release. If you only need two, they are internal and then closed.
If you are subject to the closed testing requirement, though, the choice stops being a decision. The closed track has to run for the required period, the roster has to stay complete for that period, and the result is what supports the production access application. Choosing open testing instead does not avoid the step; it adds a second one on top of it.
There are rules about tracks that are worth knowing before you start, because they are not reversible and they are the reason some recruited testers never count. Testers cannot be moved between tracks, so someone recruited for a closed test cannot be transferred elsewhere to make a number work. A track cannot be deleted once it has history. Promoting a release from one track to another is a promotion rather than a new upload, which is what keeps its history attached.
The practical consequence is that the track has to be right the first time. If you create the closed track before the release you intend to test is live in it, the testers who opt in are testing a build you were never going to ship, and their opt-in dates are attached to the wrong version. Check what is live in the track before you send the link to anyone.
Every testing track has an opt-out mechanism, and it applies to closed and open testing alike. Testers can leave a track at any time without giving a reason, and once someone has opted out of a track they cannot rejoin it. Google also surfaces early real-world feedback from testers installing through open testing, which arrives before you have committed to a full release.
For anyone running a required window, this is the mechanism that makes retention a genuine problem rather than a formality. A tester who opts out cannot be replaced by a rejoin, and the replacement starts their own period from their own opt-in date. That is why a roster of fifteen with two people who leave on day three is a roster of thirteen at the end.
Internal testing is limited to email addresses you add and is available within minutes. Closed testing is limited to people who opt in through a link you share. Open testing can be joined by anyone who finds the app. They differ in who can join and how, not in how rigorous the testing is.
A complete closed testing roster within hours, retained for the full window, with the record Play Console needs behind it.