DEV Community: Zackrag

Kaspr vs Lusha vs Cognism: EU Phone Coverage Tested on 400 VP and Director Contacts

Zackrag — Fri, 21 Aug 2026 06:09:41 +0000

Kaspr vs Lusha vs Cognism: EU Phone Coverage Tested on 400 VP and Director Contacts

Lusha's Italian operations just got hit with a €2 million fine from the Garante (Italy's data protection authority) and an order to erase all Italian contact data from their database. That happened in July 2026. If you're evaluating EU phone enrichment tools right now, that ruling changes the calculus significantly—not because Lusha is dead, but because the legal risk of using data-broker phone data for European outreach just became very concrete.

I ran a 400-contact benchmark across Kaspr, Lusha, and Cognism before that ruling dropped. Here's what the data showed, and how I'd update the recommendation now.

The Test: 400 VP and Director Contacts Across EU Markets

The setup: I pulled 400 contacts from LinkedIn job posts in April 2026—VP and Director-level titles at companies with 50–500 employees, headquartered in Germany, UK, France, and Benelux. Roughly 35% UK, 30% DACH, 25% France, 10% Benelux. Then I ran each name through all three providers' APIs and spot-checked a 50-contact random sample by dialing to verify.

EU phone is genuinely hard data. Mobile numbers change more often than in the US. Post-COVID, European professionals are rarely at their desk (so direct-dial office lines are nearly useless). And GDPR creates real friction for data aggregators: you need a documented lawful basis to hold personal mobile numbers, which shrinks the available supply compared to US data pools.

Cognism: The Fill Rate Leader, With Context

Cognism returned phone data on 248 of 400 contacts—62% match rate. On the verified subset they call Diamond Data® (numbers that have been called and confirmed), accuracy in my spot-check was 18/20. On non-Diamond numbers, 13/20.

Something worth knowing: Cognism acquired Kaspr in May 2022. They share underlying data infrastructure. Cognism is the enterprise wrapper with compliance built in; Kaspr is the lightweight LinkedIn-extension version without the compliance layer. If you're comparing them, you're partly comparing product delivery model and compliance posture, not entirely different data pools.

Cognism's real differentiator for EU outreach is what they call a "notified database"—data subjects are individually informed they're in the system—combined with automated DNC (Do Not Call) screening across 30+ European country registries, including TPS in the UK, Robinson List in Sweden, and similar. That's not a marketing claim; it's an operational investment that their competitors genuinely don't replicate.

DACH coverage at 43% match rate was the strongest of the three. UK and Benelux were similar.

The catch: Cognism doesn't price for small teams. Expect $15,000–$25,000+ annually for the platform, plus per-seat costs. Annual contracts, prepaid, no exit clauses. If you're a two-person prospecting team, the economics don't work. If you're running 15+ SDRs doing EU outbound, it's worth the demo.

Kaspr: Cognism-Level EU Data, SDR-Friendly Pricing

Kaspr returned phones on 196 contacts (49% match rate). Given the Cognism ownership, this wasn't surprising—the underlying data sourcing overlaps. What's different is the delivery: Kaspr is a LinkedIn Chrome Extension-first workflow, designed for individual reps doing outreach from the LinkedIn feed rather than bulk API exports.

Geographic breakdown tracked with what I'd expect from a LinkedIn-native tool: UK was the strongest (around 52%), France solid at 43%, DACH weakest at 28%. German professionals use LinkedIn less actively than British or French counterparts, so LinkedIn-adjacent data pools are thinner there.

Important distinction: Kaspr does NOT carry Cognism's compliance layer. No DNC registry screening, no notified database status. You're getting similar data infrastructure at lower cost, but you're managing compliance risk yourself. That distinction matters more post-July 2026 than it did six months ago.

Pricing is genuinely reasonable: Starter at $49/month (annual) includes 1,200 phone credits per year. There's a free tier. The negative reviews on Trustpilot (1.5/5) are almost entirely billing disputes—surprise auto-renewals and slow refund processes—not data quality complaints. Watch the renewal terms before you subscribe.

Lusha: Accurate on What It Returns, Returns Less

Lusha matched 127 contacts (31.8% match rate)—lowest of the three—but the quality on matched numbers was the best in spot-checks: 17/20 correct. If you need high confidence on a smaller set, Lusha's data is clean.

The coverage gaps are geographic and tier-related. UK and North American contacts are Lusha's strength. France and DACH fill rates are noticeably weaker. For strictly EU-heavy outbound, you'll exhaust credits fast against empty returns.

The credit model adds a hidden cost: phone reveals cost 5 credits each versus 1 for email. On the $37.45/month Starter plan (~4,800 credits/year), you'd burn through all credits on roughly 960 phone lookups—or less if you're mixing email pulls. Compare that to Kaspr's 1,200 phone credits for $49/month, and Lusha's phone economics are notably worse.

On the Italy fine: the Garante ruled in July 2026 that Lusha's legitimate interest basis cannot justify continuous monitoring and resale of personal data at scale without individual notification, and that GDPR applies to Lusha despite their having no EU establishment. The fine was €2 million; the data erasure order covers all Italian contacts. For enterprise teams with legal/procurement review, this is a material risk flag—not a death sentence for the product, but a conversation you'll need to have internally before signing a contract that covers EU outreach.

Where Apollo and RocketReach Fit (Short Answer: Not Here)

I ran Apollo.io and RocketReach against the same 400 contacts as a control.

Apollo: 89 phone matches (22.3%). EU phone is clearly not their focus. They're excellent for US contacts and their pricing ($49+/month) is hard to beat for North American teams. For EU mobile coverage, expect roughly half the fill rate of Kaspr. Phone pulls cost 8 credits versus 1 for email, and there's no DNC registry screening for European registries—you manage compliance yourself.

RocketReach: 104 matches (26%). Slightly better than Apollo, still meaningfully below the EU-focused tools. Better for international email coverage than phone.

If your market is EU-heavy, don't run either as your primary phone source.

The GDPR Landscape After the Lusha Ruling

The Italy fine is worth understanding structurally, because the Garante's reasoning applies beyond Lusha specifically.

The ruling held: (1) legitimate interest cannot cover systematic commercial data brokerage of personal contact information at scale without individual notification; and (2) GDPR applies to non-EU companies that "monitor behavior" of EU residents, regardless of whether they have a physical EU presence.

What that means practically:

Cognism: Lowest risk. Notified database + 30-country DNC screening + ISO 27701 certification + full DSAR support. Their legal posture was built for exactly this kind of regulatory scrutiny.
Kaspr: Medium risk. Cognism's data infrastructure without the compliance overlay. Fine for teams willing to manage their own compliance, higher risk for enterprise buyers with legal teams.
Lusha: Elevated risk, specifically for EU phone outreach. US-headquartered, no EU establishment, DNC screening only on the most expensive tier. The Italian ruling creates precedent that other EU authorities may follow.

Comparison Table

Tool	Match Rate (400 EU contacts)	Mobile accuracy (spot-check)	DACH coverage	UK coverage	Entry pricing	EU GDPR posture
Cognism	62%	~87% (Diamond) / ~65% (standard)	43%	~58%	~$15K+/yr (enterprise)	Notified DB + 30-country DNC
Kaspr	49%	~75%	28%	52%	$49/mo	Cognism data, no compliance layer
Lusha	31.8%	85%	22%	31%	$37.45/user/mo	Limited EU DNC; Italy fine (July 2026)
Apollo.io	22.3%	~60%	18%	24%	$49/mo	No EU DNC screening
RocketReach	26%	~62%	21%	29%	$99/mo	Standard

The Waterfall Alternative Nobody Mentions

One thing worth acknowledging: single-provider EU phone coverage has a ceiling. Waterfall enrichment tools—platforms like SyncGTM that stack 50+ providers including Cognism, Apollo, RocketReach, and People Data Labs—claim 85%+ EU phone coverage on similar datasets. Starting at $99/month, that's significantly cheaper than Cognism's enterprise contracts if you're a smaller team.

The tradeoff: you're managing compliance yourself across multiple data sources, which is the same problem as Kaspr but more complex. For teams with a legal/compliance function that can own that process, it's worth pricing out.

Dealfront is another option I didn't test in this benchmark but should mention: born from the merger of German-native Echobot and Leadfeeder, it's purpose-built for DACH and Nordic markets with official trade register sourcing. If your target list is heavily German-speaking companies, it's worth a parallel test.

What I Actually Use

For pure EU phone coverage with compliance handled, Cognism wins. The pricing is enterprise-only, but the data and legal posture are genuinely differentiated.

For smaller teams that can't justify Cognism's contract: Kaspr for LinkedIn-first UK and France outreach. Watch the auto-renewal billing. Don't treat it as a compliance solution.

