Analytics bot filtering without hiding the uncertainty
Keep known crawlers, previews, automation and obvious data-center traffic out of human analytics while preserving transparent exclusion reasons.
Bot filtering is necessary because automated requests can inflate visitors, shorten sessions, distort sources and produce impossible conversion rates. It is also imperfect. A trustworthy analytics product should state which layers it uses, expose excluded totals and avoid claiming that every accepted visit is definitely human.
MetricFold filters before an event enters decision metrics. Legitimate crawler observations can remain in a separate crawler report, while invalid probes and obvious automation are counted by exclusion reason.
User-agent classification is the first layer
Known crawler registries cover search bots, monitoring agents, previews, feed readers, SEO tools, AI crawlers and headless automation. MetricFold uses a maintained crawler-detection library plus a reviewed emerging-agent list. Product operators can add exact observed tokens without shipping a new regular expression.
User agents are self-declared and can be forged. Classification is useful for known honest automation; it is not proof of humanity.
Maintain regression probes for ordinary browsers, in-app browsers and assistive technology so a broad token does not exclude legitimate use. Record the classifier version used for a release.
Edge evidence adds a second opinion
A trusted reverse proxy may supply a bot score, verified crawler class, country code or network owner. Only accept these headers from infrastructure you control. A public client can forge the same header.
Data-center and hosting-network rules can remove obvious scripted traffic, but they can also affect corporate VPNs, privacy relays and real users on cloud-backed services. Keep the rule narrow, versioned and reversible. Never store raw visitor IPs in analytics simply to support later filtering.
Behavior detects abuse patterns, not identity
Rate and repetition gates catch event storms that evade a known user-agent list. Examples include too many events for one privacy-safe visitor bucket in a minute, repeated page views with no meaningful action, impossible timing and malformed origin patterns.
These are admission controls. They should protect measurement and infrastructure without becoming a hidden fingerprint. Use coarse windows and bounded identifiers already required for delivery. Do not combine canvas, fonts, hardware and network traits to create a persistent bot score for a person.
Referrer and campaign spam needs its own rule
Some automated traffic exists primarily to place a domain in a referrer report. Maintain a bounded domain list, normalize hosts and reject malformed or self-referrals. Payment-gateway return domains should be ignored for attribution without being classified as malicious traffic.
Campaign values also need length and cardinality limits. A bot that generates a new UTM value for every request can turn a report into an expensive unbounded query even when volume is modest.
Show what was removed
A clean dashboard should include accepted events, excluded events, excluded percentage and ranked reasons. Operators need to distinguish a genuine acquisition fall from a new rule or crawler burst.
Keep a separate crawler surface for recognized search and AI agents. This supports SEO and GEO analysis without polluting the active-human map. Do not expose raw IP addresses or an unbounded request log in that surface.
Test classification as a changing dependency
Bot rules require ongoing verification:
- test a broad corpus of known bots and automation tools;
- test real desktop, mobile and in-app browser user agents;
- test blank, malformed and excessively long user agents;
- verify trusted proxy headers are ignored from untrusted sources;
- fuzz event velocity and repeated-page thresholds;
- compare accepted and excluded trends after each registry update;
- preserve a kill switch for a rule that creates false positives.
Known lists change. A scheduled dependency review is more reliable than a hard-coded list copied from a blog post. Newly observed agents should be added with a source and a test.
How this compares with GA4 and Plausible
Mature analytics platforms apply automated-traffic filtering, but the exact result will differ because identity, network intelligence, sampling and definitions differ. Running products side by side will not produce identical visitor counts.
Use a validation window. Compare trends, inspect exclusion reasons, test your own monitoring and preview tools, and verify conversions against server-owned outcomes. Accuracy is a documented measurement system, not numerical agreement with another vendor.
Build a labelled validation set from real operations
The strongest local evidence comes from sessions whose outcome can be validated outside analytics. A server-confirmed activation, successful authenticated workflow or verified payment provides positive human evidence. It does not follow that every non-activated session is a bot: real people abandon, browse anonymously, encounter errors or decide the product is not for them.
Keep three labels, not two
Use validated_human, known_automation and unknown. A recognised search crawler or synthetic monitoring key can provide automation evidence. A completed server-owned activation can provide human evidence. Everything else remains unknown until another reliable signal exists. This avoids poisoning a training set with ordinary human drop-off.
MetricFold can send these labelled, minimized features into a shadow detector such as FakeTraffic. Shadow mode scores traffic but does not change admission. Compare scores with a time-separated holdout before enabling any blocking rule. The product analytics guide explains why the activation definition must remain a meaningful completed action rather than a page view.
Prevent label leakage
Do not train on features that occur only after the label if the production decision happens before them. A model deciding whether to admit the first page view cannot use a later activation event as an input. Activation is a training label for earlier bounded behavior, while evaluation must reproduce the exact information available at decision time.
Split evaluation by time, acquisition source, browser family and product release. A random event-level split can place the same visit in both train and test sets and report false confidence. Keep entire visits together and retain a final untouched period for promotion decisions.
Measure accuracy as asymmetric risk
False positives remove real customers from reports and can be more damaging than leaving some automation in an unknown bucket. Report precision and recall separately for validated humans and known bots, plus the unknown coverage rate. A single “95% accurate” number hides class imbalance and the cost of each error.
| Decision | Required evidence | Safe default |
|---|---|---|
| Exclude known crawler | Maintained token or trusted verified-crawler signal | Exclude from human reports; retain crawler aggregate |
| Exclude obvious event storm | Bounded rate/repetition policy with regression tests | Reject and record the exact reason |
| Score behavioral anomaly | Versioned model evaluated on a time holdout | Shadow only |
| Accept ordinary browser session | Valid origin, schema and no exclusion trigger | Count as accepted, not “proven human” |
| Label validated human | Server-owned activation or equivalent durable outcome | Use for evaluation/training provenance |
This language matters. “Accepted traffic” means the event passed the current controls. “Validated human” means there is affirmative product evidence. The realtime map should show accepted active sessions and expose traffic-quality totals nearby; it should never imply every dot is a known person.
Operate detector changes like releases
Version rules and models
Store the classifier version with aggregate exclusion evidence. Review dependency updates and new user agents in a pull request. Run the labelled corpus, false-positive browser matrix, fuzz inputs and time holdout before promotion. Deploy a model behind a kill switch and begin with a narrow shadow period.
Watch the business guardrails
Monitor accepted activation rate, verified purchases, support complaints, country/device mix and source mix after a change. A sudden rise in “quality” caused by deleting a legitimate mobile browser is a regression. Compare raw admission totals with server-owned outcomes so a filter cannot silently optimize its own metric.
The AI crawler analytics guide covers authorised machine traffic that should remain visible separately. Cloudflare's bot score documentation is an example of useful edge evidence, while the Google crawler documentation shows why verified search automation needs distinct handling.
Frequently asked questions
Can MetricFold guarantee that every reported visitor is human?
No analytics product can guarantee that from browser events alone. MetricFold removes known and high-confidence automation, labels exclusion reasons and keeps accepted traffic distinct from validated-human evidence.
Should sessions that do not activate be labelled bots?
No. They are unknown. Treating abandonment as automation would train the detector to hide the exact friction, positioning and conversion problems analytics is meant to reveal.
Can an open-weight model improve detection?
Potentially, once there is a representative labelled set and strict input boundary. Gradient-boosted trees or compact anomaly models are often easier to calibrate and explain than a large language model for tabular traffic features. Promotion depends on holdout performance and false-positive guardrails, not model size.
Why expose excluded traffic?
Rules and dependencies change. Visible exclusion trends let an operator distinguish a real acquisition decline from a classifier change and reproduce why traffic was removed.