Egress Report

Home › Implementation › How to Test an IP to Company API on Your Own Traffic

How to Test an IP to Company API on Your Own Traffic

Editorial team · Updated 2026-10-14 · 5 min read

To test an IP to company API, export one day of deduplicated client IPs, resolve them with each candidate, tally the verdicts, hand-check about 50 named results per vendor and compare correct answers rather than raw fill rate. One afternoon is enough for a reliable first read.

Why test at all

Published match rates depend on whose traffic was measured, and the vendor chooses the sample. Even honest vendors say as much: BusinessMCP’s product page states that accuracy “depends entirely on whose traffic you send” and suggests testing on your own logs. Your audience, region and mix of remote and office staff decide the outcome, so only your data predicts your results.

What you need

  • A day of server logs or analytics exports with client IP addresses.
  • A list of known customers, open deals and recent form fills with domains, as ground truth.
  • API access or trial credit for each candidate.
  • A spreadsheet or small script.

The procedure

  1. Clean the input. Remove your own offices, agencies, monitors and obvious crawlers. Drop private and malformed addresses. If you are behind a CDN or load balancer, use the forwarded client address and only trust it for requests that verifiably passed through your proxy.
  2. Deduplicate. One row per unique IP, with a visit count and the pages seen.
  3. Resolve with each vendor. Use the same list for all. See bulk lookups for batching.
  4. Record the full response. Keep verdict, name, domain, class and confidence, not just the company name.
  5. Tally verdicts. Count company, non-business (ISP, mobile, hosting, VPN) and unidentified.
  6. Sample for precision. Pick about 50 named results per vendor, favouring the ones with the most visits, since they influence decisions most.
  7. Judge each one. Correct, wrong or unknown, using your ground-truth list and a quick web check.
  8. Compute the metrics in the table below.
  9. Cost it out. Divide spend by correct answers.

The metrics

BusinessMCP’s evaluation guide names three measures, which we use with small additions.

Metric How to calculate Why it matters
Precision on named results Correct names ÷ names checked Wrong names waste sales time
Leakage Named “companies” that are ISPs, carriers, clouds or gateways ÷ names returned Shows whether verdicts are honest
Coverage Correct named addresses ÷ addresses that were resolvable Compare between vendors on one sample
Cost per correct answer Spend ÷ correct names The number finance cares about
Refusal quality Share of non-company results with a sensible class and reason Shows how the vendor handles uncertainty

Key takeaway: a vendor that names fewer companies but is right 90 percent of the time beats one that names twice as many at 60 percent. Rank by correct answers.

Pitfalls that spoil a test

  • Testing on the wrong traffic. A sample dominated by one big campaign skews everything. Use a representative day or a week of unique addresses.
  • Letting the vendor pick the sample. Always use your own.
  • Checking only easy cases. Include long-tail names, not just famous brands.
  • Ignoring billing. Note your balance before and after. Vendors differ on whether non-company results are billed, and pages from one vendor can differ too. See IP to company API pricing.
  • Forgetting freshness. A graph rebuilt nightly can lag on a range that changed owner today; do not penalise a vendor for one-day lag, but do ask about cadence.
  • Skipping edge cases. Include IPv6, mobile and known gateway addresses to see how each service behaves.

Verdict questions to ask

For any confidence score, ask what evidence moves it, where the cutoff is and whether it drops for carriers. For any verdict set, ask how each class is defined. BusinessMCP’s IP to company API documents company, non_business and unidentified; your candidates should be at least as explicit.

Interpreting results

Outcome Reading Next step
High precision, low coverage Honest, narrow Use as-is; pair with forms
Low precision, high coverage Guessing Reject or raise the confidence cutoff
Both high Rare; check sample Repeat on another day
Both low Audience may not resolve Lean on deterministic signals

If two vendors are close, break the tie on billing clarity, privacy terms and integration effort. Our selection guide covers the full criteria.

Write it down

Record the test date, the sample size, the vendors, versions or graph identifiers if exposed, the metrics and your conclusions in a short note. When you revisit in a quarter you will know whether change came from the vendor or from your traffic. Also record two or three false positives with explanations; they make the best onboarding material for the team that will use the data, and they stop the question “how do we know it’s right?” from recurring.

A control set that exposes weak services

Alongside your real sample, add a small set of addresses whose correct answer you already know. It takes ten minutes to assemble and exposes most weak services quickly.

Control address Correct answer What a bad service does
Your own office or a customer’s office on its own network A company name Misses it or names the ISP
A home broadband address you control ISP, no company Names your employer or an invented company
A phone on cellular data Mobile carrier, no company Names a company
A cloud VM you rent Hosting, no company Names the cloud provider as a prospect
A consumer VPN exit VPN, no company Names a company
An IPv6 address from your own connection Correct class Errors or returns nothing

Run it with every vendor on the shortlist. A service that fails more than one control row is a poor candidate however good its demo looks. Controls also give you a regression test: rerun them monthly and watch for changes after the vendor updates its data.

Sharing the result

When the test is done, present a one-page summary: sample description, counts per verdict, precision, leakage, cost per correct answer and a recommendation. Include two or three false positives as examples. A short, reproducible summary is persuasive, and it makes the next evaluation, perhaps when a vendor changes pricing, a fraction of the work. You can try BusinessMCP’s IP to company API on such a control set with its free trial credit before you spend anything.

Frequently asked questions

How big should my test sample be?

A day of deduplicated client IPs is a good start, with about 50 named results hand-checked per vendor. Larger samples tighten the estimate but cost more.

What should I measure?

Precision on named results, carrier or vendor leakage, and coverage of resolvable visits. Raw fill rate rewards guessing and should not be your headline metric.

Can I test with the free trial?

Yes, if the credit covers your sample. BusinessMCP’s trial is $5 for 7 days, which its guide describes as covering about 250 company answers.

How often should I repeat the test?

Quarterly, or after a major change in traffic mix or vendor data. Both drift over time.