Google Play Production Access Form: All Questions, Quoted

What is the Google Play production access form?

The short answer: it is a three-section questionnaire that opens from the Dashboard button Apply for production, and it is the last thing between your closed test and a public app. Google describes the gate on its App testing requirements for new personal developer accounts help page: "Developers with personal accounts created after November 13, 2023, must run a closed test for their app with a minimum of 12 testers who have been opted in continuously for at least 14 days. When you meet these criteria, you can apply for production access on the Dashboard in Play Console to distribute your app on Google Play."

That is the whole official description of the form's structure: three sections, three subjects, no published question list. This page gives you every prompt Google does publish, the question wording developers report seeing in their own accounts, and the specific places applications come apart. It applies to personal accounts created after 13 November 2023; organisation accounts and older personal accounts reach production by a different route, which our closed testing requirements page sets out.

What does Google publish about the form — and what does it not?

The verifiable position, dated. We fetched that help page in full on 3 October 2026 — 17,589 characters of rendered text — and read the applying-for-production-access section line by line. Google documents the form as a sequence of steps under three headings, in its own words:

What that same fetched text does not contain: the word "character" (0 occurrences), the phrase "Preview questions" (0), and any numbered list of questions. So Google publishes the prompts and their order, but no canonical "question 1 to question 10" list, no answer-length limit, and no sample answers. Anything beyond the steps below is reported by developers reading their own forms — which is why guides disagree on the count, and why your own Console is the only authority that matters.

What questions are on the production access form?

Google's steps translate into eight documented prompts across the three parts. Developers who have submitted report up to ten, because their forms also ask how testers were recruited and — only after a "continue testing" outcome — what changed since the last attempt. The reported wording, collected from two independent published walkthroughs, is:

1. "How did you recruit users for your closed test?"
2. "How easy was it to recruit testers for your app?"
3. "Describe the engagement you received from testers"
4. "Provide a summary of the feedback that you received"
5. "Who is the intended audience for your app?"
6. "Describe how your app provides value to the users"
7. "How many installs do you expect in your first year?"
8. "What changes did you make based on your closed test?"
9. "How did you decide that your app is ready for production?"
10. "What did you do differently this time?" — conditional, reported only by developers reapplying after being asked to continue testing

Why the counts differ. One walkthrough covers 10 questions, another covers 9 plus the conditional reapplication question, and Google documents 8 prompts. The gap is bookkeeping, not policy: Google groups recruitment-difficulty and engagement under Part 1 steps, splits feedback into "summarize" and "describe how feedback was collected", and never counts the conditional question at all. Reported wording and field types also differ between accounts. Read your own form — where the Preview questions link described below appears, it lets you do that before you commit to anything.

Which production access questions are multiple choice?

Two of them, and both are confirmed by Google's own step wording even though Google never publishes the option list:

• Recruitment difficulty. Google's Part 1 step one is "Select an option indicating how easy it was to recruit testers" — a selection, not a paragraph. Developers report five options running from Very Difficult to Very Easy.
• Expected first-year installs. Google's Part 2 step three is "Select an estimated install range for your app or game during its first year". Reported choices are ranges, with examples such as 1k to 10k.

Everything else in the reported form is free text. The practical rule for the two selections: pick the honest, conservative option and keep it consistent with what you write elsewhere. "Very Easy" next to a written answer describing a two-week hunt for testers is the kind of mismatch a reviewer sees in one glance.

How long can your production access answers be?

Google publishes no character limit. The word does not appear on the help page that governs the application. Developers report a counter near 300 characters on their forms, and the two published walkthroughs disagree about what to do with it: one keeps every example under 300, the other advises 250-400 characters per text field. Neither claims a verified universal figure, and no published evidence links answer length to the outcome.

So treat the counter in your own form as the only limit, and treat length as a symptom rather than a target. An answer that names three testers' devices, two bugs and one shipped version fits in 300 characters. Testers liked the app, no issues found fits in 40 and fails for the same reason it would fail at any length: it contains nothing a reviewer can check. See the last section of our production access rejection guide for what vague answers lead to.

How do you read the form before you apply?

The Apply for access to production panel on your app Dashboard lists the criteria still unmet, shows a live counter of how many days your testers have continuously been opted in (screenshots show readings such as "12 days continuously"), and — according to a published walkthrough of that panel with screenshots — carries a Preview questions link that opens the form for reading while the Apply button is still greyed out. Google's help page does not mention that link, so treat it as a Console feature that may move or be renamed, and check your own account rather than assuming it.

Reading it before day 14 changes what you record during the test. From day one, keep five things:

• The channel each tester came from — this answers the recruitment question factually instead of impressionistically
• Which features testers actually opened, and which they never touched
• Where feedback landed and how it arrived (email, messaging group, Play Console private feedback)
• Every build you ship during the window, with what it fixed
• Your reason for believing the app is ready — crash-free runs, checklist items, policy sign-off

What does Part 1 ask about your closed test?

Google states the purpose plainly: "Information provided in the 'About your closed test' section helps verify that apps have been thoroughly tested before publication on Google Play. This process protects users from low-quality apps, prevents malware distribution, and reduces fraud." Then the steps:

Three prompts, and the middle one is the hardest to answer honestly if nothing happened during the window. It asks for feature coverage and a comparison against how production users would behave, including differences — so everyone installed it is not an answer, and a difference you observed (say, testers skipped onboarding because you gave them login details) is exactly the kind of detail that reads as real. The third prompt is two obligations: the summary, and the collection method. Feedback arrived over WhatsApp is a collection method; a crash in settings on a Galaxy A54, reported by two testers is a summary. You need both, which is why a feedback channel should be running from day one, not reconstructed on day 14.

