In-App Traffic and Mobile Ad Fraud: How to Spot Click Spamming, Click Injection and Device Farms

On the web, fraud is usually a bot pretending to be a browser. In apps it is more complicated: the fraudster controls not a page but an entire device, can fake the ad SDK's signals, and gets paid for installs and actions attributed to them. The general principles used to catch such schemes are covered in the article on what an anti-fraud system is. At the same time, in-app traffic is a legitimate and large market: ads in games and utilities pay app developers and give advertisers precise device targeting. The goal is not to give up on it but to learn to separate real users from in-app traffic fraud.

What is in-app traffic

In-app traffic is ad impressions and clicks inside mobile apps. The main formats:

This traffic is bought through ad networks and exchanges that aggregate thousands of apps. To an affiliate the source looks like a native or push network: a dashboard, a bid, GEOs, macros with the app or placement ID. The difference is where the click goes. If the offer is an app, the click leads to the store, and the install is recorded by a mobile attribution platform through an SDK inside the app. If the offer is a website, the click opens the page in an in-app browser or WebView.

Why there is more fraud in apps than on the web

The reasons lie in how the market works:

• Payment is for results, not impressions. The CPI model — pay per install — creates a direct incentive to claim someone else's install.
• Last-click attribution. An install is usually credited to the source of the last click before it. Whoever gets the last click in gets the money.
• A chain of intermediaries. Networks, exchanges and sub-networks sit between the advertiser and the app. Each layer adds opacity.
• The device is a full computer. A fraudster can run hundreds of real phones or thousands of virtual ones and control them programmatically.

The main mobile ad fraud schemes

Click spamming

Click spamming, or click flooding, is mass sending of fake clicks on behalf of many devices. A fraudulent app clicks on ads in the background even though the user never saw them. The math is simple: some of these people will eventually install a popular app on their own, and the install gets credited to the fraudster's last click.

Signs:

• a huge number of clicks with a tiny click-to-install rate;
• click-to-install time spread evenly over hours and days, without the typical peak in the first minutes;
• a high share of attributed users who behave like organic ones.

Click injection

Click injection is a more precise scheme typical of Android. A malicious app on the device detects that another app has started installing and fires a click at that moment. It becomes the last click before first launch and steals the attribution.

The sign is an abnormally short time between click and install: seconds in which a person physically could not have gone to the store, downloaded and opened the app. Another tell is a click arriving after the download has already started, if the attribution platform can compare those timestamps.

Emulators

An emulator is software that imitates a phone on a regular computer or server. It can run apps, click on ads and install offers without a single real person.

Signs:

• a data center or hosting network instead of a mobile carrier or home ISP;
• inconsistent device characteristics: model, screen, sensors and OS version do not add up to a real phone;
• uniformity: hundreds of different devices with identical parameters.

Device farms

A device farm is racks of real phones controlled by software or by low-paid workers. The devices are real, so emulator checks do not catch them.

Signs:

• many installs from a small set of IP addresses or a single subnet;
• identical post-install behavior: opened, did the minimum action, never came back;
• implausibly even activity across hours, without the daily rhythm of real people;
• resetting the device advertising ID so one phone looks like many new ones.

SDK spoofing and fake installs

The most technically advanced scheme: the fraudster studies what messages the attribution SDK sends to the server on installs and events and generates them directly, with no device at all. Attribution platforms fight this with message signing and integrity checks. For an affiliate, the sign is events that nothing else confirms: no revenue, no retention.

How to detect in-app traffic fraud

No single signal proves fraud on its own. Only a combination of signals works:

1. Network. A mobile carrier or home ISP is normal; a data center is almost always automation. How such addresses are detected is covered in the article on VPNs, proxies and data center IPs.
2. Timing. The distribution of time from click to install or to lead. Too short means injection; too flat and long means flooding.
3. Device. Consistency of model, OS, screen and browser. Automation signs are described in the article on headless browsers and fingerprinting.
4. Repeats. Number of clicks from one address and device per day.
5. Post-conversion quality. Retention, repeat actions, revenue. A farm delivers an install but no purchases.
6. Concentration. If almost all suspicious traffic comes from a few app placements, the problem is in them, not in the whole network.

A general breakdown of automation signs is in the article bot traffic: signs and how to spot it, and schemes that drain the ad budget are covered in the piece on click fraud.

Tip. Compare a suspicious source with a control one. If one placement's time to conversion, share of repeat clicks and retention differ sharply from the rest with the same GEO and creative, that is a reason to dig in, not a coincidence.

