Seatext library / BotRefund evidence

Common Bot Detection Signals for Websites

BotRefund evaluates over 100 network, device, debugger, and behavioral signals to decide if a visit is human or automated. Major signal groups include network/geolocation, device/OS, debugger/anti‑stealth, and user behavior, each with concrete checks such...

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

Common bot detection signals fall into four major categories: network/geolocation (e.g., WebRTC network leak, DNS tunnel leak, IP address inconsistency), device/OS (e.g., OS/TCP TTL mismatch, HTTP User‑Agent mismatch, Accept‑Language mismatch), debugger/anti‑stealth (e.g., CDP debugger leak, native patching, JS engine mismatch), and behavioral signals (e.g., pointer‑path straightness, motion jitter absence, super‑fast click speed, grid‑aligned movement). These examples illustrate the breadth of data a modern detector examines.Source

CategoryTypical SignalsWhat It Reveals
Network & GeolocationWebRTC leak, DNS tunnel leak, IP inconsistency, latency mismatch, suspicious ports, UTC timezone biasConflicting location or routing data suggests proxies, VPNs, or data‑center bots.
Device & OSOS/TCP TTL mismatch, HTTP User‑Agent mismatch, Accept‑Language mismatch, HTTP protocol mismatch, engine mismatchImpossible or contradictory OS fingerprints indicate emulated environments.
Debugger & Anti‑StealthCDP debugger leak, native patching, Rebrowser leaks, JS engine mismatch, automation propertiesAutomation tools leave detectable traces in the browser stack.
BehavioralPointer path, motion jitter, speed (<1 ms), grid‑aligned movement, engagement gaps, session duration anomaliesHuman micro‑movements and irregular browsing patterns are missing.

Why detecting bots matters

Invalid clicks waste ad spend, poison conversion pixels, and distort analytics. When bots trigger conversion events, machine‑learning bidding models learn from false data, driving up cost‑per‑acquisition and lowering return on ad spend.

Network & Geolocation Signals

These signals compare the visitor’s network footprint with expected geographic patterns.

  • WebRTC network leak – reveals the real IP behind a VPN or proxy by exposing local ICE candidates.Source
  • DNS tunnel leak – checks whether DNS queries travel the same route as HTTP traffic; mismatches suggest tunneling.
  • IP address inconsistency – compares the public IP seen by the server with the IP inferred from WebRTC or DNS; a mismatch flags evasion.
  • Latency mismatch – measures round‑trip time versus expected latency for the claimed region; unusually low latency can indicate a data‑center bot.
  • Suspicious ports – detects use of non‑standard ports (e.g., 8080, 8443) that are common in automated scanning tools.
  • UTC timezone bias – compares the browser’s reported timezone offset with the IP‑derived location; a bias toward UTC often signals a headless environment.

Device & OS Signals

Device‑level checks look for impossible or contradictory hardware fingerprints.

  • OS/TCP TTL mismatch – each OS sets a default TTL (e.g., Windows 128, Linux 64). A TTL that does not match the reported OS suggests packet manipulation.
  • HTTP User‑Agent mismatch – compares the User‑Agent string with other clues such as screen size, language, and OS; contradictions indicate spoofing.
  • Accept‑Language mismatch – verifies that language preferences align with the IP‑derived locale; mismatches are common in bots that reuse generic headers.
  • HTTP protocol mismatch – looks for deprecated HTTP versions or malformed headers that browsers rarely emit.
  • Engine mismatch – checks whether the reported JavaScript engine version aligns with the claimed browser version.

Debugger & Anti‑Stealth Traps

Automation frameworks leave subtle footprints that can be detected without user interaction.

  • CDP debugger leak – Chrome DevTools Protocol leaves a flag when a debugger is attached; bots that use Puppeteer or Playwright often trigger this.
  • Native patching – examines low‑level browser APIs for missing native functions that are usually present on real devices.
  • Rebrowser leaks – detects inconsistencies when a bot switches user‑agent strings without updating underlying APIs.
  • JS engine mismatch – compares the behavior of built‑in functions (e.g., Math.random) against expected entropy.
  • Automation properties – looks for known navigator.webdriver, navigator.plugins, or webdriver-specific variables.

Behavioral Signals

