AdMob Invalid Traffic in 2026: 8 Questions About Ad Serving Limits, Deductions, and Recovery

AdMob does not tell publishers which clicks it removed or how much each app lost. What it does publish is the rulebook: what counts as invalid traffic, what happens when it is detected, and why the number in your report will never match the number in your payment. Read as a system, those pages answer most of the questions publishers send us after a serving limit or a sudden earnings drop.

These eight questions are the ones that actually decide whether an appeal is worth filing and whether the account survives. Every answer below is anchored in Google's own policy text, not in forum folklore.

Google defines invalid traffic as any clicks or impressions that may artificially inflate an advertiser's costs or a publisher's earnings, and it explicitly covers both intentionally fraudulent traffic and accidental clicks. The published examples are narrow but they land on real implementations:

• clicks or impressions generated by publishers clicking their own live ads;
• repeated ad clicks or impressions generated by one or more users;
• publishers encouraging clicks, including any in-app language that asks users to click, or implementations that cause a high volume of accidental clicks;
• automated clicking tools, traffic sources, robots or other deceptive software.

The part most teams miss is the closing sentence: clicks on Google ads must result from genuine user interest, and any method that artificially generates clicks or impressions is prohibited by the program policies. That is a behaviour rule, not a list you can check off.

Yes, and it is the single most common self-inflicted case we see. Google's prevention guidance states plainly that publishers may not click their own ads or use any means to inflate impressions or clicks, that testing your own ads by clicking them is not allowed, and that clicking too many ads without test mode can flag the account.

The correct path is test ads: either one of Google's sample ad units, or your own ad unit with test mode enabled on Android or iOS. Development traffic should never touch a live unit, and that includes the build you hand to a QA tester who taps through the flow twenty times.

Three escalating outcomes are documented. If Google observes high levels of invalid traffic on an account, it may suspend or disable the account. If it cannot verify the quality of the traffic, it may limit or disable your ad serving — that is the serving limit publishers notice as falling fill and rising unfilled requests, not as an email. And because invalid activity is deducted before payment, you will also see a gap between estimated and finalized earnings.

Separately, the AdMob policies page states that Google reserves the right to disable ad serving to your app and/or disable your AdMob account at any time for non-compliance, and that an account disabled for policy reasons is not eligible for further participation in the AdSense and AdMob programs. That last clause is the one to read before improvising an appeal.

Because the reports are estimates until the end of the month, when Google adjusts for invalid clicks and impressions and refunds that revenue to the affected advertisers. You are paid on finalized earnings, which appear in payments and transaction history — see estimated vs finalized earnings.

Two details matter for your bookkeeping. First, a small difference can be pure time zone: reports are shown in your account time zone, while finalized earnings and payments are calculated in the AdSense billing time zone, America/Los_Angeles. Second, Google also reserves the right to adjust earnings when an advertiser defaults on payment, for example after using stolen cards. A gap is not automatically your violation — but a recurring gap on one app is a signal worth investigating.

No, and this is by design rather than by neglect. Google states that to maintain the integrity of its detection system and prevent circumvention, it is not able to provide details on what activity it noticed in your account, nor how much was adjusted per day or per app. The systems overview explains the filtering approach — automated plus manual — without handing out the thresholds.

Practically, this means an appeal that demands "show me the bad clicks" cannot succeed. What can succeed is a submission that shows the implementation itself is sound and that no purchased or incentivised traffic is reaching the app.

Start with traffic provenance, not with ad code. Google's own checklist is to use Analytics in AdMob to investigate changes in traffic sources over the last 90 days, and to look for spikes in traffic or downloads from unknown sources. Then review the implementation guidance, because invalid clicks frequently come from poor ad implementation rather than from an attacker — poorly placed interstitials in particular are called out as a generator of accidental clicks.

The uncomfortable question to answer honestly: did anyone pay for installs or engagement in that window, or run an incentive that rewards taps? Paid traffic from unreliable sources is explicitly named as a publisher responsibility.

Google acknowledges that a third party may generate invalid traffic without your knowledge or permission. It then says the same sentence every time: ultimately it is your responsibility as the publisher to ensure the traffic on your ads is valid. Reporting is possible — there is a form for suspected third-party invalid click traffic that routes to the traffic quality team — but reporting does not transfer liability.

What actually helps is evidence: the Analytics source breakdown, the app versions involved, and any change in placement or mediation partner in the same window. A report without that context reads like a guess.

Work in this order, and do not skip the first step because it is unglamorous.

1. Stop the bleeding: pull live units from development and QA builds, confirm test mode is on everywhere except production.
2. Fix placement: move interstitials away from accidental-tap zones, and re-read the interstitial and banner implementation guidance against your current layouts.
3. Audit sources: cut any traffic source you cannot name, and reconcile the 90-day Analytics spike against your own release and campaign dates.
4. Correct the record: if an ad unit, mediation partner or SDK was misconfigured, document what changed and when — this is the only substantive content an appeal can carry.
5. Assume the limit outlives your fix. Serving limits and deductions are applied by systems you cannot query, so plan revenue around the corrected baseline rather than the pre-limit peak.

Policy text quoted from Google AdMob Help, checked on 2026-10-22. Enforcement thresholds are not published and are not inferred here.