DEV Community: Jay

"Item not found." in Google Play Closed Testing: A 5-Step Debug Checklist

Jay — Mon, 09 Nov 2026 07:17:25 +0000

You send your closed testing link, and a tester replies with a screenshot: a satellite, the words "Item not found." and a Try again button.

Your app is almost certainly fine. Google Play hides closed test apps from every account it doesn't recognize as a tester, and "Item not found." is how it says "you're not on the list (yet)".

The fastest way to debug it is to answer one question first.

Start here: who can't open it?

Who sees "Item not found."	Where the problem usually is	Start with
One or a few testers	Tester side: account, sync, opt-in	Steps 1–3
Every tester, including your own second account	Developer side: release, review, countries	Steps 4–5

If you're not sure, run the self-test at the end of this post. It takes about 15 minutes and tells you which side to look at.

What has to be true for a tester to get in

Two things, both at once:

The tester's Google account is on your tester list. With a Google Group, that means the account is a member of the group you added on the Testers tab.
Your closed testing track has a live release that's available in the tester's country.

With a Google Group, a member can install straight from the Play Store listing (play.google.com/store/apps/details?id=<package>), and the install counts as opting in. The other route is the opt-in link (play.google.com/apps/testing/<package>) and its "Become a tester" button. If either condition above fails, both routes end in "Item not found."

Tester side

Step 1: Is the Play Store using the account that joined the group?

This is the most common cause by far. Many phones are signed in to several Google accounts. The tester joins the group in a browser with account A, but the Play Store app is on account B.

Fix: In the Play Store, tap the profile picture (top right) and switch to the account that joined the group. Then open the link again.

Step 2: Has Google had time to sync?

Joining a group doesn't work instantly. In our experience the Play Store usually recognizes a new member after 10–15 minutes, occasionally longer.

Fix: Wait, then try again. Leaving and rejoining the group doesn't speed it up. If it still fails after an hour, go back to step 1 or move on to step 3.

Step 3: Try the opt-in page instead

Now and then the Play Store listing keeps showing "Item not found." even though the account is in the group.

Fix: Open the opt-in link (play.google.com/apps/testing/<package>) in a browser signed in with the same account, tap "Become a tester", then go back to the Play Store and install. It's the classic flow and still works.

Developer side

Step 4: Is there a live release, and were your changes approved?

If nobody can open the link, check your own setup first:

Releases tab of the closed testing track: you need a release that's available to testers, not one that's still in review or saved as a draft.
Publishing overview: adding a Google Group or changing countries is a change that needs review. If you see changes that haven't been sent, click Send changes for review. Until they're approved, the new group's members can't see the app.

Step 5: Is the tester's country included?

The closed testing track has its own Countries / regions tab, separate from production. If a tester's Play Store country isn't selected, they get "Item not found." even when everything else is right.

Fix: Select all countries/regions for the closed testing track. It doesn't affect where your production release goes later, and it removes a whole class of errors.

The self-test: find out which side it is

Take a second Google account you control and join your tester group with it.
Wait 15 minutes.
On a phone or browser signed in with that account, open your Play Store listing.

If your own second account can install the app, your setup is fine and the problem is on the tester's side (steps 1–3). If you get "Item not found." too, fix steps 4 and 5 before asking testers to try again.

Checklist

Testers

The Play Store is signed in with the account that joined the group
Waited 10–15 minutes after joining
If the listing still fails, tried the opt-in link and "Become a tester"

Developers

The closed testing track has a release that's available to testers
Publishing overview has no unsent or unapproved changes
All countries/regions are selected for the closed testing track
The Testers tab lists the group your testers actually joined

Why this happens so often in test-for-test swaps

In most swap threads, every developer creates a separate Google Group for their own app. To test 12 apps, you join 12 groups, wait for 12 syncs, and get 12 chances to join with the wrong account. That's where most "Item not found." errors come from.

How BetaLobby avoids most of this

