Google Play Production Access Questionnaire Answers (2026): All 10 Questions & Sample Answers
Every question Google asks before unlocking production, with worked sample answers, evidence checklists, and the exact recovery steps if you get a "more testing required" denial.
Prepare answers from your own recruitment, testing, feedback, changes, and readiness records. Use the examples below as drafting frameworks, replace every factual detail, and follow the wording and character limit shown in your own Play Console form. Never submit an answer that still describes someone else's app.
You made it past the 14-day closed-testing wall. Now comes the form that trips up more developers than the testing itself: the Google Play production access questionnaire.
Vague answers like "testers loved it" or "no bugs found" are the fastest route to a "more testing required" rejection — and another two weeks of chasing testers. This guide walks every field, shows a worked draft, and covers what to write when your evidence is thin, qualitative, or produced no code change at all.
1. What Is the Production Access Questionnaire?
When your closed test meets the criteria, Play Console shows "Apply for access to production" on your app dashboard. That panel lists the criteria you still have to meet and carries a Preview questions link, so you can read the form before you start. Google asks in three sections:
Google describes the purpose of the closed-test section as confirming that apps are satisfactorily tested before publication. Section 2 is the lightest part: Google states those answers are not shown on Google Play and do not affect access to Play Console features.
What Google publishes about the review
- Review usually takes 7 days or less, and may take longer.
- You may be asked to continue testing if you do not have 12 eligible testers, or if testers were not engaged with the app.
- Section 2 answers are not published and do not affect feature access.
- Leaving the form without working through it can discard unsaved answers: use Next between sections and Apply at the end.
How many questions are there, really?
This page covers nine questions from the initial application, plus one reapplication question reported by developers who were asked to continue testing. Google publishes no fixed list, and reported wording, field types, and which questions appear differ between accounts. Follow your own form.
Note on answer length. Every example here is under 300 characters and shows its own count. Some developers report a limit near that figure, but no universal current limit could be verified, so your own form's counter is the authority.
2. What Evidence Should You Prepare First?
Do this once and the form stops being a writing problem. Gather these three things before you open it. Everything on this page is assembled from them.
2.1 Facts to reconcile
The figures you will be asked about, taken from Play Console eligibility information and from your own records, so that the two agree with what you write.
- How many testers were opted in, and on which dates.
- Whether the opt-in ran continuously for the last 14 days, with no break.
- Which release each tester ended the test on.
Uninstalling is not leaving
A tester who deletes the app is still opted in. Leaving is deliberate, from the test link or the app's beta section in the Play Store. So an install count proves neither that testing happened nor that it stopped.
2.2 What testers actually did
Activities, not adjectives. Write down the flows they completed and how you know.
- Which core flows were exercised: sign-up, the main task, sharing, settings, payment.
- Roughly how often the app was opened, and over what period.
- Where people got stuck, and on which devices or Android versions if you know.
Label the source of each claim. A count based on tester reports is a different thing from a count recorded by analytics, even when both are written as numbers. Either is usable; say which one you have.
2.3 Feedback, the change, and the check
Google points developers at the Play Console testing feedback page and recommends keeping a record. One row per finding is enough:
- Where the feedback arrived (Play Console feedback, in-app form, chat, email).
- What you released in response, and in which version.
- How you confirmed it worked, and which findings are still open.
2.4 A record that answers four of the nine questions
Three columns is all it takes. The rows below belong to the fictional app introduced in the next section; yours will look nothing like them, which is the point.
| What the test found | What was released | How it was verified |
|---|---|---|
| Shift reminders did not fire after a roster was edited. | Version 1.4.1: reminder rescheduling corrected after roster edits. | Both testers who reported it confirmed reminders arrived on the next two shifts. |
| Publishing a roster failed on slow connections and lost the draft. | Version 1.4.2: the draft is kept locally and retried until the publish succeeds. | Retested on a throttled connection before and after; the draft survived. |
| The week view was cramped on small screens. | Not released. Scheduled for after launch. | Open. Named as an open item in the readiness answer rather than claimed as fixed. |
2.5 What if you do not have detailed analytics?
If you did not collect session analytics, you can still answer every question. What you cannot do is turn an impression into a measurement. Say what you know and label how you know it. "Ten of twelve testers told me they built at least one roster; I had no session analytics" is usable and checkable. An invented average session length is not.
3. How to Use These Answer Examples
Every fact in every example below is invented
They all describe one fictional app, so you can see how a single test record turns into nine consistent answers. None of them is a submission-ready answer for your app, and none of them becomes one by being shortened.
Replace every name, number, date, feature, and finding with your own before you use any of this. An answer that still says "Shiftly", or still claims twelve testers over fourteen days when that is not what happened, describes someone else's test.
Fictional example used throughout this page: Shiftly
A shift-planning app for small shops and cafes. Not a client, not a case study, and no outcome is claimed for it.
- Closed test: 12 testers, 14 continuous days
- Core flows: Sign up, build a weekly roster, invite a coworker, publish, receive a shift reminder
- Releases in the test: 1.4.1 and 1.4.2
- Open item: Cramped week view on small screens
4. Part 1: About Your Closed Test (Q1–Q4)
This section asks you to describe recruitment, activity, and feedback. Keep your answers consistent with the eligibility information in Play Console and with your own testing records.
How did you recruit users for your closed test?
Google asks where your testers came from. Name the source you actually used and say who ran the test. Diversity is sensible practice, not a rule against a single source, so an honest one channel beats an invented list.
- The channel or channels you genuinely used.
- Who the testers are in relation to your app's audience.
- Who set the scenarios, read the feedback, and released the changes.
276 characters in this example
"I found testers online." — It names no channel, no relationship to your audience, and nobody who ran the test.
Alternative variants: if you used a paid testing service, name the source then say who set the scenarios, read the feedback, made the changes, and verified them. If all testers came from one channel, say which one and how that channel relates to your users.
How easy was it to recruit testers?
A scale from very difficult to very easy. Choose the option that matches your experience. No published guidance names a preferred option.
- Very difficult — You could not reach 12, and the test slipped or stalled.
- Difficult — It took repeated asking, or several attempts over a long stretch.
- Neither — It took some effort and roughly the time you expected.
- Easy — One or two asks filled the list.
- Very easy — You had more volunteers than places.
No option here is recommended. The wording and the number of choices can differ from what is shown above; read your own form.
Describe the engagement you received from testers
Google's own examples here are about feature usage and whether it resembles real production use. "Highly engaged" names nothing anyone can picture. Give the flows, the period, the pattern, and where your figures come from.
- How many testers, over what period.
- Two to four flows they actually completed, by name.
- The usage pattern, and where the figures come from.
294 characters in this example
248 characters in this example
"Testers were active and used the app." — No count, no period, no named flow, and no source for any of it.
Provide a summary of the feedback you received
Google asks both what the feedback was and how you collected it. Give the channel, the themes that genuinely came up, and what you did about each, including what is not done.
- Where the feedback arrived.
- The themes that actually came up, however many that is.
- Which ones you have released, and which are still open.
288 characters in this example
"Feedback was positive." — It gives no channel, no theme and no response, which is all three things the field asks for.
5. Part 2: About Your App or Game (Q5–Q7)
Google states these answers are not shown on Google Play and do not affect your access to Play Console features. Write them plainly. This is not store copy, and there is nothing to be gained by selling here.
Who is the intended audience for your app?
Google asks you to be specific. "Everyone" describes no one. Cover who they are, what problem they have, and when they reach for the app.
- Who they are: role, situation, or age range if it is genuinely relevant.
- The problem they have before your app exists.
- When and how often they use it.
237 characters in this example
"Everyone." — It names no user, no problem and no occasion, and it is almost never true.
Describe how your app provides value to users
Lead with the outcome, then name the two or three features that deliver it. For a game, the value is the experience: the loop, what makes it distinctive, how long a session runs and why anyone comes back.
- The outcome, in one sentence, before any feature list.
- Two or three features that produce that outcome.
- For a game: the loop, the distinctive element, the session length.
168 characters in this example
211 characters in this example
"My app is useful and has good features." — No outcome, no feature and no user, in a field Google does not publish anyway.
How many installs do you expect in the first year?
Google says a rough estimate is fine and the ranges are deliberately wide. Select the range supported by your own audience and launch estimate. No published guidance names a preferred range.
- 0 – 10k
- 10k – 100k
- 100k – 1M
- 1M+
- I do not know — A real option, and more defensible than a number you invented.
No option here is recommended. Range labels and wording vary; read your own form.
6. Part 3: Production Readiness (Q8–Q9)
This section asks what the test produced and why you decided to ship. Both answers should read as conclusions drawn from the record you built earlier.
What changes did you make based on your closed test?
Describe the changes you actually made and how you checked them. The published guidance sets out no scoring formula for this field and no minimum number of updates. Keep completed and planned work apart.
- What the test found, in your own words.
- What you released in response, with a version if you have one.
- How you checked it, and what is still open.
283 characters in this example
293 characters in this example
"We improved the app." — It names no finding, no release and no check, so it cannot be reconciled with your feedback answer.
What if you made no changes?
The guidance prescribes no number of updates, and an unchanged app is not automatically a weak application. What makes an answer weak is unexplained testing. Use the No changes released draft above: which flows and conditions were checked, what the results were and where they came from, and what is unresolved. Do not invent a defect to have a fix to report.
How did you decide your app is ready for production?
Google is asking for your decision criteria, not your confidence. Name the two or three things you looked at and the evidence behind each. Everything here should already appear earlier on the form.
- The criteria you used, stated as criteria.
- The evidence behind each one.
- The open items, and why they do not block the release.
230 characters in this example
"I felt the app was ready." — A feeling is not a criterion, so there is nothing here to agree or disagree with.
7. Common Answering Mistakes That Guarantee Rejection
None of these is a rule that Google publishes. They are the patterns that make an answer communicate less than the developer who wrote it intended.
"Highly engaged", "very positive", "thoroughly tested". Each occupies space in a short field without naming a flow, a count, or a period.
"No issues were found" in one field and "I fixed several bugs" in the next. Both cannot be true, and a reader has no way to tell which one is.
If you report feedback, say where it arrived: Play Console testing feedback, an in-app form, a chat group, email. Without it the summary is unsourced.
A pasted example that still describes someone else's app, audience, or bug is not a description of your test. Every template shares this failure mode, including the ones here.
A percentage invented to look rigorous is a claim you cannot support. A count from tester reports is perfectly usable; just say that is what it is.
Say which fixes shipped and which are scheduled. Presenting a plan as a release is contradicted by your own version history.
Picking the strongest-sounding option rather than the one that happened puts your dropdown at odds with your free text.
8. Pre-Submission Checklist: Check Your Answers Before You Submit
The form is read as one document. Most of what makes it weak is not a bad sentence but two sentences that disagree. Run this pass with all nine answers side by side.
Nothing on this checklist predicts a decision. It is the pass that stops your form from arguing with itself.
9. What Happens After You Apply?
Four outcomes are worth telling apart, because two of them are routinely mistaken for each other.
Google states that review usually takes 7 days or less, and may take longer. A long wait on its own is not a reason to resubmit or restart the test.
Access and a live app are separate things. You still have to prepare and roll out a production release, which carries its own review.
A decision about your test, not only about your wording. Full recovery guidance below.
If your app is behind a login, the reviewer needs working credentials. No answer on the questionnaire can substitute for access.
10. If Google Asks You to Continue Testing
Do not resubmit the same form, and do not assume the problem was your writing. Work through it in this order.
The notification usually names a reason: fewer than 12 eligible testers, an opt-in that broke during the 14 days, or testers who were not engaged.
If you were short of testers, or an opt-in lapsed, get back to 12 eligible testers with an unbroken recent history before reapplying. Rewriting answers over an unchanged tester record does not change the eligibility information.
Update the facts that changed, and clarify any answer that was incomplete or ambiguous. What rewording cannot do is fix an underlying testing problem.
Google requires the most recent 14 consecutive days to have eligible testers, so never apply while short of 12. Some denial messages name an additional period and others name none: Google publishes no universal reapplication interval.
What did you do differently this time?
Reported by developers reapplying after being asked to continue testing. Reported wording varies, and not every account reports seeing it.
Name what is different in the record, not what is different in your attitude. If the second test matched the first, that is what to fix before reapplying.
- What changed about the test itself.
- What that produced: findings, releases, confirmations.
- How the current evidence addresses the earlier decision.
252 characters in this example
"This time I focused on gathering and implementing feedback." — It describes an intention rather than a difference, which is the only thing this field asks about.
11. Frequently Asked Questions
It is the mandatory form you complete when applying for production access after a closed test. It covers three areas: the test you ran, your app or game, and your production readiness. You reach it from "Apply for access to production" on your Play Console app dashboard.
There are typically 10 questions: 8 free-text and 2 multiple-choice. The first 9 appear on the initial application. A 10th question about what you did differently only appears when reapplying after a "more testing required" denial.
As a framework, yes. As text to submit, no. Every fact in the examples belongs to a fictional app, so an answer that keeps those facts describes someone else's test. Replace every name, number, feature, and finding with your own before submitting.
Every example in this guide is under 300 characters. Some developers report a limit near that figure, but no universal current limit could be verified. Your own form's character counter is the authority.
If you did not collect session analytics, report what you know and label how you know it. "Ten of twelve testers told me they completed sign-up" is usable. An invented average session length is not.
The guidance prescribes no number of updates, and an unchanged app is not automatically a weak application. What makes an answer weak is unexplained testing. Say which flows and conditions were checked, what the results were and where they came from, and what is unresolved.
Answer truthfully. No published guidance suggests naming a provider affects the outcome, and inventing a list of channels you did not use is the bigger risk. Name the source, then say who set the scenarios, read the feedback, made the changes, and verified them.
Google states it usually takes 7 days or less and may take longer. A review still in progress is not a rejection. Monitor Play Console and your account email, and respond to anything Google asks for.
Read the message you received: some name a specific additional period and some do not, and Google publishes no universal reapplication interval. In every case, the most recent 14 consecutive days need at least 12 eligible testers. Never reapply while short of 12.
No. Once production access is granted, the 12-tester requirement is fulfilled for that app. You can safely remove testers from the closed track. However, keeping a closed testing track active is recommended for safely testing future updates.
12. Bottom Line
Write each answer from your own record: who tested, what they did, what they reported, what you released, and how you checked it. Replace every invented detail on this page, choose the dropdown options that match your circumstances, follow the wording and counter your own form shows, and read the answers together so they agree.
If the record is the missing piece — if you cannot find 12 people who will stay opted in for 14 unbroken days — that is the part we solve. Compare our closed-testing plans and get the evidence you need to answer the form with confidence.
Authored by our Lead QA Analyst
With over 10,000+ apps successfully pushed to production, our team tracks every Google Play policy update to bring you accurate, tested advice. Need help launching your app? Start a testing campaign today.