Debugging log · Monetization

AdMob suspended my account for "invalid traffic"

One day the ads stopped and a message said my account was flagged for invalid traffic — ad serving limited or suspended. The instinct is to suspect a competitor or a bot attack, and occasionally that's real. But far more often, for a solo developer, the invalid traffic came from us: testing an ad-supported app the wrong way. This one is worth understanding before it happens, because prevention is far easier than appeal.

What "invalid traffic" means

AdMob pays advertisers' money for clicks and impressions, so it aggressively filters anything that looks inflated or non-genuine: a developer clicking their own ads, repetitive clicks from one device, bots, or users nudged to tap. When the filters decide a meaningful share of your traffic isn't trustworthy, they limit or suspend serving to protect advertisers. It isn't a judgment that you're malicious — it's the system refusing to bill advertisers for traffic it can't trust, and a new or low-volume account trips it more easily because there's little history to weigh against a burst of odd activity.

The self-inflicted causes (most common)

• Testing with real ad unit IDs. Every time you run your app in development and an ad loads, that's a real impression on your live unit — and if you tap it, a real self-click. This is the number-one cause for solo devs.
• Clicking your own ads, even "just to check it works." Don't, ever, on live units.
• Asking or incentivizing users to click — "tap the ad to support me," or placing ads where accidental taps are likely. Both count as invalid.
• Repeated impressions from one device during heavy testing on a live unit.

How to never cause it

• Use Google's test ad unit IDs during all development. They return real-looking ads you can tap freely with zero risk to your account.
• Register your dev devices as test devices so any real units in a build serve test ads to them instead of billable ones.
• Keep live ad IDs out of debug builds. Wire test IDs to debug and real IDs to release, so you physically can't generate live impressions while developing. (There's a companion write-up on this exact setup.)
• Never click your own ads, and never ask users to. Design placements so accidental taps are unlikely.

If you're already flagged

• Stop the cause immediately — switch all testing to test ads and test devices, and remove any click-encouraging text or risky placements.
• Read the policy notice in your AdMob account; it names the issue category and whether serving is limited or suspended.
• File the appeal if one is offered, honestly: explain what likely caused it and what you've changed to prevent recurrence. Vague or defensive appeals fare worse than a straightforward "I was testing with live IDs; I've moved to test ads and test devices."
• Be patient. Limited serving can lift after a review period if the invalid activity stops; wait it out rather than generating more odd traffic trying to test whether it's back.

AdMob's policy wording and appeal flow change over time; the principle — only genuine, un-encouraged user traffic on live units — is the stable part. This is general developer guidance, not account-specific advice.