Google Play Suspension and Account Termination: What Actually Happens

Google Play publishes four distinct actions — warning, rejection, removal and suspension — plus account termination above them, and the difference between two of them is the difference between a bad week and losing every rating your app has ever earned. Almost every article on this subject treats "banned" as one event. It is not.

The ladder, as set out in Google Play's enforcement process documentation:

Read the "your data" row twice. On a removal, your ratings and install statistics survive and come back when you resubmit. On a suspension, they do not. Google's wording is explicit that upon suspension users, statistics and ratings are forfeited permanently.

One more detail with a direct revenue consequence. On a removal, future subscription renewals are cancelled, and past charges are not refunded. If a subscription app is removed for a fortnight, that is not a fortnight of paused billing — it is a cohort of subscriptions permanently ended that must be re-acquired.

Because a removal pauses distribution while a suspension resets your accumulated social proof, and social proof is the one asset in app growth that cannot be bought back at any price.

Consider what an established listing actually holds. A four-year-old app with several thousand ratings at 4.4 stars has an install conversion rate built on that number. Its keyword rankings are partly a function of its install and retention history. Its paid acquisition works at the CPI it does because the store listing converts. None of that is in the binary. All of it is in the listing's accumulated record.

A removal preserves that record. You fix the violation, resubmit, and the ratings, statistics and users come back with you. The cost is the distribution you lost during the gap, which is real but bounded and measurable.

A suspension destroys it. You may publish a new compliant version — provided your account is still in good standing — but you publish it into a listing with no history. Every downstream number resets with it: conversion rate falls because there is no social proof, organic ranking falls because there is no install history, and paid acquisition becomes more expensive because the listing converts worse. In our portfolio the recovery from a suspension has consistently been measured in quarters rather than weeks, and the media cost of rebuilding is far larger than the revenue lost during the takedown itself.

Suspensions also accumulate. Google's documentation describes them as strikes against the standing of the developer account, arising either from egregious violations or from repeated rejections and removals. That creates a path that founders rarely see coming: a series of individually minor removals, each fixed and forgotten, escalating into a suspension, and multiple suspensions escalating into termination.

Every app you have is removed, you cannot publish again, and — the part that surprises people — any related developer accounts are permanently suspended alongside it. Termination is not a bigger suspension. It is a different category of event, and it reaches beyond the account that triggered it.

Google's enforcement process policy states the trigger plainly: multiple suspensions, or suspensions for egregious policy violations, may result in the termination of your Play Console account.

The consequence, quoted directly:

That final sentence is the one to sit with. Termination is not scoped to the offending app or even the offending account. Related accounts are permanently suspended too, and Google does not publish a precise definition of "related" — in practice it is understood to include signals such as shared payment instruments, shared contact details and shared infrastructure.

For a studio running several apps across multiple accounts, that turns a single app's violation into an existential event for the whole portfolio. It is also why the common structure of "keep the risky experiment on a separate account" provides much less protection than founders assume. If the accounts are linked by anything Google can see, they are related.

On appeals, Google states that you may submit one appeal per enforcement action, and that apps are reinstated in appropriate circumstances including where an error was made. There is a practical constraint worth knowing in advance: appeals are currently processed in Chinese, English, Japanese and Korean only.

What Google does not publish, at least anywhere I could locate at the time of writing, is a specific appeal deadline for account termination. Figures circulate in community threads. None of them appears in an official help article, so treat any specific number you read — here or elsewhere — as unverified, and appeal immediately rather than relying on a window you cannot confirm.

Because Google explicitly anticipates it, terminates the new account as well, and keeps the registration fee. This is the single most common piece of bad advice in founder communities on this subject, and Google's policy addresses it directly.

Three things follow from that sentence. The new account will be terminated. The fee is not refunded. And the attempt itself is visible — which means it becomes part of the record against you while an appeal on the original account may still be open.

The advice that circulates — new company, new bank account, new device, new everything — is describing evasion of an enforcement action, not a compliance strategy. Even where it appears to work initially, it produces a business built on an account that can vanish without recourse, which is a poor foundation for anything you intend to raise money against or sell.

