Executive Summary (TL;DR)
- Google Play Requirement: Apps on personal developer accounts must complete a closed test with at least 12 active testers opted-in continuously for 14 days.
- Avoid Rejections: Maintain a buffer of 15 testers. If your active count drops below 12, Google's automated telemetry may pause or reset your 14-day timer.
- Guaranteed Solution: Instead of relying on uncommitted testers, join a 14-Day Testing Cohort at Testers Hub to secure 15 dedicated Android testers and guarantee production access.
You have completed your 14 days of closed testing with 12 or more opt-in testers. When you click the "Apply for production" button in your Google Play Console dashboard, you are not immediately approved. Instead, you are greeted by an extensive questionnaire asking you to justify your testing process, detail user feedback, and explain why your app is ready for global release.
Google's review team uses these written responses—combined with telemetry from your closed testing track—to decide whether to grant production access or require further testing. In this guide, we provide proven, field-tested answer templates and explain exactly what Google reviewers are looking for in each response.
The Anatomy of the Production Questionnaire
The questionnaire consists of three primary sections:
- About your testers: How you recruited them and who they are.
- Feedback received: What bugs, UX flaws, and device issues were discovered.
- Changes made & readiness: What code updates were released and why the app is production-grade.
The #1 Rejection Mistake
Writing vague, one-sentence answers such as "Recruited friends and fixed all bugs." Reviewers reject these immediately because they look automated or unverified.
Section 1: How Did You Recruit Your Testers?
What Google Wants to See:
Google wants to verify that your testers are real human beings with diverse Android devices, not automated bot accounts. Mentioning developer communities, peer beta testing groups, or early access newsletters works best.
Winning Template:
We recruited a cohort of 15 verified Android developers and beta testers through dedicated Android developer communities, developer testing exchanges (including Testers Hub), and early access sign-up lists. All testers were onboarded through a managed Google Group and opted in via the official Google Play closed testing track link. Testers represented a diverse mix of physical Android devices (ranging from Android 11 to Android 15 across Samsung, Google Pixel, Xiaomi, and Motorola hardware) to ensure real-world compatibility across varying screen sizes and processor architectures.
Section 2: What Feedback Did You Receive During Testing?
What Google Wants to See:
No first beta build is flawless. Google wants authentic technical details: UI overflow issues, performance latency, navigation confusion, or locale formatting glitches.
Winning Template (Customize with Your App's Specifics):
During the 14-day closed testing period, our testers provided actionable feedback across three key areas: 1. UI & Layout Adjustments: Testers on smaller screen devices (e.g. 5.5-inch displays) noticed that the primary submit button overlapped with the bottom navigation bar on certain form screens. 2. Network Error Handling: Two testers encountered an unhandled timeout error when switching between Wi-Fi and mobile data during background sync. 3. Dark Mode Contrast: Testers reported that secondary metadata text had low contrast against dark backgrounds in the settings panel.
Section 3: What Changes Did You Make Based on Tester Feedback?
What Google Wants to See:
Google cross-references this answer against the App Bundles (AABs) you uploaded to the Closed Testing track. Always mention your version codes.
Winning Template:
In response to the feedback gathered, we implemented the following technical iterations during the closed testing track: • Version 1.0.1 (Build 2 - Released Day 6): Refactored the layout constraints using dynamic safe area insets to eliminate button clipping on compact devices. • Version 1.0.2 (Build 3 - Released Day 11): Implemented an exponential backoff retry mechanism for API requests to resolve network disconnects, and updated color tokens to meet WCAG AA contrast standards. All crash logs on Android Vitals are currently at 0.00% crash rate with zero ANRs reported over the final 7 days of testing.
Section 4: Why Is Your App Ready for Production?
Winning Template:
The application has undergone 14 continuous days of real-world testing with 15 active developers. We have resolved all identified edge cases, verified memory consumption under 80MB on mid-range devices, and confirmed that our backend architecture handles peak concurrent traffic seamlessly. The app is fully compliant with Google Play Developer Program policies and ready for public users.
Summary: Honesty + Specifics
By following these structured templates and backing them up with genuine telemetry gathered through peer testing, your production track application will pass human review smoothly. For our comprehensive portal, visit our dedicated Google Play Production Access Guide, read our overview of the Closed Testing Policy, or learn about our hands-free VIP Managed Testing.
Get Real Feedback from Real Developers
Join a 15-developer testing Squad on Testers Hub and gather real bug reports to include in your questionnaire.
Download Testers Hub on Google Play ➔4. The Exact Rubric Google Reviewers Use to Grade Your Questionnaire
When you click "Apply for production" after completing the 14-day closed testing period, you are presented with a series of qualitative questions regarding your testing cohort, feedback loops, and production readiness. Google Play utilizes human policy evaluators supported by NLP rubric scoring to determine whether your answers demonstrate genuine software engineering rigour.
| Questionnaire Section | Failing Response Pattern (Immediate Denial) | Passing Response Pattern (High Approval Score) |
|---|---|---|
| Tester Recruitment Method | "I asked my friends and family to download it." | "Recruited 20 verified Android QA testers via Testers Hub matching target demographics across 12 OEM device models." |
| Engagement & Activity | "They used the app and told me it was good." | "Testers logged daily sessions, executed complete checkout/workout flows, and submitted telemetry tracked in Firebase." |
| Feedback Collected | "No bugs were found. Everything worked perfectly." | "Identified 3 edge-case issues: keyboard overlapping form inputs on small screens, and intermittent network timeouts on 3G." |
| Changes Made Based on Feedback | "No changes were needed because the app is ready." | "Shipped update v1.0.2 resolving layout padding and adding offline SQLite caching; verified across all 20 devices." |
5. Battle-Tested Answer Templates for All 3 Core Questions
Question 1: Describe your testing audience and recruitment method
"Our testing cohort consisted of 20 independent Android enthusiasts and QA testers recruited through the Testers Hub developer community. We specifically selected testers operating physical devices across Android 11, 12, 13, 14, and 15, representing diverse hardware profiles including Samsung Galaxy, Google Pixel, Xiaomi, Motorola, and OnePlus. Testers represented our target user demographic (daily productivity and utility users) and agreed to engage with the application across the complete 14-day testing timeframe."
Question 2: How did you collect feedback from your testers?
"Feedback was systematically collected through three synchronized channels: (1) Google Play Store private testing feedback dialogs visible in Play Console, (2) an in-app feedback dialog capturing device model, screen density, and OS version, and (3) real-time automated crash and ANR logging via Firebase Crashlytics. We conducted mid-test check-ins on Day 6 and Day 11 to gather qualitative usability impressions regarding navigation smoothness and battery performance."
Question 3: What changes did you make to your app based on feedback?
"Testers submitted several valuable observations: on Xiaomi devices running Android 13, the virtual keyboard occluded the confirmation button on the settings screen. Additionally, testers noted that when switching network connections from Wi-Fi to cellular data, pending local sync operations occasionally stalled. In response, we implemented a custom keyboard-aware scroll container and enhanced our background synchronization retry logic with exponential backoff. We built App Bundle version 1.0.4 (versionCode 4) and deployed it to closed testing on Day 8. Testers confirmed the fixes resolved the issues completely."
6. Pre-Submission Self-Audit Checklist
Before submitting your completed questionnaire, verify these 4 technical facts in Google Play Console:
- The 14-day testing countdown meter in Play Console must indicate 14 full days completed.
- At least 12 testers must remain listed as active opted-in testers under your closed track.
- Your User-Perceived Crash Rate in Android Vitals must be strictly under 1.09%.
- You must have uploaded at least one updated App Bundle during the testing period.
7. Production Access Questionnaire FAQs
How long does Google take to review the questionnaire?
Turnaround times range between 3 to 7 business days. If additional information is needed, Google Play Developer Support will email you with specific questions regarding your tester cohort.
Can I copy and paste these templates word-for-word?
Customize the templates with your specific app features, version numbers, and actual device observations. Google's review algorithm flags identical verbatim submissions across multiple accounts.
Executive Summary: The 3 Golden Rules of Questionnaire Approval
To maximize your approval odds on your first submission: (1) Quantify Everything: Never write "many testers tested the app"; write "20 testers logged an average of 4.2 active sessions per day across 14 consecutive days". (2) Acknowledge Technical Imperfections: Google reviewers view "zero bugs reported" as proof of absent testing. Highlighting a real UI glitch or network latency bug that you subsequently patched validates genuine software testing. (3) Cite Specific Version Codes: Explicitly link tester feedback to the exact App Bundle version code (e.g. versionCode 3 deployed on Day 7) where the fix was shipped.