A rack of two hundred real phones in a rented room and a script on a rented server sell the same product: an audience that was never there. In reporting, they look almost identical: a block of impressions and clicks that turns into nothing. Device farm fraud runs on real hardware: real handsets, real sensors, real identifiers, often on ordinary home broadband. Emulated bot traffic runs on software describing a device it does not have.
The first passes nearly every ‘is this a real device’ test and gives itself away through behavior and location. The second scales for almost nothing and gives itself away through its environment.
Which is why emulator detection and device farm detection are not interchangeable settings on the same dial. What follows compares the two models by cost, by the traces they leave, and by which signal class catches which – plus the overlap zone that flags both, the false positives that punish real users, and why both count as sophisticated invalid traffic.
Contents
- The Rack of Real Phones: What Physical Hardware Buys an Operator
- Emulated Bots: Cheap Scale on Borrowed Ground
- Device Farm vs Bot Traffic: The Trace Each One Leaves
- Which Detection Signal Class Catches Which Threat
- When the Hardware Belongs to Someone Else
- The Economics Behind Which Method an Operator Picks
- Why a Stack Tuned for One Threat Goes Quiet on the Other
- What Neither Signal Class Resolves Cleanly
- FAQ
- Two Threats, One Line Item
Key Takeaways:
- Device farms pass device integrity checks because the hardware really is a phone. Their traces live in behavior, sensor data, and geolocation.
- Emulated bots fail environment checks (build strings, missing sensors, graphics mismatches, hosting addresses), but scripted behavior can be tuned to look ordinary.
- Only a narrow band catches both: late conversion quality, placement concentration, event timing. That band confirms waste without naming the method.
- Compromised consumer hardware is the hard middle case: real devices and residential addresses at botnet scale.
- Both threats count as sophisticated invalid traffic (SIVT), where IAB and MRC guidance calls for advanced analytics and multi-point corroboration.
The Rack of Real Phones: What Physical Hardware Buys an Operator
A device farm is a room of real handsets wired to power and to a network, driven by automation tools, by paid workers tapping screens, or by both. Every phone reports a genuine model, operating system build, advertising identifier, and sensor stack, because all of it is genuine. That is what the expense buys: device integrity checks ask whether the sender is a real consumer device, and a farm answers yes truthfully. Root and jailbreak checks pass, and the fingerprint belongs to a phone that exists.
In practice, teams looking at farm traffic for the first time hunt for a device tell and find nothing. The tells sit one layer up. Hundreds of handsets in one room share a location within a few meters, share an uplink, charge continuously, sit still so the accelerometer reads almost nothing, and go quiet when the shift ends.
Cost is the limit. Hardware, power, space, and staff all scale with volume, so every extra unit of fake traffic costs money.
Emulated Bots: Cheap Scale on Borrowed Ground
An emulated bot is software describing a device it does not have: a mobile emulator running an app image, a headless browser with no screen attached, or a scripted client that speaks the ad request protocol and skips rendering entirely. It runs on rented compute, so a thousand instances cost what one costs, multiplied.
The economics run opposite to the farm. Setup is a template, scale is a configuration value, and a block costs a rebuild rather than a capital purchase.
What software cannot supply is the physical layer. Emulator images carry build and kernel strings no shipped handset carries, the graphics driver string does not match the claimed model, and motion sensors are absent or return constants. Residential proxy services close the network gap, which is why address reputation alone stopped being a reliable answer. The device gap stays open.
Device Farm vs Bot Traffic: The Trace Each One Leaves
The two threats invert each other at nearly every layer.
| Layer | Device Farm (Real Handsets) | Emulated Bot (Software) |
|---|---|---|
| Device signals | Genuine and consistent, passes integrity checks | Imitated, and it leaks in build, graphics, and sensors |
| Network origin | Consumer broadband or carrier, one uplink for many devices | Hosting ranges, unless routed through residential proxies |
| Behavior | Human-driven, with unnatural sameness across devices | Scripted, and tunable toward realistic variation |
| Geolocation | Tightly clustered and repeating | Whatever the proxy says, so it can look correct |
| Cost of the next unit | High: hardware, power, space, staff | Near zero: a configuration change |
| What usually breaks it | Sameness across a population | Inconsistency inside one request |
Both land in the same reporting bucket. The IAB and MRC invalid traffic detection and filtration guidelines addendum separates general invalid traffic (GIVT), which routine list-based checks remove, from sophisticated invalid traffic (SIVT), the category the guidance treats as needing advanced analytics and multi-point corroboration. Both of these threats sit on the SIVT side, for opposite reasons.
Which Detection Signal Class Catches Which Threat
Detection signals fall into four families.
- Environment and device integrity signals read what the client claims to be: build strings, driver names, sensors, browser properties;
- Behavioral signals read how a session moves: touch timing, scroll rhythm, dwell time, variance between sessions.
- Place and network signals read where the request came from: address class, carrier, geolocation consistency, how many identifiers share one uplink;
- Outcome signals read what happened afterward: installs opening, purchases repeating, anyone coming back.
Emulated bots are cheapest to catch in the first family, because the imitation is thin and one request can carry the contradiction. Device farms are catchable mainly in the second and third, and rarely on a single request: one phone tapping a banner looks like a person tapping a banner, which it partly is, so the evidence sits in the population.
The map below sorts the working signals into the three groups that matter for a buying decision, including the shared band that catches both threats and names neither.
Which Signals Catch Which Fake Audience
Signal classes rarely transfer between the two threats. The shared band is narrow.
Device Farms Only
Racks of real handsets
- Geolocation repeats one address
- Devices always report charging
- Motion sensor data stays flat
- Touch and swipe timing is uniform
- Ad identifiers reset in batches
- Activity follows shift windows
- One Wi-Fi name is shared by hundreds
What it proves Behavior and place expose coordinated activity across real devices.
What it cannot prove Device integrity checks alone may still read this traffic as legitimate.
Overlap Zone
Catches both, names neither
- Late conversion quality drops
- Volume sits on a few placements
- Click-to-action gaps are too short
- No organic return visits appear later
- The event mix is identical every hour
What it proves The traffic or its outcomes are abnormal.
What it cannot prove It does not identify which of the two threats caused the pattern.
Emulated Bots Only
Software on rented compute
- Emulator build and kernel tags appear
- The graphics string fits no handset
- The entire sensor stack is missing
- The address belongs to a hosting or data center range
- Headless browser traits leak
- Screen and battery values are inconsistent
- Thousands of devices appear in one minute
What it proves The reported client environment contradicts a real handset.
What it cannot prove Scripted behavior can still pass when the environment is well disguised.
The Failure Mode in Both Directions
Tune only for emulated bots and a rack of real phones can still read as clean traffic.
Tune only for device farms and a fresh emulator template can pass straight through.
When the Hardware Belongs to Someone Else
The cheapest way to obtain real hardware is not to buy it.
In June 2025 the FBI issued public service announcement I-060525-PSA, warning that internet-connected consumer devices on home networks were being used for criminal activity through the BADBOX 2.0 botnet. The products named include internet-connected TV boxes, digital projectors, aftermarket vehicle infotainment systems, and digital picture frames, most manufactured in China. Devices arrived with malicious software already installed, or were infected during setup.
HUMAN Security, which contributed intelligence to that alert alongside Google, Trend Micro, and the Shadowserver Foundation, describes the compromised hardware as devices running the open source version of Android, and the disclosures put the affected population in the millions of devices. The botnet generated fraudulent ad requests and click activity, and it sold access to the compromised home networks as residential proxy capacity. Disruption came in stages through 2025 – ad-platform blocking, Play Protect warnings, and a July 2025 Google lawsuit against 25 China-based entities – and the researchers call it partial, since none of it reaches hardware that ships pre-infected.
Read that against the signal families. Every device is genuine hardware on a genuine residential connection in a plausible location, scattered across households instead of clustered in one room. Environment checks pass, place checks pass, and behavioral clustering weakens. What is left is device-level behavior, an appliance requesting ads while nobody is using it, plus threat intelligence naming the infrastructure.
The Economics Behind Which Method an Operator Picks
Method selection follows cost. A farm is expensive per unit and cannot be rebuilt overnight, so it gets pointed at expensive outcomes: installs, in-app events, anything inspected at the device level. An emulated fleet is nearly free per unit and disposable, so it gets pointed at volume.
Compromised consumer hardware breaks that trade-off. It delivers the device realism of a farm at close to the marginal cost of software, because someone else already paid for the device, the connection, and the electricity. For buyers, that traffic is hardest to trace back to a source in unfiltered open programmatic supply and in long chains with opaque resellers.
Cost, Scale, and How Real the Hardware Is
Schematic only. Positions are illustrative and do not represent measured values.
Cost to run High cost → near-zero cost
Reachable scale One room → botnet scale
On-Premises Device Farm
Real handsets on real home broadband. Every extra unit requires more hardware and power.
Compromised Consumer Devices
Real hardware and residential addresses, while someone else pays for the phone and power.
Emulated Bot Fleet
An imitated environment that can be launched in minutes on rented compute and rebuilt cheaply after a block.
Real hardware: the revealing traces sit in behavior, sensors, and place.
Real hardware at botnet scale: the hardest model to separate from genuine users.
Imitated hardware: the revealing traces sit in the reported environment.
Why a Stack Tuned for One Threat Goes Quiet on the Other
A strong device check can make a farm more profitable rather than less. A scoring pipeline can treat a passed integrity check as evidence of quality, or skip expensive behavioral scoring to protect response time. A rack of stock handsets does not merely survive the device check; it collects a trust credit and spends that credit at every stage after. The better the hardware verification, the more it is worth to an operator to use real hardware.
The reverse failure is quieter and just as expensive. Rules built on location and sameness (one address serving too many identifiers, geolocation that never moves, activity confined to office hours) do nothing to an emulated fleet routed through residential proxy capacity in the target city. Each instance presents as one device on one home connection in the right place.
This is a real conflict rather than a gap someone forgot to close. Hard environment enforcement raises false positives on real users: custom builds, privacy-hardened devices, hardware too old to report a full sensor stack. Loosen it and the emulated fleet gets easier to run. The requirement is knowing which threat the current setting leaves alone.
What Neither Signal Class Resolves Cleanly
False positives cluster in the same places for both models. Managed corporate device fleets share an uplink, a location, a configuration, and a working-hours pattern, which is the farm shape almost exactly. Internet cafes and phones on institutional Wi-Fi produce similar identifier density. Meanwhile developers run emulators and quality assurance teams run headless browsers, both legitimately.
Sensor evidence is thinner than it sounds. A phone reading flat on a shelf in a farm and one flat on an office desk produce the same reading. These signals carry weight in combination and across a population, almost none alone, which is why analysts who work these cases distrust single-signal certainty first.
Two constraints are worth stating plainly. Networks and verification vendors do not publish which signals fired on a flag, and they should not, because naming the signal is how an operator learns what to change next. And no filter reaches zero, so the working question is whether residual invalid traffic stays small and stable enough to price in. Review by someone who knows the campaign is still what separates a farm from a call center, or an emulator from a test device.
FAQ
What is device farm fraud?
Device farm fraud is invalid traffic generated from racks of real physical devices, usually mobile handsets, operated together to produce impressions, clicks, installs, or in-app events no genuine user asked for. Because the hardware is real it passes device integrity checks, so it is caught through behavioral sameness and repeating geolocation.
What is the difference between a device farm and bot traffic?
A device farm fakes the audience with real hardware, so its behavior and location give it away. An emulated bot fakes it in software, so it scales far more cheaply and its reported environment gives it away. Detection methods do not transfer between the two.
Can emulator detection catch a click farm?
No, and that is the most common blind spot in traffic quality reviews. Emulator detection looks for evidence that a claimed device does not exist: build strings, missing sensors, graphics identifiers matching no shipped handset. A farm of stock phones supplies none of that.
Which signals work for click farm detection?
Population-level signals rather than single-request ones: many identifiers sharing one uplink and one location, geolocation that never varies, motion sensors reporting a device that never moves, activity confined to shift windows. Pairing those with downstream conversion quality beats any of them alone, and confirmation still needs a person to read the pattern.
Are device farms and bots both sophisticated invalid traffic?
Yes, when either is built with care. Under IAB and MRC invalid traffic guidance, general invalid traffic is what routine filtering and known-source lists remove, while sophisticated invalid traffic requires advanced analytics and multi-point corroboration. Farms and behavior-mimicking bots sit on the sophisticated side of that line.
Two Threats, One Line Item
The invoice does not distinguish. Wasted spend from a rack of handsets and from an emulated fleet arrive in the same report, often inside the same campaign. The detection stack does distinguish, whether or not anyone configured it deliberately.
So the question is not which threat is bigger. It is which of the two your current coverage is not built to see. Traffic that fails no environment check, converts poorly, and arrives from a few plausible locations is a different diagnosis than traffic that fails every environment check on the first request.
Join our Telegram for more insights and share your ideas with fellow-affiliates.