BetaLobbyYou found 12 testers, ran your closed test for 14 days, and clicked Apply for production on the Dashboard. Next comes a questionnaire: 3 sections and 9 questions. 7 are text boxes with a 300-character limit, and 2 are single choice.
When my app was rejected, my answers were vague, mostly along the lines of "testers used all features and everything worked as expected". In the round that passed, I replaced every answer with concrete facts.
Google doesn't publish how it reviews these answers, so this isn't an official guide, just my experience. All the examples are for a made-up expense tracker. They only show the style, so don't copy them.
4 things to know first
- Closing the form loses your answers. If you close it partway through, Play Console asks Close form? and the button is Close and discard. Write your answers somewhere else first, then paste them in. You can use our free production access questionnaire: all 9 questions word for word as in Play Console, the same character count, and drafts that stay in your own browser
- The last button is "Apply". Clicking it submits your application. It doesn't save a draft
- Count your characters. 300 characters is only about 50 words, so every sentence has to say something. I'd aim for about 260 characters per answer. The "more specific" examples below run from about 190 to 280 characters
- Language. I didn't find any language requirement in the Help Center. I answered in English
Part 1: About your closed test
This part asks what you actually did. It's the easiest part to fill with vague claims, and the easiest place for your answers to stop adding up.
1How did you recruit users for your closed test?
How did you recruit users for your closed test? For example, did you ask friends and family, or use a paid testing provider?
Say honestly which channels you used and how many people joined. The same goes for paid services. The question itself lists them as one way to recruit, so hiding one or making something up is the bigger risk.
- Too vague: I recruited testers online.
- More specific: I recruited through two Android developer communities and my coworkers. 18 people joined, and I didn't use a paid testing service. 5 of them already track their spending every day, so they match my target users.
2How easy was it to recruit testers for your app?
How easy was it to recruit testers for your app?
Single choice: Very difficult, Difficult, Neither difficult or easy, Easy, Very easy. There's no right answer here. Pick what matches your experience.
3Describe the engagement you received from testers
Describe the engagement you received from testers during your closed test
The hint under the question asks for two things: whether testers used all of your app's features, and whether their usage was consistent with how you'd expect a real user to use your app. If it wasn't, describe the differences.
Many people just write that everyone used everything and it all matched. That's hard to believe, because real tests are almost never that tidy. Saying where usage differed from what you expected is more credible.
You can cover these three points:
- Features used a lot: what most people used regularly
- Features used little: what only a few people touched, or nobody did
- Differences from what you expected: for example, you expected daily use but people were mostly active in the first few days, or many people got stuck at the same step
If you don't know what your testers actually did, that's normal. Statistics shows how many people opened your app each day, but not which features they used. Here's how to find out:
- Ask them. Ask a few people in your tester group or by direct message which features they used and where they got stuck. Do this during the test, not when you sit down to fill in the questionnaire
- Check your app's own data. If you use an analytics tool like Firebase, or your server keeps records, you can see directly which features get used
- Read the feedback. Someone who reports a problem with a feature has at least used it
If you can no longer ask anyone and have no data, write only what you know for certain and explain the situation. You can also include problems you found while testing yourself, as long as you say you found them. Don't claim everyone used every feature just to make it look good.
- Too vague: Testers used all features, and the experience met expectations.
- More specific: Most testers logged expenses daily and checked monthly stats, as expected. Only a few used multiple ledgers or export. Real users may start the same way, so I moved both into Settings. Some testers logged often only in the first few days.
- If you don't know exactly what they did: The app has no usage analytics, so I asked 6 testers. All used logging and monthly stats, and only 1 tried export, about what I expected. 2 couldn't find the export option, so I moved it.
My own app is a platform where developers team up and test each other's apps. In the round that passed, my answer here said roughly this: some members' apps crashed on launch so check-ins failed, a few testers uninstalled mid-test, and we adjusted the flows for each case. None of that is good news, but all of it really happened.
4Provide a summary of the feedback you received
Provide a summary of the feedback that you received from testers. Include how you collected the feedback.
Cover two things: what feedback you received and how you collected it. Channels can be email, an in-app form, or a community. Testers can also send private feedback through Google Play, which you'll find under Monitor and improve > Ratings and reviews > Testing feedback.
So write feedback down from day one instead of trying to remember it when you apply. If you really didn't get much, say so, then explain what else you did, such as who you asked directly and what you found yourself. Don't make anything up.
- Too vague: Testers gave positive feedback, and no major issues were found.
- More specific: Collected through an in-app form and our tester group. Three main issues: export crashed on two Android 12 phones, logging took too many taps, and charts were hard to read in dark mode. Some asked for weekly stats, which I'm still considering.
Part 2: About your app
This part isn't about the test. It asks who your app is for and what it does for them.
5Who is the intended audience of your app?
Who is the intended audience of your app?
The Help Center asks you to be as specific as possible. Don't write "everyone". Say which people would use it and in what situation.
- Too vague: Anyone who wants to track expenses.
- More specific: Young professionals who are just starting to manage their personal spending, especially those who want to log an expense in a few seconds a day and don't want to learn complicated finance software.
6Describe how your app provides value to users
Describe how your app provides value to users
Focus on the problem your app solves, not a list of features. According to the Help Center, if it's a game, describe what makes it unique.
- Too vague: Rich features, a beautiful interface, and easy to use.
- More specific: Many people give up on tracking expenses because each entry asks for too much. This app logs an expense in two steps and summarizes where the money went each month, so users can see their spending without organizing any data.
7How many installs do you expect in your first year?
How many installs do you expect your app to have in your first year?
Single choice: 0 - 10K, 10K - 100K, 100K - 1M, 1M+, I don't know. Again, there's no right answer. Give your honest estimate, and if you really can't estimate, choose I don't know. There's no need to aim high to look good.
Part 3: Your production readiness
This part shows most clearly whether you've really been iterating, and it needs the most preparation.
8What changes did you make based on what you learned?
What changes did you make to your app based on what you learned during your closed test?
Write the specific changes. Ideally they connect to the feedback in question 4 and match the versions you actually released during the test. It's fine if you got no feedback: problems you found yourself or through the Pre-launch report count too.
So release several versions with real changes during the test, and write down what changed each time.
- Too vague: Fixed some bugs and improved the user experience.
- More specific: Fixed the export crash on Android 12, moved logging to the home screen so it takes two steps instead of four, and adjusted chart colors in dark mode. Released 4 versions during the test. Weekly stats aren't built yet and are planned for after launch.
9How did you decide that your app is ready?
How did you decide that your app is ready for production?
Write the evidence behind your decision: for example, the main flows all work, the serious problems from feedback are fixed, and which specific problems stopped appearing in the last few versions.
You can also add a line at the end saying your app meets Google Play's policy requirements on privacy and data safety, as long as you've actually checked. This is only a supplement. Most of the answer should still be what the test showed you.
Don't write "no bugs", and don't claim you finished something you didn't. If small problems remain, say they don't affect the main use of the app and how you plan to handle them. That's more credible.
- Too vague: The app is very polished and ready to release.
- More specific: Core flows like logging, stats and export work on testers' devices, the reported crash is fixed, and the last two versions had no new crash reports. Non-core requests like weekly stats will follow after launch. The app also meets Google Play's privacy and data safety policies.
If you're applying again
The text boxes are pre-filled with your previous answers. Don't just click Next. Go through each one and update it for this round.
You'll also get an extra question about what you changed since last time. You can mention new recruiting channels and the updates you shipped this round. If you're still not sure why you were rejected, read "More testing required" on Google Play: 5 reasons and fixes first.
One last check before you submit
- Every answer describes something that really happened, with nothing made up or exaggerated
- The feedback in question 4 matches the changes in question 8
- The changes in question 8 match the versions you actually released
- All 7 text boxes use the space well, and the grammar is clean. AI can check your grammar, but don't let it write your answers from scratch, because it easily invents things that never happened
Even the best answers need a real test behind them. Whether you get access is up to Google, but what goes into questions 3 and 4 builds up little by little over those 14 days.
If you still need 12 testers, take a look at BetaLobby, a platform where developers team up for closed testing. 16 developers form a team and test each other's apps for 14 days. Each daily check-in really opens your app, you can see how many testers checked in each day, and you get feedback with device info attached.