Production Questionnaire
The production access questionnaire, question by question
After your 14 days, Google doesn't just check a counter and wave you through. You fill in a short written questionnaire, and those answers are part of how the decision gets made. Below are the actual sections and questions, taken from a real completed application, along with what each one is really testing and how to build a truthful answer from the cycle you ran.
Section A — About your closed test
"How did you recruit users for your closed test?"
Asked as: for example, did you ask your friends and family, or use a paid testing provider? Answer plainly and specifically. Naming the channels you actually used — personal contacts, developer communities, a testing provider — reads better than a vague sentence designed to sound impressive.
"How easy was it to recruit testers for your app?"
A five-option scale: very difficult, difficult, neither difficult nor easy, easy, very easy. There is no right answer and no advantage to claiming it was easy. Pick the one that matches your experience.
"Provide a summary of the feedback that you received, including how you collected it"
This is the question that separates a real cycle from a countdown, and note the second half — how you collected it. Structured surveys, direct messages, a shared sheet, a QA report: say which. Then summarise what testers actually said, including the unflattering parts. "All positive, no issues" from twelve people is a weaker answer than three concrete problems you found and handled.
Section B — About your app
"Who is the intended audience of your app?"
A specific description of the people the app is for. Broad claims like "everyone" tell the reviewer nothing and quietly undercut the rest of your answers.
"Describe how your app provides value to users"
What the user gets and why they would keep it installed. Write it the way you would explain it to a person, not the way you would write store-listing copy.
"How many installs do you expect?"
An honest estimate. There is nothing to gain from inflating it.
Section C — Your production readiness
"What changes did you make to your app based on what you learned during your closed test?"
The hardest question to answer well if the cycle was a formality. You want at least one concrete change traceable to tester feedback. If genuinely nothing needed changing, say so — but back it with what was tested and how you verified it, rather than leaving the answer empty. A blank "no bugs, no feedback" story is the weak one.
"How did you decide that your app is ready for production?"
Your evidence for stability and completeness: which devices and Android versions it ran on, which core flows were exercised, what the outcome was. This is where a device coverage table and completed test sheets do the work for you.
How to build answers you can actually defend
Write the answers during the cycle
Not after. Keep a running note of feedback as it arrives, with device and OS. Reconstructing it on day 15 is where vagueness comes from.
Name your collection method
Survey, direct messages, structured QA report. The question explicitly asks how you collected feedback, and most people answer only what they collected.
Keep one fix you can point to
Even a small one. It converts "we tested" into "testing changed the product", which is the entire point of the gate.
Be specific, not impressive
Concrete detail from a modest cycle beats polished language describing nothing.
Related: what a completed cycle should produce (including the drafted questionnaire section), what to do if production access is refused, and the 12 testers requirement explained.
Nothing to write in the feedback section?
We run the cycle so the answers write themselves.
Real testers with tasks, feedback collected in writing, and a QA report with the questionnaire section drafted from your cycle's actual findings. Plans from $180, worldwide.
Start your testing cycle