Last reviewed against current Google Play Console Help documentation.
You have picked a managed closed-testing provider. The order is placed, the invoice is paid, and then comes the part nobody writes a guide about: what you actually hand over so the test can begin.
A campaign does not start when money changes hands. It starts when a tester can open a link, install your build, and stay opted in. Most of the work before that point sits on the client's side, because the things that decide whether a test can start live in your Play Console and your app — not in the provider's.
This guide is the pre-start brief: what a provider genuinely needs, the checks worth doing before you send it, what never to send, and why campaign starts slip.
Quick answer
- What the provider needs: your package name, the name of the closed-testing track, confirmation the release is published and available, the opt-in link for that exact track, how testers are attached (email list or Google Group), the countries your testers are in, and a test account for your app if it needs a login.
- What it does not need: your Google account password, recovery codes, two-factor codes, payment credentials, or ownership of your developer account.
- What decides the start: a published release, a link that works for a non-admin Google account, and a tester list or group that already contains the intended testers.
- What no provider can control: Google's review of your app and Google's decision on production access. Preparation improves the odds of a clean start; it cannot guarantee an approval.
Why preparation matters more than most developers expect
Three things make the handover worth an hour of your time.
The 14 days only count from real opt-in. For personal developer accounts created after Google's cutoff date, the documented requirement is a closed test with at least 12 testers opted in continuously for the preceding 14 days before you can apply for production access. Invited testers, or testers staring at a link that shows nothing installable, contribute nothing to that clock. The difference between invited, opted in and installed is set out in what counts as an eligible tester.
Access problems look identical from the outside. "Testers cannot see my app" can mean the release is not published, the tester is on the wrong account, the group was never joined, the country is not targeted, or a managed-publishing hold is sitting on the track. A provider that receives a working link and a confirmed tester list skips a whole round of questions.
You keep ownership of your account. A reputable provider tests your app; it does not need to run your developer account. A request for full account control is a reason to slow down, not to hand over credentials.
What a provider actually needs
The items below are practical coordination details rather than Google requirements. Nothing here is something Google asks for; it is what makes a managed test able to start on the agreed date.
| Item | What exactly to send | Why it matters |
|---|---|---|
| App identity | App name and package name (for example com.yourcompany.yourapp) |
Removes any ambiguity between two apps, a renamed listing, or a test build of the same product. |
| Track | The closed-testing track name, especially if you have more than one | Testers added to the wrong closed track can opt in and still see an older build. |
| Release state | Confirmation that the release on that track is available to testers, not just approved | Approval and publication are separate steps in Play Console. Managed publishing can hold an approved release back. |
| Opt-in link | The shareable link from that track's testers page | This is the only reliable way in. Closed tests are not meant to be found by searching Google Play. |
| Tester access method | "Email list" or "Google Group", plus the list or group address if the provider must join it | Google Groups only admit their members; an email list admits whoever is on it. |
| Countries | The Play countries of the testers, and whether your track is limited | A tester whose Play country is outside your targeting sees an unavailable message, however good the link is. |
| App access | A dedicated test account and the steps to reach the parts worth testing — through a safe channel | An app behind a login cannot be tested without one, and testers should never receive real user data. |
| Feedback expectations | Where reports should go, what you want tested, and who answers questions | Prevents a fortnight of installs that produce feedback nobody can act on. |
Six checks before you hand over
Run these in order. Each takes a minute and removes a class of failure that is expensive to debug mid-campaign.
- The release is published, not merely approved. Check the item status on the Publishing overview page. If managed publishing is on and your release sits under "Changes ready to publish", testers have nothing to install. See managed publishing and approved-but-not-live releases.
- The opt-in link comes from the right track. Copy it from that track's testers page — not from an internal test, and not from an older closed track you abandoned.
- The link works for someone who is not you. Open it as a normal Google account that is not on your developer account. Your own experience is not evidence: your access comes from ownership, not from tester settings.
- The tester list or group is already in place. With a Google Group, intended testers must join before opting in — Google states only members of the specified groups can join the test. With an email list, add the addresses and save first.
- Countries line up. Country availability applies across tracks. Check each tester's Google Play country, not their physical location; see testers in different countries.
- You have margin above the minimum. Twelve opted-in testers is the documented threshold, so start with more. One person opting out shouldn't put the run at risk.
Two more, if your app is not a one-screen tool: it installs and runs on a clean device with the test account using the build on the track, and the version code is higher than anything testers may already have. When someone is selected to test through both Play Console and the Google Admin console, Google states they receive the highest version code among all available app versions.
What never to send, and what to send instead
Credentials are where enthusiastic clients create unnecessary risk. No legitimate testing task requires these:
| Never send | Send this instead |
|---|---|
| Your Google account password | Nothing. There is no testing step that needs it. |
| Two-factor codes, backup codes or recovery email access | Nothing. These protect the account that owns your app. |
| Payment credentials, tax details or payout information | Nothing. Testing does not involve your payments profile. |
| Full access to your Play Console account | A Play Console user invitation with the narrowest role that is genuinely needed — Google documents how accounts, users and permissions work — and remove the user when the test ends. |
| Real customer accounts, or production data in your test build | A dedicated test account with sample data, created for this test only. |
| Long-lived admin logins for your backend | A limited test login, or a demo environment, that can be revoked after the test. |
Share test credentials the way you would share a temporary password: through a channel you control, with an expiry, and changed afterwards. If a provider asks for your Google password, that is a signal about the provider, not a step in the process.
Who does what
Most friction at kickoff comes from unclear ownership rather than missing information.
| Client (you) | Provider | |
|---|---|---|
| Build and upload the release; publish it to the track | Recruit and coordinate testers | Review the app and the release |
| Add testers, or supply the group and confirm membership | Get testers to opt in and stay opted in | Decide whether a tester counts as opted in |
| Share the correct opt-in link and test account | Install, exercise the app, report issues | Decide production access |
| Fix defects testers report | Escalate access problems with specifics | Publish approved changes, or hold them under managed publishing |
The column that surprises people is the third. A provider can organise people and process; it cannot approve your app, influence Google's review, or turn a failing app into a passing one. Any provider promising a guaranteed outcome is describing something it does not control.
Why campaign starts slip
These are the recurring causes, roughly in order of how often they appear. Each has a small fix, and none of them is the fault of the testers.
The release is approved but not published. Managed publishing holds approved changes until you publish. Fix: publish from the Publishing overview page.
The release is still in review. Review can take a few hours or up to seven days, longer in exceptional cases. Fix: submit early, and avoid adding edits while a review runs — review time is counted from your last submitted change.
A new tester list or group has not gone live. Setting a new email list or Google Group on a track counts as a configuration change, which managed publishing also holds. Editing the membership of a list already attached is the exception that goes live without publishing.
Testers joined the group but did not opt in. Membership and opt-in are separate steps. Fix: send the opt-in link explicitly, with one line of instructions.
The link is from the wrong track, or the tester's Play country is not targeted. Fix: re-copy the link from the intended track's testers page, test it on a non-admin account, and check targeting against each tester's Play country rather than their location.
The app needs a login nobody supplied, or "test the app" was the whole brief. Fix: create the test account before kickoff, and say which flows matter, what a useful report looks like, and where to send it.
The broader diagnosis path for testers who cannot get in at all is covered in closed testing not working: common problems and fixes.
If a tester cannot get in, send these details
Vague reports cost days. When you escalate, include:
- The exact message, copied as text if possible — "item not found", "app not available in your country" and "your device isn't compatible" point to different causes.
- A screenshot of the failing screen, including the URL if it is a browser page.
- The full Google account used — account mismatches are the most common cause.
- That account's Google Play country, and whether it changed recently.
- The track name, version code and opt-in link you sent.
- Timestamps with a time zone, especially just after publishing, because propagation to testers can take several hours.
- Device and Android version, if the message mentions compatibility, and whether that tester installed a previous build successfully.
Useful screenshots, in order of value: the tester's error screen, the track's testers page showing the attached list or group, and the item status on the Publishing overview page.
A copyable intake brief
Paste this into your message to any provider and fill it in. It covers what is needed to start without exposing anything sensitive.
App name: Package name: Closed-testing track name: Release status (available to testers / in review / approved but unpublished): Opt-in link: Tester access method (email list / Google Group): List or group address (if applicable): Number of testers already opted in: Countries targeted: Any testers based outside those countries? (list their Play countries): App requires login? (yes/no): Test account details sent by: (channel) Feedback should go to: Preferred report format: Campaign start date and time zone: Anything sensitive to avoid testing:
Keep the test account out of this message and send it separately through a channel you control. If a provider needs to join your Google Group, say so explicitly and confirm when each tester has joined, because group membership is required before opt-in.
Frequently asked questions
Do I have to give a testing provider access to my Play Console?
Usually not. Most coordination needs the opt-in link, a tester list or group you control, and a test account for the app. If console access is genuinely required, Google documents how to add users and assign permissions — invite with the narrowest role that works, and remove the user afterwards. Never share your account password.
Is it allowed to use a paid testing service?
Paying people to install and use your app is not the same as faking engagement. What matters is that the test is genuine: real people, real devices, real use, and honest feedback. Services that simulate activity or fabricate reports are a risk to your account, not a shortcut.
When does the 14-day clock actually start?
From each tester's continuous opt-in — not from your order, your payment, or the day a build was approved. A tester who opts in on day three contributes from day three. This is why a published release before kickoff matters more than any other preparation step.
Can I add testers after the campaign has started?
Yes, and it is common when someone drops out. Watch two things: the change may need publishing if it introduces a new list or group, and replacements start their own clock rather than inheriting the previous tester's days.
What if my app needs a login to test anything?
Create a dedicated test account with sample data, write the steps to reach the main flows, and check it on a clean device before kickoff. Google also requires app access instructions for review, so the same account often serves both purposes.
Why did the provider ask for a Google Group when I already have an email list?
Groups can be a practical way to manage changing members, but they add a step: each tester must join the group before opting in. If your track uses an email list, you can simply add addresses and share the link. Choose one method and say which it is.
Conclusion
The handover is short when it is deliberate: a published release on the right track, a link that works for a normal Google account, a tester list or group that already contains the intended people, countries that match, a test account if the app needs one, and a written idea of what feedback is for.
Everything else — your password, recovery codes, payment details, account ownership — stays with you. A provider that understands closed testing will ask for the first list and not the second.
If you would rather hand the coordination over and keep the setup, our team runs real-device closed tests with a progress dashboard you can watch, and the required information is exactly the brief above. You can see how the 12 testers service works, and the guide to adding testers covers the Play Console steps either way.
Official sources
- Google Play Console Help — App testing requirements for new personal developer accounts
- Google Play Console Help — Set up an open, closed, or internal test
- Google Play Console Help — Control when changes go live
- Google Play Console Help — Publishing status
- Google Play Console Help — Add developer account users and manage permissions
- Google Play Console — Publishing overview
Requirements and Play Console behaviour change over time. Verify current details in the official Play Console Help pages linked above before acting on them for a live test.
