Seatext library / BotRefund evidence

How to Distinguish Human Users from Bots

You tell humans and bots apart by looking at behavior, session duration, and interaction patterns together, not by any single browser property or IP address. Detection works best as a sequence: collect network, device,...

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

You tell humans and bots apart by looking at behavior, session duration, and interaction patterns together—not by any single browser property or IP address. A real visitor leaves a trail of imperfect movements: pauses, scrolling, cursor jitter, and clicks that follow a natural order. A bot usually leaves a trail that is too fast, too straight, or too predictable.

If you manage paid ads or a public web form, start with a diagnostic sequence: gather network, device, and behavior signals, compare them for conflicts, and only then label the visit. This article walks through that sequence and explains where bot detection still fails.

Start with the diagnostic sequence

Use the same order every time. It protects you from jumping to conclusions.

  1. Define a normal session for your page. Note usual device types, languages, time zones, visit length, scroll depth, and click paths.
  2. Collect signals in three layers. Capture network data (IP, DNS, WebRTC), device and browser data (user agent, engine, hardware profile), and behavior data (pointer, speed, path, engagement).
  3. Compare signals inside a single visit. Ask whether the network path matches the stated location, and whether the browser profile matches the device.
  4. Look for contradictions. A time zone that disagrees with the language, a DNS route that does not match the web route, or a JavaScript engine that does not match the browser are all flags.
  5. Score the pattern, never one raw signal. A single suspicious property can appear in a real user's session; many conflicting signals appearing together are far more telling.
  6. Verify with the outcome. Check what happened after the click: did the visitor scroll, pause, correct a form field, or convert? Then check whether that outcome led anywhere, such as a call, booked demo, or repeat engagement.

This order works for a single suspicious lead, a campaign placement, or an entire traffic source.

Prerequisites for a trustworthy bot check

Before you start, you need three things.

  • A tracking layer that can see client-side activity. Server logs alone miss most advanced botnets. Client-side tracking gives you the event-level logs needed to identify a session and, later, to claim refunds.
  • A baseline of your own human traffic. Without knowing what a normal session looks like, you cannot spot abnormal sessions. Pull data from your CRM, analytics, and ad platform before making judgments.
  • A clear policy for what you will do with a bot classification. Blocking traffic is one workflow; proving invalid clicks to an ad platform is another. The evidence you collect should match the action you plan to take.

Network, device, and location signals to compare

Bot networks use evasion vectors to hide. The goal of a check is not to catch one lie, but to see whether all facts agree. These are the common conflicts to test:

  • WebRTC network leak: browser network paths reveal conflicting locations.
  • DNS tunnel leak and DNS routing mismatch: DNS and web traffic do not follow the same route.
  • Timezone, UTC bias, language, and Accept-Language checks: location and language settings disagree.
  • Latency and HTTP protocol mismatch: connection and browser request details stay inconsistent.
  • IP inconsistency, suspicious ports, and OS/TCP TTL mismatch: the visitor's network identity is not coherent.
  • HTTP user-agent mismatch and engine mismatch: often surface when browser automation or masking tools are in use.

Remember: any one of these can happen in a real session. Treat them as prompts for further inspection, not as proof of a bot. For instance, a privacy browser may block WebRTC or return unusual DNS information; that alone should not get a user blocked.

Behavioral signals that separate humans from bots

Behavior is harder for bots to fake than network metadata. Use these signals:

  • Ghost clicks: click activity happens without the natural sequence of human intent, such as clicking a button before reading the page.
  • Honeypot trap interactions: a bot responds to hidden or intentionally deceptive page elements that a person never sees.
  • Pointer movements: robotic linear mouse movements appear as unnaturally straight paths; humans rarely move in perfectly straight lines.
  • Mouse tremor: human movement includes tiny imperfections and jitter; absence of that tremor is suspicious.
  • Input speed: clicks faster than a person could realistically perform, for example under one millisecond, signal automation.
  • Path shape: grid-aligned movement snaps to lines or blocks instead of following natural curves.
  • Engagement: no clicks or scrolling in a session that should require reading.
  • Session duration: visit lengths that are too short, too long, or too uniform to be human.

A session that combines several of these is a stronger bot candidate than one that shows a single odd behavior.

Detection approaches compared

Most detection approaches fall into three groups.

