Dozenflow

Knowledge base

How to Run a Closed Beta Test on Android (Google Play)

· · ~5 min read

How to run a closed beta test on Android (Google Play)

Last updated: July 2026 · Reading time: ~11 min

A closed beta on Android usually means: you ship a pre-production build through Google Play to a limited audience, collect crashes and feedback, and — for many accounts — satisfy testing requirements before production.

This guide walks through a practical organizer workflow: Console setup, recruitment, day-to-day monitoring, and what to instrument in your app (anyapp).

Dozenflow is an organizer tool (app + dashboard + Closed Test SDK). It does not hire testers for you and does not replace Play Console.

Who this guide is for

  • Indie and small-team Android publishers
  • First closed test on Play, or a messy previous run
  • People who already have (or can recruit) testers via Telegram, email, Discord, or a waitlist

If you need strangers to fill a quota only, see find beta testers and the honest note on marketplaces in Dozenflow vs alternatives.

Closed testing vs internal testing (quick)

Internal testing Closed testing
Audience Very small, often your team Larger invited cohort
Speed Fastest Play distribution Slightly more ceremony
Typical goal Dogfood / smoke Broader beta + production readiness

Many “12 testers / 14 days” discussions refer to closed (or account-specific) requirements. Confirm what your Console asks for: Play testing requirements.

Deep dive: Play 12 testers / 14 days explained.

If you are choosing where to start, compare tracks here: Internal vs Closed vs Open testing on Google Play.

Step-by-step: run a closed beta

1. Stabilize a build worth testing

  • Crash-free on your devices for core paths
  • Clear versionName / versionCode for the track
  • Privacy / data-safety copy ready if you collect anything new in beta

Shipping a broken AAB burns tester goodwill in the first 48 hours.

2. Create the testing track in Play Console

  1. Open Play Console → your app → Testing.
  2. Create or open Closed testing (or the track Google requires for your case).
  3. Create a release, upload the AAB, roll out to testers.
  4. Copy the opt-in URL — testers must join the Play program, not only install a random APK.

3. Define the campaign window

Decide:

  • Start date (UTC-aware if you care about consecutive days)
  • Target headcount (Play minimum vs buffer for drop-off — often 12+ with spare)
  • What “good enough usage” means for you (sessions, key screens, bug reports)

Use a beta testing checklist before invite day.

4. Recruit testers (your channel)

Channels that work for indie apps: existing users, Telegram / Discord, Reddit (careful with rules), email list, colleagues, mutual testing communities.

Dozenflow does not find testers. You bring the audience. More channels: Where to find beta testers in 2026.

5. Onboard with a short brief

Send:

  • Opt-in link
  • What to test (3–5 flows)
  • How to report bugs (issue tracker, form, or Telegram)
  • Reminder that daily opens may matter for Play’s window

Avoid a 10-page PDF nobody reads.

6. Instrument the app (recommended)

Play Console shows official opt-in and delayed aggregates. It will not tell you who abandoned onboarding yesterday in real time.

Options:

Tool Role
Play Console Source of truth for Google
Firebase / Amplitude Long-term product analytics
Spreadsheet + chat Tiny trusted groups only
Closed Test SDK + Dozenflow Organizer campaign: roster, sessions, screen flow

Minimum SDK path: dozenflow.com/docs/sdk · artifact com.groundspaceteam:closed-test-sdk.

7. Monitor during the window

Every day (or twice a day near the end):

  • Who opted in but never opened?
  • Who went silent after day 5?
  • Are core screens visited? (screen flow guide)
  • Any crash spike after a hotfix?

Console retention may lag 24–48 hours. If the deadline is tight, do not rely on Console alone — see monitor beta tester activity.

8. Close the loop before production apply

  • Triage P0/P1 bugs
  • Confirm Console metrics match your expectation
  • Freeze the build you will promote
  • Apply for production only when Console requirements are met

No third-party tool can guarantee approval.

Common mistakes

  1. Inviting testers before the build is crash-stable
  2. Sharing APKs without Play opt-in when Console requires the program
  3. No written “what to test” — vague feedback
  4. Discovering drop-off only after the 14-day window
  5. Treating marketplace installs as product validation
  6. Skipping instrumentation and living in “who tested?” chats

When Dozenflow helps

  • Create/manage the organizer side of the test in the Dozenflow app
  • Embed the SDK in anyapp so testers only need your APK
  • See today’s activity before Play’s daily batch
  • Roster grid, sessions, idle signals, optional Telegram / FCM reminders
  • Screen flow when you emit screen_view

Not included: hiring 12 strangers, bypassing Play policy, replacing Console.

FAQ

How long should a closed beta run?

Play discussions often center on 14 consecutive days for certain production paths. Product-wise, run until crashes and core flows are acceptable — which may be longer.

Do testers need a special app?

They need your beta build (via Play). They do not need Dozenflow for basic SDK telemetry.

Can I run closed testing without Google Play?

Sideload / other stores are possible, but this guide focuses on Play closed testing — the path most Android publishers use for production readiness.

Internal or closed first?

Start internal for dogfood, then closed for a wider cohort when the build is ready.

Next steps

  1. Play 12 × 14 explained
  2. Beta testing checklist
  3. Internal vs Closed vs Open testing
  4. Easy start on Dozenflow · SDK guide
  5. Monitor activity

Terms: anyapp = app under test. Dozenflow = organizer product (com.ground.proofflow).