In short. Google documents three sections: "About your closed test", "About your app/game" and "About your production readiness". The answers that carry weight are engagement, feedback and the changes you made; Google says the app section is not public and does not affect visibility or feature access. Google publishes no scoring grid, so the best you can do is answer with numbers you can back up.
Where is the Google Play production access questionnaire?
The application opens once your closed test meets the requirement for new personal accounts: at least 12 testers opted in continuously for the preceding 14 days. In Play Console, open your app's Dashboard and click Apply for production, as described in Google's App testing requirements for new personal developer accounts. If you are not there yet, start with the 12 testers, 14 days rule.
The form moves section by section with Next, and the last one ends with Apply. Google warns, for every section, that clicking Discard or leaving the page before Next (Apply, on the last one) loses your changes. Write your answers in a text file first, then paste them in one sitting.
What questions does the production access application ask?
Here is what Google's Help Center lists for each section, and what each part is really checking. The wording in your Play Console may differ slightly from the Help Center; answer the questions as they appear on your screen.
| Section | What Google asks | What it checks (our reading) |
|---|---|---|
| About your closed test | How easy it was to recruit testers (you select an option). Tester engagement: whether testers used all available features, and whether their usage matched expected production behavior, with any differences. A summary of the feedback and how you collected it. | That real people used the app, and that you listened to them. |
| About your app/game | Your target audience, as specifically as possible. Your value proposition (for apps, how the app provides value to users; for games, what makes the game unique). An estimated install range for the first year. | Context for the reviewer. Google says these answers are not shown on Google Play and do not affect visibility, Play Console feature access or program eligibility. |
| About your production readiness | The changes you made based on what you learned from the closed test. How you determined the app was ready for production. | That the test changed something, and that you have a reason to ship now. |
Google states the purpose of the first section plainly: it "helps verify that apps have been thoroughly tested before publication on Google Play. This process protects users from low-quality apps, prevents malware distribution, and reduces fraud." Write every answer with that reader in mind: someone checking that a test really happened.
How do you answer "About your closed test"?
How easy was it to recruit testers?
This one is a choice between options, not free text. Google does not say how the answer is used, and there is no right option. Pick the one that is true, and keep it consistent with the rest of your answers: if recruiting was hard and you replaced testers along the way, the engagement answer can say so.
How engaged were testers, and did they use all the features?
Google asks for details about engagement during the test, including whether testers used all available features and whether their usage matched expected production behavior, with details on any differences. This is where vague answers hurt. Give the reviewer numbers:
- how many testers opted in, and how many stayed for the full 14 days;
- how many used the app on most days, and how much (sessions, minutes) if you measured it;
- which features testers used, and which they did not, with the reason;
- how test usage differs from what you expect once the app is public.
The last point is a question in its own right, and the honest answer is rarely "no difference". Testers who are friends or other developers behave differently from your target users. Saying how, and what you did about it, reads better than claiming a perfect match.
[N] testers opted in to our closed test between [date] and [date], and [N] of them stayed opted in for the full 14 days. [N] testers used the app on at least [N] of the 14 days, for [N] sessions and about [N] minutes in total, measured by [our analytics / the SDK we used during the test]. Testers used [feature A], [feature B] and [feature C]. [Feature D] saw little use because [reason]; we [what you did about it].
Test usage matched what we expect in production for [core flow]: short daily sessions to [task]. It differed in one way: our testers were [Android developers / friends and colleagues] rather than [target users], so they [behavior]. We expect real users to [behavior], and we [adjusted onboarding / added an empty state / changed defaults] to account for it.
What feedback did you receive, and how did you collect it?
Google asks you to summarize the feedback and describe how you collected it. Name your channels: the private feedback testers send through Google Play (you read it on the Testing feedback page in Play Console), the feedback email or URL you set on the Testers tab, an in-app form, a survey, or a chat group, which Google itself suggests in its FAQ. Then summarize by theme, with counts, rather than quoting the two nicest comments.
We collected feedback through [Google Play private feedback, the feedback email shown on our opt-in page, a short survey at day 3 and day 10, a chat group with testers]. We received [N] pieces of written feedback from [N] testers, with an average rating of [x] out of 5. The main themes were: [theme 1] ([N] testers), [theme 2] ([N] testers) and [theme 3] ([N] testers). Two testers also reported [specific bug] on [device / Android version].
How do you answer "About your app/game"?
Google says these answers give context and are not displayed publicly on Google Play. They do not affect app visibility, Play Console feature access or eligibility for developer programs. That is a reason to be precise, not a reason to skip them.
Who is your target audience?
Google asks you to be as specific as possible. "Everyone" says nothing. Describe who, in what situation, with what need. Keep it consistent with the target age group you declared on the App content page: Google's pre-submission checklist asks you to confirm that your target age group and store listing reflect your app's audience.
[Who: e.g. amateur climbers aged 18 and over] who [situation: train indoors two or three times a week] and want to [need: log routes and see progress without a spreadsheet]. Most are [level / context], use the app [when], and [what they already use today].
What is your app's value proposition?
For apps, Google asks how your app provides value to users, and points to its app quality guidelines. For games, it asks what makes your game unique. Say what the user gets that they do not get today, in two or three sentences, without marketing adjectives.
[App] lets [audience] [do the core task] in [time / steps], where today they [current workaround]. It [key difference: works offline, needs no account, imports X]. During the test, [N] testers used [core flow] on most days, which is the behavior the app is built around.
How many installs do you expect in the first year?
You select a range. Since Google says this section does not affect visibility or feature access, there is nothing to gain from inflating it. Pick what your launch plan supports.
How do you answer "About your production readiness"?
What changes did you make based on the closed test?
This is the question that shows whether the test was a test. List concrete changes, tie each one to what testers reported, and name the versions you shipped to the closed track. Google's own FAQ recommends updating your app in closed testing before production, so a test with no updates is harder to describe.
During the test we shipped [N] updates to the closed track ([version names]). Based on tester feedback we: fixed [crash or bug] reported by [N] testers on [device / Android version]; changed [flow] because [N] testers [problem]; added [feature] requested by [N] testers. We decided not to change [X] because [reason], and will revisit it after launch.
How did you determine the app was ready for production?
Google asks how you decided, so describe your criteria and show they were met. Useful criteria are ones you can check: no open crash reports in the last days of the test, core flows used by most testers, the main feedback themes addressed, the pre-launch report reviewed, policy declarations complete.
We considered the app ready when: [no new crashes in the last N days of the test]; [N of N] testers completed [core flow]; the [N] most reported issues were fixed in version [x]; the pre-launch report showed [no errors / only warnings we reviewed]; and the App content declarations, privacy policy and reviewer sign-in details were complete.
What evidence should you gather before you apply?
- Tester list with opt-in dates, so you know who completed 14 days.
- Usage per tester: days active, sessions, minutes, if you measure them.
- Feedback log: Google's tip is to "Maintain a record of received feedback", because you must summarize it when applying.
- Changelog of the builds you shipped to the closed track, each with the feedback it answers.
- Reviewer access: if your app needs sign-in, Google asks for valid, working login credentials in Play Console.
Collecting usage numbers is the hard part with testers you do not see. TestBuddy's production access report gathers them from its SDK rather than from what testers declare: testers, the days with 12 or more active testers, sessions, minutes, the share of expected tester days completed, and the ratings and written feedback collected at day 3 and day 10.
What leads Google to ask for more testing?
Google names two reasons in its testing requirements article: "having fewer than 12 opted-in testers or insufficient tester engagement during the testing period". It does not publish thresholds. These mistakes point toward the second reason, or simply make your test hard to believe:
- Answers without numbers. "Testers liked the app" tells the reviewer nothing.
- Claiming every feature was used when some cannot be reached in a test build, such as a paywall or a sign-up limited to one country.
- Saying usage matched production exactly. Twelve testers recruited for a test rarely behave like your future users.
- Only praise in the feedback summary, or no feedback at all.
- "No changes needed" in the readiness section. It reads as a test that taught you nothing.
- Numbers that contradict each other, such as more daily users than opted-in testers.
- Templates pasted as is, including the ones on this page. They are a structure, not an answer.
- Known crashes or policy gaps. Google writes that "review is not a troubleshooting step" and that submitting non-compliant apps leads to rejections and delays.
If Google does ask for more testing, keep the closed test running and fix the reason before you apply again. Our guide on production access refusals goes through it.