ApproachWhat it seesWeak spotBest fit
Server-side log auditIP addresses, request headers, user-agent dataCatches basic scraper bots, struggles to detect advanced botnetsA first pass when you have server logs
Client-side behavior trackingPointer paths, speed, clicks, scrolling, session lengthNeeds a script on the page; behavior data must be stored for later reviewPages where you can measure real engagement
Full-pattern prediction AIBrowser, network, hardware, and behavior signals seen togetherNeeds enough data to judge patterns; accuracy depends on the signal setHigh-volume ad traffic where one signal misleads

Not every product fits every site. Choose server-side filtering if you only need to remove obvious scrapers. Choose client-side or pattern-based detection if you run paid campaigns and need proof for refunds.

Key facts: what the full pattern looks like

Scope. Bot detection is the process of deciding whether a web visit or click was automated or human. It is used to protect conversion data, prevent wasted ad spend, and keep lead quality high.

FactDetail
Signal set106 browser, network, hardware, and behavior signals can be read together before a decision is made.
Core ruleSignals become a decision only when they are seen together; one signal can be misleading.
Behavior examplesGhost clicks, honeypot interactions, linear movement, superhuman speed, grid-aligned paths, static sessions, unusual duration.
Network examplesWebRTC leak, DNS mismatch, timezone or language mismatch, IP inconsistency, OS/TCP TTL mismatch.
Refund evidenceClient-side tracking gives logs needed to claim refunds from ad platforms.

Use this table as a quick reference for what counts as a signal and why no single signal decides the outcome.

Limitations and when detection is not straightforward

Bot detection is not perfect, and you should know where it stops being useful.

  • Not every bad lead is a bot. Treating all unresponsive contacts as fraud will make you exclude valuable audiences. The evidence has to support the label.
  • Advanced botnets hide in normal-looking traffic. Residential proxy botnets route clicks through household IPs, and click farms use real phones, so IP reputation alone fails.
  • Server-side logs miss advanced threats. IP, header, and user-agent checks catch basic scrapers but not sophisticated automation.
  • Platform inventory can add low-quality traffic. On Meta, Audience Network placements can send traffic from third-party apps and sites with inflated clicks.
  • Legitimate bots exist. Search engine crawlers and monitoring tools are bots too. If you block every bot, you can harm SEO and uptime checks.

When this advice does not apply: if your site has no meaningful interaction signal, such as a one-page landing with no scrolling, behavioral detection has less to work with. If you cannot store client-side data, you cannot later prove that a click was invalid.

Bot detection FAQ

What is the most reliable sign of a bot?

No single sign is reliable. The most reliable approach is a pattern: several network, device, and behavior signals that conflict or look unnatural when taken together.

Can bots imitate human mouse movements?

Some can, but they still leave traces. Very straight paths, grid-aligned movement, missing tremor, or clicks that are faster than humans are common tells.

Why do session duration and scrolling matter?

Humans read at a natural pace. A session with no scrolling, no pauses, and no field corrections does not match a real browsing journey. Uniform visit lengths across many sessions are also suspicious.

Can I detect bots with server logs alone?

Only basic bots. Server logs show IP addresses, request headers, and user agents, but advanced botnets hide inside residential proxies and real devices. Client-side data is usually needed.

What should I do after I identify a suspicious session?

Preserve the evidence before changing anything. Save the click identifier, landing-page URL, session timeline, and behavior data, then compare it with CRM and ad-platform data before making a refund request.

Do all bots cost money?

No. Search engine crawlers and some monitoring tools are useful. The costly ones are bots that click paid ads, submit fake leads, scrape offers, or poison conversion pixels.

How fast can detection decisions be made?

With client-side tracking, a decision can be made almost immediately because behavior signals are captured while the page is open. For refund disputes, you still need the saved logs and click identifiers.

Further reading and comparison sources

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

How BotRefund can help

BotRefund looks at 106 browser, network, hardware, and behavior signals as one pattern before it classifies a visit. It also captures the click identifiers and behavioral evidence that Google Ads and Meta refund disputes require, and it helps large advertisers and agencies negotiate directly with the platforms. The detection script can be added to a site in about one minute, and the service focuses on Google Ads and Meta traffic; if you run neither platform, the refund workflow will not apply to you.

Get my free bot audit