A VP of Sales at a SaaS company sent me 500 inbound form fills last month. Names: none. Company: none. Just email addresses and a note: "We need to know who these people are before our AEs call them."
I spent three days running every major reverse lookup tool against those same 500 addresses. What I found was uncomfortable: almost every published comparison I'd read was measuring the wrong thing.
Why Every Reverse Lookup Comparison You've Read Is Wrong
Most "email lookup" benchmarks — including Dropcontact's well-circulated 20,000-contact study — test forward lookup: you give the tool a first name, last name, and company domain, and it finds the email address. That's a genuinely useful test. But it's not what you need when inbound leads arrive with just an email.
Reverse lookup (email → profile) is mechanically different:
- The tool has to parse the email pattern to infer the person's name and company domain
- Then it has to match that parsed signal back to a contact record
- Then it has to return enriched fields: title, seniority, LinkedIn, phone
The inputs are worse — you have less confirming information — but the output requirements are the same. Match rates drop meaningfully. I've seen vendors claim 85% accuracy in their forward-lookup demos and then quietly produce 38% match rates when I hand them an email list.
My Testing Methodology
500 email addresses. All from real B2B inbound form fills — SaaS, financial services, professional services, and light manufacturing. I had ground-truth profiles for all 500 via LinkedIn (manually verified before the test), so I could score each result as:
- Match: tool returned name + title + company that matched ground truth
- Partial: tool returned name only, or name + company without title
- Miss: no result returned
- Wrong: result returned but name or company was incorrect
I tested each tool via its API, not through any UI, and disabled caching where possible. Every tool got the same 500-row input: just email addresses, nothing else.
Match Rates: The Actual Numbers
Here's what I found. These are from my test, not vendor-supplied figures.
| Tool | Match % | Partial % | Miss % | Wrong % | Cost per 1,000 lookups |
|---|---|---|---|---|---|
| People Data Labs | 62% | 11% | 24% | 3% | ~$10–$15 |
| Prospeo | 58% | 8% | 31% | 3% | ~$20–$25 |
| FullEnrich | 51% | 12% | 26% | 11% | ~$55–$60 |
| Hunter.io | 44% | 6% | 49% | 1% | ~$3–$5 |
| Clearbit/Breeze | 38% | 9% | 51% | 2% | ~$35–$50 |
| Datagma | 34% | 14% | 28% | 24% | ~$10–$12 |
A few things to flag:
- PDL won on pure match rate, but their data freshness varies. About 18% of their "matches" came back with job titles that were 1–2 roles out of date based on my LinkedIn ground truth.
- FullEnrich had the second-highest wrong rate at 11%. That's their waterfall model at work — it finds something more often than single-source tools, but when it's wrong, it's confidently wrong.
- Datagma had the worst wrong rate at 24%. One in four results I would have sent to an AE would have been the wrong person or wrong company entirely.
- Hunter.io had the cleanest data: 1% wrong rate, nearly zero false positives. But it missed almost half the list.
Why PDL Leads (and Where It Breaks Down)
People Data Labs wins this test because their /person/enrich endpoint is purpose-built for exactly this use case. You pass an email, they return a structured person object. The database is genuinely large — they claim 3B+ profiles — and API response time was consistently under 200ms in my runs.
The problem: freshness. PDL would confidently return a person's old company for executives who had changed jobs in the past 12 months. On my 500-address set, 18 of 311 matches showed a title or company that LinkedIn showed as historical. For a warm outbound call, that's a credibility problem.
Their pricing is also opaque at volume. The developer tier looks cheap ($0.01/record) until you hit volume minimums and overage terms. At 10,000 enrichments per month, you're negotiating a custom contract.
What Clearbit/Breeze Became After the HubSpot Acquisition
Clearbit used to be competitive on standalone accuracy. Since HubSpot renamed it Breeze Intelligence and wove it into their platform, the reverse lookup API has become progressively harder to access outside the HubSpot ecosystem. I used the legacy API endpoint, which still works but isn't promoted.
Match rate of 38% in my test, but the data quality on what it does match is solid: title, seniority, industry, company size all returned cleanly. If you're already in HubSpot and enriching form fills in-place, Clearbit/Breeze is probably your lowest-friction option even at lower match rates. If you're not in HubSpot, there's no reason to choose it over PDL or Prospeo.
FullEnrich's Hidden Accuracy Cost
FullEnrich is built on the premise that querying 20+ providers gives you more coverage. In my test, it did — 51% match rate vs. 44% for Hunter.io and 38% for Clearbit. But the 11% wrong rate is the hidden cost of that waterfall approach.
When FullEnrich's waterfall hits a borderline result — say, two providers return slightly different records for the same email — it appears to merge them rather than flag the conflict. I saw cases where the returned full name combined a first name from one provider with a last name from another. Your CRM doesn't know that happened.
For workflows where you QA enrichment results before they touch a rep's pipeline, FullEnrich's volume coverage is genuinely useful. For fully automated enrichment that flows directly to outreach sequences, that 11% wrong rate will create problems you'll trace back weeks later when reply rates tank.
The DIY Waterfall: Does It Beat FullEnrich?
I built a simple three-tier waterfall: PDL first, then Hunter.io for PDL misses, then Prospeo for anything still unresolved. Results on the same 500 addresses:
- PDL caught 62% of addresses
- Hunter.io caught 19% of PDL's misses (11% of total)
- Prospeo caught 22% of remaining misses (8% of total)
- Combined coverage: 81% — wrong rate of 4%
Compare that to FullEnrich: 51% match, 11% wrong, at 5–6x higher cost per successful result. The DIY waterfall wins on every metric that matters — but it requires three API integrations and logic to handle conflicts when providers disagree. Clay handles this cleanly out of the box if you'd rather configure waterfall sequences without building the routing yourself.
What 500 Lookups Actually Cost
| Tool | Cost for 500 lookups | Cost per successful match |
|---|---|---|
| Hunter.io | ~$2 | ~$0.009 |
| PDL | ~$6 | ~$0.019 |
| Datagma | ~$6 | ~$0.035 |
| Prospeo | ~$12 | ~$0.041 |
| FullEnrich | ~$29 | ~$0.113 |
| Clearbit/Breeze | ~$22 | ~$0.116 |
Hunter.io's cost per successful match looks nearly free because its wrong rate is negligible — but the 49% miss rate means you're paying another tool to fill the gap regardless. PDL is the best combination of match rate and cost per result at the volume most growth teams actually run.
What I Actually Use
For most reverse lookup workflows I inherit, I run PDL first via their /person/enrich API. It covers roughly 60% of addresses at low cost and high confidence. For the remaining 40%, I layer in Hunter.io for the ones it knows confidently, and Prospeo for SMB contacts where PDL's coverage thins out.
If I'm building in a HubSpot context, I accept Clearbit/Breeze's lower match rate for the platform's in-place enrichment, then use PDL via Zapier for overflow.
For social-profile-heavy lookups — where the inbound email is personal (Gmail/Hotmail) rather than a work domain, or where the workflow involves Twitter or Facebook profile data — Ziwa has been faster for me than PDL's direct API for those edge cases. PDL's coverage drops sharply on personal emails; tools built around social-graph data handle them better.
The real conclusion I'd push back on from every vendor comparison I've read: there is no single tool that solves reverse lookup at 80%+ accuracy with clean data. The waterfall is the answer. The question is whether you build it yourself with PDL + Hunter.io + Prospeo, or use a platform like Clay to abstract the plumbing — and whether you're willing to pay FullEnrich's premium for that abstraction.
Top comments (0)