The Google Play Production Access Questionnaire: What They Ask and What Google Actually Wants to See
You ran the 12 testers for 14 days. The Play Console showed your timer completing. You clicked "Apply for production access" — and Google rejected you. The reason given was vague. "Your app requires more testing." But you did the testing. What went wrong?
In almost every case like this, the answer is the Production Access Questionnaire — the 10-question form Google presents after your testing period ends. Most developers do not know it exists until they hit it. Fewer know what answers Google is actually evaluating.
This article breaks down the questionnaire, what each question is probing for, and how to prepare during your 14-day testing window so your answers pass review.
Why the questionnaire exists
Google introduced closed testing requirements to reduce low-quality apps reaching production. The 14-day period forces a delay, but a delay alone does not prove quality. The questionnaire is Google's way of verifying that actual testing happened — not just 12 accounts sitting dormant on an APK.
Google reviewers are looking for evidence of a genuine feedback loop: testers found issues, you received that feedback, you made changes.
The questions (summarized from developer community reports)
The exact wording changes, but the questionnaire consistently covers these areas:
1. How many testers participated and how did you recruit them?
Google wants to see a real answer here — not "I found them online." If you used a community, a service, or your personal network, say so clearly. Vague answers like "I got 12 testers" without any context raise flags.
2. How did testers interact with your app?
Describe specific interactions. "Testers navigated through onboarding, tested the core [feature name] flow, and used the settings screen" is what a passing answer looks like. "They used it normally" is what a rejected answer looks like.
3. What feedback did you receive?
This is the highest-stakes question. You need specific, actionable feedback — not a summary of praise. Passing answers document real observations:
- "Three testers reported the login button was unresponsive on Android 12 devices"
- "One tester found the settings screen text was cut off on smaller display sizes"
- "Testers on older Android versions reported a crash on the profile page"
If your testing ran for 14 days and you received zero negative feedback, Google will not believe you. Build a feedback mechanism into your test — a simple Google Form linked in your tester email works.
4. What changes did you make based on tester feedback?
Even minor changes count: fixing a layout issue, adjusting button tap targets, updating copy based on tester confusion. What Google cannot accept is "No changes were needed." The entire point of the testing requirement is that developers find and fix issues before hitting production.
5. Did you test on multiple device types and Android versions?
Yes is the expected answer. If all 12 of your testers were on the same device model, flag that proactively and explain why (e.g., your app targets a specific device category). Homogeneous testing is not automatically a rejection, but unexplained homogeneous testing looks suspicious.
6. Were there any crashes or ANRs?
The Pre-Launch Report in Play Console will have already recorded these. Google knows the answer before you answer. If there were crashes, describe what caused them and what you fixed. If you say "no crashes" and the Pre-Launch Report shows crashes, you will be rejected for providing false information.
7. How would you summarize the overall quality of the testing period?
Write 3–4 sentences. Be specific. "We completed 14 days of closed testing with 16 opted-in testers. Testers provided feedback through a Google Form and direct email. We identified and resolved two layout bugs and one crash on Android 10. The app is stable and ready for production." That is a passing summary.
How to prepare during the 14 days
Start a simple feedback document on Day 1. Every piece of feedback from a tester goes in it — screenshots, emails, form submissions, messages. When the questionnaire asks what feedback you received, you are describing real events from a real document, not constructing a plausible story after the fact.
Send testers a feedback prompt at the halfway point: "We are on Day 7 of testing. Please open the app today and let us know if anything looks broken or confusing on your device." This generates engagement data Google can see and written feedback you can quote.
Document every change you make during and after the testing period, even trivial ones.
The rejection you can avoid
The most common questionnaire rejection is not from developers who did bad testing. It is from developers who did fine testing and then wrote bad summaries — one-liners, vague claims, zero specifics. The 14-day requirement is a hurdle. The questionnaire is the actual gate. Treat it like a written exam, not a checkbox.
Top comments (0)