The first week after your production release is when real users find the problems your testers didn't. Use it to confirm the listing is right, watch crashes and ANRs daily, control your rollout, and ship your first fix through the closed track before it reaches everyone. The checklist below is ordered roughly by day.
This assumes your production release has been approved and is live. If you're not there yet, start with your next steps after production access is approved.
Day 1: confirm what users actually see
Your app being "live" in Play Console doesn't mean it looks right to users. On day 1:
- Find the app as a user. Search for it on a phone signed in with an account that isn't one of your testers. Check that the listing appears in the countries you chose.
- Install it from the public listing on a real device and go through first launch, sign-up and the main feature.
- Read the listing on a small screen. Check the short description, screenshots and feature graphic. Our store listing checklist covers what each element should do.
- Check that links work. Privacy policy, support email and website should all open.
If something is wrong with the listing, fix it now. Listing changes are changes like any other: they collect under "Changes not yet sent for review" until you click Send for review in Publishing overview.
Days 1 to 7: watch Android vitals every day
Android vitals collects data from users who opt in to sharing usage and diagnostics. With few users in week one, numbers can jump around, but trends still matter. Google defines bad-behavior thresholds:
| Metric | Overall | Per phone model |
|---|---|---|
| User-perceived crash rate | 1.09% | 8% |
| User-perceived ANR rate | 0.47% | 8% |
Going over a threshold may reduce your app's visibility or add a warning on the store listing. Each day, look at the top crash and ANR clusters, note the device models involved, and decide whether a fix can wait. The Android vitals basics article explains what these metrics mean and why "user-perceived" matters.
Days 1 to 7: manage your rollout
If you released with a staged rollout, the first week is when you decide whether to widen it. Increase the percentage when vitals look stable and early feedback is fine. Halt it if a serious crash appears, fix it, and then continue. Using a staged rollout walks through these decisions.
If you released to 100% straight away, every user gets each problem at the same time, so the daily vitals check matters even more.
Days 2 to 4: read every piece of feedback
Feedback comes from several places now:
- Public ratings and reviews from production users.
- Private feedback from closed testers, under Monitor and improve > Ratings and reviews > Testing feedback. It "won't affect your app's public rating."
- Your own support email and in-app channels.
Sort what you hear into bugs, confusion and feature requests. Confusion often points to the listing or onboarding rather than the code.
Never offer rewards in exchange for ratings or reviews. Google's policy prohibits "incentivizing feedback" and "inflating product ratings, reviews, or install counts by illegitimate means." That includes asking friends or testers to leave five-star reviews.
Days 3 to 6: ship your first update through closed testing
Your closed track is still there, and this is what it's for. Google advises: "Updating your app in closed testing before releasing to production helps minimize low ratings and negative reviews."
A simple flow for your first fix:
- Build the fix with a higher version code.
- Release it to your closed track and send it for review.
- Ask your closed testers to update and check the fix.
- Read the pre-launch report for the new upload. It's free and runs automatically on test devices; see the pre-launch report explained.
- Promote the build to production and send it for review.
Every update has to meet the current target API level rule. From August 31, 2026, new apps and updates for phones and tablets "must target Android 16 (API level 36) or higher."
Day 5: re-check your declarations
Launch week is when teams add things quickly: a crash reporting SDK, an analytics tool, an ad network. Each of those can change what your app collects or shows. If you added one, update the matching declarations under Policy and programs > App content, especially the Data safety form and the ads declaration, in the same release.
Also confirm that the test login credentials you gave Google still work. Reviewers may need them for every update, not just the first one.
Day 7: review the week
At the end of the week, write down:
- Crash rate and ANR rate trends, and the top issues still open.
- What users found confusing, and whether the listing or onboarding needs a change.
- What shipped this week, and what's planned for next week.
- Whether to continue, widen or pause the rollout.
This short review gives you a baseline for week two and stops you from reacting to every single review.
The checklist
- App found and installed from the public listing on a real device
- Listing text, graphics and links checked on a phone
- Android vitals checked daily, top crash and ANR clusters noted
- Rollout percentage decided based on data
- Public reviews and Testing feedback read and sorted
- No incentives offered for ratings or reviews
- First fix tested on the closed track before production
- Pre-launch report read for the new upload
- Target API level met for every update
- App content declarations updated for any new SDK
- Test login credentials still valid
- End-of-week notes written
Keep the closed track alive
Closing your closed test after launch is a common mistake. It's the safest place to try fixes with people who already know your app. Keep your testers informed and keep using the track for every meaningful update.
If you're preparing another app on the same account and it still needs a closed test, our setup guide shows how to add GoPlayTester's tester group for a 14-day test with 12+ real testers on real devices. Google makes the final decision on production access.