The alternative is unglamorous and it is the only one that works: appeal the original decision properly, fix the underlying violation, and if the appeal fails, understand precisely why before making any further move. An appeal that is refused for a reason you have genuinely corrected is a different situation from one refused because the violation is ongoing, and only the first is worth pursuing further.

There is one legitimate structural point worth separating from evasion. If you operate genuinely distinct businesses — different companies, different products, different teams, different payment instruments — separate accounts are normal and appropriate. The problem is not having multiple accounts. It is having multiple accounts that exist to survive the loss of one.

At the top of it, because manipulation of ranking and reviews is treated as an integrity violation rather than a content one, and integrity violations are the category that escalates fastest.

Google's user ratings, reviews and installs policy prohibits attempts to manipulate placement through inauthentic installs, ratings or reviews. Both stores treat this as a matter of platform integrity rather than as a policy technicality, and both extend liability to work done on your behalf. Apple's App Review Guidelines are unusually direct about it, and the clause that matters most to anyone considering a vendor is this one:

"Or engage with third-party services to do so on your behalf" is the operative phrase. Contracting the work out does not move the liability. A vendor's assurance that their method is safe is not a defence, and the vendor does not lose their business when yours is terminated.

Apple's introduction to the guidelines puts the same point more bluntly still: attempting to cheat the system — including manipulating ratings or App Store discovery — results in apps being removed and the developer being expelled from the Apple Developer Program. Guideline 2.3.1(b) adds that egregious or repeated behaviour is grounds for removal from the programme.

Guideline 3.2.2(x) covers a related and more common own goal: apps must not force users to rate the app, review the app, or download other apps in order to access functionality or content. Incentivising in-app actions is permitted; incentivising store actions is not. Plenty of teams have built a rewarded flow that crosses that line without ever intending to buy a review.

We have written separately about how to evaluate an install vendor without crossing these lines and about the fraud signals that make bought traffic detectable in the first place. The point of this article is the other half of that conversation: what the downside actually costs, so it can be priced rather than waved at.

Apple's ladder is shorter and its top rung is harsher: expulsion from the Apple Developer Program, which ends your ability to distribute on iOS at all rather than merely closing one account.

The structural differences worth understanding:

• Apple gates before publication, Google gates after. Apple's review happens pre-release, so a large share of Apple's enforcement is rejection — an app that never shipped. Google's automated review admits more and enforces more after the fact, which is why live-app removals and suspensions feature more heavily on Android.
• Apple's terminal action is programme expulsion. Not an account suspension with a possible appeal into a new listing, but removal from the developer programme itself.
• Both extend liability to vendors acting on your behalf. Apple states this explicitly in Section 3. Google's manipulation policies operate the same way in practice.
• Google publishes the finer gradations. The four-rung structure with its explicit data consequences is more legible than Apple's, which is genuinely useful when you are trying to work out how much trouble you are in.

For a team shipping on both platforms, the practical implication is that the same growth tactic carries different failure modes. On iOS you are more likely to be stopped before launch; on Android you are more likely to be stopped after you have accumulated something worth losing. Our guide to the App Store rejection reasons that actually block launches covers the pre-release side, which is a different problem with a different remedy, and the first-publication guide covers the account setup that determines what is at stake later.

Across the 300+ apps we have managed since 2013, the teams that get into trouble here are rarely the ones deliberately gaming a store. They are teams that adopted a growth tactic from a competitor, or a vendor's standard package, without reading the policy that governs it — and who then discover that "everyone does this" is not a defence either store recognises.

Establish exactly which rung you are on, preserve the evidence, and resist the two instincts that make things worse — appealing immediately with a denial, and shipping a rushed update.

1. Identify the action by its name. Warning, rejection, removal, suspension or termination. The email uses one of these words and each has a different consequence and a different remedy. Everything else depends on this.
2. Screenshot and archive everything — the email in full, the Play Console policy status page, current ratings, install statistics and revenue figures. If ratings are about to be forfeited, this is the last moment they exist.
3. Find the specific clause cited, and read the policy it points to rather than the summary in the email. The remedy has to address the clause, not your interpretation of it.
4. Establish whether the violation is ongoing. If bought traffic is still being delivered, or a non-compliant SDK is still live, stop it now. An appeal filed while the violation continues will fail, and the attempt is on record.
5. Do not appeal yet. You get one appeal per enforcement action. Spending it on a first draft written in the first hour is the most common unforced error here.
6. Do not ship a hurried update in the hope of looking responsive. A rejected or removed update can compound the situation, and a new violation introduced in haste turns one problem into two.
7. Tell whoever needs to know. If revenue has stopped, finance needs to know today, not when the appeal resolves. If the enforcement relates to testing or release configuration, the closed testing requirements guide covers the setup that most often trips new accounts.