What does Part 2 ask about your app or game?

Google describes Part 2 as context rather than evidence — and says so in a sentence worth reading twice, because it tells you where the stakes are not: "Your answers are not displayed publicly on Google Play and do not affect app visibility, Play Console feature access, or eligibility for developer programs."

"Be as specific as possible" is the only instruction Google gives here, and it is doing work. Anyone who needs a to-do list is not a target audience; shift workers in Bangladesh and the Philippines who need reminder lists that work offline is one. The install-range selection should be consistent with the audience you just described — an app for a narrow professional niche selecting the highest range on the list is an internal contradiction in the same section.

What does Part 3 ask about production readiness?

The last section is two prompts and the button:

The relationship between Part 1 and Part 3 is the single most useful thing to understand about the form: the two answers are read together. If your feedback summary lists three recurring problems, your changes answer should describe three fixes, with version numbers if you shipped them. If Part 1 says feedback was rich and Part 3 says nothing needed to change, the reviewer is looking at a test that produced information nobody acted on — which is the same gap Google names in its rejection language about "gathering and acting on user feedback through updates to your app".

The second prompt has an equally concrete answer: readiness is a decision with stated grounds. Crash-free sessions you observed, the pre-launch report cleared, every core flow exercised, policy and data safety forms complete, working sign-in credentials supplied for review. Google's pre-application checklist in the same help page lists those items for exactly this reason.

Why do production access applications get sent back?

Google names the causes itself, in the same help page: "If your app requires additional testing, you may need to continue running your closed test. Reasons for required continued testing include having fewer than 12 opted-in testers or insufficient tester engagement during the testing period."

• Headcount at the moment you apply. "At least 12 testers must be opted in to your closed test when you apply for production access, and they must have been opted in continuously for the preceding 14 days." Invited is not opted in — a full tester list can still read 0 opted in.
• Engagement across the window. This is the Part 1 question showing up later. If you cannot describe feature coverage, behaviour differences and feedback, the answer was never there to write.
• Answers that do not reconcile. Rich feedback plus no changes, an "easy" recruitment selection plus a written account of a hard hunt, an install range contradicted by your audience description.
• Applying before the criteria clear. The Apply button can be visible while requirements are still open; the counter, not the button, is the test. Whether a lapsed streak costs you the window is covered in does dropping below 12 testers reset your clock.

A separate, different failure is the app itself: policy, broken flows, missing sign-in credentials. Google warns that "Submitting non-compliant apps expecting reviewers to identify issues leads to rejections, review delays, and lengthier appeal processes." Different cause, different fix — our rejection guide separates the two outcomes and the email each one produces.

What happens after you submit the production access form?

Three outcomes follow. Approved: the Production page and Open testing unlock and you publish. Asked to continue testing: keep the closed test running — Google's stated remedy is more testing, not an appeal — and fix whichever of the causes above applies. Still deciding: wait for the email; Google does not publish an interval shorter than its own seven-day framing.

One deadline to keep separate from all of this: the Play Console Requirements registration rule that took effect 30 September 2026 concerns registering app packages so distribution continues, not the closed test. Both can block a release, on different parts of the path, so check them as two checkpoints rather than one.

FAQ: Google Play production access form questions

How many questions does the production access form have? Google publishes no number — its help page describes three sections and eight prompts, with no numbered list. Developers report 9 or 10 questions, depending on whether they were asked the conditional reapplication question. Where your panel shows a Preview questions link, read your own form before you start writing.

Does Google publish sample answers? No. Nothing in Google's documentation provides model wording, a recommended length, or a scoring rubric. Every sample answer you find online — including on this page — is somebody's draft built from their own test record.

Is there a character limit? None is published by Google. Developers report a counter near 300 characters. The counter shown in your form is the limit that applies to you.

Are my Part 2 answers public? No. Google states they "are not displayed publicly on Google Play and do not affect app visibility, Play Console feature access, or eligibility for developer programs."

Will my answers be read by a reviewer? Google's framing is that you "answer questions to help clarify your app design, testing process, and production readiness", and Part 1 exists to "verify that apps have been thoroughly tested before publication". Specific, checkable detail is what that wording rewards.

Can I edit answers after submitting? Google documents no edit step. Its warnings are about losing work before submission — leaving a section without clicking Next discards it — so finish each section before moving on.

Do I have to keep the closed test running while the review happens? Google's instruction when an application needs more testing is to "continue running your closed test", and stopping it works against the exact thing that was questioned.

Does a testing service fill in the form for me? No service can grant production access — Google does that after its own review. What a campaign controls is the material the form asks for: testers opted in and active for the full window, plus a written feedback record you can summarize. See how a campaign runs and plans from $14.99 per app.

Build the record before day 14

The form is not a writing test; it is a reading test of the two weeks you already ran. Everything it asks — recruitment, engagement, feedback summary, changes, readiness — either exists in your notes by day 14 or does not exist at all, and no amount of drafting recovers a window in which nothing was recorded.

GetClosedTesting runs the campaign with daily engagement monitoring, replaces inactive testers while the window is still open, and hands you the bug reports and feedback notes Part 1 requires you to summarize — so the answers are assembled from a record rather than invented at submission. Google grants production access after reviewing your application; the record is what makes your application answerable. Start with the production access guide for the whole path from 12 testers to a published app.