Human interaction leaves a rich, noisy pattern that bots struggle to reproduce.

  • Pointer behavior – straight, perfectly linear mouse paths without micro‑tremor are rare for real users.
  • Motion behavior – lack of tiny jitter in cursor movement or scroll events indicates scripted control.
  • Speed behavior – clicks occurring in less than 1 ms after a page load are impossible for a human.
  • Path behavior – grid‑aligned movement (snapping to exact pixel rows) suggests a programmatic algorithm.
  • Engagement behavior – sessions with zero scrolls, clicks, or keystrokes are typical of bots that only load a page to fire a pixel.
  • Session behavior – uniform session durations (e.g., exactly 5 seconds every visit) point to automated loops.

Process: How a Bot‑Detection Signal Is Collected and Evaluated

The detection workflow runs entirely in the visitor’s browser and follows five steps:

  1. Script injection – A lightweight JavaScript snippet is added to the page’s <head>. The script loads asynchronously to avoid blocking page render.
  2. Passive probing – The script queries network‑related APIs (WebRTC, DNS resolver, fetch latency), device APIs (navigator, screen, timezone), and debugger‑exposure APIs (Chrome DevTools, webdriver flags) without prompting the user.
  3. Behavioral tracking – Low‑level event listeners capture pointer movement, scroll delta, click timestamps, and touch pressure. The data is aggregated into short‑term vectors (e.g., 200 ms windows).
  4. Normalization & scoring – Each raw value is transformed into an anomaly score (0 = normal, 1 = highly suspicious) based on statistical baselines derived from millions of real users.
  5. Pattern inference – An AI model weighs the full set of normalized scores, looking for correlated anomalies across categories. The model outputs a single confidence value (human vs. bot) that drives the final decision.

Combining Signals into a Confidence Score

BotRefund does not block a visitor because a single signal is out of range. Instead, it aggregates evidence:

  • If three or more high‑severity signals (e.g., WebRTC leak, OS/TCP TTL mismatch, CDP debugger leak) fire, the confidence exceeds 90 % and the visitor is blocked.
  • A mix of medium‑severity signals (e.g., Accept‑Language mismatch, latency mismatch, pointer‑path straightness) yields a moderate confidence (60‑80 %). These visits are logged for review or challenged with a CAPTCHA.
  • Low‑severity or isolated signals (e.g., single port anomaly) are ignored unless they appear repeatedly from the same fingerprint.

BotRefund reports that this pattern‑based approach achieves 99 % detection accuracy across its 106‑signal suiteSource.

Practical Trade‑offs of Client‑Side Detection

Running detection in the browser offers real‑time insight but has limits:

  • Privacy‑focused browsers (e.g., Safari’s Intelligent Tracking Prevention) may block fingerprinting APIs, reducing signal coverage.
  • Resource consumption – The script uses < 5 ms of CPU on average; heavy pages should test for performance impact.
  • False positives – Users on corporate VPNs or remote desktops can trigger network mismatches. BotRefund mitigates this by requiring multiple corroborating signals before blocking.

When to Supplement with Server‑Side Checks

Client‑side detection works best when combined with server‑side telemetry:

  • Log raw request headers and IP addresses to catch bots that disable JavaScript entirely.
  • Rate‑limit repeated requests from the same IP or fingerprint.
  • Correlate server‑side anomalies (e.g., unusually high request rate) with client‑side confidence scores to prioritize investigations.

FAQ

  • Do I need to install anything on the server? No. The detection runs entirely from a client‑side script that you add to your pages.
  • Can I see which exact signals fired for a visitor? Yes. The audit dashboard lists every signal that contributed to the final confidence score.
  • How fast can I start protecting my site? Adding the script takes about one minute; protection begins immediately.
  • Will blocking bots affect real users? BotRefund only blocks traffic when the confidence score is high. Low‑confidence anomalies are logged for manual review.
  • Is there a cost to use the free audit? The initial audit and basic protection are free; advanced enterprise features have paid plans.

Understanding these signals helps you see why BotRefund’s full‑pattern detection and refund‑evidence workflow can turn raw anomalies into actionable proof for ad‑platform disputes. See which of these signals fire on your site or request a free bot audit that shows the signals in action.

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