By making the reviewer's job trivially easy: name the clause, state exactly what changed, and give them something they can check without taking your word for anything. You have one appeal per enforcement action, so it should be written as evidence rather than as argument.

What a strong appeal contains:

• The specific policy clause cited, quoted back. This demonstrates you have read it and frames everything that follows.
• What was actually happening, stated plainly and without minimising. If a vendor was delivering incentivised traffic, say so. Reviewers see evasive appeals constantly and they are the easiest kind to refuse.
• What has changed, concretely. Contract terminated on a date. SDK removed in a named version. Endpoint disabled. Rewarded flow altered in a specific way. Dates and version numbers throughout.
• How they can verify it without trusting you — the build to inspect, the screen to open, the behaviour to reproduce.
• What prevents recurrence. A named owner, a review step before any acquisition contract, a policy check in the release process. This is the part that distinguishes a team that understood the problem from one that removed the symptom.

What to leave out: any argument that the enforcement was disproportionate, any comparison to competitors who do the same thing, any account of the commercial damage. None of it is relevant to whether the app now complies, and all of it consumes the reviewer's attention.

Write it, then leave it for a few hours and read it again as someone processing a queue of these. If the fix is not obvious within the first three sentences, restructure it. Note too that appeals are processed in a limited set of languages — Chinese, English, Japanese and Korean at the time of writing — so if you are drafting in another language, translate carefully rather than relying on the reviewer to.

Distribution is usually recoverable. Accumulated social proof, at suspension level and above, is not. Being clear about which is which is what lets you make a rational decision under pressure instead of an emotional one.

The asymmetry between the two columns is the entire argument for treating store policy as a growth constraint rather than a legal afterthought. Everything in the left column costs time. The top item in the right column costs the compounding asset your acquisition economics are built on.

There is a strategic decision hidden here that is worth naming. If your app is suspended and your ratings are gone, relaunching the same product into an empty listing is not the same business it was last week. Sometimes the right move is to relaunch anyway; sometimes it is to rebuild the product around whatever the users you still have actually valued. What is almost never right is to assume the previous trajectory resumes, because the input that produced it no longer exists.

By asking what happens to your listing's accumulated ratings if this goes wrong, and comparing that against what the vendor is actually promising to deliver. Framed that way, most incentivised install offers price themselves out immediately.

The pre-spend checklist we use:

1. Ask the vendor to name their traffic sources. A vendor who will not, or who answers in categories rather than names, is selling you traffic they cannot account for — and you carry the liability, not them. Google's app promotion policy is the clause that governs how an app may and may not be promoted.
2. Ask directly whether any part of the delivery is incentivised. Get the answer in writing. It is the single question that determines which side of the policy line you are on.
3. Read the clause that governs the tactic before signing, not after an email arrives. If you cannot find a clause that permits it, assume it is not permitted.
4. Price the downside honestly. Not "we might get a warning" but "if this becomes a suspension we lose every rating this listing has, and our CPI rises permanently as a result".
5. Check whether the tactic is separable from your account. Mostly it is not — which is the point of the related-accounts clause.
6. Decide who owns the policy check before any acquisition contract is signed, and make it a named person rather than a step in a document.

The uncomfortable conclusion is that the tactics most likely to trigger enforcement are also the ones most likely to be recommended to a founder under pressure to show traction. That timing is not a coincidence, and it is worth recognising in the moment.

The idea worth carrying out of this article is that "banned" is not one event with one cost. It is four different events with sharply different costs, and the gap between the third and fourth rung is where a recoverable setback becomes a permanent loss of the thing your growth was actually built on. Knowing which rung you are on — before you act, and certainly before you appeal — is the whole game. If you would rather have a vendor or a tactic assessed against policy before you commit spend than after an email arrives, send us what you are being offered.