BetaLobby is where indie Android developers team up to get their 12 testers: 16 developers form a team and test each other's apps for 14 days. It's built around the steps above:

One shared group for every app: betalobby@googlegroups.com. Add it to your closed test once (next to any groups you already have), join it once, and you can install every app on the platform. No new group, and no new sync, for each app.
The right account, checked for you: BetaLobby checks that the Google account you signed in with is in the group, and if the Play Store says "Item not found.", it tells you which account to switch to (step 1).
Your setup is checked before testers see it: when you submit, BetaLobby checks that your app is actually visible to testers. If Google is still reviewing your tester changes, it re-checks automatically every 20 minutes and notifies you when it passes (step 4). It also checks a few countries to catch region limits (step 5).
No screenshots: installs and daily check-ins are verified automatically.

It's free, with no paid plan.

Originally published on betalobby.com.

Google Play Closed Testing: Email List or Google Group?

Jay — Wed, 04 Nov 2026 07:54:41 +0000

When you set up closed testing in Play Console, the Testers tab asks you to choose one option: Email lists or Google Groups.

Most people pick email lists without thinking twice. That's why test-for-test posts are full of "send me your email": you send your Gmail, they add it to their list, then they send you theirs.

Both options can get you through the 12 testers / 14 days requirement, but they work very differently, and once you pick one, switching mid-test is tricky. It's worth deciding before you start.

How each option works

Email lists: you manually add every tester's Gmail in Play Console. Only people on the list can join the test.

Google Groups: you create a Google Group and enter only the group's address in Play Console. Testers join the group themselves and become eligible automatically. You don't add anyone one by one.

With groups, there's also a shortcut at the opt-in step that a lot of people don't know about. We'll cover it separately below.

Side-by-side comparison

	Email lists	Google Groups
Adding testers	Ask every new tester for their Gmail, then add it by hand	Testers join the group themselves, nothing for you to do
Privacy	You swap Gmail addresses with strangers	No emails exchanged, and members can be hidden from each other
Speed	Takes effect almost immediately	A newly added group needs review, about 10 minutes
Switching later	Switching to groups means your list stops applying	Add as many groups as you like, existing testers stay

Here are the points that matter most.

Group members can install directly, and that counts as opting in

A common belief is that, whichever option you use, testers must first open the web opt-in link (play.google.com/apps/testing/<package>) and tap "Become a tester" before installing from the Play Store.

After testing this many times, we found that with Google Groups, this step isn't needed. A tester who is already in the group can open the app's Play Store page (play.google.com/store/apps/details?id=<package>) and install it right away. Once installed, they're automatically counted as opted in.

With groups, that means:

One less step for testers, and one less thing to go wrong
When you share your app, the Play Store link is enough
The web opt-in link still works, so the old flow is fine too

Privacy: the point most people overlook

Testing through email lists means sending your Gmail to stranger after stranger, and collecting a pile of strangers' addresses in return. Those emails sit in chat histories, and you have no control over what happens to them later.

With a Google Group, nobody has to hand over an email. They just join the group. Just make sure the group is set up properly:

Open your Google Group and go to Group settings
Find Who can see members
Choose Group managers

Now people who join can't see the member list, so they can't see each other's emails.

Switching later: why it's best to start with a group

Email lists and Google Groups are either/or. If you start with an email list and later switch to groups, the people on your list are no longer on the tester list.

Google hasn't said publicly whether this resets the 14 days. To be safe:

You haven't started yet, or only have a few testers: just go with a group, you lose nothing.
You've been testing with an email list for several days: create your own group first, add everyone from your list using the group's Add members, confirm they're in, and only then switch to groups in Play Console.

Groups are much more flexible the other way around: Play Console lets you enter several groups at once. You can add another group next to your existing one at any time, and your current testers aren't affected at all.

One group per app, or one shared group?

Once you've chosen groups, there's one more decision: create a group just for your app, or share one with other developers?

	Each app has its own group	Everyone shares one group
