When your closed test has had at least 12 testers opted in for 14 days in a row, the Play Console Dashboard unlocks Apply for production. Clicking it opens a short form. It looks like a formality, but it is the part of the process where a human reviewer decides whether your test was real and whether the app is ready, and weak answers are a frequent reason developers are told to keep testing.
This guide goes through the questions, what each one is really asking, and how to answer with specifics. Google adjusts the wording from time to time, so treat the question text below as a close paraphrase rather than an exact copy.
Before you apply
Good answers are written from notes, not from memory. Before you open the form, gather:
- How you recruited testers and how many you invited versus how many opted in.
- What testers did: which features they used and roughly how often.
- Every piece of feedback you received and where it came from (feedback email, form, chat, bug reports).
- The updates you shipped during the test, with version numbers and what each one changed.
- Crash and ANR numbers from Android vitals, and anything the pre-launch report flagged.
Part 1: About your closed test
How easy was it to recruit testers for your app?
This is a multiple-choice question, from very easy to very difficult. There is no right answer; choose the honest one. Some forms follow up by asking you to describe how you recruited people, so be ready to name your channels: friends and colleagues, a developer community, your own mailing list or a testing service.
Describe the engagement you received from testers during your closed test
Reviewers want evidence that testers used the app, not just opted in. Describe which features were used, how often, on what kinds of devices, and anything notable you saw in your analytics or vitals.
A weak answer: “Testers used the app and liked it.”
A stronger answer, for an example habit tracking app: “15 testers opted in and 14 stayed for the whole test. Most opened the app daily to log habits; the reminder and streak screens were the most used. Testers used phones from five manufacturers running Android 10 to 15, including two tablets. Android vitals recorded two crashes in the first week, both on Android 10, which we fixed in version 1.0.2.”
Provide a summary of the feedback you received and how you collected it
Name the channels, then group the feedback into themes. Mention both positive and negative feedback; a test where nobody found anything to improve is less believable than one with a few real issues.
Example: “We collected feedback through the feedback email on the testing track and a short form linked in the release notes. Testers reported that reminders did not fire after a phone restart, that the dark theme had low-contrast text on the statistics screen, and asked for a weekly summary. They found the onboarding clear.”
Part 2: About your app or game
Who is the intended audience of your app?
Be specific about who the app is for and why. “Everyone” is not an audience. Example: “Adults who want to build small daily habits, such as drinking water or reading, and prefer a simple app without an account or social features.”
Describe how your app provides value to users
Explain the problem and how the app solves it, in two or three sentences. Point out what makes it more than a thin wrapper around a website or a template, since apps with minimal functionality are a policy concern on Google Play.
How many installs do you expect in your first year?
You choose a range. Pick a realistic one based on your marketing plans. There is no advantage in exaggerating, and a modest estimate is perfectly normal for a first app.
Part 3: Production readiness
What changes did you make to your app based on what you learned during closed testing?
This is often the most important answer. Google wants to see that the test changed the app. List concrete changes with version numbers, and link each one to the feedback or data that caused it.
Example: “Version 1.0.2 fixed the two crashes on Android 10 found in vitals. Version 1.0.3 rescheduled reminders after a device restart and raised text contrast in the dark theme, both reported by testers. We also added a weekly summary screen, which several testers asked for.”
If you shipped no updates during the test, you have very little to write here. That is why we recommend at least one update during every closed test, even a small one.
How did you decide that your app is ready for production?
Give criteria, not feelings. For example: no open crash reports in the last week, all reported bugs fixed or deliberately scheduled, the main flows tested on a range of Android versions and screen sizes, and store listing and data safety information complete.
Do's and don'ts
| Do | Don't |
|---|---|
| Use numbers: testers, days, versions, devices | Write one-line answers |
| Mention real problems you found and fixed | Claim testers found nothing at all |
| Describe how feedback was collected | Paste the same generic answer into every field |
| Keep answers consistent with your Play Console data | Invent engagement or feedback that did not happen |
| Reuse your notes for the next app | Copy an answer template without adapting it |
Honesty matters here. Google can see your testing track, tester counts and vitals, and answers that do not match the data are not convincing.
After you submit
Google says it usually reviews applications within 7 days, though it can take longer. You will get an email and a message in Play Console. If you are approved, you can create a production release, ideally with a staged rollout. If you are not, the message explains that more testing is needed and you can apply again later; our guide on what to do when production access is rejected covers the next steps.
While you wait, resist the urge to change your store listing or declarations unless something is wrong. Reviewers compare what you wrote with what they see, and a consistent picture is easier to approve. If you notice a mistake in your answers after submitting, note the correction so you can use it if you have to apply again.
Keep your closed test running while you wait. If testers drop off during the review, you may have less to show if Google asks for more testing.
Make the answers easy to write
The best answers come from a test that produced something to report: steady use, a few bugs, feedback and an update or two. If you are planning your test now, read how to set up closed testing and where to find 12 testers.
With TesterBie, real Android phones use your app every day for 14 days, crashes and broken screens are reported with the phone model, Android version and a screenshot, and the dashboard keeps a daily activity log. At the end you get a report and tips for these questions, so your answers are based on what actually happened. See plans.
Frequently asked questions
Do I have to answer the production access questions in English?
Google does not require English, but clear English is the safest choice because it is easy for any reviewer to read.
Can I use an answer template I found online?
Use templates only for structure. Reviewers see many identical answers; write about your own testers, feedback and changes, and keep the details consistent with your Play Console data.
How long does Google take to review a production access application?
Google says reviews usually take 7 days or less, though some take longer. You are notified by email and in Play Console.
What happens if my application is rejected?
Google tells you that more testing is needed. Keep the closed test running with at least 12 engaged testers, ship improvements, and apply again when Play Console allows it, with more specific answers.