Your App Installs Dropped Overnight: A Diagnostic

Check this first, because Google documents a history of statistics outages and corrections, and a reporting fault is indistinguishable from a business catastrophe on a chart. It takes two minutes and it has saved teams in our portfolio entire weeks of misdirected investigation.

Google's page on troubleshooting app statistics problems catalogues real incidents. A systems change in mid-2022 caused missed data across installs, acquisitions and engagement metrics, with partial recovery and some of it unrecoverable. Acquisition data was under-reported in an earlier period and corrected later. Deep link traffic was once incorrectly classified as organic Play Store traffic. Store listing preview installs were once not counted in Play Store search metrics.

So the first question is not "why did installs drop" but "did installs drop". Three checks settle it:

Also remember the definitional trap before you panic. Google defines install events as the number of times your app was installed including devices where it had been installed previously, while user acquisitions counts only users who did not have your app on any other device. Those two move differently, and a team reading one while quoting the other reaches the wrong conclusion. We cover the full set of definitions in why Play Console shows more uninstalls than installs.

Google has two enforcement actions that restrict distribution while leaving your app live and installable — Limited Visibility and Limited Regions — and neither affects your account standing, so neither looks like an enforcement event. This is the cause founders almost never check, because the app is right there when they search for it by name.

Google's documentation on its enforcement process defines them precisely:

The reason these hide so well is that every instinctive check comes back clean. The app is live. You can install it. Your account has no strike. If you search for your app by name while logged in on a device that already has it, everything looks normal — and the only thing that actually changed is whether people who were not looking for you can find you.

Google states that it provides relevant information about the action taken via email, along with instructions on how to appeal. So the notification exists. The problem is that it goes to whichever address is on the developer account, which in our experience is frequently a founder's personal inbox, a shared alias nobody reads, or an address belonging to someone who left. Check the Play Console policy status page directly rather than trusting that an email would have reached you.

If you find an enforcement action, the recovery path is a separate discipline — our guide to Play suspension and account termination covers the enforcement ladder and the appeal process.

If your app targets an old API level, Google restricts it to devices running the same or lower Android version — which removes you from every new handset without removing you from the store. This is the most under-diagnosed cause of a slow-then-sudden organic decline, and the current deadline is live right now.

Google's target API level requirements set out the mechanism. From 31 August 2026, existing apps must target Android 15, API level 35, or higher to remain available to new users on devices running an Android version higher than the app's target. Apps targeting Android 14, API level 34, or lower will only be available on devices running an Android OS the same as or lower than the app's target API level. New apps and updates must target Android 16, API level 36, or higher.

Read the consequence carefully, because it is unusually sharp for something with no notification attached. Your app does not disappear. It becomes invisible to anyone on a newer phone. Since new phones are disproportionately the devices being bought right now, your addressable market shrinks continuously from the day it applies — and the shape on your chart is a decline that accelerates rather than a cliff, which makes it easy to blame on competition or seasonality.

Google documents an extension route to 1 November 2026, with extension forms accessible in Play Console. Permanently private apps restricted to a specific organisation for internal distribution are exempt.

Google states that exceeding a bad behaviour threshold means Play may reduce the visibility of your title and may show users a warning on your store listing — so a bad release can suppress organic installs without anyone filing a bug. If your drop began within a few days of a rollout, start here.

The published thresholds are a user-perceived crash rate of 1.09% of daily users across all device models and 8% for a single device model, and a user-perceived ANR rate of 0.47% of daily active users across all models with 8% for a single model.

The per-device figure is the one that causes confusion during a drop investigation, because a team checks the overall crash rate, sees a healthy number, and rules technical quality out. A single popular handset breaching 8% is enough, and in markets where a handful of budget devices carry a large share of installs, that is not an edge case. Segment by device before you dismiss this.

Two properties of this cause shape how you investigate it. It is assessed on a 28-day basis, so both the onset and the recovery lag the underlying change by weeks — the release that caused it may be a month old. And it produces exactly the same chart shape as a demand problem, which is why it survives so many investigations that started by looking at marketing.

Our article on the vitals thresholds that decide distribution covers finding the responsible device and what to do about it, and why bad vitals act as a tax on acquisition covers what the same problem does to your paid numbers at the same time.

Installs are visitors multiplied by conversion, and confusing a conversion collapse with a traffic collapse sends you to entirely the wrong team. Play Console gives you both numbers, and separating them is the single highest-value split in this whole diagnostic.

If store listing visitors held steady while installs fell, your traffic is fine and something on the page stopped working. The usual candidates:

