Google Play Production Access Questionnaire: Prepare a Useful Submission

The Google Play production-access questionnaire is a summary of work that should already have happened during your closed test. It is not a form to complete with generic promises. Before you open it, confirm the requirement shown for your own developer account in Play Console, make sure the correct closed track is live, and collect a concise record of what testers did and what you learned.

Start with a plain description of the app. Explain its intended users and the main actions it supports in factual language. For example, describe the sign-in, checkout, booking, content-creation, or offline flows that people tested. A concise technical explanation is more credible and more useful than a marketing slogan, especially when the app has account access, payments, location, NFC, notifications, or other important device behaviour.

When describing your tester group, use only facts you can support. State how testers were invited, how they joined the closed track, which core flows they were asked to try, and how feedback was collected. Do not claim that every person used every feature every day if that is not true. A useful record includes the opt-in link, the closed-track release, the testing dates, device or Android-version context where relevant, and a summary of actual participation.

The feedback summary should show what a real test revealed. Good entries identify the user flow, the observed issue or friction, its impact, and the action taken. Examples may include a button obscured on a small display, an unclear permission explanation, a slow screen after restoring a connection, or a confusing onboarding step. Do not invent defects simply to make a report sound more substantial. If a build was stable, report the usability feedback and compatibility checks that actually occurred.

Document changes with the same discipline. Name the release version or date, identify the issue that led to the change, and explain the result after retesting. A statement such as “improved performance” has little value by itself. “Reduced unnecessary image loading on the search screen after testers reported slow scrolling on lower-memory devices” tells a reviewer what happened and gives the development team a useful release note.

Keep the production-access submission aligned with Play Console. If you mention a new build, it should appear in your closed-track release history. If you describe a country limitation, device restriction, paid-app test flow, or required hardware, explain how testers were able to access it. If the tester roster changed during the campaign, record the dates accurately and give the replacement enough time to complete the period required for that tester.

Before submitting, review the whole account from a tester’s perspective: the correct Google account can opt in, the app can install in the intended countries, login or test credentials work, required permissions are explained, and feedback is available in a form your team can act on. Google makes the production-access decision independently, so no testing provider can promise approval. A truthful, specific account of a meaningful test is the strongest submission you can make.

12Tests can help with the operational side of a closed test by assigning real Android testers, showing the campaign timeline, and providing reports on the relevant plans. You remain responsible for your app, your Play Console configuration, and the accuracy of the production-access application. Use the official documentation below and the message in your own Play Console as the final source of truth.