Filter Bot and Cloud Traffic by IP: A B2B Analytics Guide

To filter bot and cloud traffic by IP, classify each address by network type, drop or flag hosting, cloud and known VPN ranges from account reports, and keep the rest for company resolution. Combine the class with behaviour checks, since network type alone is a strong hint but not proof of automation.

Why this matters for company reports

If you resolve unfiltered traffic, three things go wrong at once. Reports fill with providers that are not prospects. Visit counts inflate, which makes campaigns look better than they are. And you pay for lookups that were never going to name a customer.

A network class turns an unreliable name into a usable label. Classes you will meet in IP intelligence services include business, ISP, mobile, hosting, VPN, Tor, education and government. BusinessMCP’s evaluation guide lists those as the network classes its API reports, and its IP to company API page says the same verdict system covers filtering bot and cloud traffic alongside naming B2B visitors.

Which classes to act on

Network class	Typical traffic	Suggested handling
Business	Office networks, staff on corporate lines	Keep and resolve
ISP	Households, small offices	Keep as visits, no company claim
Mobile	Phones on cellular data	Keep as visits, no company claim
Hosting or cloud	Scripts, scanners, proxies, previewers	Exclude from account reports; review sample
VPN or Tor	Privacy tools, some bots	Flag; exclude from account reports
Education	Students and researchers	Keep or exclude by your ICP
Government	Public bodies	Keep or exclude by your ICP

Key takeaway: filtering is a labelling exercise first and a deletion exercise second. Tag rows, report on tagged data, and delete nothing you cannot recreate.

A practical rule set

1. Resolve and classify first. Do not hard-code lists of cloud ranges by hand; they go stale.
2. Tag, do not delete. Add a traffic_class column to your visit table.
3. Exclude hosting, cloud, VPN and Tor from account views. Keep them in traffic-quality dashboards.
4. Add behaviour checks. Sub-second page sequences, no scroll or time-on-page, missing referrers on deep pages, and repeated hits to one URL are common bot patterns.
5. Add user-agent checks as a supplement, not a foundation, since user agents are trivially faked.
6. Maintain an allowlist for your own offices, agencies and partners, and a blocklist for repeat offenders.
7. Re-run weekly. Ranges change owners and bots move.

Cloud traffic that is not a bot

Not everything from a hosting range is hostile. Examples:

• Link-preview services that fetch a page when someone shares a URL in chat.
• Email security gateways that click links to scan them. These can look like highly engaged visitors.
• Corporate secure web gateways that proxy staff through a vendor’s cloud.
• Monitoring tools you or your customers run on purpose.

The third case is worth dwelling on. Staff behind a secure gateway are real prospects whose visible address belongs to the vendor. Responsible services flag such ranges rather than naming the vendor or guessing the customer. We explore this in VPN and proxy identification.

Measuring what you removed

A filter that you never audit will eventually remove something valuable. Run this monthly:

1. Take a sample of 50 addresses you excluded.
2. For each, check whether any contact in your CRM or any form submission came from the same session.
3. Count false exclusions.
4. If more than a few percent were real, loosen the rule that removed them.

Likewise sample 50 retained named companies and confirm none are carriers or clouds. The method matches the one in how to test an IP to company API.

Effect on cost

Filtering before resolution saves money when billing is per lookup, and reduces noise either way. If you already know an address is crawler or cloud traffic, skip the call. IP to company API pricing explains how billing rules change the saving, and bulk lookups shows where the filter step sits in a pipeline.

Reporting that stays honest

When you present figures to stakeholders, show three numbers: total visits, visits after traffic filtering, and visits tied to a named company. Showing all three prevents a single flattering number from circulating. Note the date and the ruleset version so changes over time are explainable.

Quick checklist

• Classify every address before you resolve it.
• Tag rows rather than deleting.
• Exclude hosting, cloud, VPN and Tor from account reports.
• Keep an allowlist of your own and partner networks.
• Audit false positives and false negatives monthly.
• Remember that behaviour beats network type when they disagree.

With these in place, the named-company list you hand to sales becomes shorter, cleaner and more believable.

Building the filter step into a pipeline

Where you place the filter changes what it costs and what it risks. A workable order, using BusinessMCP’s IP to company API or any service that reports a class, looks like this.

Order	Stage	Purpose
1	Drop private, loopback and malformed addresses	They cannot resolve
2	Drop addresses on your allowlist of own and partner networks	Keep reports clean
3	Apply cheap behavioural rules	Remove obvious scripts before spending on lookups
4	Resolve and classify	Get class and verdict
5	Tag rows by class	Preserve everything
6	Build account views from company verdicts only	Protect sales from noise

Each stage should write a reason code to the row, such as private, allowlist, behaviour:rapid, class:hosting. Reason codes make audits fast, because you can count removals by cause and spot a rule that has started catching real people.

Examples of behavioural rules

Behaviour rules are imperfect, so treat them as tags rather than verdicts.

• More than a set number of page requests within a few seconds.
• Requests to many sequential URLs in alphabetical or numerical order.
• No JavaScript events despite page loads, if your tracker records them.
• A single user agent string with thousands of distinct addresses.
• Repeated requests for files that no human page links to.

Combine two or more before excluding anything from account views, and always keep the raw rows so a rule can be loosened later.