• The rating moved. Google states the rating users see is weighted toward more recent ratings, so a bad fortnight moves the displayed figure far more than a lifetime average would suggest. The rating is one of the most prominent conversion elements on the listing. Our piece on why app ratings drop covers the mechanism and the recovery.
• A quality warning appeared on the listing. The same vitals breach above can put a warning in front of every visitor.
• Someone changed the listing. Screenshots, icon, short description — a well-intentioned creative refresh that nobody A/B tested is a common and easily-reversed cause.
• Your app got bigger. Google documents that above 200MB, users on a mobile data connection see a dialog when installing informing them of the app's large size, and states that size can affect install and uninstall metrics.

If visitors fell and conversion held, the problem is upstream — discovery, enforcement, target API level, or paid delivery. That single fork eliminates roughly half the causes on this page in about a minute, which is why it belongs near the front of any real investigation.

If a meaningful share of your installs is paid, a campaign that stopped delivering looks exactly like an organic collapse on a blended chart. Split paid from organic before you conclude anything, because these are separate investigations with separate fixes.

Google's guidance on App campaign performance fluctuations lists ten causes: recent changes to account or campaign settings, conversion tracking setup and delay, bids and bid targets, budget settings, low creative coverage and diversity, targeting settings and overlaps, policy and ad review status, app status, other account issues, and auction dynamics.

Three of those deserve attention specifically in an overnight-drop scenario, because they can act instantly rather than gradually:

• Account issues. A billing failure or account suspension stops delivery immediately and completely. It is the first thing to check and the fastest to rule out.
• Policy and ad review status. New assets go back through review. A creative refresh shipped yesterday can put part of a campaign into a non-serving state today.
• Conversion tracking. If the signal your bidding depends on stopped arriving — a renamed event, an SDK change in a release — delivery degrades sharply and the cause is in your app rather than your ad account.

Note also that app status appears on Google's list, and its guidance under that heading is to check Android vitals for high crash rates and ANRs. The causes on this page are not independent: a vitals breach can suppress organic discovery and degrade paid delivery simultaneously, which is why a drop that hits both at once is more likely to be a product problem than a coincidence. Our full campaign diagnostic is in why your Google App campaign stopped spending.

Play Console breaks acquisition down by channel and country, and a drop concentrated in one of those is a completely different problem from a drop spread evenly across all of them. This is the check that turns a vague decline into a specific hypothesis.

Google's acquisition reporting separates channels including Play Store organic, Google Ads, UTM-tagged traffic, Google Search organic and third-party referrers, with country breakdowns, refreshed daily on Pacific Time. Read the drop through that lens and the shape tells you where to look:

The time-zone detail is worth holding on to during a fresh investigation. Reports refresh daily on Pacific Time, so "today's" number in your morning is a partial day measured on someone else's clock. We have watched more than one team declare an emergency over what turned out to be an incomplete day, and the check costs nothing.

One benign explanation belongs here too, and it is worth ruling in rather than out: seasonality and calendar effects. A festival, an exam period, a holiday, or the end of a competitor's campaign all move install volume without anything being wrong. Compare against the same period last year before assuming a fault — if you have a year of history, that comparison is more informative than anything else in this section.

Run the checks in order of how quickly each one can be eliminated, not in order of how likely you think each one is. The expensive mistake in a drop investigation is starting with the hypothesis you find most interesting.

That last step is the one that most often produces the answer, and the one teams reach for last. In our portfolio, the majority of sudden install drops with no obvious cause resolve to something that shipped — a release, a listing edit, a creative refresh, an SDK update — within the preceding week. Build the timeline before you build the theory.

Alerts on the four things that can restrict distribution silently, plus a change log you can line a chart up against. Every cause on this page is detectable before it becomes an emergency, and almost none of them announce themselves.

• Policy status, checked on a schedule. Limited Visibility and Limited Regions do not affect account standing and may not reach a monitored inbox. Someone should look at that page weekly, by name, as a task.
• Target API level, diarised annually. The requirement moves every year with a 31 August deadline and a 1 November extension. Put it in the roadmap in the first half of the year rather than discovering it in the second.
• Vitals with a device-level alert. Overall crash and ANR rates alone will not catch the per-model 8% threshold, and the 28-day assessment basis means an alert that fires late fires useless.
• Store listing conversion rate as a first-class metric. Visitors and installs plotted separately, so a conversion problem is visible on the day it starts rather than inferred a fortnight later.
• A change log everyone writes to. Releases, listing edits, campaign changes, SDK updates, pricing changes. Not a formal process — a dated list. It converts most of this diagnostic from investigation into lookup.

The change log is the highest-return item on that list and the one nobody wants to maintain. Across the 300+ apps we have managed since 2013, the difference between a two-hour diagnosis and a two-week one is almost always whether somebody wrote down what changed and when.

If your installs have dropped and the checks above have not localised it, that is usually a fast conversation for someone who has seen the pattern before — tell us what the chart looks like and when it started, or see how we approach store presence and organic discovery in our ASO work.