Groups a tester has to join	One group for every app they test	Join once, test every app
Waiting for sync	Wait again after joining each new group	Wait only once, the first time
What the developer does	Create a group, approve join requests, send the link to everyone	Add the shared group's address to your testers
"Item not found"	More groups means more wrong accounts and missed groups	One group, far fewer chances to get it wrong

Separate groups per app are common in test-for-test communities, but every new app means another group to join and another sync to wait for. That's where a lot of "Item not found" errors come from: the wrong account joined the group, a group hasn't synced yet, or one was simply missed.

Common beginner mistakes

These come up again and again when we help people troubleshoot:

The account that joined the group isn't the one signed in to the Play Store. This happens most on phones with several Google accounts. Tap your avatar in the top-right of the Play Store and make sure it's the same account you used to join the group.
Changing tester settings but forgetting to send them for review. After adding a group or changing countries/regions in Play Console, go to Publishing overview and click Send changes for review. Otherwise the changes don't take effect.
The closed testing track isn't available in all countries/regions. Closed testing has its own countries/regions setting, separate from production. Even if you only plan to launch in one country, you can safely select all of them for the testing track. Otherwise testers elsewhere will see "Item not found" or "This item isn't available in your country".

Summary

Haven't started yet: go with Google Groups. Adding testers is easy, testers can install directly, and nobody has to swap emails with strangers.
Already a few days into an email list: move your testers into your own group first, then switch.
Want to skip joining group after group and waiting for each sync: share one group with other developers.

That's how BetaLobby works. It's where indie Android developers team up to get their 12 testers: 16 developers form a team and test each other's apps for 14 days.

One shared group: every tester shares betalobby@googlegroups.com, and members can't see each other's emails. Add it to your closed test (it can sit right next to your existing group) and join it once yourself.
No screenshots: installs and daily check-ins are verified and recorded automatically by the app.

Originally published on betalobby.com.

12 Testers for 14 Days: What "Continuously" Really Means

Jay — Fri, 30 Oct 2026 12:14:11 +0000

To publish to production, a new personal developer account has this task on the Play Console dashboard: Run your closed test with at least 12 testers, for at least 14 days.

It looks simple, and the countdown moves forward by itself, so many developers assume they just have to wait 14 days. But what Google means by "continuously" is much stricter than that countdown.

Do all 12 testers have to start on the same day? What if someone opts out halfway? Do testers have to open the app every day? You'll find different answers online, and some of them contradict each other. This post goes through Google's own wording, point by point.

1. What Google actually says

Start with the original wording. Hover over that task on the dashboard and a tooltip spells it out:

When you apply for production access, at least 12 testers must be opted-in to your closed test. They must have been opted-in for the last 14 days continuously

Play Console Help goes into more detail in App testing requirements for new personal developer accounts, and the sections below quote it line by line.

Put together, it comes down to 3 key phrases:

When you apply: the requirement is checked at the moment you click "Apply for production"
The last 14 days: counted backward from the day you apply
Opted in continuously: those 12 people have to stay opted in for the whole 14 days

2. Do all 12 testers have to start on the same day?

No. Google doesn't require everyone to join on the same day. The countdown starts on the day the 12th tester opts in.

For example:

Day 1: 10 people opt in
Day 3: the 11th person joins
Day 5: the 12th person joins

The 14-day countdown starts on day 5, so the earliest you can apply is day 19. The first 4 days with 10 people don't get you there any sooner.

So the slower you gather testers, the longer you wait. It's best to get everyone together first and start at the same time.

3. The countdown doesn't stop, but "continuously" can still break

On the surface: the 14 days never seem to break

As covered in Google Play closed testing: 5 things new developers get wrong, the 14-day countdown on the dashboard works like this:

It starts once the 12th account opts in, whether or not anyone installs or opens the app
Once it starts, it doesn't stop on its own, even if some testers opt out

