How to Answer Google Play's Production Access Questions (With Examples)
After your 14-day closed test, Google asks about your testers, your feedback and your app. Here's what each question is really asking, with example answers you can adapt.
3
Sections in the form
8
Questions to answer
Specific
Beats long
Before you start
The form unlocks in Play Console once your closed test has had 12 or more testers opted in for 14 days in a row. If you're not there yet, see how to get 12 testers for Google Play's closed test.
Gather these first. It makes every answer easier:
- How many testers you had, and how you found them
- Every bug report and suggestion testers sent, and where (email, form, chat)
- The versions you released during the test and what each one changed
- Devices and Android versions your testers used, if you know them
Part 1: About your closed test
How easy was it to recruit testers for your app?
What Google wants to know: how you found people, and whether it was a real test rather than a box to tick.
| Weak | Stronger |
|---|---|
| "It was easy." | "We recruited 15 testers: 6 from our newsletter, 4 friends who use budgeting apps, and 5 through a managed testing service so we'd have a buffer above 12. Keeping everyone opted in for 14 days was the harder part, so we checked the count every few days." |
Describe the engagement you received from testers during your closed test
What Google wants to know: did testers actually use the app, or just opt in?
| Weak | Stronger |
|---|---|
| "Testers used the app a lot." | "Most testers opened the app several times a week. We asked them to try a different flow each few days (sign-up, adding expenses, exporting a report) and 11 of 15 sent at least one piece of feedback." |
Provide a summary of the feedback you received, and how you collected it
What Google wants to know: that you listened. Group the feedback and say how it reached you. (Not much feedback yet? Here's how to get useful feedback from testers.)
| Weak | Stronger |
|---|---|
| "Positive feedback, no issues." | "We collected feedback through a Google Form and a shared chat. We got 23 reports: 4 crashes (all on Android 11 when offline), 9 UX notes (the main one: people couldn't find the export button) and 10 suggestions, such as a dark theme." |
Part 2: About your app
Who is the intended audience of your app?
Be concrete: who they are and what they need. "Freelancers in Bangladesh who want to track income in BDT and USD" is better than "everyone".
Describe how your app provides value to users
One or two sentences on the problem and how your app solves it. Avoid marketing language. Describe what the app does.
"Freelancers paid in different currencies struggle to see their real monthly income. The app converts every payment to one currency and shows monthly totals, so they can plan taxes and savings."
How many installs do you expect your app to have in your first year?
Pick an honest range. There's no prize for a big number. A realistic estimate shows you understand your audience.
Part 3: Your production readiness
What changes did you make to your app based on what you learned during your closed test?
This is the question that matters most. It's where you prove the test was useful. List real changes and tie each one to feedback.
| Weak | Stronger |
|---|---|
| "We improved the app." | "Fixed the offline crash on Android 11 (v1.0.2). Moved the export button to the main screen after testers couldn't find it (v1.0.3). Shortened sign-up from 4 steps to 2. We noted dark theme for a later release." |
How did you decide that your app is ready for production?
Explain your bar for "ready", with evidence.
"No crashes reported for the last 7 days of the test, and Android vitals show no ANRs. Every bug testers reported is fixed. Testers completed the main flows (sign-up, adding expenses, exporting) on 14 different devices without problems."
Common mistakes
- Copy-pasting the same text into every question. Each one asks something different.
- Claiming things that didn't happen. Inflated tester counts or invented feedback don't help.
- Leaving out the changes. If you fixed nothing, Google may decide the app needs more testing.
- Writing an essay. A few clear, specific sentences per question is enough.
If your application was already turned down, see why production access gets rejected and how to fix it.
FAQ
How long should my answers be?
A few specific sentences per question is usually enough. Clear facts like numbers, bugs, versions and changes matter more than length.
Is it bad to say testers found bugs?
No. Finding and fixing bugs is the point of a closed test. Saying you found nothing usually looks less convincing than explaining what broke and how you fixed it.
Can I reuse an example answer from this guide?
Use them as a pattern, not a copy. Your answers should describe your own test, your own testers and your own changes.
What if I made no changes during the test?
Then you probably need to keep testing. Ship at least one update that fixes what testers reported before you apply. It gives you something concrete to write in the most important question.
Talk to a human, not a bot
Stuck on setup, Google's rules or your app? Message us and a real person from our team answers.
- Avg. reply under 5 minutes
- Any day of the week
Keep reading
- Closed vs Internal vs Open Testing on Google Play: What's the Difference?Google Play has three testing tracks. Here's who each one is for, how testers join, and which one counts for the 12-tester requirement on new personal accounts.
- Free vs Paid Google Play Testers: An Honest ComparisonFriends, tester exchanges, freelancers or a managed service? What each way of getting 12 Google Play testers really costs in money, time and risk.