Surviving AdMob's Invalid Traffic Hammer: The Operator's Recovery Guide

The AdMob email arrives. "Your account has been suspended due to invalid traffic." No specifics. No actionable next step. Just a link to the policy page that lists everything AdMob considers invalid without telling you which one hit you. Ad serving stops. Pending revenue gets clawed back. Apps that were earning yesterday earn nothing today.

After watching this happen across dozens of apps in 15+ years of running mobile monetization, including a stretch at Unity managing more than $150M a year in ad revenue, the pattern is consistent. The trigger is almost always one of five specific patterns. Google's appeal process works if you write the appeal correctly. And there is a prevention pattern most developers only learn after their first suspension.

This guide covers all three. What invalid traffic actually means, the five patterns that trigger suspensions, how to write an appeal that has a real chance of succeeding, and what to do if the appeal fails. If you got the suspension this week, start with the appeal section. If you are reading this preventively, the prevention pattern is the part that matters.

What "invalid traffic" actually means (and why Google stays vague)

Google's definition is broad on purpose. From the policy page: any traffic that does not reflect genuine user interest. In practice this covers everything from clear fraud (bot installs, click farms) to legitimate user behavior that looks like fraud (sudden viral growth, a single high-engagement user). The reason Google does not differentiate publicly is that detailing the exact thresholds would let bad actors stay just under them.

The practical implication is that AdMob's invalid-traffic detection is a black-box scoring system. You do not get to see your score. You do not get told which signal tripped. You see the outcome (suspended, limited, or terminated) and the rest is inference.

The good news: the patterns that consistently trigger the system are knowable from the publisher side. They are documented across Google's policy pages, the AdMob blog, and years of community-thread evidence. The five below cover the vast majority of suspensions I have seen.

The 5 patterns that actually trigger an invalid-traffic suspension

Pattern 1: Bot traffic from cheap user-acquisition networks

The most common pattern. A developer buys installs from a low-cost UA network promising massive volume at $0.50 CPI or less. A meaningful percentage of those installs turn out to be bots: SDKs running in emulators on a server farm, mimicking real users, generating fake ad impressions and fake clicks. Google's detection catches the pattern and suspends the account.

The trigger: a sudden spike in installs from a single source with abnormally consistent session lengths, click-through rates, or device fingerprints. The signal looks like a real install pattern to your MMP (Branch, AppsFlyer, Adjust) at first, then turns sour as the post-install behavior shows the bot pattern.

How to spot it after the fact: pull your MMP install reports for the 30 days before the suspension. Look for any UA source that contributed more than 20% of installs at a CPI significantly below market. That source is almost certainly the trigger.

Pattern 2: Incentivized installs misclassified as organic

Some UA networks offer "rewarded installs" where users get in-app currency for installing your app from a third-party rewards platform. AdMob policy says this is fine if labeled as such and routed through the AdMob mediation flow. It is not fine if those installs are reported to AdMob as organic users (which gives them a much higher trust score than they should have).

The trigger: AdMob detects that users from a specific install source have systematically lower engagement than your true organic users (shorter sessions, lower retention, predictable interaction patterns) while being labeled organic. The mismatch flags the account.

How to spot it: look at your MMP attribution for the 30 days before suspension. Any source flagged as "organic" but with retention curves that fall off a cliff at the reward-eligibility window is the issue.

Pattern 3: Click-farm integration via "watch ads to earn" schemes

A subtler version of Pattern 1. The user is real (or human-real-enough to pass basic detection), but the app integration encourages or pays for ad views and clicks. Examples: an app that gives in-app rewards for watching rewarded video, where the reward is too high relative to ad revenue. An app that runs as the "watch ads" component of a larger rewards platform. An app where users are paid in cryptocurrency or gift cards proportional to ad engagement.

The trigger: ad engagement (CTR, video completion, time on ad) that is far higher than the comparable benchmark for the app category. Reviewers and the automated system both flag this. It is one of the highest-conviction suspension patterns because the financial incentive structure makes it intentional, not accidental.

Pattern 4: Self-clicks during development that were not isolated from the production app

A developer integration tests the SDK with the production ad unit ID instead of Google's test ad unit IDs. Every click during development counts as a real click on a real ad. Google's invalid-traffic detection sees a small set of devices generating outsized clicks on a single ad unit and flags it.

The trigger: an unusual click-to-impression ratio on a specific ad unit, especially during the first 30 days when the account is in the new-account validation window. Even five test clicks across a few sessions can be enough.

How to spot it: cross-reference your suspension timing with any recent development or QA work that touched ad-loading code. If you were testing ads in a debug build with live IDs, that is the trigger.

Pattern 5: Sudden CTR or session spike that looks like manipulation but may be legitimate