If you only look at the dashboard, the 14 days almost never break. You just wait and they run out.

In reality: these 5 things break "continuously"

The countdown is just a timer. It doesn't check whether your testing was really continuous. Of the 5 cases below, the first two are about the rules; the other three don't show up in the count at all, but they do show up in review.

① A tester opts out

This is the one Google states most clearly:

Testers who opt in, test for fewer than 14 days, and then opt out do not count toward the requirement.

If a tester opts out and opts back in later, the 14 days must be consecutive to count toward the minimum requirement of 12 continuous opted-in testers.

So if someone opts out halfway, the countdown keeps running, but that person no longer counts toward "12 continuous testers". If you have exactly 12, losing one means you no longer meet the requirement. That's why you should always stay above 12 and keep some margin.

② Your application is rejected

In our own experience, when an application for production access is rejected with "More testing required", the countdown restarts on the day of the rejection. The 14 days you already ran don't carry over to the next round.

③ Opted in, but never installed

A tester opens your opt-in link and taps Become a tester, and your opted-in count goes up by 1. But they may never install your app.

The count doesn't break at all, but your installed audience is 0. In review, that looks like nobody tested.

④ Uninstalled halfway

Uninstalling the app is not opting out. A tester who uninstalls your app is still opted in, so your opted-in count doesn't drop and the countdown isn't affected.

But installed audience in Play Console drops, and the statistics show clearly that testing stopped partway.

⑤ Installed, but never opened

The app stays installed, but nobody opens it. If Daily Active Users (DAU) stays close to 0 for a long time, your testers aren't really testing.

Google lists this explicitly as a reason for more testing:

Reasons for required continued testing include having fewer than 12 opted-in testers or insufficient tester engagement during the testing period.

Summary

Case	Countdown	Counts as a tester	In review
① Opts out	Keeps running	No	You may fall below 12
② Application rejected	Restarts	—	Another round of testing
③ Opted in, never installed	Keeps running	Yes	Low installed audience
④ Uninstalled halfway	Keeps running	Yes	Installed audience drops
⑤ Installed, never opened	Keeps running	Yes	DAU near 0

Only case ② restarts the countdown. In the other 4, it keeps running as usual. But Google can see all 5 when it reviews your application.

To find installed audience and DAU in Play Console, see the first two sections of "More testing required" on Google Play: 5 reasons and fixes, with screenshots and steps.

4. So do testers have to open the app every day?

Google doesn't say testers must open the app every day, and it doesn't set a number of minutes. Missing a day or two won't restart the countdown.

But when you apply for production access, the questions ask about tester engagement, for example:

Whether testers used all available app features

Whether tester usage matched expected production user behavior

You'll often see this claim online: "As long as testers don't opt out or uninstall, it doesn't matter whether they use the app." That's only half right. If testers don't opt out, they keep counting and the countdown can finish. But if the app just sits there and almost nobody opens it, you're likely to get "More testing required" in review.

A safer approach: you don't need every tester to open the app every single day, but across the 14 days your DAU line should always have data.

5. 3 common myths

"All 12 testers must install on the same day." No. The countdown starts on the day the 12th tester opts in. See section 2.
"Once the countdown finishes, you've tested for 14 continuous days." The countdown doesn't stop when testers opt out, never install, uninstall, or never open the app, but all of these break the real "continuously". See section 3.
"Miss opening the app one day and the 14 days start over." No. What restarts the countdown is a rejected application, not a missed day. See section 4.

6. How to get through the 14 days safely

Put the sections above together and it comes down to a few things:

Gather everyone first, start together: don't make the early testers wait for nothing
Keep a margin: have a few more than 12, so one person opting out isn't a problem
No opting out, no uninstalling: tell testers up front not to opt out or uninstall the app during the 14 days. Google makes the same point in its help page: "Inform your testers that they need to remain opted in to your closed test continuously for at least 14 days."
Use the app naturally every day: no need to pad screen time, but keep your DAU line from going empty