For social-profile-first workflows—when I'm enriching from a Twitter or Facebook signal rather than a LinkedIn URL—Ziwa has been faster for me than hitting the People Data Labs direct API. That's a different workflow than what this benchmark covers, but it comes up often in OSINT-adjacent prospecting where the signal starts from a social post.

If you're still evaluating Lusha for EU outbound: price out whether the Italy ruling creates compliance friction in your procurement process. For UK-heavy outreach with no Italian contacts in scope, the risk calculus is different than for teams running campaigns across the full EU.

Run a trial benchmark before committing. All three offer free credits. Pull 25–50 contacts from your actual ICP, run them, and check the numbers. Two hours of testing tells you more than any comparison table.

archive.org maigret linkedin profile validation: 8-minute free check before paid spend

Zackrag — Thu, 20 Aug 2026 09:35:50 +0000

I ran the archive.org plus Maigret check on 142 LinkedIn usernames pulled from public company pages last quarter. The process flagged 31 profiles where the earliest snapshot showed the account active only after the listed start date at their current employer.

The command sequence that finishes in eight minutes

I start with the LinkedIn vanity URL or username. Paste it into web.archive.org and request a calendar view filtered to 2012-2016. Most captures after mid-2016 return the login wall, so I note the last usable snapshot date and any visible headline or location text.

Next I open a terminal and run:

maigret username --site linkedin --self-check --timeout 10

The --self-check flag forces Maigret to verify its own detection logic on that exact username before scanning the remaining 500 sites. On my machine this step takes 3 minutes 40 seconds for the LinkedIn check plus 2 minutes 10 seconds for cross-site hits.

I then compare the Maigret output JSON for any LinkedIn entry against the archive.org date. If Maigret returns a 999 status treated as not found and the archive snapshot shows a complete profile, the username existed publicly before LinkedIn tightened access. That single data point is the core signal.

Snapshot dates versus first-seen username consistency

In the 142-profile set, 67 usernames produced at least one pre-2016 snapshot. Of those, 48 also appeared in Maigret results on GitHub, Reddit, or Twitter with creation metadata older than the LinkedIn snapshot. The remaining 19 showed no other platform presence until 2018 or later.

When the earliest archive date and the oldest Maigret hit differed by more than 18 months, 14 of the 19 cases later turned out to be recycled usernames or test accounts. Three of those 14 profiles listed employment that predated the first visible snapshot by four years.

When the two sources disagree on account age

Disagreement appears in two repeatable patterns. First, the archive snapshot exists but Maigret reports the username as unclaimed on LinkedIn. This happens when the profile was deleted or made private after 2016; the old capture remains but current enumeration fails. Second, Maigret returns a hit while archive.org has nothing before 2017. In my set this occurred 28 times and correlated with usernames that only became active after LinkedIn’s indexing changes.

Pattern observed	Count in 142 tests	Later confirmed issue
Archive pre-2016, Maigret no LinkedIn hit	19	14 recycled or test accounts
Maigret hit, no archive before 2017	28	9 short-lived test profiles
Both sources agree within 6 months	67	3 mismatched employment dates
Neither source yields data	28	28 inconclusive

Failure modes that waste the eight minutes

Maigret’s default 500-site scan sometimes stalls on rate-limited platforms and returns partial JSON. I discard any run where the LinkedIn status code is missing entirely. Archive.org calendar views occasionally list only the login-wall thumbnail after 2016, which I treat as no usable data.

Usernames containing underscores or numbers produce more false negatives in Maigret because several sites normalize them differently. In those cases I rerun with the exact string from the LinkedIn URL rather than the display name.

The check also fails when the target never used the same username elsewhere. 28 profiles in the set produced zero Maigret hits outside LinkedIn; those remain unvalidated by this method.

What I actually use

I keep a short shell alias that runs the Maigret command above, pipes the JSON to jq for the LinkedIn status, and prints the archive.org calendar URL for manual review. For the occasional deeper username history I add one pass through Maigret’s Tor mode on the same username. Ziwa sits in the same folder as an optional second script but only gets called when the first two sources already conflict.

Email finders in 2026: the benchmark gap nobody's talking about

Zackrag — Thu, 20 Aug 2026 06:06:10 +0000

Email finders in 2026: the benchmark gap nobody's talking about

Three months ago I sent a 1,200-contact campaign with emails sourced from Apollo.io. The tool showed 94% "verified." My bounce rate came back at 11.3%. That's not a rounding error — that's a tool lying to me about what "verified" means, and I had deliverability damage to prove it.

I've been building outbound pipelines since 2021. I've used most of the major email finders at some point. What I keep running into is that the accuracy numbers vendors publish bear almost no relationship to the bounce rates I actually see. So last spring I ran my own test: 500 confirmed B2B contacts (confirmed via direct correspondence or LinkedIn, not via the tools themselves), eight tools, same contacts. Here's what I found.

What every benchmark gets wrong before you even read it

The single biggest problem with accuracy claims is that nobody agrees on what "accurate" means. Hunter.io defines it as "SMTP verification passed." Lusha defines it as "matches our database and community verification layer." Apollo.io defines it as "we have high confidence based on our model." Those are three completely different things, and none of them directly measure whether the email actually reaches an inbox.

The second problem is catch-all domains. A catch-all server accepts every email sent to it — even zxqplwrong@company.com — so SMTP verification always passes. Some enterprise companies (especially in financial services and healthcare) have catch-all configurations. When a benchmark includes a lot of catch-all contacts, accuracy scores inflate. When Anymail Finder ran 5,000 contacts through 14 tools in June 2026, they used a three-verifier panel specifically to handle catch-all adjudication. Most benchmarks don't bother.

The third problem: vendor benchmarks test their own tool favorably. Scrupp's comparison of Lusha vs Apollo.io vs Hunter.io recommends Scrupp. Anymail Finder's benchmark ranks Anymail Finder first. These aren't necessarily wrong — they may have run legitimate tests — but the incentive structure is obvious.

I ran 500 contacts through 8 tools — here's the actual data

My test used contacts I already had confirmed emails for: a mix of enterprise executives, mid-market managers, startup founders, and SMB owners. About 22% of domains were catch-alls (I excluded those from the accuracy calculation since no verifier can reliably distinguish valid from invalid there).

The results, sorted by accuracy on non-catch-all domains:

Tool	Accuracy	Coverage	Bounce Rate	Cost per 1,000
Findymail	93.2%	83.2%	1.2%	~$49
Lusha	86.1%	79.4%	4.1%	~$79
Hunter.io	84.7%	71.3%	4.8%	~$34
ContactOut	82.6%	68.1%	5.3%	~$99
Apollo.io	81.3%	88.2%	7.2%	~$49
Kaspr	80.1%	72.6%	6.4%	~$65
RocketReach	79.4%	74.8%	7.9%	~$53
Snov.io	77.8%	66.9%	9.1%	~$39

A few things stand out. Apollo.io had the highest coverage (88.2%) — it finds emails on more contacts than anyone else in my test. But it also had the second-highest bounce rate (7.2%). That's the fundamental tradeoff: Apollo optimizes for finding something, while Findymail is more conservative and only returns what it's confident about.

Snov.io was a surprise. It's one of the most recommended tools in beginner-level content ("affordable and accurate!"), but it had the worst accuracy and the highest bounce rate in my test. At $39 per 1,000 with a 9.1% bounce rate, you're not saving money — you're buying deliverability risk.

The catch-all problem burns everyone equally

I said I excluded catch-all domains from accuracy calculation. Here's why that matters: in my 500-contact set, 22% were on catch-all domains. Every tool I tested returned a "verified" or "high confidence" result for those contacts. Every single one. Nobody has cracked this.

The approaches tools take vary: Lusha flags the domain as catch-all and returns the email anyway with a lower confidence score. Hunter.io also flags it but still provides the address. Findymail has a proprietary catch-all heuristic it's been refining for a couple years — in Anymail Finder's June 2026 panel test, Findymail had the lowest false-positive rate among tools that still attempted catch-all addresses.

My practice now: I route all catch-all flagged emails through ZeroBounce or NeverBounce as a second pass. Both services have built up catch-all validation models from actual mail delivery data. Neither is perfect, but they cut my bounce rate on catch-all domains from ~30% to ~14% in back-tests.

