Seatext library / BotRefund evidence

How to Test If Your Website's Bot Detection Correctly Identifies Automated Sessions

Validate your bot detection by running a controlled test suite that combines real browsers, headless Chrome and Firefox with stealth plugins, Puppeteer and Playwright scripts, and device farms. Measure true-positive and false-positive rates across...

Built for advertisers who need clear, refund-ready traffic evidence.

Start with a controlled test suite that runs real browsers, headless Chrome and Firefox with stealth plugins, Puppeteer and Playwright scripts, and device-farm sessions against your detection endpoint. Record the verdict for each session, then calculate true-positive and false-positive rates across fingerprint vectors such as WebGL texture constraints, suspicious port mismatches, and behavioral signals like mouse tremor, input speed, and click-path geometry. Automate the suite in CI/CD so every deploy re-verifies coverage before code reaches production.

What bot detection testing actually means

Testing bot detection checks whether your classifier correctly labels human sessions and automated sessions that mimic humans. You must exercise the same evidence vectors your detector uses: browser fingerprint, network context, and interaction behavior. The result is a confusion matrix you can track over time.

BotRefund, for example, runs 106 independent checks per visit, including WebGL texture constraints and suspicious port mismatches, then feeds those signals into an AI model that weighs the complete pattern instead of trusting a single rule. The vendor reports 99% accuracy from this corroboration approach. Your test suite should confirm that each signal class fires as expected and that the aggregate verdict matches the ground truth you define.

Prerequisites before you start testing

  • Ground-truth labels: A dataset of confirmed human sessions (from internal QA, employee traffic, or verified customers) and confirmed bot sessions (from your own automation scripts, known scrapers, or honeypot traps).
  • Detection endpoint access: Ability to send test traffic to your detection API or JavaScript snippet and read the raw verdict plus the contributing signals.
  • Environment parity: Test harness runs on the same network egress, TLS termination, and CDN configuration as production so network-level signals (IP reputation, port behavior, geo consistency) are realistic.
  • Version control for test cases: Each browser version, automation framework version, and stealth plugin configuration is pinned so regressions are attributable.

Building a controlled test suite

Organize the suite as a matrix: rows are session types, columns are fingerprint vectors. For each cell, record whether the detector flags the vector. Include at least these session types:

  1. Real Chrome on Windows, macOS, Linux (latest stable).
  2. Real Firefox on the same OSes.
  3. Real Safari on macOS and iOS (via device farm).
  4. Headless Chrome with no stealth (baseline automation).
  5. Headless Chrome with Puppeteer Stealth plugin.
  6. Headless Firefox with Playwright Stealth plugin.
  7. Puppeteer scripts that simulate form fills, scrolls, and clicks at human-like intervals.
  8. Playwright scripts that replay recorded human sessions.
  9. Residential proxy rotations to test geo and port consistency.
  10. Known bad actors from your blocklist or honeypot logs.

Run each session type at least 30 times to smooth variance. Capture the full signal payload: WebGL renderer and vendor strings, canvas fingerprint, audio context, navigator properties, TCP/IP stack behavior, mouse movement traces, click timestamps, scroll deltas, and session duration.

Testing with real browsers vs headless automation

Real browsers establish the baseline of what "normal" looks like on your stack. Headless Chrome and Firefox without stealth plugins should trigger multiple signals: missing or inconsistent WebGL texture parameters, absent mouse tremor, superhuman input speeds (sub-millisecond), grid-aligned pointer paths, and suspicious port mismatches when proxied.

Stealth plugins attempt to patch these gaps; your test suite measures how many they actually close. BotRefund's signal list includes ghost click detection, honeypot trap interactions, robotic linear mouse movements, absence of humanlike mouse tremor, superhuman input speed under 1ms, grid-aligned movement patterns, absence of clicks or scrolling, and unnatural session durations. Your test harness should synthesize each of these behaviors deliberately and verify the corresponding signal fires.

Measuring true/false positive rates across fingerprint vectors

For each vector, compute:

  • True positive rate (recall): Fraction of bot sessions where the vector fires.
  • False positive rate: Fraction of human sessions where the vector fires.
  • Precision: Of sessions where the vector fires, fraction that are actually bots.

A single anomaly is not a bot verdict. Privacy tools, corporate networks, travel, and unusual devices can produce unexpected behavior for genuine people. BotRefund keeps each signal as evidence — not a verdict — and cross-checks it against independent browser, network, device, and behavior data. Your test report should surface vectors with high false-positive rates so you can adjust thresholds or add contextual rules.

Device farm and CI/CD integration