BetaLobby is a platform where developers help each other through closed testing, built around exactly these points:

Teams of 16: each app gets 15 testers, a margin above 12
Everyone starts together: once all members have installed their teammates' apps, the 14 days start at the same time
Daily check-ins: each check-in really opens your app, and you can see in the app how many testers checked in each day
4 hearts of slack: missing a day or two doesn't break Google's rules, but not using the app for a long time hurts in review. So everyone has 4 hearts, and TRUST is only deducted after missing more than 4 days in the 14

In the end, the "continuously" Google wants isn't a dashboard countdown that reaches 14 days. It's 12 or more people really using your app throughout those 14 days.

Originally published on betalobby.com.

Google Play closed testing: 5 things new developers get wrong

Jay — Thu, 29 Oct 2026 11:52:55 +0000

For a new personal developer account, the rule for production looks simple: at least 12 testers, opted in to your closed test for at least 14 days in a row.

In practice, from development through closed testing to production, a few points are easy to misunderstand, and getting them wrong often costs an extra round of testing.

1. Opted in is not installed, and installed is not opened every day

When a tester opens your opt-in link (play.google.com/apps/testing/<package>) and taps Become a tester, the opted-in count in Play Console goes up by one right away.

That only means they opted in. It doesn't mean they installed your app, and it certainly doesn't mean they open it every day.

Play Console tracks these as three separate numbers:

Opted-in testers: what the application requirements count
Installed audience: people who actually have your app installed
Daily Active Users (DAU): people who opened your app on a given day

Where to find the last two, and why they matter so much when you apply for production, is covered with screenshots in "More testing required" on Google Play: 5 reasons and fixes.

2. The 14-day countdown is not 14 days of real testing

On the dashboard, the countdown for "Run your closed test with at least 12 testers, for at least 14 days" is easy to read as proof that your test is good enough. It has little to do with how well you tested:

It has nothing to do with installs. Whether or not anyone actually installs or opens your app, the 14-day countdown still starts.
The 14 days don't stop. Once the 12th Google account opts in, the countdown officially starts, and it won't stop on its own before day 14, even if some testers opt out (Google's requirement is still at least 12 testers for 14 days in a row, so it's best to stay above 12).
It resets automatically. Think of the 14 days as an hourglass that flips itself. If your last application was rejected, the countdown restarts on the day of the rejection, again regardless of installs or testing activity.

That's why this number can't be your measure of a good test: when the countdown finishes, it only means you can apply. It doesn't mean your test passed.

3. Internal testing is not closed testing

After you create a new app in Play Console, the dashboard lists a series of tasks, and internal testing is first. Many developers assume it's a required step toward production and spend real time on it.

Play Console says so right under that task: "This is optional, and you'll still need to run a closed test before publishing to everyone in production."

Internal testing doesn't count toward production access. The required part is closed testing: the 12 testers / 14 days rule only counts your closed testing track.

Internal testing is still a useful tool for sending a new build to a few trusted people fast. If you just want to install a new version yourself without waiting for closed testing review, try internal app sharing (Test and release > Testing > Internal app sharing) instead: upload a build and get an install link, no review, and only people with the link can install it.

Two things to watch with internal app sharing:

The test phone has to turn on "Internal app sharing" in the Play Store settings first, or the link won't open
Google re-signs internal app sharing builds with a different key. If your app uses Google Sign-In, add the internal app sharing certificate fingerprint to your OAuth client in Google Cloud too, or sign-in fails in that build

4. Closed testing countries are separate from production

When picking countries / regions, many developers worry they can't change them later, so they only select the few countries they plan to launch in. That's a misunderstanding:

They're independent. Closed testing and production are separate tracks, each with its own countries / regions setting. Selecting every country for closed testing doesn't affect launching production in just a few.
You can change them anytime. Both tracks' countries / regions can be edited whenever you like. Just remember to go to Publishing overview and send the changes for review. They take effect once approved.

