PeerPlay
Most developers find out their closed test went wrong on day 15, when the production application asks questions they cannot answer, or the tester count turns out to have dipped below 12 somewhere in the middle.
A daily log fixes both problems. It takes about a minute, it warns you while there is still time to react, and by day 14 it has written half of your production application for you. Here is what to put in it, with real numbers from one finished test to show what the columns look like.
What to log each day
Date and day number. Day 1 is the first day you had testers on the track. Write both, because "day 9" is what you will think in and the date is what you will need to look things up.
Opted-in testers. The number Play Console shows for your closed track. This is the number Google's 14-day rule cares about, so it is the one to watch every single day.
Active testers. How many people actually opened and used the app that day. Opted in is not the same as active, and the gap between the two is your early warning.
Joined and dropped. Who came in and who left today. A single drop on day 4 is noise. Two drops in a row is a trend.
Build version. Which version was on the track. When feedback says "it crashes", this column tells you which build it was.
Feedback received and fixes shipped. A short count and one line each. This is the raw material for the production application, which asks what you learned and what you changed.
Setting it up in five minutes
Open a new spreadsheet and make one header row: Date, Day, Opted in, Active, Joined, Dropped, Build, Feedback, Fixes, Notes. Fill in Day 1 to Day 14 down the second column before the test starts, so the empty rows stare back at you every day.
Add a simple rule to the Opted in column that turns the cell red below 14. Two testers of buffer is the point where you still have time to recruit calmly. Below that, every drop is an emergency.
Keep the Notes column for anything you will want to remember later: an update that went out, a tester who reported a crash, a day when Play Console was slow to show new opt-ins. Those small notes are exactly what you forget by day 15, and they are often the most concrete details you can give Google when it asks how the test went.
Finally, decide where feedback lands before day 1. One email address, one form or one chat channel. If feedback is scattered across five places, the Feedback column will always be wrong.
What the numbers looked like in a real test
PeerPlay's first paid campaign, for a cycle tracking app called Nada, ran from September 16 to October 6, 2026. A tracker for it would show a slow first day: only 7 testers were active on day one. From September 17 to October 1, at least 12 were active every day.
Across the whole campaign, 18 testers joined, 11 completed all 14 days and 3 quit. 217 tester-days were logged, all of them qualified. Testers sent 14 feedback items and the developer marked 8 as solved during the test. Google then granted production access.
Two lessons fall straight out of those numbers. Day one can easily be below your target, so do not panic, but do not plan a launch around the first day either. And losing 3 testers is normal, which is why you start with more than 12.
Warning signs to act on
Opted-in count at 13 or 12. You have no buffer. Recruit one or two more testers today, not when it hits 11.
Active count far below opted-in. People joined and forgot. Send a short message with one thing to try in the app, or ship a small update and say what changed.
No feedback by day 5. Your testers do not know what to look at. Give them two or three concrete scenarios.
Feedback with no fixes by day 10. You will have little to describe in the production application. Ship at least one fix before the test ends.
Keep it boring
A spreadsheet with one row per day is enough. Fill it in at the same time each day, right after checking Play Console. Don't build a dashboard for a two-week test. The value is in looking every day, not in how the log looks.
If you test through PeerPlay, the app already tracks whether each tester opened your app for a real minimum session each day and removes testers who go quiet. You still want your own row for the Play Console count, because that is the number Google reads.
FAQ
What should I track during Google Play closed testing?
Every day: the opted-in count from Play Console, how many testers actually used the app, joins and drop-outs, the build version, feedback received and fixes shipped.
Is opted in the same as active?
No. Opted in means the tester joined your closed test. Active means they actually used the app that day. Google's rule is about opted-in testers, but low activity is the early sign that people will drop.
How many testers drop out of a typical closed test?
It varies. In one real 14-day campaign, 18 testers joined, 11 completed all 14 days and 3 quit, so plan for a buffer above 12.
Does a tracker help with the production application?
Yes. The application asks about your testing, the feedback you got and what you changed. A daily log of feedback and fixes answers those questions with real details.