How to Get Production Access on Google Play: Complete Application Guide

You finished 14 days of Closed Testing. Your 12 testers stayed engaged. Now you face the final gate: the production access application. This questionnaire — not the testing itself — is where many developers stumble. Generic answers, missing documentation, and vague descriptions of feedback get applications rejected even when testing was solid.

Here is how to answer each question, what evidence to attach, and how to maximize your first-attempt approval odds.

When to Apply

You can submit the application as soon as day 14 completes, but wait until day 15 or 16. Google’s engagement data takes time to fully sync. Applying on day 14 with incomplete data risks a reviewer seeing lower engagement numbers than what actually occurred.

Before applying, verify:

• Your Closed Testing track shows “Available” status (not “In review” or “Processing”)
• The Statistics tab shows 12+ installs with crash-free session rates above 90%
• You have screenshots, feedback messages, and changelogs organized and ready to reference

The Production Access Questionnaire: Questions and How to Answer

The questionnaire appears under “Production access” in Google Play Console. Here are the questions developers report seeing, along with the answer style that correlates with approval.

Question 1: “Describe the feedback you received from testers”

Bad answer: “Testers said the app works well and they liked it.”

Good answer: “Three testers reported that the login button was unresponsive on Samsung Galaxy A54 devices running Android 14. We reproduced the issue, identified it as a layout constraint conflict on 1080x2340 resolution screens, and deployed a fix in v1.0.2 on day 6. All three testers confirmed the fix. Additionally, two testers requested a dark mode option, which we added in v1.0.3 on day 10.”

Why this works: It names specific bugs, specific devices, specific Android versions, specific fix versions, and specific dates. It shows you collected feedback, triaged it, and shipped fixes.

Question 2: “How many testers participated and for how long?”

Bad answer: “12 testers for 14 days.”

Good answer: “We recruited 15 testers on [date]. 14 installed within 24 hours. 13 remained actively engaged through day 14 (one dropped out on day 9 due to a device failure). Average daily active users: 12.8. All testers used physical Android devices across 6 manufacturers (Samsung, Xiaomi, OnePlus, Google Pixel, Oppo, Motorola) and Android versions 12 through 15.”

Why this works: It acknowledges dropouts honestly (Google can see them anyway), gives specific numbers, and demonstrates device diversity — all signals that testing was genuine.

Question 3: “What changes did you make based on tester feedback?”

Bad answer: “We improved the app based on feedback.”

Good answer: “We deployed two updates during the 14-day period:

• v1.0.2 (Day 6): Fixed login button responsiveness on Galaxy A54 (reported by 3 testers). Fixed crash on app resume after backgrounding (reported by 1 tester on Oppo A78). Improved button contrast based on accessibility feedback.
• v1.0.3 (Day 10): Added dark mode toggle (requested by 2 testers). Fixed notification permission flow on Android 13+ devices. Reduced APK size by 4.2MB through ProGuard optimization (suggested by a tester).“

Why this works: Versioned updates with dates, specific fixes tied to specific feedback, and quantifiable improvements (APK size reduction) all demonstrate that testing drove real development.

Question 4: “How did you recruit your testers?”

Bad answer: “We found them online.”

Good answer: “We used TesterBee’s verified tester network to recruit 12 testers, supplemented by 3 personal contacts as a buffer. Testers were geographically distributed across India, Brazil, Indonesia, Germany, and the United States. Each tester confirmed they used a unique personal Android device and Google account.”

Why this works: Geographic distribution eliminates IP clustering concerns. Naming the recruitment method shows transparency. Mentioning unique devices and accounts addresses the authenticity question directly.

Evidence to Attach

Google’s questionnaire may include an option to attach supporting files. Prepare these in advance:

• Screenshots of tester feedback: Discord messages, WhatsApp threads, or Google Form responses showing dated feedback
• Changelog: A simple text file or PDF listing each update, date deployed, what changed, and which feedback prompted it
• Engagement data: If you integrated analytics (Firebase, Mixpanel), export the daily active user chart for the 14-day period
• Crash reports: The Android Vitals page showing crash-free session rate above 90%

Do not fabricate screenshots. Google’s reviewers have seen thousands of applications and recognize templated or generated evidence.

Tips for First-Attempt Approval

1. Over-recruit: Start with 14-15 testers. Dropouts happen. Staying above 12 avoids the most common rejection reason.
2. Ship at least one update: An app that received zero updates during testing suggests feedback was not collected or was ignored.
3. Document in real time: Screenshot feedback as it arrives. Do not try to reconstruct a 14-day testing narrative the night before applying.
4. Ensure device diversity: If all 12 testers use the same phone model, it looks coordinated. Real testers have different devices.
5. Be honest about dropouts: Google can see install and uninstall counts. Claiming 12 testers were active all 14 days when data shows 9 by day 10 will get you rejected for misrepresentation.
6. Answer every question fully: The questionnaire is not a formality. It is the primary evidence Google uses to evaluate your testing.

What If You Get Rejected?

Google will state the rejection reason. Common reasons and fixes:

Rejection Reason	What It Means	How to Fix
Insufficient tester engagement	Testers installed but did not use the app regularly	Use testers who commit to daily engagement. Restart with a paid service that monitors this.
Suspicious tester activity	Shared IPs, emulators, or tester-sharing detected	Ensure testers use unique devices on different networks. Avoid emulators entirely.
Incomplete feedback documentation	No evidence of feedback collection or response	Next cycle: collect feedback through a structured channel and deploy at least one update based on it.
Policy violation in app	Your app violates a Developer Program Policy	Fix the policy issue before restarting testing.

If rejected, you must run a new 14-day testing cycle before reapplying. There is no appeal process for production access decisions.

If you used TesterBee and were rejected due to tester engagement, you are eligible for a full refund under the production access guarantee.

Frequently Asked Questions

How long does Google take to review the production access application?

Most developers report a decision within 1-3 business days. Some reviews take up to 7 days. There is no way to expedite this.

Can I publish to production immediately after approval?

Yes. Once production access is granted, you can create a production release, upload your app bundle, and publish. The production release goes through a separate review process that typically takes a few hours.

Do I need Closed Testing for every app I publish?

Once your developer account has production access, subsequent apps do not require another 14-day Closed Testing cycle. The requirement is account-level, not per-app.

What if my app was rejected for a reason other than testing?

If your production release (not production access application) is rejected for a policy violation, fix the violation and resubmit the release. You do not need to repeat Closed Testing.