The trickiest pattern because it can be triggered by real success. Your app gets featured in a YouTube video, goes viral on TikTok, gets picked up by a popular Reddit post. Suddenly your daily active users 10x. Your ad clicks 10x. To AdMob's detection system, this is indistinguishable from a manipulation pattern in the first 24-48 hours, before the underlying behavior data confirms the growth is real.

The trigger: any 24-hour window where your ad-related metrics deviate from your trailing 30-day baseline by more than a few standard deviations, especially in a new account or after a quiet period.

How to spot it: look at your store analytics, MMP data, or any external traffic source for the suspension window. If you can show a legitimate cause for the spike (press mention, organic viral moment, featured placement), this is the most appeal-friendly pattern of the five.

How to identify which pattern hit you

The single best signal is timing cross-referenced with what changed. If the suspension came:

• Within days of starting a new UA campaign: Pattern 1 or 2.
• After integrating a third-party rewards or earn platform: Pattern 3.
• In the first 30 days of the account, after development work touched ad code: Pattern 4.
• Right after a viral moment or sudden traffic spike: Pattern 5.
• With no obvious recent change: most likely Pattern 1, where bot traffic accumulated slowly enough to look organic until a threshold tipped.

The AdMob console gives one weak signal: the date the suspension took effect. Use that as the anchor and look back 7-14 days at what changed. The trigger is almost always in that window.

If you genuinely cannot identify the pattern after this exercise, the appeal section below covers what to say in that case (it is a legitimate appeal angle on its own).

Writing the appeal that actually works

Google reads appeals. Humans read appeals. The system is not a black hole. The appeals that succeed share four elements. The appeals that fail tend to share the same mistakes (denying the issue, blaming Google, using generic language, demanding to know specifics Google will not share).

Here is the structure that works:

Step 1: Open the appeal form via the AdMob console. Navigate to Account > Account status, find the suspension notice, and click the appeal link. The form is a single text area with a 1000-2000 character limit depending on the appeal type. Do not use any other channel (no Twitter, no separate email) for the formal appeal.

Step 2: State the facts. No denial, no blame. Open with one sentence acknowledging the suspension. Then state the facts: when it took effect, what you understand the cause to be (your best guess from the pattern triage above), and what your account history looks like. Do not start with "this was unfair" or "you are wrong." Google's reviewers see hundreds of those a week and they all read the same.

Step 3: Include traffic-source documentation. This is the highest-leverage part of the appeal. Pull your MMP reports for the 30 days before the suspension. Show the source breakdown. If the trigger was Pattern 1 (bot traffic from a UA network), name the network and show the data that confirms it. If the trigger was Pattern 5 (viral spike), include the external link (the YouTube video, the news article, the Reddit thread) that explains the spike. Concrete external evidence moves appeals.

Step 4: Outline the corrective actions you have already taken. Past tense. Not "I will." Not "I am planning to." "I have removed the X UA campaign and replaced it with Y reputable network." "I have audited my ad placements and removed the rewarded video integration from screen Z." "I have isolated my development environment from the production ad unit IDs going forward." Reviewers look for actions that prove the problem will not recur.

Step 5: Submit and wait 7-14 days. Do not resubmit a near-identical appeal during this window. Doing so resets the queue position and can flag the account as appeal-spam. If you genuinely have new evidence after submission, wait for the first response before sending a follow-up.

The appeal success rate when these five elements are followed and the underlying cause was a fixable Pattern 1, 2, or 5 is meaningful, on the order of 30-50% in my experience. The success rate drops for Pattern 3 (which Google treats as intentional) and is rare for accounts with a history of multiple suspensions.

The prevention pattern

If you have not been suspended yet, the prevention pattern is straightforward and most of it is upstream of AdMob entirely.

Pick UA networks carefully. The single biggest preventable cause is buying installs from networks that turn out to source from bot farms. Reputable networks (UAC, Meta, AppLovin, Unity Ads, ironSource, TikTok Ads) have skin in the game on traffic quality. Networks promising massive volume at unrealistic CPI without showing retention and event data are the highest risk.

Set up real-time alerts for suspicious patterns. Your MMP should be able to alert you on sudden CTR spikes, sudden session-length anomalies, or sudden traffic from a single source. If you cannot afford the MMP's premium alerting tier, a manual weekly review of your top 5 UA sources catches most issues.

Isolate development from production. This is the easiest fix. Google publishes test ad unit IDs for every format. Use them in debug builds. Switch to live IDs only in production builds. Wire this with a build-config flag so it cannot be wrong by accident.

Monitor your supply-chain health. A separate but related concern: the ads.txt and app-ads.txt files on your developer website determine which SSPs and resellers can monetize your inventory. Unauthorized entries (or sloppy reseller chains) can create invalid-traffic signals on your inventory that originate downstream. My own product, Beamflow, monitors ads.txt and sellers.json hygiene for publishers; alternatively, audit your file monthly by hand.

Run the AdMob Approval Checker periodically. It covers the prevention checklist for app-ads.txt setup, store listing health, and the "using-official-AdMob-SDK" check that prevents Pattern 3 issues.