If your closed test is only open in a few countries, testers elsewhere get "Item not found" when they open your link. It's one of the 5 causes of "Item not found" on a closed testing link. So go ahead and select all countries / regions for your closed testing track. Recruiting testers gets much easier.

5. Meeting 12 testers / 14 days doesn't guarantee production access

This is the last one, and the most expensive. Once all three requirements are ticked on the dashboard and Apply for production is clickable, a lot of people assume they're done.

Those three requirements are only the bar for applying. After you submit, Google reviews your test: whether testers really used the app, whether you shipped updates based on feedback during the test, and how seriously you answered the questions. Fall short, and you get a "More testing required" email and another 14 days.

For how to check each part, see "More testing required" on Google Play: 5 reasons and fixes.

Final thoughts

The closed testing rule fits in one sentence, but every number in it can mean something other than what you think. Getting these 5 points straight can save you at least one extra round.

BetaLobby is a platform where developers help each other through closed testing, designed around exactly these traps:

Everyone shares one Google Group, so you join once and can test every app on the platform
Team mode requires your closed test to be open in all 178 countries / regions, so no teammate gets blocked by region
Each daily check-in really opens your app, and you can see in the app how many testers checked in each day

Whether you get production access is still up to Google. But making sure testers actually install your app and actually open it every day is the part you can get right.

Originally published on betalobby.com.

"More testing required" on Google Play: 5 reasons and fixes

Jay — Tue, 20 Oct 2026 15:44:00 +0000

You found 12 testers, ran your closed test for 14 days straight, clicked Apply for production, and a few days later this landed in your inbox: More testing required to access Google Play production.

I got this email more than once while applying for production access myself.

The email gives only two reasons, and both are vague:

Testers were not engaged with your app during your closed test
You didn't follow testing best practices, which may include gathering and acting on user feedback through updates to your app

Then it asks you to "test your app using closed testing for an additional 14 days with real testers" before applying again.

Google doesn't publish exactly how it reviews applications, so what follows isn't an official answer. It's what I learned from being rejected and finally approved: the 5 things most worth checking.

Installed audience
Daily Active Users (DAU)
App quality and updates during the test
How you fill in the application questions
Whether your testers are real

Go through them before you start the next 14 days.

1. Installed audience: opted in is not the same as installed

The most common misunderstanding about closed testing: the number of testers who opted in, the number who installed your app, and the number who open it each day are three different numbers. Play Console showing 12 opted-in testers doesn't mean 12 people installed your app. There are several more assumptions like this, which I covered in 5 things new developers get wrong about closed testing.

To see real installs, open Play Console and click Statistics in the left menu. By default it shows Installed audience for the last 28 days.

One catch: the chart is split by Country / region, with 5 rows selected by default (all countries plus your top 4), so you see several lines at once. Open that filter, keep only All countries / regions, untick the rest, and click Apply. The single line left is your total installed audience.

Play Console defines it as the number of users who have your app installed on at least one device that has been turned on in the last 30 days. It counts people, not installs, so one person installing on two phones counts once.

I also noticed something in my own tests: when several devices on the same network (the same Wi-Fi, say) installed the app with different accounts, installed audience only went up by 1. That isn't part of Google's definition and I'm not sure why it happens, but if most of your testers are family or coworkers in one place, keep an eye on it.

How many do you need? My advice: before you apply, keep this at 12 or more. Higher is better.

Just started recruiting and see nothing? The data isn't real-time and usually lags by two or three days. Give it time.

2. Daily Active Users (DAU): installed but never opened doesn't count

This is the metric people overlook most. Many developers assume that if testers install the app and don't uninstall it for 14 days, the test "counts". But the first reason in the email, "testers were not engaged with your app", is exactly about this.

To check it, stay on the Statistics page, open the Installed audience metric picker, and choose Engagement > Daily Active Users (DAU). Play Console's definition is simple: the number of users who opened your app on a given day.

