Human-Like Behaviour in Automation

Behavioural detection is the part of anti-bot that does not care about your fingerprint or your address. It looks at what you did, in what order, and how long each step took.

The instinct is to add delays and randomise them. That helps less than people expect, and the wrong kind of randomisation makes things worse.

What is actually measured

Six signal families show up across commercial and open detection systems.

Timing distributions. Not whether a delay exists, but whether the set of delays looks like human timing. Human inter-request gaps are heavy-tailed: mostly short, occasionally long, with pauses that cluster around reading and context switching.

Event sequences. Browsers emit mousemove, scroll, keydown and focus events in characteristic orders. A page that receives a click with no prior mouse movement, no focus change and no scroll looks automated.

Pointer paths. Real cursor movement is not linear. It curves, overshoots and corrects, and its velocity profile has an acceleration and deceleration phase. Robot moves tend to be straight lines at constant speed.

Typing cadence. Keystroke intervals vary and, critically, correlate with the characters being typed. Uniform intervals, or a single fixed delay between every key, is a strong signal. Real typing also includes corrections.

Navigation patterns. Humans arrive from somewhere, scroll, and leave. A session that jumps straight to a deep URL, reads nothing, and requests an endpoint directly is a scraper regardless of its other signals.

Session shape. Duration, page depth, and the ratio of time on page to requests made. Very fast, very shallow sessions are the opposite of human browsing.

What to emulate, and what to skip

Effort should follow impact. Ranked:

Worth doing

• Realistic inter-request timing with a heavy-tailed distribution rather than a fixed delay, which is the practical takeaway from Rate Limiting vs Blocking.
• Sensible navigation. Load the page, scroll, then act. Do not call a deep endpoint from a cold session.
• Session structure with a plausible start and end, including a warm-up page or two when the target expects it.
• Consistent device and viewport signals across the whole session, since a viewport that changes mid-session is its own flag.

Low value

• Randomising user agent per request. Changing device mid-session is worse than a fixed one.
• Randomising viewport or screen size. Real people do not resize constantly.
• Adding mouse jitter to a headless browser that has no pointer at all. If the automation runs without a real input pipeline, synthetic events are often detectable as synthetic.
• Randomising timezone per request, for the same reason as user agent.

The pattern is that coherence beats randomness. Detection systems are looking for contradictions and for distributions that are too clean, and adding noise to one field while leaving the rest fixed creates the first problem without solving the second.

Consistency is the real signal

A bot that waits a uniformly random five to fifteen seconds between requests is easier to spot than one whose timing matches a real usage pattern, because the distribution is the tell.

Two properties to aim for:

Correlation. Human delays correlate with what the person is doing. Reading a long article takes longer than clicking a link. A generator that produces delays independent of the action is generating a distribution with the wrong shape.

Bursts and idle. Real sessions have bursts of activity separated by minutes of nothing. A steady stream at a constant average rate is machine-like even if each gap is randomised.

Where proxies fit

Behaviour and network are read together. A perfectly paced session from a datacenter range on its fourth hundred request of the minute is still a scraper, and the network layer is the subject of Anti-Scraping Techniques and How to Respond.

The two most common combinations that get flagged: human-like timing from a hosting address, and a residential address at an inhuman request rate. Both contradictions are visible without any behavioural model.

A pragmatic approach

Rather than emulating human behaviour in detail, reduce the reasons a target would look for it:

1. Keep request rates within what the site would tolerate from a real user, and spread load across addresses.
2. Follow the normal entry paths instead of deep-linking.
3. Keep the client configuration coherent and stable.
4. Prefer an official API where one exists and covers the need.

That covers most of the benefit of behavioural emulation without maintaining a simulation of mouse physics. Where the target runs a specialised detection suite, the honest answer is usually to change the approach, not to out-simulate it.

For tooling that already handles the browser side, see Best Browser Automation Tools and Scraping Browsers Explained.