How to answer Google Play's production access questions
Updated
When your fourteen days are up, Play Console lets you apply for production access. The application is a short form, and Google says plainly that you must summarise your testing feedback in it. It is not a formality: the tester count gets you to the form, and the form is where you show the testing was real.
This guide goes through each question, what it is checking, and what a strong answer looks like. The wording below reflects the form at the time of writing; Play Console shows the current version when you apply, so check it there.
Section 1: About your closed test
How did you recruit users for your closed test?
What it checks: that real people took part, and how you found them.
Google does not restrict how you recruit. Its own help page suggests friends, family, colleagues, communities where your users are, and social media. So say what you did, in plain words.
I recruited [15] testers: [4] friends and colleagues, and [11] Android developers through a test-for-test exchange, where I tested their apps in return. I checked each tester's opt-in in Play Console before counting them.
If you used an exchange, you do not need to hide it. See is a tester exchange allowed for why.
How easy was it to recruit testers for your app?
What it checks: context, as a multiple-choice question from very difficult to very easy.
There is no known right answer here, and no public evidence that one option is held against you. Pick the honest one and move on.
Describe the engagement you received from testers
What it checks: whether testers used the app, or only opted in.
This is where weak applications show. "Testers were engaged" says nothing. Numbers and actions say a lot.
Testers used the app across the whole test. [9] of [15] opened it on at least [5] separate days. Most sessions covered [the main flow: creating a list and sharing it]. [6] testers sent written feedback, and [2] reported crashes with steps to reproduce.
If you do not know how often testers opened the app, check your own analytics or crash reporting. If you have neither, describe what testers told you and did, rather than guessing numbers.
Provide a summary of the feedback you received
What it checks: that feedback existed, and that you read it.
Group it into themes, and be specific. Negative feedback is fine to include. It is the point of testing.
The main themes were: (1) a crash on Android 10 when opening [settings], reported by [2] testers; (2) the sign-up screen was confusing, [4] testers asked what [the code field] was for; (3) requests for [dark mode]. Positive feedback centred on [how fast the list sync was].
Section 2: About your app
Who is the intended audience of your app?
What it checks: that you know who the app is for.
Be concrete. "Everyone" is not an audience.
[Home cooks who plan meals for a family], mostly adults who want [a weekly shopping list generated from recipes]. The app is not aimed at children.
Describe how your app provides value to users
What it checks: that the app does something useful, not just that it exists.
Describe the problem and how the app solves it, in two or three sentences.
Planning meals and writing a shopping list takes [30 minutes a week]. The app builds the list from the recipes you pick and merges duplicates, so it takes [a couple of minutes].
How many installs do you expect in your first year?
What it checks: your expectations, as a multiple-choice question.
Choose the range you honestly expect. For most first apps from an individual developer, the smallest range is the realistic one, and there is nothing wrong with saying so.
Section 3: About your production readiness
What changes did you make based on your closed test?
What it checks: that testing changed the app. This is the question that separates a real test from a waiting period.
List the changes and link each one to the feedback that caused it.
Based on testing I released [2] updates during the test: fixed the Android 10 crash in [settings]; rewrote the sign-up screen and added help text for [the code field]; and fixed [3] layout issues on small screens. [Dark mode] is planned for after launch.
If you have not shipped an update yet, you still can: uploading a new build does not reset the 14-day clock, and iterating during the test is what Google wants to see.
How did you decide that your app is ready for production?
What it checks: that you have a reason, not just a finished timer.
The last [5] days of testing produced no new crashes, all reported bugs are fixed, testers completed [the main flow] without help, and the store listing, Data safety form and content rating are complete.
Common mistakes
- Pasting a template unchanged. Reviewers read many of these. An answer that could describe any app tells them nothing about yours.
- Claiming "no issues found". A real test almost always finds something. Saying it found nothing suggests nobody looked.
- Numbers that do not match. If you say 20 testers were active every day and your data shows 12 opted in and 3 sessions, that is a problem.
- Removing testers after you apply. Review happens after the fourteen days and can take up to a week or more. Keep everyone opted in until access is granted.
If you are refused
A refusal is not permanent. Fix what the decision names, improve your answers, and apply again. The full checklist is in production access denied after closed testing.
The easiest way to have good answers is to have had a real test. Testers who actually use your app and tell you what is broken give you something true to write in every box on this form. That is why TestersWiz asks testers to check in with evidence during the fourteen days: when you reach this form, you have check-ins and feedback to draw on rather than a blank page.