- A false positive is not a malfunction, it is the built-in cost of threshold-based decisions. The verdict applies to the request environment, not the person — the same customer on a different network can flip from blocked to allowed.
- There is no lookup-table false positive rate for DataDome. The only meaningful number is the one on your property with your traffic mix, driven by which endpoints are protected, how thresholds are set, and how much of your audience sits on shared, mobile or corporate networks.
- False positives do not surface as errors, they surface as a gap: ad platform clicks, edge requests and landing page views stop reconciling, and the shortfall concentrates in particular countries, carriers, devices or hours.
- Most false positives fall into four patterns: shared egress IPs, non-mainstream or dated client environments, privacy-hardened configurations, and real users behind tooling such as comparison services, accessibility software or corporate proxies.
- Confirming a case calls for two actions: adjust the rule in the protection console against the evidence, and archive that evidence — otherwise the next tightening cycle re-blocks the same pattern.
What a false positive means here
The object of the judgement has to be stated precisely, because this is where the misunderstanding starts: bot detection does not decide whether a visitor is human. It decides how much the environment around the request resembles automation. In the vast majority of cases those overlap, but they are not the same question. A real customer whose request happens to leave a combination of network, TLS and client-environment characteristics that sits inside the common distribution for automated traffic will be handled as automation. The system has not erred; it has ruled on the signals it could see.
This also explains the most counter-intuitive property of false positives: they are unstable. The same person on the same phone passes on home broadband, may be stopped on a mobile network in transit, and passes again from the office. What changed is not the person but the environment. The mechanics of scores and thresholds mean that any visit sitting near the decision boundary will naturally flip back and forth.
One clarification, since the terms collide: the false positives discussed here are not the ones from content-consistency checks. Those concern a URL that returns different results on two fetches and is queried as a result, covered separately in benign content differences. This piece is about allow and block decisions at the visit level.
Why real people trip an automation verdict
Grouping the signals is more useful than listing them:
- Network layer. Where the egress IP belongs and what it has done recently. Data-centre ranges, public proxies and addresses that recently carried large volumes of automation all carry negative weight. The complication is that shared egress is a normal part of the internet: carrier-grade NAT, corporate gateways, campus networks and some VPN services all put many real people behind a handful of addresses.
- Client environment layer. Whether what the browser declares about itself is consistent with how it actually behaves. Automated environments often break down here — the declared browser does not match the rendering behaviour, font list or API surface. Real people get caught by the same test on dated hardware, niche browsers, runtimes altered by corporate policy, or setups loaded with extensions that rewrite page behaviour. The mechanics are covered in the device environment check.
- Continuity and behaviour layer. Whether this visit reconciles with previous ones, and whether on-page interaction timing fits human distributions. First-time visitors, anyone who cleared storage, and cross-device journeys inherently lack this evidence. The credential cookie exists to carry that continuity; without it the verdict leans harder on the first two layers.
One conclusion is worth holding on to: the more privacy-protective the visitor, the more likely the false positive. Disabling readable fingerprint surfaces, blocking scripts and using privacy-focused browsers all reduce the identifying evidence attached to the visit. Less evidence does not mean suspicious, but in a threshold system less evidence does push the outcome toward the conservative side. The full tension is discussed in fingerprinting and crowd anonymity.
What the blocked visitor actually sees
This detail matters for diagnosis because it determines the shape the problem takes in your data. A stopped visitor does not usually see an error. They see a replacement page, often carrying a device or environment message, sometimes asking them to complete a check. Some of those message strings are themselves searched often enough to show up in query data, which is indirect evidence of how many real people meet these pages.
The consequence is what makes this hard: that replacement page takes the place of your landing page. Your own analytics tag never runs on it, so the visit does not exist in your reporting at all. On the ad platform side the click has already been billed and reported. On your side there is no matching session. That is the characteristic data signature of a false positive — not a rise in the error rate, but a slice missing from the top of the funnel.
Estimating the rate without vendor dashboard access
Many advertisers do not own the protection — it belongs to the merchant, the client or a partner. Counting can still size the problem. Take one time window and line up three counts from different points in the chain:
- Platform clicks. Billed clicks from the ad platform report — the upstream number in the chain.
- Edge requests. Requests for the same paths recorded at the CDN or edge layer. It should sit slightly below the click count, since some people abandon immediately, but not far below.
- Landing page views. What your own tag recorded. The gap between edge requests and landing page views is the portion stopped before the page.
- Split the gap by dimension. Break it down by country, carrier or ASN, device class, OS version and hour. Genuine automation rarely spreads evenly along these lines. When the shortfall concentrates in one carrier, one class of older device or one region at particular hours, a false positive pattern is the stronger explanation.
- Cross-check with conversion rate. If a dimension shows a gap while the conversion rate of the surviving traffic holds or rises, what was stopped was largely low-value. If conversion rate falls alongside the gap, real demand was inside it.
This does not yield a precise false positive rate, but it answers the question that actually drives a decision: whether this is worth the effort to tune. Running the same reconciliation continuously is the routine described in reading traffic routing analytics.
Four patterns behind most false positives
| Pattern | Who it catches | How it shows up |
|---|---|---|
| Shared egress IP | Mobile users behind carrier-grade NAT, staff behind a corporate gateway, campus networks, mainstream broadband in some countries | The gap concentrates in a few ASNs, while surviving traffic from the same ASNs converts normally or better |
| Dated or niche clients | Low-end Android devices, long-unpatched systems, regional browsers, vendor-customised WebViews | The gap stratifies clearly by OS version or device model and clusters in emerging markets |
| Privacy-hardened setups | Privacy browsers, strict tracking protection, script-blocking extensions, first-time visitors with cleared storage | The gap skews toward developed markets and higher-income segments, with an unusually high share of first visits |
| Real users behind tooling | Comparison and aggregation services, accessibility software, enterprise security proxies, link prefetch and safety scanning | The gap tracks specific referrers or fixed timing patterns, and some of those sources produce genuine orders |
The fourth pattern is both the most damaging and the easiest to overlook, because on the signals it genuinely does look mechanical — the request really was initiated by software. The distinction is whether a person making a purchase decision sits behind that software, and a detection system cannot resolve that on its own. It has to be configured by the site owner from business knowledge. How different systems trade off along this line is compared in bot detection systems compared and Cloudflare versus DataDome.
What to do with a confirmed false positive
First, what not to do: do not loosen the global threshold because of one or two complaints. A threshold is global, and relaxing it for one pattern relaxes it for all of them. The handling granularity should be the pattern, not the dial.
- Collect evidence before changing configuration. Record the timestamp, egress IP and ASN, device and client environment, the verdict and the stated reason. Without that record every later adjustment rests on impressions.
- Adjust by pattern in the protection console. Target the specific ASN, device characteristic or referrer source rather than the global score line. That action belongs to whoever owns the protection; the advertiser side supplies the evidence.
- Archive the evidence. Protection configuration gets tightened periodically, especially after a genuine attack. If the reasoning behind an earlier allowance was never written down, the same pattern is re-blocked in the next cycle and diagnosed from scratch.
- Fold the loss into media planning. When a gap for a region or device class persists and cannot be fixed in the short term, it stops being an anomaly and becomes structural loss on that route. It belongs in the bid and expected conversion rate for that dimension, rather than being rediscovered monthly.
One point deserves emphasis: a false positive rate cannot be driven to zero, and chasing zero means admitting a great deal of automation. The goal is not elimination but knowing how large the rate currently is, who it falls on, and whether that cost is one worth paying. Being able to answer those three questions continuously already puts an account ahead of most.
Frequently asked questions
What is a DataDome false positive?
A real human visitor whose request is challenged or blocked because the signals attached to it resemble automation. The verdict concerns the request environment rather than the person, so an ordinary customer on an unusual network or an older browser can be caught while the same person on another connection passes without noticing anything.
Does DataDome publish a false positive rate?
Vendors publish target ranges for their own tuning, but the number with decision value is the one on your property with your traffic mix, and it is not something you can look up. It depends on which endpoints are protected, the thresholds set for them, and how much of your audience sits on shared, mobile or corporate networks.
What does a visitor see when they are blocked?
Usually an interstitial page instead of the site content, often with a device or environment message and sometimes a check to complete. Because that page replaces the destination, the destination tag never fires and the visit does not exist in your analytics — which is why blocked traffic reads as a funnel gap rather than an error.
How can I estimate how many real customers are being blocked?
Compare three counts across the chain for the same window: ad platform clicks, CDN or edge requests, and page views in your own analytics. A persistent gap that concentrates in particular countries, carriers, device classes or hours is the signal worth investigating, since genuine automation rarely distributes itself along those lines.
Can a false positive be reversed for a specific customer?
Through the protection console the site owner can review the request, adjust the rule or threshold that produced the verdict, and allow that pattern going forward. It is an operational change, and it should be archived together with the evidence that justified it so it is not re-tightened away later.
ROAS365 keeps a visit-level record for every arrival: the verdict, the reason behind it, and what that visit was served. Records can be exported and reconciled against platform reports, edge logs and downstream conversions — the raw material the gap analysis above requires. To see how that fits your setup, contact sales.