Do Testers Need to Open the App Every Day? Google Play

Do Google Play testers need to open the app every day?

Short answer: no published rule says daily, but you should ask for daily anyway. Google Play's closed testing requirement is worded entirely around opt-in: at least 12 testers, opted in continuously for the preceding 14 days. On the help page that defines that rule, checked on 6 October 2026, the strings daily, every day and session each appear 0 times. What Google does publish is that it will ask you to describe tester engagement when you apply, and that insufficient tester engagement is one of the two named reasons your application can be sent back for more testing. Daily opens are not the rule. They are the cheapest way to make the answer you eventually write defensible.

This page separates three things that get argued about as if they were one: what Google has written down, what publishers and paid services claim Google measures, and what you should actually tell twelve people for two weeks. We run closed testing campaigns at GetClosedTesting — more than 200 of them so far — and the middle section matters to us as much as the first one: a claim we cannot check is a claim we cannot repeat to a developer who is on day 11 of a window.

What does Google actually require of a tester?

Three things, all on the same help page, and all about status rather than behaviour.

• They must opt in. Google: "After clicking the opt-in link, testers receive an explanation of tester responsibilities and a link to opt in. Each tester needs to opt in using the link." - Set up an open, closed, or internal test, fetched 6 October 2026. An address sitting in a tester list is not a tester — that is why a full list can still read 0 (see 0 testers currently opted in? 7 fixes for Play Console).
• They must stay opted in for 14 consecutive days. Google's FAQ: "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."
• You must tell them that. Google puts it in bold on the same page: "Important: Inform your testers that they need to remain opted in to your closed test continuously for at least 14 days."

That is the whole documented obligation. There is no sentence anywhere on that page telling a tester to launch the app, no minimum number of launches, no minimum session length, no daily cadence. The one behavioural instruction Google publishes is aimed at you, not at them: "Encourage testers to use as many features as possible to provide holistic feedback," filed under best practices for tester engagement alongside "Provide beta testers with clear instructions on how to test your app and report bugs." Encouragement, not a threshold.

Note what the FAQ answer above actually protects: continuity of the count. The consequences it spells out are about a tester leaving and rejoining, which is a clock problem, and the clock is the thing we took apart in Does dropping below 12 testers reset your 14-day clock?. Opens are not part of that machinery at all.

Where does the daily-opens idea come from?

From three published places, none of which is a rule about daily opens. First, the application form. When you apply for production access, Part 1 asks you to "Provide details about tester engagement during your closed test, including: Whether testers used all available app features" and "Whether tester usage matched expected production user behavior, including details on any observed differences." Google is asking you to describe usage in prose, and to compare it with how a real production user would behave.

Second, the refusal language: "If your app requires additional testing, you may need to continue running your closed test. Reasons for required continued testing include having fewer than 12 opted-in testers or insufficient tester engagement during the testing period." Engagement is named as a reason your application comes back. Third, the feedback obligation: "You must summarize your testing feedback when applying for production access" — so the form also needs material you can only have if people opened the thing. Our walk-through of every prompt on that form is at Google Play production access form: questions and answers.

Put those together and the inference writes itself: engagement matters, engagement implies opens, therefore opens must be checked daily. The inference is reasonable. It is still an inference, and the developer community reads it every possible way. One thread asks directly whether testers need to open a game daily because the writer "couldn't find anything stating that testers must launch the game daily" (r/GooglePlayDeveloper), and the replies disagree with each other inside the same comment section. Another thread asks the same question as a rejection survivor (r/AndroidClosedTesting). Nobody in either thread cites a Google page, because there is not one to cite.

Does Google track whether testers open the app?

We cannot show you that it does, and neither can anyone ranking above us for this question. We re-fetched the requirement page on 6 October 2026 and counted: 17,590 characters of article text, 0 occurrences of "daily", 0 of "every day", 0 of "session", and 1 occurrence of "insufficient tester engagement". There is no published Google document that describes a per-tester open counter, a session-length threshold, or a daily-active measurement applied to closed tests.

Several guides ranking for this query state flatly that Google does measure it. The claims range from plausible to invented: that Play Console tracks daily active users in your testing cohort, that Google Play Services pings the device and reads background logs, that a tester inactive on day 8 is "no longer active" and you "lose that tester", that session length below two seconds is flagged, and that battery and memory footprint prove a human touched the screen. Some of those same pages still describe the requirement as 20 testers, which has not been the number since 11 December 2024. Not one of them links to a Google page supporting the measurement claim.

• Verified today: the requirement is 12 opted-in testers for 14 continuous days; engagement is a named reason for continued testing; the form asks you to describe usage; feedback must be summarized.
• Not verifiable from Google's documentation: any specific threshold — opens per day, days out of 14, seconds per session, or a per-tester activity graph inside Play Console.
• Honest caveat: absence of documentation is not proof that nothing is measured. Google is free to look at signals it never publishes, and the review is described as a review, not a formula. What we can say is narrower and more useful: you cannot aim at a number nobody will tell you, so you aim at the description you will have to write.

