How to Answer the Production Access Questions in Play Console

Answer the production access questions with specifics from your own closed test: how you found testers, what they told you, what you changed because of it, and why the app is ready. Vague, copy-pasted answers are the most common way to waste the 14 days you just spent.

This post walks through the kinds of questions Play Console asks after your closed test, what a useful answer contains, and how to avoid the usual traps. Google changes this form from time to time, so the exact wording you see may differ from what is described here. Check Play Console Help for the current requirements before you submit.

When the questions appear

New personal developer accounts created after November 13, 2023 must run a closed test before applying for production. The requirement is now 12 testers opted in for 14 days in a row. Once that is done, Play Console lets you apply for production access and asks you to fill in a short questionnaire.

The questions have generally fallen into three groups. Treat this as a rough map, not an official list:

• About your closed test: how you recruited testers, how they engaged, and what feedback you collected.
• About your app: what it does, who it is for, and what value it gives users.
• About production readiness: what you changed after testing and why you think the app is ready.

Nobody outside Google knows exactly how answers are reviewed. Nobody, TesterMob included, can promise approval. What you can control is giving a reviewer clear, honest, checkable information.

Before you open the form: collect your evidence

Answering from memory leads to generic text. Spend 20 minutes gathering material first:

1. The date your test started and the date your 14-day streak completed.
2. Where your testers came from (friends, a community, a tester service, a mix).
3. A list of the feedback you received, even if it is messy.
4. A list of the bugs you fixed and the changes you shipped during the test.
5. Your crash and ANR data from the Android vitals section, if any exists.

If you used a service that gives you tester activity data, pull that too. For example, TesterMob's optional Android SDK (an .aar file) shows daily tester activity in your developer dashboard, which makes it easier to describe real engagement. See the developer page for how that works.

Answering the closed test questions

How did you recruit your testers?

Say plainly where they came from. You do not need to apologize for any of the options. Real people on real devices using the app is what matters.

Example: We recruited 12 testers through a mix of personal contacts and a tester service. All testers installed the app from the closed test link on their own Android phones and stayed opted in for the full 14 days.

Do not claim a recruiting method you did not use, and do not exaggerate numbers. Your test data is in the console, so your answer should match it.

How engaged were your testers?

Describe what testers actually did. If you asked them to use the app daily, say so. If engagement was uneven, say that too and explain what you did about it.

Example: Testers were asked to open the app daily and try the main flows: creating an entry, setting a reminder, and exporting data. Most used it regularly. A few dropped off mid-test, and we reached out to them for feedback on why.

Avoid invented figures. If you do not have a number, describe the pattern in words.

What feedback did you receive?

This is where specifics matter most. Name two or three real pieces of feedback, not a general statement like "testers found it useful."

• A bug report with the device or Android version it appeared on.
• A usability complaint, such as a confusing onboarding screen.
• A feature request you accepted or deliberately declined.

Written feedback is much easier to summarize than a vague sense of how things went. If you are using testers who submit written reports, keep them in one document as you go.

Answering the app questions

These questions are about the product. Write as if explaining the app to someone who has never heard of it.

• What does the app do? One or two sentences, no marketing language.
• Who is it for? Name a real audience: "people who track daily habits and want a no-account, offline option," not "everyone."
• What makes it useful? State the problem it solves.
• Expected reach: If asked about expected installs or growth, give an honest estimate and the reasoning behind it. Inflated guesses do not help you.

Make sure your answers agree with your store listing, screenshots, and description. A reviewer who sees one story in the form and another in the listing has reason to doubt both.

Answering the production readiness questions

This is the section where you show that the 14 days changed something. A good answer links feedback to action:

Example: Testers reported that the reminder notification did not fire on two devices after a restart. We fixed the boot receiver, shipped the fix as a new closed test release, and confirmed with those testers that it worked. We also shortened onboarding from five screens to three after two testers said it felt long.

Then add what you checked before applying:

• Crash and ANR rates in Android vitals look acceptable to you.
• Your privacy policy and Data safety form are complete and match what the app does.
• Content rating and target audience declarations are filled in.
• Permissions in the manifest are all necessary and explained.

If your test turned up problems you have not fixed yet, it is often better to fix them and wait than to apply with known issues.

Common mistakes to avoid

• Copy-pasted answers. Template text from a forum thread reads like template text. Use examples like those above as a shape, then fill in your own details.
• Contradicting the console. If you say 20 testers engaged daily and the console shows 12 opted in, that mismatch is easy to spot.
• Saying nothing changed. If the test produced zero fixes, explain why. A 14-day test with no learning looks like a box-ticking exercise.
• Applying before your counter is truly complete. If your streak reset, check it first. Our post on why the 14-day counter resets covers the usual causes.
• Writing in a rush. Reapplying after a rejection can take time, so one careful pass beats two quick ones.

If your application is not approved

Read the message from Google carefully. It may point to specific areas to improve. Fix what you can, keep testing, and update your answers to reflect the new work. Eligibility details and reapply timing can change, so check Play Console Help rather than relying on a blog post, including this one.

Where TesterMob fits

If you are still short on testers, TesterMob provides real testers for your closed test. They use their own Android phones, use the app about 20 minutes a day, and write feedback you can reference in your answers. It costs $9.99 per app, paid once in USDT, with no subscription. See pricing or the FAQ for details. We are not affiliated with Google and cannot guarantee production approval. What we can do is help you end the test with real data and feedback to describe.

A quick checklist before you hit submit

1. Your tester count and dates match the console.
2. You named at least two concrete pieces of feedback.
3. You listed at least one change you made because of that feedback.
4. Your app description matches your store listing.
5. Nothing in your answers is exaggerated or invented.

Honest, specific answers take about an hour to write and cost nothing. They are the best use of that hour after a 14-day test.