Tracking in-app campaigns

With in-app traffic it is important to set up tracking from day one so you can break results down by placement.

What to pass in the link. Ad networks fill macros into the link: the app or placement ID, campaign and creative IDs, device type, click cost, the network's click ID. Every network names its macros differently — check them in its help center. The principles of tagging are described in the article on UTM parameters and ad platform macros.

How to tie a click to a result. Your click ID has to reach whoever records the conversion — the affiliate network, the attribution platform or your site — and come back in the postback. More in the articles on click ID and sub ID and on the postback in affiliate marketing.

What to look at in the report. Not just installs or leads but the whole chain: clicks → reached the offer → conversions → confirmed conversions → revenue. Fraud often shows up at the last step: there are installs but no confirmations and no revenue. How to read statuses is explained in the article on conversion statuses.

In-app vs mobile web: the difference for filtering

Mobile web is a person who opened your landing page in the phone's regular browser. In-app is a person who tapped an ad inside a game or utility, and the page opened in the app's built-in browser. For a filter these are two different profiles:

Hence the rule: settings built for desktop or mobile browser traffic must not be carried over to in-app without testing. What looks suspicious on a website is normal behavior for a real app user.

What you can see in ArtisanClo

ArtisanClo filters and counts clicks on the ad link — what happens before the app store or the offer site. Installs and in-app events are recorded by the advertiser's attribution platform, but the quality of the click itself is visible before that.

• In-app browsers and WebView are recognized. An automation signal does not cut such a visit right away but is weighed in the trust score together with the network, timing and referrer: in these browsers it is often a false alarm. For campaigns where almost all traffic opens inside apps, pick the «Balanced» strictness and do not turn on blocking of visits without a referrer.
• Network checks. Blocking data center ASNs and visits without an ISP cuts emulators and server-side clicks that do not pretend to be a mobile carrier.
• A daily limit on clicks per IP from the Professional plan — against flooding from one address. On mobile addresses do not set it too tight: many subscribers can sit behind one carrier IP.
• A per-placement report. Pass the app or placement ID into a label, for example sub1, and open «Money by slice» on that label: clicks, conversions, revenue, cost and ROI for each app.
• A reason for every decision in the click log: «High-risk network», «Too many clicks from one IP», «A program, not a browser», «Headless browser detected» and dozens of others.
• Google Play deep link. If the offer is an app, you can set the offer address to market://details?id=package in «Redirect» mode.
• Duplicates. In flows with a tracker, a repeat lead from the same visitor via a different click within the uniqueness window goes to «Trash», marked as a duplicate.

Tip. If you suspect the filter is cutting real app users and you connect via the PHP file, turn on shadow mode for a few hours: everyone goes to the offer, and the log shows whom the filter would have cut. If the would-be-cut visitors include conversions, the rule is too strict.

What to do with a suspicious placement

1. Gather evidence. A placement report: clicks, filtered share and reasons, time to conversion, confirmations from the network.
2. Exclude the placement in the network's dashboard. Only that stops the spend.
3. Tell your network manager. Most networks have a process for investigating fraud and refunding invalid traffic, but it only works with facts.
4. Do not draw conclusions from one day. Delayed conversions are normal in apps, especially for subscriptions and in-game purchases.
5. Watch for repeats. Fraudulent placements often come back under a new ID. If a new placement shows the same profile, it is not a coincidence.

Common mistakes

• Optimizing for installs without revenue. Farms and injection deliver installs. Only users who stick around deliver money.
• Hard-blocking mobile IPs. Mobile carriers route thousands of subscribers through shared addresses; blocking a single IP will cut random people.
• A strict filter that ignores WebView. In-app browsers look unusual, and a rule designed for desktop will cut real mobile traffic.
• No placement ID in the link. Without it you cannot pinpoint fraud — the only option left is to kill the whole campaign.
• Treating the pass rate as a verdict. A high pass rate is normal for traffic with a verified click ID. It is alarming when almost no one reaches the offer.

In short

In-app traffic is a large, workable source, but mobile ad fraud works differently there than on the web: click spamming, click injection, emulators, device farms and SDK spoofing. You recognize it by the combination of network, timing, device, repeats and post-conversion quality. Pass the placement ID into a label, filter server-side and automated traffic, count money per app and switch off suspicious placements in the network itself. The catalog of sources ArtisanClo works with is on the traffic sources page.