Skip to content

Founding membership is open — limited to 100 developers. Become a founder →

SwapTesters (SwapTesters)

How to answer Google Play's production access questions (examples)

By Sabahattin Sudan, founder of SwapTesters · Updated October 14, 2026 · 4 min read

After 14 days of closed testing with at least 12 testers, Play Console lets you apply for production access. The application has nine questions in three parts, and vague answers are one of the reasons Google gives for rejecting apps. This guide goes through each question: what it's really asking, and an example answer.

Before you start: collect your notes

  • How many testers you invited, how many stayed, and how you found them.
  • Every piece of feedback, with the date and where it came from.
  • Each update you released during the test and what it changed.
  • A clear idea of who your app is for and how many installs you realistically expect.

Answers are saved only when you click Next (parts 1 and 2) or Apply (part 3), so write them in a document first and paste them in.

Part 1: About your closed test

1. How easy was it to recruit testers?

Google wants to know where your testers came from and whether they resemble your future users. Be honest — “it was hard” is a fine answer if you explain what you did.

Example: “It took about a week. I invited 18 people: 6 friends who already use habit apps, 8 developers from a test-swap community and 4 people from a productivity forum. 16 stayed for the full 14 days.”

2. How engaged were your testers?

This asks whether testers used the features you wanted tested. Name the features and say how you know they were used.

Example: “I sent a short task every two days. 14 of 16 testers created habits and used daily check-ins on most days; 11 tried reminders and 9 exported their data. Nobody used the widget until I added instructions on day 8.”

3. How did tester usage compare with production?

Google wants you to notice differences between testers and real users. Testers often follow instructions; real users won't.

Example: “Testers checked in mostly in the evening, as we expect real users to. They explored more settings than typical users will, because tasks asked them to. Real users will probably skip the tutorial, so we made it shorter.”

4. Summarise the feedback and how you collected it

Give numbers and categories, and say which channel you used.

Example: “26 pieces of feedback through a Google Form and a group chat: 5 bugs (including a crash when deleting a habit), 12 usability notes (mostly about reminders) and 9 feature requests.”

Part 2: About your app or game

5. Who is the intended audience?

Google asks you to be as specific as possible. “Everyone” is not an audience.

Example: “Adults aged 20–40 who want to build one or two daily habits (exercise, reading, water) and prefer a simple app without an account.”

6. How does your app provide value?

For games, the question is what makes the game unique. Describe the problem you solve and what is different about your approach.

Example: “It takes five seconds a day: one tap to check in, with a weekly summary. It works offline, needs no sign-up and stores data only on the device.”

7. How many installs do you expect in the first year?

Pick a realistic range and, if you can, say why. There's no prize for a big number.

Example: “1,000–10,000. We'll promote it on our own social accounts and two productivity communities; there's no ad budget yet.”

Part 3: About your production readiness

8. What changes did you make based on the closed test?

This is where a test without updates falls apart. List concrete changes and link them to feedback.

Example: “Version 1.0.2 fixed the delete crash. Version 1.0.3 moved reminders into the first-run setup after 7 testers didn't find them, and shortened onboarding from 4 screens to 2.”

9. How did you decide the app is ready for production?

Explain your criteria — not just “it works”.

Example: “No crashes reported in the last 6 days of testing, all bugs testers reported are fixed, and in the final survey 13 of 16 testers said they would keep using the app.”

Common mistakes

  • One-line answers (“Testers liked it”, “No problems”).
  • Describing the app's features instead of the test.
  • Saying you made changes when no update was released during the test.
  • Copying the same text into several answers.
  • Inventing numbers. Only write what you can stand behind.

Rejected already? Read what “testers were not engaged” means. New to the rule? Start with the 12 testers, 14 days guide.

Source: Play Console Help — App testing requirements for new personal developer accounts. Questions checked on 14 October 2026; Google may reword or change them.

← All guides