What does Play Console show you about tester activity?

Two things on the documented path, and neither of them is per-tester opens.

• The opted-in count on your closed testing track, which moves only when somebody completes the opt-in and can lag by a few hours. It answers "am I at 12 and staying there", nothing else.
• The Testing feedback page, which Google's help page points to at "Monitor and improve > Ratings and reviews > Testing feedback" for browsing feedback by date, language, reply state, app version or device type. Feedback only exists if people opened the app and had something to say.
• No documented open history per tester. Google publishes no per-tester session view for closed tests. Treat any screenshot circulating of one as unverified.

The practical consequence: the only open data you fully control is your own. If your app talks to a server, your logs already know who connected. If it does not, an analytics SDK you add before day 1 — Firebase Analytics or anything equivalent — turns "are they opening it" from a guess into a chart you can look at every morning, and it costs an afternoon. Developers who add it after the window starts lose the first week they most need to see. Your own instrumentation is also the honest answer to "how do I know", because it is measurement you performed, not a threshold you assumed.

In our campaigns we keep one row per tester that separates four states — invited, opted in, active, and reporting — because the count you report and the count you act on are different numbers. "Active" means the tester has opened the build recently enough to count as participating, which is our definition and not Google's. That distinction is the whole reason the window is watched as it runs instead of audited at the end: testers do not announce that they have stopped opening the build.

How often should testers use the app during the 14 days?

Aim for every tester, every day, and treat 10 or more of the 14 days per tester as the floor you are managing against. That is a target you choose, not a limit Google publishes — and it is chosen because the form asks you to describe usage, not because a counter turns red at 9 opens. We monitor engagement daily across every campaign and replace inactive testers, so this is a target we hold ourselves to, not one we observe Google enforcing.

The published third-party datasets are worth reading precisely because they agree on the shape and disagree on the details. TesterBee, from 1,500+ of its own campaigns, reports an average of 12.4 opens per tester across 14 days spread over 8.7 distinct days, with 22% of testers opening the app every single day — and reports a correlation between 10+ active days and first-attempt approval (97%) versus 5-7 active days (41%). A correlation reported by a testing service about its own customers, not a rule published by Google.

ACT Party's separate log — 1,862 test runs and 8,054 daily check-ins between 16 August and 10 September 2026 — counts only the 116 runs that reached day 14: 27.6% finished, 5.2% never opened the app once, and the average tester logged 10.3 days. That 10.3 sits close to TesterBee's 8.7 distinct days, from a different operator with a different population, which is about as much corroboration as an unpublished threshold will ever get. What both datasets say you should plan for is that nobody behaves perfectly: expecting all 12 people to open it 14 days out of 14 is expecting the one outcome no dataset shows.

How long should a testing session be?

No duration is published, and the durations you read elsewhere are estimates dressed as requirements. Guides variously assert that a session must exceed two seconds, that 30 to 60 seconds "looks normal to the tracking algorithms", and that 2 to 5 minutes per session is what real users produce. One tester's account of a passing test describes sessions averaging around 90 seconds on a utility app. A QR scanner, a meditation app and a video editor have nothing in common as pieces of software, so a single magic number cannot be right for all three.

The measurable standard is not time, it is coverage. The form asks whether "testers used all available app features" and whether their usage "matched expected production user behavior". A 40-second session that reaches your onboarding, your core action and your settings screen answers both questions better than four idle minutes on the launch screen. Ask testers to walk the flows you would be asked about, not to hold the app open on a timer.

What should you tell your testers?

"Please test my app" produces silence, and silence is what you will be describing on the form three weeks later. Send one message on day 0 with four parts in it. This is the version we hand to developers starting a window:

• The account, named. The most common failure we see is not inactivity, it is a tester opting in with a different Gmail from the one on your list, which leaves your counter at 0 while everyone believes they joined.
• A daily instruction with variety. A specific task per day gives a tester something to do and gives you something to summarize. "Use it when you can" gives neither.
• A named channel. Google's own best practice is to "Provide a clear feedback channel, such as email, a website, or a messaging forum" — pick one and keep it in the same message.
• The two things not to do. Opting out restarts their 14 days under Google's FAQ; uninstalling guarantees they cannot open anything for the rest of the window.

How do you know if a tester has gone quiet?

Check every day, not on day 14, and check four places in this order.

• Your own analytics or server logs. One row per tester, last open date. This is the only view that names individuals.
• The opted-in count on the track. If it moved, somebody left — a continuity problem, not an engagement one.
• The Testing feedback page. No feedback from a tester across a fortnight means no session worth reporting, or a tester who never found the feedback route.
• The tester themselves. A single direct message on day 3 or 4 works better than a broadcast reminder on day 12, because by then the window is nearly over and there is nothing to fix.

