How to Answer Google Play's Production Access Questionnaire (With Examples)
A field-by-field breakdown of the form Google Play shows after closed testing, with guidance on what makes an answer convincing versus generic.
Key takeaways
- The questionnaire appears once your 14-day closed test is complete and asks how you recruited testers, what feedback you got, and how the app changed as a result.
- Generic, copy-pasted answers are the most common reason developers get sent back to testing instead of approved.
- Answers need to be internally consistent — install estimates, audience description, and the changes you list should all describe the same app.
- This form summarizes a real process; it works best when you actually made changes during testing and can describe them specifically.
Why this form exists
It exists for the same reason the 14-day, 12-tester minimum exists in the first place: Google wants evidence that testing was genuine, not a checkbox exercise run purely to unlock production access. See our companion piece on the closed testing requirement for the full policy background.
Field-by-field guidance
- How testers were recruited — describe the real channel (personal network, a paid testing service, a community group), not a vague "various sources."
- How easy recruiting was — a short, honest answer is fine; this field is mostly a sanity check.
- Tester engagement — mention specific behavior: what they used most, what confused them, what they asked for.
- Feedback summary — describe two or three concrete pieces of feedback and how you collected them (survey, direct messages, in-app reports).
- Intended audience — be specific about who the app is for, matching your store listing's actual positioning.
- Value proposition — one or two sentences on the real problem the app solves for that audience.
- Install estimate — a number that roughly matches your app's category and marketing plan, not an arbitrarily large figure.
- Changes made during testing — the strongest field: list actual fixes or adjustments, however small, rather than "no major issues found."
- Readiness justification — tie it back to the changes above: what you fixed, and why the app is stable now as a result.
A worked example
Our Tester Service page includes a full, real sample answer set for every field above, plus a prompt generator that drafts tailored answers for your specific app — useful as a starting point to adapt rather than to copy verbatim, since Google can tell when an answer is generic.
After you submit
Google reviews the testing history summarized in this form. Passing that check moves you to the separate public-release review, which checks broader policy compliance for the app itself — a distinct, often stricter, stage that this questionnaire doesn't cover.