A global false-positive rate stays 0.2% when every block lands on one carrier

Two hundred false positives against 99,000 known-human requests is 0.202% ^[2][19]. The figure does not move when those 200 change address. Spread them evenly over every route and it holds. Land all of them on one carrier's mobile users at checkout and it still holds ^[19]. A ratio taken across the whole known-human population has already discarded the partition, so concentration shows up only in a per-route count. The dev.to post asks for that count directly: how many known-human sessions each rule challenged or blocked on each protected route, and what happened next ^[8].

Accuracy flatters the detector for a second reason. Most requests on a customer-facing app are legitimate and the attacks worth stopping are a small slice ^[25], so in the post's example a detector that called all 100,000 requests human would score 99% ^[26]. The one that catches 900 of the 1,000 attacks scores 99.7% ^[3]. It also issues 1,100 bot verdicts, 200 of them wrong, which is 18.2%, or one in 5.5 ^[20]. The post describes this as "a bot verdict that is wrong almost one time in six" ^[5]; one in six is 16.7%, so the worked example is slightly worse than its own description ^[21].

The metric you gate on depends on which action fires. The post cites Google's classification metrics guide for the coupling: change a threshold and precision, recall and the false-positive rate all change, and no threshold can be evaluated independently of the cost of each kind of mistake ^[10]. Hence three operating goals rather than one: hard blocks favor precision, challenges balance precision and recall because they leave a recovery path, and monitoring favors recall because a person or a later rule reviews the signal before enforcement ^[11].

The expensive part is the label set. Strong human labels come from successfully authenticated sessions, completed purchases that were not reversed, support-confirmed sessions, or employees following a controlled test plan, and the post grants that none of these is perfect alone ^[12]. Two shortcuts are ruled out: calling every session that failed to convert a bot, and calling every session that passed a JavaScript check human, because both put the detector's own assumptions into its ground truth ^[13]. Genuinely ambiguous traffic stays labeled unknown ^[13]. Search crawlers, uptime monitors, accessibility scanners, payment callbacks and partner integrations go into the set as automated traffic that is not hostile ^[14].

A vendor's global false-positive rate describes the population it was measured on ^[7]. For it to describe yours, that known-human set would need your desktop and mobile browser mix, your older devices and slow connections, and your traffic behind corporate networks, universities and carrier-grade NAT ^[15]. It would also need the VPNs and privacy tools your customers actually use, plus assistive technology and keyboard-only navigation ^[15]. The post says: "If the known-human set contains only employees on recent MacBooks, the benchmark is measuring employee laptops, not customers" ^[16].

A clean lab set with one Chrome version and a few obvious Selenium scripts proves the code runs, and does not establish that the detector is safe for customers ^[23]. On the automated side the post asks for controlled clients driven by Playwright, Puppeteer, Selenium and curl, plus slow bots, distributed low-volume clients, headless browsers and scripts carrying realistic headers ^[24]. Every verdict gets its configuration recorded: engine version, rule and threshold version, the signals that fired, score and proposed action, route group, session identifier ^[17].