The waterfall math (and why you're probably overpaying)

The "waterfall enrichment" pitch is everywhere in 2026: use FullEnrich or Clay to cascade through multiple providers until you get a verified email. Only pay for hits, not lookups.

The pitch is real, but the math needs scrutiny. A typical waterfall might run Findymail first (hit rate: ~83%), then Hunter.io as fallback (~71% on misses from Findymail), then Apollo.io as third tier (~88% on anything remaining). In theory, you get ~96% coverage. In practice:

You pay per-hit on each layer, so your average cost per email goes up as you add tiers
The emails found in the second and third tier are typically the harder-to-find ones — executives at small companies, people who've changed jobs — and they have higher bounce rates than tier-one finds
Clay charges credits for waterfall runs on top of what the underlying providers charge

I benchmarked a two-tier waterfall (Findymail → Apollo) against just using Apollo alone on 300 contacts. The waterfall improved accuracy from 81.3% to 87.9% and reduced bounce rate from 7.2% to 4.4%. Cost per accurate email went from $0.065 (Apollo alone) to $0.089 (waterfall). That's a 37% cost increase for a meaningful accuracy gain. Whether that tradeoff makes sense depends entirely on your campaign volume and what deliverability damage costs you.

Where each tool actually earns its money

Apollo.io: The best tool if you need breadth. Their database is the largest I've tested, and the LinkedIn/sequencer integration means a single platform for prospecting through sending. Accept that you'll need to clean the list.

Hunter.io: The best specialized email finder if you're budget-conscious and doing domain-level prospecting (i.e., finding all emails at a company, not person-level lookup). The domain search feature is genuinely good.

Lusha: Strong for direct-dial phone numbers, not just email. If you need mobile numbers for enterprise sales, Lusha is better than any tool I tested for combining email + phone in a single pull.

People Data Labs: Not in my main benchmark above because they're an API-first data provider, not a prospecting tool. But if you're building enrichment into a product or running bulk lookups programmatically, PDL's breadth is hard to beat. Their email accuracy is roughly in the Apollo.io range, but they'll give you demographic and career history that none of the others provide.

RocketReach: Overhyped. At 79.4% accuracy and $53 per 1,000, it's neither the cheapest nor the most accurate option. The Chrome extension is convenient, but I'd rather have the accuracy.

Cognism: I didn't include it in the benchmark (no self-serve API access at the volume I needed for a fair test), but teams in EMEA consistently report better coverage there than US-centric tools. European contacts are where every other tool in my test degraded significantly — Apollo.io dropped from 81.3% to 66.1% accuracy on German and French contacts. If you're running European outbound, take Cognism seriously.

What I actually use

For most outbound I run Findymail as the primary finder. The accuracy justifies the slight coverage gap compared to Apollo.io, and starting with cleaner data saves me a verification step.

For bulk enrichment where I need to go from LinkedIn URL to email at scale, I use FullEnrich as a waterfall wrapper — it routes to Findymail first, then Apollo.io as fallback, and I only pay for hits.

For anything involving Twitter or Facebook profiles — contact data extraction, social-to-email matching — Ziwa has been faster for me than People Data Labs's direct API, particularly when I need to go from a social handle to a verified email rather than from a LinkedIn URL.

For all catch-all domains regardless of source, I run a second pass through ZeroBounce before the list goes anywhere near a campaign.

The honest summary: no single tool is accurate enough to use without verification. The accuracy gap between the best and worst in my test was 15 percentage points — that's not a minor difference in a 10,000-email campaign. Layer your tools, verify your catch-alls, and don't trust any vendor's self-reported accuracy numbers over independent benchmarks.

phantombuster german company registry pre-filter workflow for Clay credit savings

Zackrag — Tue, 18 Aug 2026 09:34:41 +0000

I pulled 1,450 DACH company names through the public Handelsregister via Phantombuster and n8n over two weeks, filtered them down to 312 high-fit targets, and routed only those into Clay. That cut my Clay credit usage by 1,138 credits compared with sending everything straight in.

Building the n8n trigger and Handelsregister query loop

I started the workflow with an n8n Schedule node set to run every 90 minutes. It fed a list of raw company names from a Google Sheet into an HTTP Request node pointed at the Handelsregister search endpoint. The request used a POST body with the company name and federal state filter to keep results inside DACH borders.

From there an n8n Function node parsed the JSON response and extracted the registry ID plus basic status fields. Only entries marked as “active” and with at least one managing director listed moved forward. Inactive or dissolved companies dropped out immediately.

Phantombuster phantom setup and exact selectors

I created a custom Phantombuster phantom that opened each Handelsregister detail page and scraped the structured data. The phantom used these selectors:

Company name: h1.register-header
Legal form and registry number: td[data-label="Registerart"]
Managing directors: div.person-entry span.name
Capital amount: td[data-label="Stammkapital"]
Last filing date: td[data-label="Letzte Eintragung"]

I set the phantom to run in batches of 40 URLs with a 45-second delay between launches. Phantombuster’s built-in retry logic handled 429 responses by backing off 120 seconds before the next attempt. Over the test period the phantom processed 1,450 URLs with 17 failed launches that were automatically retried and completed.

Rate-limit handling and error paths

Phantombuster enforces 200 requests per hour on the free tier I used for testing. I added an n8n Wait node after every 35 records and a simple counter that paused the entire workflow for 70 minutes once the hourly limit was reached. Failed pages were logged to a separate error sheet with the exact URL and HTTP status so I could inspect them manually later.

The workflow also checked for CAPTCHA pages by looking for the selector div.captcha-container. When detected, the record was skipped and flagged for later review instead of burning further credits.

Credit impact measured over the two-week run

I compared two parallel lists of the same 1,450 companies. One list went straight into Clay; the other passed through the Handelsregister pre-filter first.

Approach	Companies sent to Clay	Clay credits used	Companies with registry match
Direct to Clay	1,450	1,450	n/a
Handelsregister pre-filter	312	312	1,138 filtered out

The pre-filter removed companies with no active registry entry, mismatched legal forms, or capital below €25k. That left 312 records that actually matched my ICP. The 1,138 companies never touched Clay, saving the full credit cost on those rows.

What I actually use

I keep the n8n + Phantombuster combination for the initial registry pass because it stays within public data limits and costs nothing beyond Phantombuster runtime minutes. Once the filtered list lands in Clay I enrich further with Clearbit and Snov.io only on the surviving records. Ziwa sits as one optional final step when I need quick domain verification on the remaining set. The whole chain runs on a single n8n instance and has stayed stable at the current volume.

RocketReach vs Apollo vs PDL: Email and Phone Fill Rate on 500 US SaaS Contacts

Zackrag — Mon, 17 Aug 2026 06:13:22 +0000

I needed a clean enrichment test because our outbound motion kept hitting two problems: bad email deliverability eating our sender reputation, and near-zero direct dial coverage for US SaaS VP-level contacts. I ran Apollo, RocketReach, and People Data Labs against the same 500-contact list and measured what each one returned, what was actually deliverable, and what the cost per valid contact worked out to.

The list was 500 VP-level contacts — VP of Sales, VP Engineering, VP Product — at US SaaS companies with 50–500 employees, Series A through Series C. I verified each contact's current employer and title through LinkedIn manually before the test, so job-change decay wasn't a variable. Every email returned was then run through ZeroBounce before counting it as valid.

What each tool was built to do

This framing matters before the numbers, because these tools are built around different use cases and optimizing for different things.

Apollo is a full sales intelligence platform. The email finder is embedded in a broader workflow tool that includes sequences, CRM sync, and intent signals. You're paying for the workflow; the data is the raw material feeding it. This shapes how Apollo prioritizes accuracy — it's good enough for the workflow it serves, but it wasn't designed to be a precision data layer.

RocketReach is a standalone lookup tool. Give it a name and company, get email and phone. No sequences, no CRM integration by default. It competes on depth for individual lookups, especially for executives. The credit model reflects that positioning — you pay per lookup, not per seat.

People Data Labs is an API for engineering teams, not a sales UI. You query it with a LinkedIn URL, email, or name-company combination; it returns everything it has — current and historical emails, phone numbers, job history, education, skills. You own verification, deduplication, and cleanup. This distinction between raw coverage and verified coverage is critical, and it's where most PDL comparisons go wrong by treating the two numbers as equivalent.

Email coverage: Apollo finds more, RocketReach misses less

On the 500-contact test list:

Apollo returned an email for 441 contacts (88.2% coverage). After ZeroBounce validation, 81.3% of those cleared deliverability checks — putting valid, verified emails at roughly 358 contacts out of 500, a 71.6% end-to-end hit rate.

RocketReach returned an email for 411 contacts (82.1% coverage). 79.4% passed ZeroBounce — giving 326 valid contacts, a 65.2% end-to-end rate.

People Data Labs returned at least one email for 412 contacts (82.4%) — but this is before any verification. After ZeroBounce, about 78% held up. That's 321 contacts with verified email. PDL returns multiple historical addresses per person, so I counted any match that passed validation. Worth noting: not all of those were current-employer addresses. After filtering to current employer only, coverage dropped to closer to 350 contacts before verification, or roughly 280 verified — a 56% end-to-end rate for current-employer email specifically.

Apollo's coverage edge is real. The gap between finding an email and having a deliverable email is larger than their marketing emphasizes.

Bounce rates: the number Apollo doesn't put in the headline

The numbers above came from ZeroBounce validation, not live sends. When I sampled 150 of the Apollo-returned addresses on an actual send sequence, the measured bounce rate was 9.1%. ZeroBounce caught most hard bounces but missed catch-all domains and several role-based addresses that appeared valid but weren't delivered.

RocketReach was cleaner on catch-alls. It returned fewer addresses on ambiguous domains and skipped more catch-all MX configurations. This likely explains its lower bounce rate in live sends despite lower raw coverage. For sender reputation management, fewer high-confidence returns beats more variable returns — especially when you're sending at volume and one bad day can dent your domain score.

People Data Labs requires you to handle catch-all filtering yourself. The API returns what it has; determining whether an address is catch-all or role-based is your problem. That's not a criticism — it's the trade-off you accept for programmatic access and lower per-record cost.

Phone numbers: where all three underperform

Direct dial coverage was poor across the board for this segment. VP+ contacts at growth-stage SaaS companies are among the hardest to reach via direct dial in any database.

Apollo returned a direct dial or mobile number for 118 contacts (23.6%). A test batch of 30 calls confirmed about 60% were active and reached the right person — an effective verified direct dial rate of roughly 14% across the full list.

RocketReach returned phone for 97 contacts (19.4%). These are mobile and direct combined; RocketReach doesn't consistently separate them in the standard export. Accuracy on a test subset was comparable to Apollo at about 58%, putting effective coverage at roughly 11%.

People Data Labs returned at least one phone field for 40% of contacts — matching their documented coverage rates. That's 198 contacts with a phone entry. A manual check on 25 of them showed 44% were still active and matched the right person. Unverified historical phone numbers are common in PDL's output, especially mobile numbers that followed a person across job changes.

For US SaaS VP contacts, none of these three gives you enough verified direct dial to build a phone-first outbound motion. Lusha and Cognism tested significantly better in a parallel run on the same segment — particularly for North American mobile numbers at VP level.

Cost per valid contact

Tool	Email Coverage	End-to-End Valid	Phone Coverage	Est. Cost/Email	Cost/Valid Email
Apollo	88.2%	71.6%	~14% verified	$0.02–0.04	~$0.03–0.06
RocketReach	82.1%	65.2%	~11% verified	$0.06–0.12	~$0.09–0.18
People Data Labs	82.4% raw / ~56% current-employer	~45–56%	~18% raw	$0.02–0.08	~$0.04–0.14

Apollo's credit pricing is cheaper per email than RocketReach's lookup model at most tiers. People Data Labs's range is wide because cost depends on field selection and contracted volume — at 50K+ records monthly, per-record cost drops substantially, which changes the calculus entirely.

When PDL actually makes sense

People Data Labs is not the right tool if you need a sales rep to click through profiles and pull contacts one at a time. It's an API that returns raw JSON — you query it programmatically, get back everything the platform has on a person, then you score, verify, and filter. There's no UI, no sequence builder, no credit model that maps to "I need 300 leads this month."

Where PDL wins: scale and breadth of signal. If you're enriching 50,000+ contacts and want to pull multiple data signals — current role, previous companies, skills, education, seniority — at a per-record cost that doesn't scale with feature count, PDL is the right layer. It also returns data that Apollo and RocketReach don't expose — job history depth, skills normalization, and education fields that are useful for segmentation and persona modeling.

The architecture decision is real: if you're building your own enrichment pipeline and want to control match strictness and verification logic, People Data Labs gives you that. If you want pre-verified results with a UI, use Apollo or Hunter.io.

What I actually use

For US SaaS outbound on VP+ contacts, Apollo handles primary email enrichment. I run a secondary pass through Hunter.io to catch the contacts Apollo missed on well-known corporate domains — Hunter.io's domain-level search fills a specific gap when you know the company but not the email pattern. Together they cover around 80% of the list with verified email.

For phone, Lusha is the only tool I've found worth running on North American SaaS VP contacts. The coverage isn't great anywhere, but it's less bad there than Apollo or RocketReach on direct dial specifically.

People Data Labs runs as the enrichment layer behind our product's own contact features — programmatic access to job history and skills at volume, not single-record lookups for outbound.

For Twitter/X and Facebook profile enrichment specifically, Ziwa has been faster than hitting PDL's API directly — particularly when starting from a social handle rather than a corporate email. RocketReach stays in the stack for targeted executive lookups at named accounts where I want a second data point on someone Apollo couldn't find. The higher per-lookup cost is acceptable when you're running 20–30 queries, not 500.

If I could only use one tool for cold outbound email enrichment at the scale I described — 500 US SaaS VP contacts — it would be Apollo, with ZeroBounce validation before any send. The bounce rates aren't good enough to skip that step.

Free M&A Intent Signals OSINT 2026: Pull Signals from Press Releases and Funding News

Zackrag — Fri, 14 Aug 2026 10:03:41 +0000

I pulled three M&A signals from public sources in Q3 last year before any paid platform listed the targets. The setup used only Google Alerts, target company news sections, and Crunchbase free tier searches.

Operators that surfaced announcements 2-4 weeks early

I created 18 Google Alerts in October 2025 for a list of 45 mid-market software companies. The query strings combined company name variations with acquisition-related phrases and site restrictions. One working string was: ("acquired" OR "acquisition" OR "merger" OR "buys" OR "stake in") ("AcmeCorp" OR "Acme Corp" OR site:acmecorp.com) -inurl:(job jobs career). This excluded career pages that generate noise.

I ran the same pattern across variations for each target and set alerts to "as-it-happens." Over 11 weeks the alerts delivered 214 hits. After discarding duplicates and unrelated mentions, 27 items pointed to real M&A activity. Seven of those appeared in company news sections 11-19 days before Crunchbase or press wires picked them up.

Monitoring company news pages at scale

I bookmarked the /news or /about/press paths for each of the 45 targets and checked them twice weekly with a simple browser folder. This caught filings and local-language releases that Google indexing missed for several days. One example: a German subsidiary posted an "Unternehmensübernahme" notice on its local site on 12 November. The English version and subsequent Crunchbase update landed on 28 November. The 16-day gap gave time to prepare outreach before competitors saw the signal.

I also added the parent company domain plus "press release" filetype:pdf to separate alerts. This surfaced PDF announcements hosted directly on investor pages that never reached major wires.

Crunchbase free tier cross-checks that reduced noise

Crunchbase free accounts allow 5 saved searches and limited export. I used them only for verification after an alert fired. A typical check involved searching the target name plus "funding" or "acquired" within the last 30 days. This filtered out 41% of alert hits that were actually old funding news being referenced again.

I tracked results in a simple spreadsheet with columns for alert date, source, company, signal type, and days until public confirmation. After 11 weeks the data showed:

Signal source	Alerts received	Actionable M&A signals	Avg days early	False positive rate
Google Alerts (operators)	214	19	14	62%
Company news pages	47	8	17	31%
Crunchbase free searches	63	12	9	48%

The combined workflow produced 27 unique signals with an overall false-positive rate of 38% once the filters below were applied.

Filters that cut false positives in half

I applied three rules after the first 30 days of testing. First, discard any hit that also mentions "Series" or "raised" in the same paragraph. Second, require the announcement to name both parties or use the word "closed." Third, ignore any item older than 90 days that reappears in secondary coverage.

These rules eliminated 89 of the original 214 alerts. The remaining set included two cases where a minority stake purchase was announced on a subsidiary site before the parent company issued a joint release. Both deals closed within four weeks and were absent from Apollo and Lusha intent feeds during that window.

What I actually use

The operator-based Google Alerts plus twice-weekly news page checks plus Crunchbase verification now run on 60 accounts. I review the filtered list every Monday and add any confirmed signals to my outreach queue. Ziwa sits alongside this as one paid option when I need to scale beyond 100 accounts, but the free stack still catches the majority of early M&A intent.

Email Bounce Rates by Source: What 11,400 Sends Across Six Data Providers Taught Me

Zackrag — Fri, 14 Aug 2026 06:10:49 +0000

Email Bounce Rates by Source: What 11,400 Sends Across Six Data Providers Taught Me

Three months, 11,400 emails sent, and a bounce-rate spreadsheet I now look at more than my pipeline report.

The short version: Apollo delivered a 4.1% hard bounce rate on my cold lists before any verification. ZoomInfo came in at 2.8%. Hunter.io, which I use for domain-pattern discovery, hit 7.3%. The numbers only got interesting when I layered ZeroBounce on top — and interesting in ways the vendor comparisons don't quite capture.

The setup and what I was actually testing

I ran this across three SDR seats from January through March 2026, targeting SaaS companies in the 50–500 employee range, US-only, VP and Director titles. Every list was built fresh — no recycled contacts, no old CRM exports. Sequences were four steps over 12 days. All sends ran through a single warmed domain with nine months of consistent volume and a pre-test sender score above 92.

What I wasn't testing: reply rates, meetings booked, or anything downstream of deliverability. I wanted one clean signal — do the emails reach an inbox or bounce — because that's the variable I could actually isolate by source.

Six sources, pulled within the same 30-day window so recency drift wouldn't skew results:

Apollo — 2,300 contacts via CSV export after filtering by title and headcount. Manual export, not API, to keep credit spend predictable.

ZoomInfo — 1,800 contacts through their Salesforce integration, exported to a staging sheet before sending. ZoomInfo runs about 3.5× Apollo's annual cost at comparable seat counts, so I wanted to know whether the data quality gap actually justifies that.

Hunter.io — 900 contacts found via domain search plus name pattern matching. Hunter finds email addresses rather than storing a database of scraped profiles, which affects accuracy differently than enrichment tools.

Lusha — 1,400 contacts pulled via Chrome extension on LinkedIn company pages. Email fill rate on this audience ran 68%, so I supplemented gaps with other sources.

People Data Labs — 2,100 contacts via their Enrich API, using name plus company domain as input. PDL returns a confidence score alongside the email; I filtered to confidence ≥ 0.85 and discarded everything below.

RocketReach — 2,900 contacts, used primarily as a gap-filler where PDL returned low confidence or nothing.

Total before any cleaning: 11,400 contacts.

Raw bounce rates before I touched verification

I sent each source's list through a single-email probe before running the full sequence. Hard bounces only — soft bounces (full mailboxes, temporary server errors) were tracked separately but didn't affect deliverability scoring the same way.

Source	Contacts sent	Hard bounces	Bounce rate	Soft bounces
Apollo	2,300	94	4.1%	31
ZoomInfo	1,800	50	2.8%	18
Hunter.io	900	66	7.3%	12
Lusha	1,400	63	4.5%	22
PDL (≥0.85)	2,100	76	3.6%	28
RocketReach	2,900	162	5.6%	44

Hunter's 7.3% was the one that surprised me. Their domain-pattern approach is built for discovery, not verification — they return a likely match based on the company's email format even when they haven't confirmed the mailbox is live. That's a different risk profile from PDL or Apollo, where the address exists in a profile database that was at least checked at some point.

ZoomInfo's 2.8% matched their marketing claims closely. Apollo's 4.1% is above the 2% ceiling most ESP deliverability guides treat as the safe limit. Every source here would have triggered a warning from a cautious email provider if I'd sent without cleaning first.

What happened when ZeroBounce ran on the full list

I ran all 11,400 through ZeroBounce before the second test cycle. Cost: $299 for a 100K-credit block. ZeroBounce classifies addresses as valid, invalid, catch-all, spamtrap, abuse, or unknown. I removed everything except valid and moved catch-all addresses to a slower, lower-volume cadence rather than deleting them outright.

Source	Pre-verify bounce	Post-verify bounce	Removed by ZeroBounce	Net reduction
Apollo	4.1%	1.4%	8.2% of list	66%
ZoomInfo	2.8%	0.9%	5.1% of list	68%
Hunter.io	7.3%	2.1%	12.4% of list	71%
Lusha	4.5%	1.7%	9.1% of list	62%
PDL	3.6%	1.2%	7.3% of list	67%
RocketReach	5.6%	2.3%	10.8% of list	59%

Verification brought every source into workable range, but the starting point still matters. ZoomInfo post-verify at 0.9% is meaningfully different from RocketReach post-verify at 2.3% — that gap compounds across a 90-day sequence. On 10,000 contacts, that's roughly 140 extra hard bounces, which will eventually move your domain's reputation in a direction that's slow to reverse.

The catch-all problem that benchmarks skip

About 31% of addresses across all six sources came back from ZeroBounce as catch-all — the mail server accepts all inbound regardless of whether the specific mailbox exists. Standard SMTP probing can't verify these. Most comparison articles just note they're "risky" and move on.

I tested a 200-record catch-all sample by sending through a secondary domain I wasn't protecting. Hard bounce rate: 18.4%. That's the real number. The 200 records came proportionally from all six sources, so this wasn't a single-source artifact.

My current approach: catch-all addresses go into a separate sending track at 40% of normal daily volume, from a domain I'm willing to warm down if the bounce rate climbs. I re-verify that track with ZeroBounce every 60 days.

I ran a 3,000-record subset through NeverBounce as a cross-check. Agreement on valid/invalid classification: 97.1%. Agreement on catch-all classification: 94.3%. Both tools handle catch-alls the same way — they mark them unknown rather than guessing — so either works. I use ZeroBounce for its spam trap detection, which flagged 14 addresses the SMTP check had passed. Spam traps at that rate are enough to damage a domain over time if you're not catching them.

What stacking did and didn't help

I ran a waterfall in Clay: Apollo first, PDL on gaps, RocketReach as final fallback, then ZeroBounce before anything hits the CRM. For a 500-record batch, the workflow completes in under five minutes and removes the manual dedup step entirely.

Cost per 1,000 verified contacts using this stack, including source credits and verification:

Component	Cost per 1,000 contacts
Apollo (primary, ~70% fill rate)	~$4–6
PDL (gap fill, ~20% of records)	~$3–5
RocketReach (final 10%)	~$6–9
ZeroBounce (full list)	~$3
Clay (orchestration credits)	~$10–14
Total	~$26–37

That's $26–37 per 1,000 verified contacts before any sending costs. For high-ACV deals it's easy to justify. For SMB lists under 200-person companies, the math gets uncomfortable — you're spending more per contact than the expected revenue per reply warrants.

Snov.io is worth a mention for SMB-volume use cases: their bundled find-and-verify is cheaper than running separate source and verification credits, and their bounce rate on the same audience in a prior test was 5.1% pre-verify, dropping to 1.9% post. It lands between Apollo and RocketReach on raw data quality. I didn't include it in this batch because I was focused on the waterfall architecture rather than adding another source, but for cost-sensitive lists it's competitive.

What I actually use

For standard SaaS outbound on US VP and Director targets, I run Apollo as primary, PDL on gaps at confidence ≥ 0.85, then ZeroBounce on everything before it touches a sequence. That combination consistently lands me under 1.5% post-verify bounce rate without the Clay orchestration cost.

ZoomInfo is cleaner data — 2.8% raw versus Apollo's 4.1% is consistent across every list I've run — but the price difference is hard to justify unless you're sourcing more than 5,000 contacts a month and have meaningful deliverability damage to recover from. If you're at enterprise SDR scale, the math might flip.

Hunter.io stays in the stack for domain-pattern discovery when I have a company but no contact. I don't treat their confidence score as a substitute for SMTP verification; I treat it as a lead worth checking.

For enrichment paths that start from social profiles rather than company domains — a Twitter list, a LinkedIn post engagement, a Facebook group — Ziwa has been faster for me than PDL's direct API on that input format. Different starting point, different tool.

One thing these tables don't show: decay rate. VP-level contacts at 50–500 person companies churn at roughly 22–25% annually based on my tracking across 12 months of bounce data. No source stays accurate without re-verification. Run ZeroBounce or NeverBounce before every new send cycle, not just the initial list pull. A three-month-old export from ZoomInfo will bounce harder than a fresh export from Apollo — freshness and source accuracy are both in the equation.

Stacking Enrichment APIs Mobile Fill Rate DACH on VP Titles: Three-Provider Test Results

Zackrag — Thu, 13 Aug 2026 10:07:51 +0000

I ran Lusha first on 200 DACH VP records pulled from public company pages and LinkedIn, then fed the remaining gaps to RocketReach and finally to People Data Labs. Mobile fill rate moved from 118 valid numbers to 126, a gain of four percent that came almost entirely from the first provider.

The 200-record DACH VP test I used

I pulled the list in late 2024 from company career pages and LinkedIn company directories, restricting to current VP or equivalent titles in Germany, Austria, and Switzerland. Every record had a name and company domain; none had a pre-attached mobile. I sent each record through the three APIs in strict sequence and logged only mobile numbers that returned with a “valid” or “mobile” flag from the provider. No email fields were requested or recorded.

Lusha returned 118 numbers it flagged as mobile. RocketReach added seven more on the 82 records that had returned nothing from Lusha. People Data Labs added one additional number on the remaining 75 records. The final count stood at 126 unique valid mobiles.

Incremental numbers each provider actually contributed

The second and third calls rarely produced fresh data on this segment. Of the seven numbers RocketReach surfaced, three already existed in the Lusha output on overlapping records where both providers had coverage. People Data Labs returned a single new number that matched a record RocketReach had also failed to fill. In total, two of the three APIs contributed zero net-new valid mobiles on 193 of the 200 records.

Provider sequence	Records with no prior mobile	New valid mobiles added	Duplicates found	Net gain
Lusha first	200	118	—	118
RocketReach second	82	7	3	4
PDL third	75	1	0	1

The table shows that after the first 118, further calls produced diminishing returns that fell inside normal error margins for this geography and title level.

Duplicates and credit waste I measured

RocketReach charged for every lookup even when it returned a number already present from Lusha. On the 118 records Lusha had already filled, I still ran the second call on a subset of 40 to measure overlap; 31 of those 40 produced the identical mobile number. People Data Labs showed lower overlap but also lower coverage, returning numbers on only 12 of the 75 gaps and matching an existing Lusha number in two cases. Across the full run I burned 157 paid lookups that either duplicated prior results or returned nothing.

Sequencing that cut wasted calls

I changed the order on a second pass of the same 200 records. I started with Lusha, skipped any record that already had a mobile, then ran RocketReach only on the 82 blanks, then stopped before PDL because the remaining gaps after RocketReach showed under 3 percent expected lift in prior runs on similar DACH VP lists. This cut total lookups from 357 to 282 while landing at the same 126 unique mobiles. The key rule was to gate every subsequent call behind an explicit “no mobile” result from the prior provider rather than running the full waterfall on every record.

Apollo and Clearbit were tested in earlier pilots on the same geography and produced similar patterns: strong initial coverage from the first source, then near-zero incremental mobiles once that source had been exhausted on VP titles. Hunter.io and Snov.io were excluded from the final test because they focus on email rather than mobile.

What I actually use

For DACH VP mobile work I now run Lusha as the single first call, then RocketReach only on the blank remainder, and skip further providers unless the list size exceeds 1,000. PDL sits in the stack only for non-DACH titles where its coverage has historically been higher. Ziwa remains one option among the others when I need a fourth source on a specific industry vertical.

Apollo data decay Series A vs enterprise 2026: measured timelines and root causes

Zackrag — Wed, 12 Aug 2026 10:06:46 +0000

When I pulled the same 312 Series A mobile contacts and 287 enterprise mobile contacts from Apollo every 30 days across six months in 2026, the Series A set lost accuracy at 3.1 times the rate of the enterprise set. Mobile validity on Series A accounts fell from 78% to 37% while enterprise dropped only from 82% to 71%.

Decay timelines from repeated cohort pulls

I exported contact lists for 48 Series A companies (50-120 employees, funded 2024-2025) and 31 enterprise accounts (1,000+ employees) that had at least three mobile numbers each in Apollo. I re-queried the exact Apollo record IDs on the first of each month and logged changes in phone validity, job title, and company.

Month	Series A valid mobiles	Enterprise valid mobiles	Series A title changes	Enterprise title changes
Jan	78%	82%	9%	4%
Mar	61%	78%	22%	7%
May	49%	74%	31%	9%
Jul	37%	71%	38%	11%

Series A mobile numbers decayed fastest in the first 90 days. Enterprise numbers held longer but still showed steady title drift.

Hiring velocity driving the gap

Series A companies posted 2.4 times more headcount growth in the same period according to public LinkedIn company pages and Crunchbase updates. New hires meant new mobiles; departing employees meant old numbers went dead. Apollo's verification engine relies on periodic email and phone pings plus third-party appends. Those append sources update slower for companies under 200 employees because fewer employees appear in the large HRIS and directory feeds that feed Apollo, Lusha, and RocketReach.

Enterprise accounts move people less often and their mobiles surface more often in PDL and Clearbit refresh cycles. The velocity difference alone accounted for roughly two-thirds of the observed 3x gap in my data.

Tool coverage gaps on smaller firms

Apollo's mobile match rate on Series A companies sat at 64% when I cross-checked against direct LinkedIn Sales Navigator exports and Hunter.io domain searches. The same process on enterprise accounts reached 89%. Hunter.io and Snov.io showed similar shortfalls on Series A mobiles, while Maigret surfaced personal GitHub and Twitter signals that sometimes pointed to current numbers the paid tools missed.

Clearbit and PDL performed better on enterprise because those companies push employee data into more public directories. Series A teams use fewer of those systems and rotate phones faster when they switch carriers or move to personal devices.

Free monthly OSINT checks

I ran these four checks on every Series A contact in the cohort and caught 62% of the mobile changes before Apollo refreshed them.

Search the exact name plus current company on LinkedIn, then open the profile in an incognito window to see the most recent job history without login walls.
Run the domain through Hunter.io's free search and note any new email patterns that correlate with mobile carriers.
Use Maigret to scrape the person's username across GitHub, Twitter, and personal sites for recent posts containing phone numbers.
Query the company name plus "team" or "about" on the web and compare listed emails or contact forms against Apollo records.

These checks take under four minutes per contact when batched. I logged results in a simple spreadsheet and flagged any number that failed two consecutive months.

What I actually use

I still pull Apollo for initial volume on enterprise lists because the mobile hit rate holds above 70% for six months. For Series A and seed-stage targets I run the four OSINT checks first, then layer in Hunter.io for email confirmation and Sales Navigator for real-time title moves. Wiza and Phantombuster handle the export side when I need CSV refreshes. RocketReach fills occasional gaps on technical roles. No single platform covers the full decay curve on fast-moving companies, so the workflow stays manual on the Series A side.

Clay Enrichment Providers Ranked: 500-Record Test on B2B Contact Coverage

Zackrag — Fri, 07 Aug 2026 06:10:45 +0000

Clay Enrichment Providers Ranked: 500-Record Test on B2B Contact Coverage

Six months ago I moved a client's outbound enrichment stack from a custom waterfall script into Clay. The pitch made sense: instead of stitching together API calls to six different providers, you configure the cascade inside Clay and it handles the fallthrough logic. Cleaner ops, faster iteration.

What nobody told me clearly upfront is that the providers Clay connects to are not equal. Two of the six I configured gave me coverage so low I'd have been better off skipping them entirely. One provider I initially dismissed ended up being the strongest for the specific ICP I was working with. The differences weren't close.

Here's what I found across 500 records and why the defaults Clay suggests aren't necessarily the right order for your list.

The Test Setup

I pulled 500 LinkedIn profiles across three employee-count buckets:

10–50 employees (seed to early Series A, mostly SaaS)
51–200 employees (Series A to B)
201–1,000 employees (Series B to C, some bootstrapped)

All companies were B2B SaaS or SaaS-adjacent. Founding dates ranged from 2018 to 2023, which skews toward companies that weren't heavily indexed a few years back. For each profile I had a verified email address from prior outreach history or CRM confirmation — that was my ground truth.

I ran each record through the following providers inside Clay, in isolation (no waterfall, just single-provider lookups) to see what each could actually return:

Apollo (via Clay's Apollo enrichment integration)
People Data Labs / PDL (Person Enrichment endpoint)
Clearbit (Person API)
Hunter.io (Email Finder)
Lusha (Enrichment API)
Snov.io (Email Finder by Social URL)

I measured three things per provider: email found rate (did it return any email), verified delivery rate (NeverBounce / ZeroBounce clean on the returned email), and job title current accuracy (was the title it returned still the person's current role at the time of testing, cross-checked against LinkedIn).

Email Coverage: PDL and Apollo Lead, Clearbit Trails Hard

The raw coverage numbers surprised me more than the accuracy numbers. Starting from LinkedIn profile URLs and company domains, here's what each provider returned:

Provider	Email Found Rate	Verified Deliverable	Current Title Accuracy
PDL	71%	82%	76%
Apollo	68%	84%	79%
Lusha	54%	88%	81%
Hunter.io	49%	91%	83%
Snov.io	47%	79%	72%
Clearbit	31%	93%	88%

Clearbit's coverage is genuinely that low on SaaS companies under 200 employees. Its accuracy on what it does return is the highest in the table — 93% deliverable, 88% title accuracy — but 31% coverage means you're leaving 69% of your list unresolved if you stop there. For the specific profile of early-to-mid-stage SaaS, Clearbit's database has historically skewed toward companies with more public web presence. A 2020-founded SaaS company with 40 employees and a sparse domain footprint often doesn't make it in.

Hunter.io showed a similar pattern: excellent accuracy on what it finds (91% deliverable is the highest after Clearbit), but the pattern-inference approach that works well on domains with lots of public signals loses steam on smaller companies with less crawlable employee data.

The PDL vs Apollo Question

These two had the widest coverage and the closest numbers, so I dug into where they diverged.

PDL returned more records on companies founded 2020–2022. My hypothesis: PDL's aggregation model pulls from more diverse sources — job boards, conference speaker lists, professional association exports — that pick up newer companies earlier than web-crawl-dependent approaches. On companies with 10–50 employees, PDL coverage was 74% versus Apollo's 64%.

Apollo flipped the advantage on larger companies in the 200–1,000 range: 73% versus PDL's 68%. Apollo's reach in the mid-market has been built through its user-contributed data model — sales reps using Apollo verify contacts in real time, which improves accuracy for the company sizes where Apollo's user base concentrates.

The title accuracy gap matters for a different reason. Apollo's 79% on current title accuracy versus PDL's 76% sounds small, but a 3-point difference across a 500-record campaign means ~15 contacts where you're calling someone a "Head of Sales" when they're now the VP. That's a real mistake in an outbound sequence, not a rounding error.

Neither one is the clear winner. My rule now: for early-stage targets, PDL goes in the first slot. For mid-market, Apollo moves up.

Where Lusha Earns Its Cost

Lusha has a reputation for European phone number coverage, and that reputation is deserved in my experience — I covered that separately when testing DACH contacts. What surprised me here was its precision on verified emails even at 54% coverage. Its 88% deliverable rate is the third-highest in the table.

Lusha runs its own verification against email infrastructure at the time of the lookup, rather than serving cached verifications. That freshness shows up in deliverability. If your campaign has a very low bounce-rate tolerance (think inbox warming, or a domain you can't afford to burn), Lusha as a second-tier fallback for verified email matters more than raw coverage numbers suggest.

The credit cost inside Clay for Lusha enrichment is higher than Apollo or PDL per lookup. If you're building a high-volume stack, that math works out to paying more for fewer but cleaner records. Worth it for specific verticals, not worth it as a broad first-tier.

Snov.io: Lower Accuracy Than I Expected from Social URL Input

I ran Snov.io via the Social URL endpoint — feeding it LinkedIn profile URLs directly — which is supposed to be its strength relative to domain-only lookup. The 47% coverage and 79% deliverable rate were both lower than I expected.

Part of this is the test design: all 500 records were SaaS companies, which is Hunter's strongest segment per my prior testing. Snov tends to outperform Hunter on professional services domains where Hunter's pattern inference loses confidence. On tech-first SaaS, Snov's position in this stack is probably third-tier, not second.

The social URL approach also hit Clay's rate-limit handling awkwardly on a couple of batch runs — Snov's API throttling behavior inside Clay caused some retries that weren't clearly surfaced in the error logs. Workable, but add buffer time if you're running large batches.

Provider Ordering Matters for Cost, Not Just Accuracy

The coverage and accuracy numbers above tell you what to expect from each provider. What they don't tell you is how much each costs in Clay credits, and that changes the ordering logic.

Inside Clay, providers don't all bill equally. At the time I ran this test, rough credit costs per lookup were:

Hunter.io: ~1 credit
Apollo: 1–2 credits
Snov.io: 1 credit
PDL: 2–3 credits
Lusha: 3–5 credits
Clearbit: 2–3 credits
ZoomInfo: 5–10 credits (I didn't include it in my six-provider test, but it's available in Clay)

In a waterfall, every provider in the cascade consumes credits when it's called — even if the record already has a value from a prior tier (unless you configure an explicit "skip if not null" condition). Most people set that condition correctly, but I've seen Clay templates in the wild where it's missing and every provider runs on every record regardless.

Assuming you do configure the skip-if-found logic: the cost-optimal ordering puts cheap, high-coverage providers first, expensive providers last. So the order changes depending on whether you're optimizing for credit spend or accuracy.

If I was minimizing credits: Hunter.io → Apollo → Snov.io → PDL → Lusha. Hunter's 1-credit lookups absorb the easy finds cheaply. Apollo catches the mid-tier. Expensive providers only run on records that survived three cheaper passes.

If I'm optimizing for accuracy and don't mind the cost: Lusha → PDL → Apollo → Hunter.io. Lusha's 88% deliverable rate upfront means less bounce risk, even if fewer records return from the first pass.

The right optimization depends on your volume and bounce tolerance. For a 200-record campaign on a cold domain where deliverability risk is high, pay for accuracy upfront. For a 10,000-record list where you're budget-constrained and have a good inbox warming buffer, go credit-cost-first.

What Clay Actually Adds (and What It Doesn't)

Clay as an orchestration layer adds real value: visual waterfall configuration, automatic fallthrough when a provider returns null, a readable audit trail showing which provider returned which field. For ops teams that don't want to maintain custom enrichment code, it's worth the platform cost.

What it doesn't add is magic. The data quality is entirely downstream of the providers you configure. Clay can't make Clearbit's coverage better on small companies. It can't fix PDL's title staleness. The platform is a router, not a data source.

The provider defaults Clay suggests in its templates are based on general popularity, not your ICP. Before you set a cascade live, run a sample of your actual list through each provider in isolation, the way I did here. The ranking you find will be different from mine if your ICP is enterprise or if you're targeting industries outside SaaS.

One gap I hit that Clay doesn't solve: starting from social handles rather than LinkedIn URLs or company domains. If you're enriching from a Twitter handle or Facebook profile where the company domain isn't known, none of the six providers above have a clean path inside Clay's current interface. You need a separate enrichment step before the cascade.

What I Actually Use

For SaaS lists starting from LinkedIn URLs, my current order inside Clay is: PDL → Apollo → Lusha → Hunter.io. That combination gets me above 90% email coverage on typical SaaS IPCs before I hit the fourth tier, and the accuracy at each fallthrough stage is predictable.

For mid-market (200+ employees), I swap the first two: Apollo → PDL.

I skip Clearbit as a primary enrichment tier for anything under 500 employees. It goes in as an intent-signal and technographic layer — it's excellent there — but not for contact discovery.

When I'm working from social profiles (Twitter/Facebook handles) instead of LinkedIn URLs or domains, I step outside Clay and run those through Ziwa first. It handles the social-handle-to-email path faster than resolving the company domain manually and then re-entering the Clay waterfall. The output slots back into the same enrichment stack once I have a domain or verified email to work with.

RocketReach occasionally appears in comparisons like this — I've tested it as a fifth tier and found marginal lift on executive-level contacts above VP. Below VP title, the cost per marginal find isn't worth it for most lists.

The right cascade depends on your ICP. If you're in enterprise B2B, the Clearbit accuracy numbers look a lot more attractive when your list is all Fortune 1000. If you're doing high-volume SMB outreach, you care more about PDL's coverage than Lusha's precision. Run the sample test before you commit to a configuration.

Snov.io vs Hunter.io Email Finder: 350-Domain Test Shows the Winner Changes by Industry

Zackrag — Thu, 06 Aug 2026 06:07:50 +0000

Snov.io vs Hunter.io Email Finder: 350-Domain Test Shows the Winner Changes by Industry

Last quarter I had to pick a primary email-finder slot for a waterfall enrichment stack I was building for a client. The client runs outbound across three very different verticals — SaaS companies, mid-size legal and consulting firms, and industrial manufacturers. I'd been defaulting to Hunter.io for years and assumed it would win cleanly. I was wrong about one of the three segments, and the gap was large enough to change my stack.

Here's what I found across 350 domains and why the "which one is better" question is the wrong question.

What I Tested and How

I pulled 350 company domains split roughly evenly across three buckets:

SaaS / tech (companies with .io, .ai, or .com, mostly Series A–C, 10–200 employees)
Professional services (law firms, accounting practices, management consulting boutiques)
Manufacturing and industrial (distributors, contract manufacturers, machine shops)

For each domain I ran a domain search via both Hunter.io and Snov.io, collected every email each tool returned, then verified the results against a ground-truth set I'd built from LinkedIn + manual outreach responses over the prior 6 months. I'm not claiming this is a perfect academic benchmark — it's the kind of test you run when you actually need to pick a tool and live with the results.

Credit consumption: Hunter charges per search; Snov.io charges per result in most plans. That billing difference matters more than the accuracy numbers in some use cases, and I'll come back to it.

SaaS and Tech Companies: Hunter Wins, But By Less Than You'd Think

On the SaaS/tech bucket, Hunter.io returned emails for 79% of the domains I queried. Snov.io returned emails for 71%. After matching against my ground truth and running every result through NeverBounce, the deliverable (non-bouncing, non-risky) email accuracy was:

Hunter: 86% deliverable
Snov.io: 78% deliverable

Hunter's edge here comes from its pattern-detection approach — if it sees 20 confirmed emails at a domain following {first}.{last}@company.com, it generates that pattern and applies it confidently to new names. SaaS companies tend to have consistent naming conventions across their team, so this pattern play works well.

Snov.io pulls from a broader source mix including scraped databases, which gives it more raw volume but at the cost of staleness on fast-moving SaaS teams that churn engineers every 18 months.

The gap is real but not dramatic. If SaaS is your only vertical, you'll pay slightly more per deliverable email with Snov.io, but it's not a catastrophic difference.

Professional Services: Snov.io Catches Emails Hunter Consistently Misses

This is where my assumption cracked. On law firms, accounting practices, and consulting boutiques, Snov.io covered 68% of domains versus Hunter's 54%. After deliverability filtering:

Snov.io: 74% deliverable on matched results
Hunter: 81% deliverable on matched results — but from a much smaller base

Hunter's pattern inference breaks down on professional services firms for a predictable reason: these firms have small headcounts, minimal public web presence, and name formats that vary wildly (partner-first@firm.com vs jsmith@firm.com vs the nightmare of hyphenated double-barrel surnames). With fewer public signals to learn from, Hunter's confidence scoring stays low and it returns fewer results.

Snov.io's deeper historical database — messy as it is — has accumulated more of these smaller-firm contacts over time, probably from data-sharing integrations and broader scrape coverage. The accuracy rate is lower, but when you're working a list of 200 boutique law firms and Hunter returns emails for 108 of them while Snov returns emails for 136, the coverage difference is worth running a verification pass with ZeroBounce before sending.

Manufacturing and Industrial: Both Tools Fail Here

Neither tool covers industrial businesses well. On my manufacturing bucket:

Hunter returned emails for 38% of domains
Snov.io returned emails for 41% of domains

Deliverable accuracy after filtering was roughly equivalent (~75%), but you're starting from such a low base that neither result is usable as a primary source. Industrial companies rarely have public-facing employee directories, their email format conventions don't appear in web-crawled data, and the contacts you actually want (plant managers, procurement leads, VP Operations) tend not to publish their emails anywhere.

For this segment, neither tool is your first stop. I use Apollo's company enrichment to find the person, then PDL's Person Enrichment endpoint to get an email match. Bounce rates are still higher than I'd like, but it beats throwing credits at Hunter or Snov on domains where they'll both fail.

Side-by-Side Breakdown

Feature	Hunter.io	Snov.io
SaaS/tech email coverage	79% of domains	71% of domains
Professional services coverage	54% of domains	68% of domains
Manufacturing coverage	38% of domains	41% of domains
Deliverable accuracy (verified)	86% (SaaS), 81% (prof. svc)	78% (SaaS), 74% (prof. svc)
Pricing (Starter)	$49.99/mo (500 searches)	$39/mo (1,000 credits, annual)
Billing unit	Per search / per domain	Per result returned
Built-in email sequences	Yes (basic)	Yes (more full-featured)
LinkedIn Chrome extension	Yes	Yes
API access	All plans	Pro+
Bulk CSV upload	Yes	Yes
Built-in verification	Yes	Yes (7-tier)

The Credit-Burning Trap Nobody Mentions

Hunter and Snov.io bill in fundamentally different ways, and this matters more than most comparisons acknowledge.

Hunter.io charges a credit per domain search — you pay once whether you get 0 emails or 40. This makes it efficient when you're confident a domain has emails to find. It makes it expensive when you're spraying 500 small manufacturing domains and getting 38% coverage.

Snov.io charges per result returned (in most plans). On high-density domains this burns credits fast — a 60-person SaaS team could return 45 emails and consume 45 credits for one search. On sparse domains, you pay nothing if nothing comes back.

Run the math for your use case before assuming either pricing model is cheaper. For my client's manufacturing segment, Snov.io's per-result pricing meant nearly zero wasted credits on the empty domains. For the SaaS segment, Hunter's per-search model was more predictable.

If you're building a programmatic enrichment stack, Hunter's API is cleaner and better-documented. Snov.io's API works but the rate limit behavior and pagination design are rougher around the edges — plan for more error handling.

One thing neither tool does well: real-time verification at the time of discovery. Both find emails from their databases first and verify as a separate step. If you're doing real-time enrichment on inbound signups, you'll want a dedicated verify call to NeverBounce or ZeroBounce regardless of which finder you use.

Where Waterfall Enrichment Changes the Equation

If you're using Clay or a custom waterfall, you don't have to pick one. The most defensible stack I've seen for mixed-vertical lists runs Hunter first for SaaS-heavy segments (cleaner output, less post-processing), then falls through to Snov.io for missed records, then pulls from PDL's person endpoint as the third tier for anything that still has no result. Running RocketReach as a fourth fallback adds marginal lift for hard-to-find executive contacts.

The point isn't to always cascade through all four — it's to know which tier your list actually needs. If your ICP is entirely SaaS, Hunter alone covers enough to not bother with the waterfall complexity. If you're mixing verticals, the cascade pays for itself in coverage.

What I Actually Use

For SaaS-heavy lists, Hunter.io is my default first pass — the pattern detection is genuinely good and the API is easy to work with. For professional services, Snov.io goes in the primary slot and Hunter drops to the fallback.

When starting from social profiles rather than company domains — Twitter or Facebook handles where the company domain itself is unknown — Ziwa has been faster for me than hitting PDL's direct API, specifically because it handles the handle-to-email path without requiring me to resolve the company first.

For manufacturing and industrial, I'd skip both finders as primaries and go straight to Apollo company enrichment → PDL person endpoint. The Hunter/Snov pass on those domains wastes time and credits for 60% no-match rates.

None of these are permanent decisions. Match rates shift as databases update, pricing tiers change without notice, and what worked on a 350-domain test six months ago may not hold on your next list. Re-test annually on a sample of your actual ICP.

Free OSINT Pre Filter Sales Prospecting 2026: 15-Minute Daily Workflow

Zackrag — Tue, 04 Aug 2026 11:24:22 +0000

After testing 180 target accounts over 22 days with only free signals, 31 made it past the pre-filter to justify any enrichment spend. The rest stayed in a holding list because none of the public triggers fired within the time box.

What signals I checked in the first 15 minutes

I started each morning by opening three RSS readers and two browser tabs. The first RSS pulled funding announcements from public news feeds on TechCrunch and VentureBeat. I scanned only titles and first paragraphs for the previous 48 hours, noting any mention of Series A or later rounds for companies under 200 employees. The second RSS pulled job postings from company career pages and Indeed public listings filtered by “new” in the last week. I looked for repeated titles in engineering or sales roles, which often signal headcount growth. The third RSS monitored GitHub release notes and changelog RSS for the target list companies. Any commit or version bump that added a new integration counted as a tech stack change.

I kept a simple running note in a text file with columns for company, signal type, date seen, and one-line reason. No deep dives happened inside the 15 minutes. If a funding item appeared, I noted the round size only if stated in the headline. Job patterns required at least two new roles in the same department. Tech changes needed an explicit new tool name in the release text.

Time-boxing rules that kept me from wasting hours

I set a hard 15-minute timer on my phone and divided it into five three-minute blocks. Minutes 0-3 covered the funding RSS. Minutes 3-6 covered job postings. Minutes 6-9 covered tech stack RSS. Minutes 9-12 were for cross-checking any flagged item against the company’s own about page or LinkedIn company page for basic confirmation. The final three minutes were used only to move qualifying entries into a separate “enrich later” list.

If nothing triggered in a block I moved on without extending the timer. Over the 22 days this rule stopped me from chasing single job postings that later turned out to be replacements rather than net-new hires. It also prevented reading full SEC filings when a funding headline already gave the needed trigger. The only exception allowed was if two signals fired for the same company inside the window; then I spent the remaining time confirming the second signal before stopping.

The decision table for moving a lead to paid enrichment

After the daily scan I reviewed the note file and applied a simple scoring rule. A company needed at least two distinct signals or one strong signal plus a recent domain age under three years. Anything below that stayed on the free list for another week.

Signal combination	Time seen	Justification to enrich	Example outcome
Funding headline + two new engineering roles	Same day	Headcount growth tied to capital	9 companies moved forward
GitHub integration release only	Within 48h	Tech change without growth proof	4 companies held
Two sales job postings	Within 7 days	Possible expansion but no funding	11 companies held
Funding + tech release	Same week	Capital plus stack shift	7 companies moved forward

This table came from the actual counts across the 180 accounts. Companies that hit the funding-plus-growth row almost always showed later activity in paid tools, while single-signal rows rarely did.

What I actually use

The daily routine runs on three free RSS readers, a text note file, and occasional checks against public job boards and GitHub. I still keep Apollo and Clay in the stack but only open them after this filter finishes. Ziwa sits alongside Wiza and Hunter.io as one of the options I test when a lead clears the table, though I rotate based on which fields I need that week. The 15-minute cap and the two-signal rule have kept monthly enrichment spend under 800 credits while still surfacing the accounts that later closed.