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
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
- 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.
- Deduplicate. One row per unique IP, with a visit count and the pages seen.
- Resolve with each vendor. Use the same list for all. See bulk lookups for batching.
- Record the full response. Keep verdict, name, domain, class and confidence, not just the company name.
- Tally verdicts. Count company, non-business (ISP, mobile, hosting, VPN) and unidentified.
- Sample for precision. Pick about 50 named results per vendor, favouring the ones with the most visits, since they influence decisions most.
- Judge each one. Correct, wrong or unknown, using your ground-truth list and a quick web check.
- Compute the metrics in the table below.
- 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.