Plan a continuous test around participant start times.
Calculate a testing checkpoint from anonymous participant cohorts, release availability and 14 full days; export a transparent UTC calendar.
Build a cohort-based testing calendar
Use anonymous cohorts, not tester emails. Enter every time in UTC. A cohort contains people who most recently joined at the same time and have stayed opted in continuously.
Participants with valid continuous records: 0
Earliest mathematical checkpoint
Add a valid release time and at least 12 continuously opted-in participants.
The calculation takes the 12th-earliest still-active participant start, waits until the release is available, then adds 14 full days. It does not verify opt-in records, account eligibility or Google review time. If someone rejoins, enter their new continuous start time.
A calendar starts with people, not an upload date
Uploading a release does not establish when each participant began a continuous opt-in period. This calendar lets you group people with the same most-recent start time and keep later arrivals separate. You can see how the earliest twelve still-active participants affect the mathematical checkpoint.
Enter when the release became available to the intended cohort and when each group began its uninterrupted opt-in period. All inputs are UTC so the exported record has one time reference. Use the live Console as the authority for account eligibility and recorded status.
How this calculation works
The tool excludes cohorts that are no longer continuously opted in, sorts the remaining valid starts, and finds the twelfth participant. It takes the later of that start and release availability, then adds fourteen full 24-hour periods. An incomplete active cohort date prevents a result rather than silently assuming it started earlier.
A scheduling allowance is optional and belongs to your own plan. It does not predict Google’s review duration or promise a publication date. The output separates the mathematical checkpoint from that additional planning date.
Example: ten early participants and two later arrivals
In a hypothetical run, ten people join on 1 November at 09:00 UTC and two join on 3 November at 09:00 UTC. If all twelve remain continuously opted in and the release was available, the relevant twelve-person checkpoint is 17 November at 09:00 UTC. The upload date does not make the two later participants’ days appear earlier.
If one of the later arrivals leaves, exclude that person or split the cohort. A returning participant needs a new continuous start time. Remaining participants keep their own records; this tool does not claim that every person’s clock automatically resets together.
Keep planning assumptions visible
Use anonymous cohort labels and counts. Do not paste personal tester details into this calculator. Add separate cohorts when the join times differ or some participants leave. Check that a selected date is a real calendar date and that your UTC conversion is correct.
Download the calendar to retain the inputs, the active-cohort choices and the result. The browser saves your draft locally under a new key. A warning appears if local saving is blocked, and the calculation and export can still be used.
A date is only one part of the handover
Participant continuity is not the whole release decision. Your test record should also describe access, meaningful tasks, observed issues and how feedback affected the app. Pair this calendar with the evidence-gap planner and a real testing handover.
Before requesting production access, check the current account-specific requirements in Play Console. Google makes the review decision. If your team needs managed coordination, Basic provides 14 testers for 16 days and Premium provides 16 testers for 20 days per app.
Source: Google Play testing and production-access requirements. Verify the current requirements before applying.