Device farms (BrowserStack, Sauce Labs, AWS Device Farm, or a private lab) let you run the matrix on real iOS Safari, Android Chrome, and edge browser versions without maintaining physical devices. Script the farm runs as a CI/CD job that:

  1. Spins up the matrix on every pull request or nightly.
  2. Collects verdicts and signal payloads.
  3. Compares against the baseline confusion matrix stored in version control.
  4. Fails the build if true-positive rate drops below your threshold or false-positive rate exceeds your budget.
  5. Publishes a dashboard (Grafana, Datadog, or a simple HTML report) with per-vector trends.

This turns detection validation into a regression gate rather than a one-off audit.

Key facts from BotRefund's detection model

Signal categoryExample checksRole in verdict
Hardware & GPU fingerprintingWebGL texture constraint, canvas, audio context, renderer stringsIndependent evidence; cross-checked against other signals
Network, VPN & geolocationSuspicious ports, proxy rotation, location masking, browser spoofingIndependent evidence; cross-checked against other signals
Click behaviorGhost click detection, honeypot trap interactionsBehavioral evidence fed to AI model
Pointer behaviorRobotic linear mouse movements, grid-aligned patternsBehavioral evidence fed to AI model
Motion behaviorAbsence of humanlike mouse tremorBehavioral evidence fed to AI model
Speed behaviorSuperhuman input speed (<1ms)Behavioral evidence fed to AI model
Engagement behaviorAbsence of clicks or scrollingBehavioral evidence fed to AI model
Session behaviorUnnatural session durations (too short, too long, too uniform)Behavioral evidence fed to AI model

BotRefund sends all signals into a prediction AI that evaluates the complete picture across browser, network, device, and behavior evidence. The vendor reports 99% accuracy from corroboration, not from any single browser tell. Setup takes about one minute with no credit card required.

Common mistakes and limitations

  • Testing only headless Chrome: Real attackers use Firefox, Safari, Playwright, Selenium, and custom CDP clients. Cover the matrix.
  • Ignoring false positives on corporate networks: VPNs, Zscaler, and enterprise proxies often trigger port and geo signals. Label corporate egress IPs in your ground truth.
  • Treating a single signal as a verdict: The source pack emphasizes that a single anomaly is not a bot verdict. Your test suite must evaluate the aggregate model, not individual rules.
  • No regression baseline: Without a versioned confusion matrix, you cannot detect when a browser update or detector change degrades coverage.
  • Skipping mobile Safari: iOS Safari has a distinct fingerprint (no WebGL2 in older versions, different audio context). Device farm coverage is essential.
  • Assuming stealth plugins are static: Puppeteer Stealth and Playwright Stealth update frequently. Pin versions and re-run the matrix on each update.

Terminology

  • Fingerprint vector: A measurable browser or network property (e.g., WebGL renderer, TCP window size, mouse tremor variance) used as evidence.
  • Corroboration: The practice of requiring multiple independent signals to agree before issuing a bot verdict.
  • Stealth plugin: A browser automation add-on that patches known automation fingerprints (e.g., navigator.webdriver, Chrome runtime object).
  • Device farm: A cloud service providing real physical or virtual devices for automated testing.
  • Honeypot trap: A hidden page element (link, form field) that humans never interact with; interaction signals automation.
  • Ghost click: A click event fired without the preceding human intent sequence (move, hover, mousedown).

FAQ

How many test sessions do I need for statistical confidence?

At least 30 runs per session type gives a rough 95% confidence interval of ±18% for a 50% rate. For tighter bounds (e.g., ±5%), aim for 300+ runs per type. Start with 30, then expand high-variance vectors.

Should I test against my production detector or a staging copy?

Use a staging copy that mirrors production configuration exactly. Testing against production risks polluting your analytics and triggering real mitigations (block, challenge, refund claims).

What if my detector has no API to read per-signal verdicts?

Instrument the client-side snippet to post the raw signal payload to your test harness endpoint. If the vendor does not expose signals, you can only measure aggregate verdict accuracy, not per-vector coverage.

How often should I re-run the full matrix?

Nightly for the full matrix; on every PR for a fast subset (real Chrome, headless Chrome, one stealth config). Browser updates and stealth plugin releases are the main drift sources.

Can I use public bot-check sites like pixelscan.net or cleantalk.org as part of my suite?

They are useful for spot-checking a single browser profile, but they do not replace a controlled matrix with your ground-truth labels and your detector's signal payload.

What is a reasonable false-positive budget?

Depends on your mitigation. If a false positive triggers a CAPTCHA, 1-2% may be acceptable. If it triggers an ad-refund claim or account lock, aim for <0.1%. Measure the business cost of each mitigation type and set the budget accordingly.

How do I handle new automation frameworks (e.g., Playwright 1.40, Selenium 4.15)?

Add a row to the matrix for each major framework version. Pin the version in CI. When a new version lands, run the matrix, compare to baseline, and update the baseline if coverage improves without raising false positives.

Further reading and comparison sources

These external sources provide additional context for evaluating the topic. Their inclusion is not an endorsement.

Learn more

Visit the website for more information.

Learn more