What to do if the appeal fails

If the appeal is denied, the realistic options are limited. The single worst move is to create a new AdMob account. Google's account-deduplication detects this via IP, browser fingerprint, payment method, and tax ID. The new account inherits the suspension flag, often permanently. Doing this can also blacklist your apps from being approved by any future AdMob account you create, even years later.

The realistic options:

• Switch to a different mediation platform as primary. AppLovin MAX, Unity LevelPlay (formerly ironSource), and Mintegral are the main alternatives. The decision framework between them is covered in AdMob Mediation vs AppLovin MAX.
• Run AdMob secondary inside a mediation platform that does accept your app. AppLovin MAX, for example, will often allow AdMob as a mediation source even when your direct AdMob account is suspended, because the mediation platform itself takes responsibility for inventory quality.
• Take a 6-12 month pause and reapply with a clean traffic source. Some accounts do come off the suspension list after a long enough quiet period, especially if the original cause was a third-party UA network that has since been investigated by Google directly.
• Move to a different monetization model. If your app has a real audience, in-app purchases, subscriptions, or sponsorships can replace ad revenue. This is not a fast pivot, but it preserves the app and the audience.

The realistic timeline to recover from a Pattern 1 or 5 suspension is days to weeks if the appeal works, months if it does not and you have to rebuild on a different mediation platform. Pattern 3 (incentivized engagement) is closer to permanent on the AdMob side.

TL;DR + the prevention checklist

The fast version:

1. Identify the pattern. Cross-reference the suspension date with what changed in the 7-14 days prior. Most common: a new UA campaign sending low-quality installs.
2. If you have been suspended, file the appeal using the 5-step structure above. State facts, include MMP documentation, list corrective actions in past tense, wait 7-14 days.
3. Do not create a second AdMob account. Google detects it and the new account inherits the suspension.
4. For prevention, audit your UA sources monthly, isolate development from production with test ad unit IDs, monitor your app-ads.txt and ads.txt hygiene, and run the AdMob Approval Checker periodically.

If you want full context on AdMob rejections beyond invalid traffic, the AdMob rejection reasons guide covers all eight patterns including this one.

Frequently asked questions

How long does an AdMob invalid-traffic appeal take?

Typical response time is 7-14 days. Complex cases (especially Pattern 5 viral-spike appeals requiring external documentation review) can take 30+ days. Do not resubmit during the wait; it resets the queue position.

Can I appeal more than once if the first appeal is denied?

Yes, but only with new evidence. Submitting the same appeal again gets ignored or flagged as appeal-spam. If you submitted an appeal that was denied, wait at least 30 days, gather new evidence (additional MMP data, third-party verification, documented corrective actions), and submit a clearly differentiated second appeal.

What's the difference between "account suspended" and "ad serving has been limited"?

Different severity. "Limited" means soft-throttle: ads still serve but at reduced volume while Google validates traffic quality. This often resolves automatically within 30-60 days of consistent good traffic. "Suspended" means hard-stop: no ads serve, the account is non-functional until appeal succeeds. The two have different escalation paths.

If my appeal is denied, can I create a new AdMob account?

No. Google detects new-account creation through IP address, browser fingerprint, credit card, tax ID, and sign-up patterns. The new account inherits the suspension flag and can be permanently blacklisted. Worse, it can prevent any future AdMob account you legitimately try to create. The realistic path is appeal again with new evidence, switch to a different mediation platform, or wait the suspension out.

Will switching to AppLovin MAX or Unity LevelPlay save my app if AdMob suspended me?

Sometimes. It depends on the trigger. If the issue was specific to AdMob's policies (Pattern 3 in particular), other networks may have similar policies and reject too. If the issue was traffic-quality with a specific UA source, switching mediation does not fix the underlying issue, but a different mediation platform may have more lenient traffic-quality scoring. AdMob can sometimes still be run as a secondary network through AppLovin MAX even with a direct-account suspension.

Does using Google's "Invalid Activity Filter" prevent invalid-traffic suspensions?

Helps but does not guarantee. The Invalid Activity Filter is reactive (filters out invalid clicks after they happen). Suspension triggers fire on upstream patterns the filter sees but does not stop. Prevention has to happen at the UA source and integration level, not just the filter.

Why did my account get suspended for invalid traffic when I haven't done anything fraudulent?

Pattern detection, not intent. AdMob's system flags statistical anomalies, not intent. Legitimate viral growth, accidental self-clicks during testing, or a sudden traffic shift from an external source can all look like manipulation in the first 24-48 hours of data. The appeal process exists for exactly this case: documented evidence of a legitimate cause moves appeals.

If your AdMob account is suspended and you want a second pair of eyes on the appeal draft, the free 30-minute call is the starting point: book a call. Best fit for apps doing $10K+/month in ad revenue, though anyone is welcome to read the guides and run the checkers.