The country filter you set earlier stays on, so again read the All countries / regions line. If the chart is empty, don't panic. DAU lags even more than installed audience, often by several days.

How much DAU do you need? Around 12 a day is ideal, but don't obsess over the exact number. What matters is that the line has data every day. If it stays close to zero for the whole test, your testers aren't really opening your app, and the risk of rejection goes up a lot.

So when you recruit testers, be clear: installing isn't enough, they need to open the app every day for 14 days.

3. App quality, and whether you shipped updates during the test

Almost every first-time developer misses this. Many think closed testing is about finding testers. The real focus is the app itself. Getting 12 testers only meets the baseline. Whether you get production access has a lot to do with your app's quality and how you iterate during the test.

App quality. There's no strict bar, but at minimum:

Your privacy policy and the App content declarations in Play Console are filled in correctly
The app is complete, not a single-screen shell
Use Android's official app quality guidelines as a reference

Updates during the test. The second reason in the email, "you didn't follow testing best practices, which may include gathering and acting on user feedback through updates to your app", is about this.

The 12 testers / 14 days rule exists so developers polish their apps before going public, instead of flooding the store with low-quality apps. If you're building your app seriously, you'll find more to fix during closed testing than you expect. So ship new versions during the test, whether or not testers sent feedback.

There's no official number. From my experience: release at least 3 versions with real changes in each round of testing, and write down what each one changed. You'll need it for the questions.

4. The application questions: where you show you're serious

This matters as much as anything above. If you rush through the questions, or reapply without changing a word of your old answers, you'll most likely get another rejection and another 14 days.

There's no model answer, and don't copy anyone else's. But a few things raise your chances a lot:

Be completely honest. The first question asks whether you used a paid testing provider. That answer, the changes you made, your intended audience: nothing made up, nothing exaggerated.
Use the space. Each text box allows up to 300 characters. If you tested properly, filling it is easy. I'd aim for at least about 260 characters per answer.
Keep the grammar clean. If you're unsure, let AI check your grammar, but don't let it write your answers from scratch. It easily invents facts, which breaks the first rule.
Update for this round. When you reapply, the boxes are pre-filled with your previous answers. Don't just click Next. Go through each one and change whatever is different this time. You'll also get an extra question about what you changed since your last application: new recruiting channels, the updates you shipped.

To prepare ahead, try our free production access questionnaire: all 9 questions word for word as in Play Console, with the same 300-character count, and drafts that stay in your own browser.

5. Are your testers real?

This is the most complicated one and the hardest to pin down. Google doesn't say how it decides who is a "real tester", but any of these may land you here:

Too few installed users, or almost no DAU
Testers installing and opening your app on emulators
Dozens of accounts all on the exact same device model

If you used a paid testing service, had enough testers, and were still rejected, ask whether that usage would look like real use from Google's side.

Checklist before you reapply

Before the next 14 days, check each one:

Installed audience in Statistics is 12 or more
Daily Active Users (DAU) has data every day
You shipped at least 3 versions with real changes during the test and noted what each changed
Your privacy policy and App content declarations are correct, and the app is complete
Every answer is honest, uses the space, and was updated for this application
Your testers are real people on real devices

Final thoughts

A rejection doesn't mean your app is bad. Most of the time, the test just didn't show Google enough real use and iteration.

I learned all this the hard way, one rejection at a time. It's also why I built BetaLobby, a platform where developers help each other through closed testing. 16 developers form a team and install each other's apps, so everyone gets 15 testers at once. Your testers are developers in the same spot as you, who also need to pass closed testing. Each daily check-in really opens your app, and you can see in the app how many testers checked in each day. Emulators can't join teams, pair, or check in. It's completely free, with no paid testing of any kind.

Whether you get production access is still up to Google, and no platform can guarantee it. But real testers, real daily use, and real iteration during the test are the parts you can control.

Originally published on betalobby.com.