Ad Fraud — Ad fraud (Mobile Unwanted Software)

This covers apps engineered to generate fraudulent ad interactions: clicks the user never made, ads rendered off-screen or behind other content, or impressions inflated through automated means, all of which defraud advertisers paying for real engagement.

Often traced to an ad SDK configuration that stacks multiple ad units invisibly to farm impressions, sometimes without the app developer realizing the SDK was doing it.

The short version, in more detail

The ad-fraud policy covers apps that generate fraudulent ad activity: clicks that users did not make, ads displayed where they cannot be seen, or impressions inflated through automation. These behaviours cheat advertisers who pay for genuine engagement. Many cases come from the way an ad SDK is configured, sometimes without the developer realising what the library is doing.

Why this rule exists

The advertising system rests on trust that an impression or click represents a real person seeing or choosing something. Fraud erodes that trust and drains money from advertisers, which in turn damages the market that funds free apps. Google treats ad fraud as a serious abuse and holds publishers responsible for what their apps display, because the people best placed to prevent it are those who control the app.

What this guideline covers

• Fake or automated clicks and impressions.
• Ads placed off-screen, hidden or stacked behind other elements.
• Ads loaded without the user's knowledge.
• The behaviour of ad SDKs in the app.

What usually triggers this rejection

• An SDK configuration that stacks several ad units invisibly.
• Ads rendered behind content or outside the visible area.
• Programmatically triggered clicks.
• Refreshing ads so often that impressions are inflated.
• Traffic patterns that look automated.

How reviewers evaluate it

• Automated systems analyse ad requests and interaction patterns.
• Advertisers and ad networks can report suspicious traffic.
• Reviewers inspect how ads are displayed in the app.
• Responsibility lies with the app even when an SDK is at fault.

Common misunderstandings

• Not knowing what an SDK does is not a defence.
• Fraud does not require intent on the developer's part to be actionable.
• Low volume does not make the behaviour acceptable.

Common questions