When to worry is genuinely contested, and the two datasets above disagree. TesterBee's curve puts the churn in days 4-7, with retention reported falling from 92% in the first three days to 68% by day 7. ACT Party found the opposite in its logs: of 78 drop-offs, 50 occurred on days 10-13 — "these people did not lose interest", they opened the app daily for over a week and then missed a day. Two operators, two shapes. The only strategy that survives both is watching the window from day 1 and keeping a spare tester or two, which is why our own pricing page recommends 15 rather than 12 — not because 12 is wrong, but because 12 has no margin for a single bad week.

What happens if a tester skips a few days?

Nothing happens to your count, and that is the crucial distinction. The requirement reads on opt-in status, so a tester who stays opted in and simply does not open the app for two days leaves 12 at 12 and leaves the 14-day continuity intact. What it costs you is softer and later: fewer sessions to describe, thinner feedback to summarize, and a weaker answer to the engagement question on the form.

What does break something is a status change. A tester who opts out drops you below 12, and Google's FAQ says their returning restarts their own 14 consecutive days. That is a clock event with a date attached, and it is the subject of Does dropping below 12 testers reset your 14-day clock? — including the sequence to run if your count dipped yesterday.

So the practical rule for a skip is: ignore one, act on two consecutive misses, and treat any opt-out as an emergency regardless of how the opens look.

Does the app have to stay installed for all 14 days?

Google's published requirement does not name installation duration; it names continuous opt-in. But installation is the precondition for every open, and uninstalling is usually the first step of a tester leaving the test altogether, so the practical instruction is the same either way: keep it installed for the full window. Note that the requirement page carries 0 occurrences of "uninstall" as well — the guidance on this point is practical rather than documented, and we present it as such.

The related failure — a tester who never installed in the first place — is invisible on the opted-in count, because the count only records the opt-in click. That is the gap behind 0 testers currently opted in? and behind the difference between an invitation and a tester.

Do you have to push an update during the test?

Not by any published rule — there is no documented minimum number of releases inside the window. Google's wording is advice: "Continue running closed tests while resolving user-reported issues and bugs. Updating your app in closed testing before releasing to production helps minimize low ratings and negative reviews."

It is good advice anyway, for a reason that has nothing to do with opens. One of the form's prompts asks what you changed because of the test, and an answer with a build number in it is easier to write and harder to dismiss than one without. Shipping a fix mid-window also gives every quiet tester a reason to open the app again, which quietly repairs the engagement problem this page is about. Do not fabricate changes to have something to say — name the bug, name the build, name the day.

Why do some developers pass with quiet testers?

Because the review is not a published formula and nobody outside Google has seen it. Developers who never opened their own apps report approvals, and developers whose testers opened it daily report refusals — both stories are in the threads linked above, and both are probably true, because engagement is one input among several and the others (count, continuity, crashes, the answers you wrote) vary at the same time. Anyone selling certainty in either direction is selling past their evidence.

What you control is real: 12 valid opt-ins, 14 unbroken days, apps that run without crashing, sessions across enough days that your form answers can be specific, and written feedback you can quote. Our pricing page is one flat fee per app for a 14-day campaign, and how a campaign runs shows the roster, the daily monitoring and the evidence you are left holding. We sell campaigns, so weigh the rest of this page accordingly — the Google quotes are verbatim and dated so you do not have to take our summary of them on trust.

FAQ: tester opens and daily activity in closed testing

Do testers need to open the app every day? Not by any rule Google publishes. Google's requirement is continuous opt-in for 14 days. Daily or near-daily opens are the practical target because engagement is a named reason for continued testing and the form asks you to describe how your testers used the app.

How many days out of 14 should a tester open the app? No official threshold exists. Two independent operator datasets put the typical tester at roughly 9-10 distinct days out of 14, with about a fifth to a quarter of testers opening it every day. Manage to 10 or more, not to 14.

Is there a minimum session length? None is published. The checkable question is coverage: Google asks whether testers "used all available app features" and whether usage "matched expected production user behavior".

Can I see whether each tester opened the app? Play Console publishes no per-tester open history for closed tests. The opted-in count and the Testing feedback page are what the documentation shows. For per-person data, use your own analytics or server logs and add them before the window starts.

What happens if a tester does not open the app for a day or two? Your opted-in count and your 14-day continuity are unaffected — the requirement reads on opt-in status. What you lose is engagement evidence for the form. Two consecutive misses is where we would start messaging.

What actually makes a tester stop counting? Opting out. Google's FAQ is explicit that a tester who opts out and rejoins needs their 14 days to be consecutive. See does dropping below 12 reset the clock for the sequence after a dip.

Does the app need to be opened on the same Google account that opted in? The opt-in must be completed with the invited account, and the install comes from that same account's Play Store session. A tester with two Gmail addresses who joins with the wrong one is the most common reason a full list still reads 0 — covered in 0 testers currently opted in.

Should I pay for testers who open the app daily? Whether to pay at all depends on what your bottleneck is; we priced the market and answered that in Are paid Google Play tester services worth it?. What no service can do is grant production access — Google reviews your application and emails the outcome.