Can You Use Machine Learning to Detect Bots in Real Time? Yes—Here’s the Pipeline

Yes. Machine learning can detect bots in real time, and production systems already use it for ad click validation, account fraud, and website protection. The real question is not whether ML can do it, but how you build the pipeline around the model so it makes fast, explainable decisions without punishing real users.

Real-time does not have to mean before the page loads. It can mean scoring while the page loads, flagging a click a few seconds later, or updating a review queue within a minute. Each use case changes the model and infrastructure you need.

What real-time bot detection actually needs

Treat real-time detection as a system design problem, not a model choice. You need five pieces working together:

• Labeled traffic data. You need confirmed examples of human and automated sessions. Raw logs alone are not enough.
• A feature pipeline. Collect browser, network, device, and behavior signals for every visit.
• A fast model. A classifier that returns a score in milliseconds, not seconds.
• A decision layer. Thresholds, rules, allowlists, and a review queue for uncertain scores.
• Monitoring and retraining. Bots change, so the model must change too.

Your latency budget defines the system. If you score every page request, you may have only tens of milliseconds. If you score clicks after they arrive, you have more room.

Step 1: Collect labeled traffic data

Start with ground truth. A model cannot learn to separate humans from bots if the training set is just raw server logs. You need labels: confirmed human sessions, confirmed automated sessions, and a separate unknown group you leave out of training.

Good labeling sources include:

• Sessions that passed a CAPTCHA or device challenge.
• Sessions from known internal IP ranges.
• Sessions caught by a honeypot page.
• Sessions manually reviewed by your team.
• Traffic from known automation tools in a staging environment.

A common mistake is measuring success with accuracy. If bots are only 1% of traffic, a model that calls everyone human is 99% accurate and completely useless. Track precision and recall at the score threshold you plan to use.

Step 2: Extract signals that separate humans from bots

Choose signals that are hard for a bot to fake consistently. The most useful categories are:

• Browser artifacts. Whether navigator properties, canvas, WebGL, and Date APIs behave like a real browser.
• Network identity. IP reputation, data center ranges, VPN or proxy signals, and TLS fingerprints.
• Behavior. Mouse movement, keystroke timing, scroll, click order, time on page, and form completion speed.
• Session context. Device, screen, time zone, language, and whether those values stay consistent.

Playwright is a useful example. Automation tools often patch or hide browser APIs, but those changes can break when the browser is checked from another angle. That is the idea behind the Playwright Init Scripts check BotRefund uses as one of its 106 independent checks.

One mismatch is useful evidence, but not enough for a bot verdict. Real users can fail individual checks for innocent reasons.

Step 3: Train a model that handles rare bot traffic

Start with a model that is easy to deploy and explain. Logistic regression, gradient boosting, and random forests are all good starting points. You can embed categorical features like IP range and user agent, and normalize behavioral counters.

Bots are often a tiny slice of your traffic, so handle class imbalance directly. Oversample the bot class, use class weights, or generate synthetic examples. Semi-supervised learning also helps when you have a lot of unlabeled traffic and a small labeled set.

Validate by time, not by random split. A model trained on last month's bots may not predict next month's bots. Hold out a recent time period and check how well the model generalizes.

Step 4: Deploy the model for low-latency scoring

Deploy for latency. An ML model that takes 500 milliseconds is not real-time for page-load protection. Use a small model, a precomputed feature store, and a cache for repeated IPs and browser fingerprints.

Place scoring where the traffic is: a CDN edge worker, a server-side endpoint, or a browser script that posts signals after the page loads. A one-line script tag is enough to collect many signals and send them to a scoring service.

Design the scoring endpoint to return a simple verdict: allow, flag, or block. Keep the raw feature values so you can explain the decision later.

Step 5: Set thresholds, block carefully, and verify

Do not expose raw model scores to the rest of your system. Define action bands instead:

• Low score: allow the request.
• Medium score: allow but flag for review.
• High score: block or challenge.

Run a shadow period before enforcement. Log what the model would have done, but do not act on it. Compare flagged sessions with manual review and watch for false positives from privacy tools, travel, corporate networks, and unusual devices.

Verification step: create a small validation set of sessions you can label confidently. Measure precision and recall at your chosen threshold. Only then consider real-time blocking.

Step 6: Monitor, retrain, and keep the feedback loop

Bots update quickly. A rule that catches one bot framework stops working when the framework changes. Set up dashboards for score distribution, flag rate, false-positive complaints, and feature drift.

Feed confirmed decisions back into the training data. When a flagged session turns out to be human, treat that as a training example. When a passed session later looks automated, do the same. This closes the loop and keeps the model current.

Rules, machine learning, or a hybrid?

Rules are still useful. Rules catch datacenter IPs, rapid clicks, and known bad user agents. ML catches novel behavior that rules cannot describe in advance. In production, use both: rules handle obvious cases, and ML scores everything else.

Choose rules if you have little traffic and no labeled data. Choose machine learning if you need to adapt to changing bot behavior. Choose a hybrid if you care about false positives and need explainable decisions.

Limitations and when this approach is not enough

ML bot detection is not magic. A single anomaly is not a bot verdict. Real people using VPNs, traveling, behind corporate networks, or using unusual devices can look suspicious. If the model relies on one signal, it will create false positives.

ML detection also does not produce ad refund evidence by itself. Ad platforms want click IDs, campaign details, timestamps, session recordings, and signal-by-signal reasoning. If your goal is recovering wasted ad spend, you need an evidence layer, not just a score.

Do not build a custom ML pipeline if you have very little traffic, no way to label sessions, or no engineering capacity. Start with rules and manual review. Add machine learning only after you have a reliable way to know who is human and who is not.

Key facts from BotRefund

These facts come from BotRefund’s public site. They are useful benchmarks when you plan your own detection pipeline.

Frequently asked questions

How much labeled data do I need?

There is no fixed number. Start with a few thousand labeled sessions and add more if bots are rare in your traffic. You can also use semi-supervised learning to expand the labeled set over time.

Can I detect bots without machine learning?

Yes. Rules catch simple patterns like datacenter IPs and rapid clicks. ML is better at adapting to new bot behavior, but it needs labels and maintenance. Most teams use both.

How fast does real-time detection need to be?

It depends on the action. Page-load protection may need a score in under 100 milliseconds. Ad-click verification can happen after the click and still block or log the result in near real time.

Why do false positives happen?

Real people can look automated when they use VPNs, travel, sit behind corporate networks, or use unusual devices. That is why a single anomaly should never be treated as a bot verdict.

Does BotRefund use machine learning?

Yes. BotRefund sends collected signals into a prediction AI that weighs the complete browser, network, device, and behavior picture before deciding whether a visit is bot or human.

What should I compare when choosing a bot-detection vendor?

Compare detection method, false-positive handling, latency, evidence output, data privacy, and whether the provider helps you act on the results. A score without evidence is hard to trust and hard to use for refunds.