- The device check is the in-browser layer: it needs a real browser to execute JavaScript, so it reads what the network layer cannot.
- It does not look for one signal; it looks at whether four families of signals agree with each other. Coherence matters more than any single value.
- Verdicts come in three bands: silent allow, challenge (a request for more evidence), and block (the request ends). A challenge is not a block.
- The same coherence logic also catches real customers on privacy browsers, VPNs, corporate proxies and in-app webviews — and that never shows up as an error, only as traffic that arrived and never converted.
Where the device check sits in the chain
DataDome's protection is not one test. It is a chain: a network-layer judgment about the request itself (IP reputation, ASN, TLS and protocol fingerprints, header order), then a device check that runs inside the browser, then a session credential that carries the conclusion forward to later requests. Each stage sees something the others cannot, which is exactly why they are chained.
The device check is the middle link and carries the most weight. It executes as JavaScript in the visitor's browser, collects a set of environment signals, and posts them back for scoring. Its value is that the network layer can only ask whether a request looks fine on paper, while the device check can ask whether the browser that sent it behaves like a real device. How the network and edge side reaches its verdict is covered in edge bot detection; the score these signals feed is in how the bot score is built. The whole system in outline is in what DataDome is.
What the device check actually verifies
No vendor publishes the exact field list, but from observable behaviour the signals fall into roughly four families.
1. Browser API coherence. Does what the user-agent claims agree with what the JavaScript environment actually exposes — the properties on navigator, which APIs are and are not supported, the language and plugin lists, whether the timezone is consistent with the IP's geography. An environment claiming to be one version of mobile Safari while exposing an API that version never shipped is not a plausible combination.
2. Rendering and hardware hints. What canvas and WebGL actually render, screen and viewport dimensions, device pixel ratio, reported CPU core count, memory hints, the available font set. A real device produces a stable and mutually consistent set of values; emulated or modified environments often produce combinations that do not occur in the wild — a supposed flagship phone reporting a desktop-class core count and a GPU string that model has never shipped with.
3. Automation traces. Automation frameworks leave marks: properties they inject, timing artifacts characteristic of a headless runtime, debugging interfaces that were never cleaned up. These are the most direct signals and also the most obviously targeted ones, which is why on their own they carry limited weight.
4. Interaction and timing. How the pointer moves, the cadence of scrolling, how long passes between page load and the first action. Human timing is messy; scripted timing is often too regular — or so regular that it is identical across separate visits.
No single signal decides anything. The point of a device check is not catching one bad value but testing whether dozens of values are coherent with one another. That is why changing a user-agent string alone never changes a verdict — and equally why a completely legitimate visitor can be caught because a few of their values do not line up.
How a check becomes allow, challenge or block
The check condenses into a score, and which band the score lands in decides what the visitor experiences. Roughly three bands: a silent allow, where the visitor notices nothing at all — the outcome for the overwhelming majority of legitimate traffic; a challenge, where the visitor gets an interstitial, often an interactive verification, and continues if it is satisfied; and a block, where the request ends, the visitor gets an error page with a reference id, and your page never loads at all.
Treating a challenge as equivalent to a block is the most common mistake when reading this data. A challenge says "not enough evidence yet, give me a little more" and can end in a pass; a block says "this ends here". They come from different score bands, and folding them together makes your numbers look worse than they are and pushes you to tune in the wrong direction. How scores map to verdicts is detailed in how the bot score is built.
Once a visitor passes, the conclusion is written into a session credential that travels with later requests, so every click in the same session does not repeat the full evaluation. What that credential is, how long it lives and how to classify it for privacy compliance is covered in the datadome cookie explained.
Why modified environments stand out
A whole category of tools exists to make one browser present itself as many different devices; they are usually marketed as antidetect browsers. From the detection side there is only one property worth noting: staying coherent across every dimension at once is very hard. A profile can present a convincing user-agent and still expose a rendering fingerprint, a timezone, a font set or a hardware hint that does not belong to the device it claims to be.
More importantly, the detection side does not need to identify which tool is in use. It only needs to notice that the signals disagree with each other. That is why this is a long-running cat-and-mouse dynamic rather than something either side wins once — every dimension that gets aligned leaves the next one still open.
For advertisers, the real significance of this section is not those tools but the fact that the same criteria apply to entirely ordinary things: a privacy browser that randomizes the canvas fingerprint, an anti-fingerprinting extension, a corporate VPN that puts the exit IP in one country while the system timezone says another. The detection system sees the same thing in every case — signals that do not agree. Except these are your customers.
Why real customers get caught
False positives are not a rare corner case. They have a handful of recurring sources:
- Privacy-hardened browsers and extensions. Users who deliberately randomize or suppress fingerprint signals produce exactly the kind of incoherence the check is built to notice.
- VPNs and corporate proxies. A mismatch between IP geography and the timezone or language settings is the single most common cause of a wrong verdict.
- In-app webviews. Pages opened inside a social app run in a constrained browser environment whose capability set and referrer behaviour differ from a normal browser, and desktop testing can never reproduce it. Those differences are covered in mobile traffic pitfalls.
- Old or low-end devices and very slow connections. Hardware hints that land in unusual ranges, or a check script that does not finish before it times out, both push the visitor into a stricter band.
- Carrier NAT and shared egress. Mobile carriers put large numbers of real users behind a small set of exit IPs; if one of those is scored as risky, everyone behind it is affected.
The cost is deeply asymmetric. A bot that slips through is worth a fraction of a cent; a customer who receives a block page costs you the entire conversion — and it never appears in your funnel as an error, only as a click that arrived and a session that never existed. That is why false positives deserve to be measured deliberately rather than discovered through support tickets.
Telling a device-check verdict from an ordinary error
A device-check block does not look like an ordinary failure. It is typically a branded interstitial, or a 403 carrying a reference or request id, rather than a 404, a 502 or a blank page. A reference id is a fairly reliable sign that you have hit the protection layer and not your own server.
Then do three things. First, establish which resource was blocked — your landing page itself, or a third-party script or API call on it; those lead in completely different directions. Second, do not try to reproduce it on one desktop machine: test across real devices, networks and regions, because verdicts at this layer are device- and geography-dependent by design. Third, check whether a session credential is present — its presence means a check ran and reached a conclusion, while its absence may mean the script never finished executing (see the cookie explained).
Also keep two entirely separate systems apart: the protection layer in front of your own site, and the ad platform's internal invalid-traffic filtering. They measure different things, count differently, and neither explains the other. The platform-side definitions are in GIVT and SIVT.
Reading device-check outcomes alongside ad data
There is always a gap between arrivals and sessions, and the gap itself is not the problem; the problem is a gap that widens inside one segment. The useful method is to break it down — by device class, browser, geography and traffic source — and look for the cell where the share of clicks that never became sessions is visibly higher than everywhere else. That cell is usually the group being caught.
Then ask what changed. Gaps like this rarely drift into existence: more often a protection rule was adjusted, the campaign mix shifted (a campaign that suddenly skews mobile or skews one country), or a newly added third-party script on your own page triggered additional checks. The baseline for reading bot traffic overall is in detecting bot traffic, and how different protection approaches reach their verdicts is in bot detection systems compared.
One last discipline: do not act on a single day's number. Day-to-day movement on low volume is noise; a move sustained across several periods is signal.
FAQ
Want visibility into what each visit was served?
ROAS365 provides visitor routing with a per-visit record of what happened, so you can see every arrival broken down by device, geography and source.