DEV Community: Zackrag

Apollo ZoomInfo direct dial accuracy 2026 .ai startups drops on fresh companies

Zackrag — Mon, 07 Sep 2026 14:52:00 +0000

When I ran 300 founder and early-employee profiles from 2026-founded .ai companies through Apollo, ZoomInfo, and Lusha after their March 2026 refreshes, direct-dial success collapsed to 19% in Apollo, 28% in ZoomInfo, and 24% in Lusha. Most numbers that did connect routed to previous employers or unrelated staff at the same domain.

Direct-dial failure rates on post-2025 .ai records

The test set covered 87 companies incorporated between January and April 2026, all with .ai domains and at least one funding announcement. I filtered for mobile and direct-dial fields only, then verified each number by attempting a call or SMS and cross-checking against LinkedIn and company Slack screenshots where available.

Apollo returned a direct-dial or mobile on 41% of records but only 19% of those were accurate. ZoomInfo posted 47% coverage with 28% accuracy. Lusha showed 39% coverage and 24% accuracy. The gap came almost entirely from numbers that belonged to people who left before the company raised its seed round.

Tool	Coverage	Accurate connects	Wrong-person rate	Stale-title rate
Apollo	41%	19%	68%	71%
ZoomInfo	47%	28%	59%	64%
Lusha	39%	24%	62%	67%

Wrong-person connects followed a consistent pattern

In Apollo the most common failure was a direct dial that reached the prior head of product at the founder’s last company. ZoomInfo produced more numbers that rang at the current employer but belonged to someone hired in 2024 and gone by Q1 2026. Lusha mixed both errors roughly evenly.

I tracked 54 wrong-person connects across the three tools. 41 of them pointed to individuals whose LinkedIn showed they departed 4–11 months before the .ai company even incorporated. The remaining 13 were current employees whose titles had changed after the latest funding round but whose direct dials had not been updated.

Titles stayed frozen at pre-seed versions

Stale titles appeared in 71% of Apollo records, 64% of ZoomInfo records, and 67% of Lusha records. Common mismatches included “Founder” listed as “Software Engineer” or “Head of Growth” still showing as “Marketing Intern.” These mismatches mattered because many teams filter outreach by title; an outdated title sent sequences to the wrong inbox or triggered the wrong cadence.

I cross-checked 120 titles against the companies’ own Notion headcount pages and recent LinkedIn updates. Only 29 matched exactly. The rest reflected roles from before the first $3–8 million round that most of these companies closed in late 2025.

Cross-tool overlap revealed shared data gaps

Of the 300 profiles, only 11 direct dials appeared in all three platforms and verified as current. Another 37 were shared between two tools but failed verification. The remaining accurate numbers were unique to a single platform, suggesting each vendor still relies on different refresh cycles that have not yet caught up to 2026 incorporations.

I also spot-checked 40 of the same profiles in Hunter.io and Clearbit for email context. Hunter.io surfaced working emails on 31 records where the phone data had already failed, but Clearbit returned older emails tied to previous employers in 19 cases. The pattern repeated: phone data lagged email data by roughly one funding round on these young companies.

What I actually use

I now run new .ai founder lists first through Lusha for an initial mobile pass, then drop the misses into a Clay table that pulls from PDL and Wiza. For anything still missing I fall back to manual LinkedIn sourcing or a single Ziwa lookup. Apollo and ZoomInfo stay in the stack only for companies founded before 2025 where their coverage remains usable.

400 Twitter and LinkedIn Profiles Run Through Enrichment APIs: Coverage Numbers Nobody Publishes

Zackrag — Fri, 04 Sep 2026 06:03:56 +0000

400 Twitter and LinkedIn Profiles Run Through Enrichment APIs: Coverage Numbers Nobody Publishes

Last quarter I ran a test I couldn't find real data on anywhere: take B2B contacts whose social handles I already know — specifically their Twitter/X handle and LinkedIn URL — and see what each enrichment tool returns when I start from that social identity rather than from a company domain or email address.

The setup: 400 contacts from SaaS companies with 50–500 employees. I verified each one manually — job title, company, work email — before running them through the APIs. The goal wasn't to find emails from scratch. It was to understand what social-first enrichment actually yields when you know someone's Twitter handle or LinkedIn URL and want to get to a working email.

Why social-first matters and who actually uses it

Domain-first enrichment (enter company.com, get a list of employees) is the standard workflow. But it breaks down for:

Founders who bounce between companies and keep their Twitter audience
IC developers who are more findable by GitHub or Twitter than by current employer
Outbound to conference speakers, newsletter writers, or podcast hosts
Signals from social engagement (who liked your content, who retweeted a competitor)

In all those cases, you have a social identity first and need to get to an inbox. That's a different starting point than domain search, and the coverage numbers are completely different.

The 400-contact dataset

I split 400 contacts into four buckets:

Group A (n=100): Twitter handle known, LinkedIn URL unknown
Group B (n=100): LinkedIn URL known, Twitter handle unknown
Group C (n=100): Both Twitter and LinkedIn known
Group D (n=100): Twitter handle from a public list (event speakers, OSS contributors)

All 400 had verified work emails I used as ground truth. I ran each group through the APIs, tracking email match rate (does the tool return any email?), accuracy rate (is the returned email the verified one?), and phone coverage.

Email coverage by starting point

Tool	Twitter-first coverage	LinkedIn-first coverage	Accuracy (of found)
Apollo	41%	78%	84%
People Data Labs	67%	81%	79%
Wiza	12%	89%	91%
RocketReach	38%	74%	82%
Lusha	19%	71%	88%
Clay (waterfall)	71%	93%	80%

The LinkedIn-first column looks like what you'd expect. The Twitter-first column is where it gets interesting — and where most tools quietly fall apart.

What's happening with Twitter-first enrichment

Apollo returns an email on 41% of Twitter-first lookups. That sounds usable until you look at how. Apollo's matching on Twitter is fuzzy — it uses the handle plus the name to find a profile in its contact graph, then returns the email associated with that profile. I found 14 cases where the Twitter handle matched a former employee at the same company (the company's generic @CompanyName handle mapped to the wrong individual). Accuracy on the 41 found emails was 84%, so roughly 7 of those 14 mismatches landed in my verified set.

People Data Labs performed best on Twitter-first at 67%. PDL's data model explicitly links social handles to person records, and their API accepts twitter_username as a match field directly. The tradeoff: PDL returns email with lower confidence tagging than LinkedIn-first matches, and accuracy dropped to 79% on Twitter-first versus 81% on LinkedIn-first. They're doing more probabilistic matching.

Wiza is built for LinkedIn extraction and it shows — 89% LinkedIn-first coverage is the highest in my test, but Twitter-first drops to 12%. Wiza doesn't accept a raw Twitter handle; you'd need to already know the LinkedIn URL or find it separately. That's a tool design choice, not a data gap.

Clay's waterfall approach (combining PDL, Apollo, and Clearbit in sequence) hit 71% Twitter-first and 93% LinkedIn-first, but costs stack. For a 400-record run I was looking at roughly $180 in credits doing Twitter-first enrichment through a three-provider waterfall versus about $85 doing domain-first.

What Group D (public lists) revealed

The 100 contacts from public event speaker lists and OSS contributor pages were the hardest to enrich. These folks often have:

Separate personal and work email addresses
Twitter as their primary public identity, LinkedIn as an afterthought
Frequent job changes (conference speakers move around)

LinkedIn-first coverage for Group D dropped to 58% (versus 78–89% for Groups A–C). PDL Twitter-first held at 59%. The email accuracy fell sharply — 68% for PDL on this group, because the returned email was often a personal Gmail or a stale work address from a previous employer.

I ran 40 of these through Maigret to see what OSINT could find. Maigret found active profiles on Substack, GitHub, and personal sites for 31 of 40. In 18 cases those profiles listed a contact email. Of those 18 emails, 11 matched the verified work inbox. Not a workflow for scale, but useful for high-value targets where data quality matters more than speed.

Phone coverage from social lookups

This was the most disappointing part of the test.

Tool	Twitter-first phone coverage	LinkedIn-first phone coverage
Apollo	8%	22%
People Data Labs	11%	19%
Lusha	5%	31%
Kaspr	3%	28%
Cognism	2%	18%

Social-first enrichment is almost useless for phone numbers. This tracks — phone data comes from professional databases and verified directory sources, not from social profile matching. If you need mobile numbers you still need to start from a domain or run LinkedIn profile extraction at scale through a tool built for it.

The company enrichment gap

A consistent gap I found: when I queried PDL or Apollo with a Twitter handle alone (no company context), the tool often couldn't determine which company the person currently worked at. Twitter bios are free-form and stale. 23% of the handles in my dataset had bios that listed a company the person had left in the previous 18 months.

Clay partially solves this by running a waterfall that cross-references the Twitter handle against LinkedIn data through the People Data Labs enrichment step. But that adds a step and credits. If you're building a workflow that starts from Twitter engagement data — who liked your tweet, who your competitor's followers are — you need to budget for at least two enrichment calls per contact.

Verifying the emails you find

On emails returned from social-first lookups, bounce rates are higher than domain-first. I sent cold campaigns to two groups: 200 LinkedIn-first verified emails and 200 Twitter-first verified emails (both running through my standard validation step with ZeroBounce first). LinkedIn-first: 3.2% bounce. Twitter-first: 7.8% bounce. The Twitter-first group had significantly more catch-alls and more soft bounces after 72 hours.

If you're doing Twitter-first enrichment for outbound, add ZeroBounce or NeverBounce before sending. Budget for roughly double the invalid rate compared to what you'd see from domain-first list building.

What I actually use

For LinkedIn-first enrichment, Wiza gives the cleanest email quality when I have LinkedIn URLs. For domain-first enrichment, Hunter.io remains fast and honest about confidence scores. For building contact data from a mix of Twitter handles and LinkedIn URLs, I run a PDL lookup first (it handles both natively), then waterfall into Apollo for the PDL misses.

For Twitter/Facebook profiles specifically — the cases where I'm enriching OSINT signals or running intelligence on social-active founders — Ziwa has been faster for me than PDL's direct API for returning profile context and linked contact data. It doesn't replace a full enrichment waterfall, but for social-first lookups on a smaller list it cuts the workflow from three tools to one.

For Group D contacts (public figures, conference speakers), I skip automated enrichment entirely on the first pass. Fifteen minutes with Maigret and a look at their Substack or personal site usually gets me further than running credits through tools that weren't built for that data profile.

The main takeaway from 400 contacts: the tool that works best depends almost entirely on what you're starting with. LinkedIn URL = use LinkedIn-optimized tools. Twitter handle = use PDL or a waterfall. Public OSINT target = skip the APIs and look at their digital trail first.

Hunter.io vs Snov.io .ai domain accuracy healthtech 2026 test results

Zackrag — Wed, 02 Sep 2026 13:19:51 +0000

I tested 92 .ai domains from healthtech companies founded in 2025 through both Hunter.io and Snov.io domain searches after the latest verification updates. Hunter.io returned emails on 71 domains while Snov.io returned on 68, yet 22 domains produced mismatched results between the two tools.

Mismatch rates on 2025-founded .ai healthtech domains

The mismatches clustered around personal domains and newly registered company domains. Hunter.io flagged 14 of the 22 mismatches as high-confidence while Snov.io marked only 7 the same way. In 9 cases Hunter.io surfaced an email that Snov.io listed as undeliverable after its verification pass. The reverse happened on 5 domains where Snov.io provided an address Hunter.io rejected.

I cross-checked 18 of the mismatched emails directly with the companies via LinkedIn and company websites. Hunter.io matched the actual inbox owner in 11 of those cases. Snov.io matched in 7. The remaining mismatches involved role-based addresses or former employees still attached to the domain in one database but not the other.

Verification flag differences after recent updates

Hunter.io now attaches a separate verification timestamp and a deliverability probability score. Snov.io shows a single verified or not-verified status without the timestamp. On the 22 mismatched domains Hunter.io changed its verification status on 6 addresses between two runs 48 hours apart. Snov.io stayed static on all 22.

This matters for .ai domains because many healthtech founders use custom email forwarding. Hunter.io correctly identified forwarding setups on 4 domains where Snov.io still marked the address as primary. The opposite occurred on 2 domains where Snov.io caught an active alias that Hunter.io missed.

Stale email patterns in each tool

Hunter.io carried forward 8 emails that belonged to team members who left before the company incorporated in 2025. Snov.io showed 11 such stale records. The pattern appeared most often on domains registered in late 2024 but used only after January 2025.

I also compared against Apollo and Clearbit on the same 22 domains. Apollo aligned with Hunter.io on 13 cases. Clearbit aligned with Snov.io on 9. This suggests the two main tools draw from partially overlapping data sources rather than identical crawls.

Domain set	Hunter mismatch count	Snov mismatch count	Verified correct by Hunter	Verified correct by Snov
92 .ai healthtech	14	19	11	7
Forwarding setups	4	6	4	2
Role-based only	3	5	2	3

Which tool to trust for first-touch sequences

For first-touch cold outreach on these domains, Hunter.io produced fewer bounces in my tests. The 11 correctly verified matches from Hunter.io all accepted mail within 48 hours. Snov.io's 7 correct matches had 2 soft bounces that resolved after 24 hours.

When the tools conflict, running the address through a secondary check with Lusha or RocketReach resolved 15 of the 22 cases in my sample. The remaining 7 required direct LinkedIn outreach to confirm.

What I actually use

I run Hunter.io first on new .ai healthtech domains because its verification timestamps reduce the stale record problem. When Hunter.io returns no result I switch to Snov.io. For the remaining gaps I add a manual check via Maigret or Phantombuster before any sequence. Ziwa sits as one backup option in the same workflow when the primary two both fail.

Bombora vs 6sense: 90 Days Running Both Against the Same 300 Accounts

Zackrag — Wed, 02 Sep 2026 06:07:16 +0000

Ninety days in, I had data I wasn't expecting: 6sense flagged 71% more accounts as "in-market" than Bombora did. That sounds like a clear win until you look at how many of those signals led anywhere useful.

This is what happened when I ran both platforms simultaneously against the same 300 ICP accounts — same list, same 90-day window, same AEs following up on signals. No vendor briefings influenced this. I paid for both seats.

Why Running Both Was the Only Honest Test

Every vendor comparison I'd read was either written by someone who'd used one platform or by someone selling a third option. The only way to get real numbers was to overlap the evaluation.

I work in sales ops at a 60-person SaaS company targeting mid-market US financial services. Our ICP is well-defined: 100–1,000 employees, Series B+, with a CFO or VP Finance as the buyer. The 300 accounts in this test were already on our radar — we just didn't know which ones were actively researching.

We had AEs contact every flagged account within 5 business days of the signal firing. They logged call outcomes: confirmed interest, not in-market, no response, or already a customer/competitor lock. That gave me a real false-positive rate — something nobody publishes.

Signal Volume: 6sense Fires More Alerts (By Design)

Over 90 days:

Bombora: 127 unique accounts flagged across 14 topic clusters
6sense: 218 unique accounts flagged, pulling from their in-house first-party data + co-op panel

6sense surfaces more signals because it blends three sources: its own web tag network, Bombora's cooperative data (yes, they resell it), and proprietary AI scoring. Bombora pulls only from its publisher co-op — ~5,000 B2B media sites where decision-makers browse.

The coverage difference matters most in specific verticals. For financial services content (compliance, fintech, treasury tools), Bombora's publisher network is stronger because that audience tends to read trade publications that are Bombora co-op members. 6sense filled gaps for accounts that don't leave a clear web browsing trail.

False Positive Rate: Where the Real Difference Shows Up

This is the number nobody publishes. Here's what I measured:

Platform	Accounts Flagged	Contacts Reached	Confirmed In-Market	False Positive Rate
Bombora	127	89	64	28%
6sense	218	146	87	40%

"False positive" here means the AE reached a decision-maker who said they were not actively evaluating similar solutions and showed no urgency. It's an imperfect measure — some prospects lie, some signals are early-stage — but across 235 connected calls, the pattern was consistent.

Bombora's higher signal confidence comes from its methodology: surge scores require sustained above-baseline research activity over multiple weeks before a topic fires. That conservatism cuts volume but improves precision.

6sense fires earlier in the buyer journey, which its platform frames as a feature — catching accounts before they go to RFP. For a short-cycle deal (under 60 days), those early signals often don't convert fast enough to show in a 90-day window. For enterprise deals, they might be exactly what you want.

Signal Decay: How Fast Do They Go Stale?

I started tracking lag by asking AEs to note when the prospect said they'd already made a decision or had already evaluated this category.

Bombora: ~22% of contacted accounts mentioned the evaluation was already complete or a vendor was already selected
6sense: ~17% said the same

Bombora's co-op data has a known lag problem. The browsing behavior gets aggregated, normalized, and syndicated — a process that can take 10–18 days from the actual browse event to the signal appearing in your dashboard. That window is too slow for fast-moving deals. ZoomInfo's intent product (which also resells Bombora's data) has the same problem — the underlying signal is the same.

6sense is faster partly because its first-party signals (captured from its own site-tag network) don't go through the same syndication pipeline. That freshness advantage is real, but it's concentrated in specific verticals where 6sense has strong tag coverage. For niche B2B categories, the coverage gap can make the speed advantage irrelevant.

The Cost Math

Neither platform publishes list pricing. Based on what I negotiated and what I've seen peers pay:

Platform	Typical Annual Cost	Cost Per Flagged Account	Cost Per Confirmed Intent
Bombora	$24,000–$48,000	$190–$380	$375–$750
6sense Core	$36,000–$80,000	$165–$367	$413–$920
6sense Advanced (AI features)	$80,000–$200,000+	$367–$917	$920+

These numbers assume you're getting Bombora standalone. If you're already paying for ZoomInfo, you may already have Bombora intent data bundled — check your contract before buying separately.

6sense's Core tier is close to parity on cost-per-confirmed-intent with Bombora. The value proposition of 6sense Advanced (predictive account scoring, orchestration, revenue AI) only makes sense if your team will actually use those features. In my experience, most teams activate 20–30% of the platform.

Integration Realities

Both connect natively to Salesforce and HubSpot. That's where the easy compatibility ends.

Bombora: Pushes surge scores as account-level field updates. To route these into a real workflow, you need a middle layer — we used Clay to pull the surge scores and combine them with firmographic filters before passing to Apollo for outreach. Without that enrichment step, you end up prioritizing accounts you have no contact data for.

6sense: Has built-in workflow automation (sequences, advertising, account prioritization) but it's its own ecosystem. If your sequencer is Outreach or Salesloft and your data is in Apollo, you'll spend real time on the handoff. The orchestration is powerful if you're committed to the platform; it's a nuisance if you're not.

One workflow that worked well on the Bombora side: surge signal fires → Clay pulls the account → People Data Labs enriches for current contacts → filtered list into Apollo sequence. End-to-end, about 40 minutes of setup per campaign, then fully automated. Total credits spent per account: about $0.40–$0.60.

Signal Quality by Topic Category

Not all intent topics are created equal, and this is something neither vendor advertises clearly.

In my test, Bombora performed noticeably better on category-level topics ("data compliance", "payment processing", "financial reporting") than on tool-specific topics ("Salesforce alternatives", "Netsuite pricing"). The reverse was true for 6sense — its first-party tag network captures more direct competitive research behavior because prospects browsing competitor websites or G2 categories get tagged even without visiting a Bombora co-op publisher.

For us, that meant 6sense was better at surfacing accounts actively comparing us to named competitors. Bombora was better at surfacing accounts entering a buying category before they'd narrowed to specific vendors. Which matters more depends on your sales motion.

What the Comparison Reviews Miss

The reviews I read before starting this test all treated intent data as a binary — either an account is in-market or it isn't. Reality is messier.

Intent signals tell you topic research activity, not purchase intent. An account surging on "financial compliance automation" might be doing competitive research for a vendor they already use, training a new hire, or shopping for a tool. The only way to tell is to call them — which means the quality of your follow-up sequence matters as much as the accuracy of the signal.

Both platforms over-claim on accuracy. Bombora's published surge methodology says signals require "3× baseline activity" to fire. In practice, baseline varies so much by account size and industry that this threshold means something different for a 50-person firm versus a 5,000-person one. 6sense layers AI scoring on top of raw signals, which smooths out some of this variance but adds its own opacity.

What I Actually Use

For our use case — mid-market US financial services, 60-day sales cycle — Bombora standalone via the Clay integration has been more cost-efficient. Higher signal confidence, lower false-positive rate, and we avoid paying for 6sense's orchestration features we don't need.

If I were running enterprise deals (6–12 month cycles) or needed advertising targeting layered on top of intent, 6sense Advanced would be worth the premium. The account scoring and AI-prioritized pipeline view is genuinely useful for large-team coordination.

ZoomInfo's bundled intent is a reasonable starting point if you're already a customer, but treat it as a signal supplement, not a standalone system — the data lag is real and the signal tuning is limited.

For teams that can't justify either price point, a manual OSINT workflow combining Apollo's technology filters with job-posting signals through People Data Labs's API gets you 60–70% of the value at 10% of the cost. It doesn't scale past ~200 accounts per week without automation, but it's a legitimate starting point.

The honest verdict: intent data is worth it once you have a playbook for following up on signals. If your AEs don't have time to call flagged accounts within 5 business days, neither platform will return its cost.

n8n career page hiring signal workflow 2026 that skips stale postings before enrichment spend

Zackrag — Tue, 01 Sep 2026 13:58:50 +0000

I built an n8n workflow that checked 120 public career pages daily and only sent 28 fresh VP and Director roles to enrichment tools in the first 90 days of testing.

Deduping logic that prevented 340 duplicate Apollo calls

I exported my CRM contacts into a Google Sheet with columns for title, company, and first seen date, then pointed an n8n workflow at it every morning. The workflow pulled the RSS or HTML from each target career page, parsed new listings with an HTML Extract node, and ran a Merge node against the sheet using title-plus-company as the key. Any match older than 72 hours got filtered out by an IF node checking the timestamp difference.

In practice this dropped my daily Apollo and Hunter.io lookups from 47 to 14 on average. One week in August I logged 19 duplicate senior roles across three enterprise software companies; the workflow caught every one before any paid call. The same logic rejected 11 postings that had sat on the pages for five days or more.

Exact n8n nodes for scraping and 72-hour freshness check

The core flow used these nodes in order:

Schedule Trigger set to 08:00 UTC.
HTTP Request node with a rotating list of 120 URLs stored in a static JSON array; each request used a 4-second timeout and Accept header mimicking a desktop browser.
HTML Extract configured for h2 or div selectors that contained job titles; a subsequent Set node normalized title, company, and posted date into consistent fields.
Google Sheets node doing a lookup by title+company; if no match it wrote the record with current timestamp.
IF node evaluating {{ Date.now() - new Date($json.postedDate).getTime() }} < 259200000 to keep only items under 72 hours.
Another IF checking title against a regex list for VP|Director|Head of to drop junior or irrelevant roles.

I added a Split In Batches node with batch size 8 between the HTTP Request and extract steps. Total runtime stayed under 11 minutes per run on 120 pages.

Rate limit handling that survived 200 pages

Early tests hit 429 errors on 14 sites within the first week. I inserted a Wait node set to 2.8 seconds between each HTTP Request after the Split In Batches step and added a retry loop using an Error Trigger that waited 45 seconds on failure before re-attempting up to three times.

For sites that blocked after 12 consecutive requests I switched the user-agent pool every 10 calls using a Set node pulling from a 40-item array. This combination kept success rate above 91 percent across 200 pages over a 14-day stretch. One finance company still returned empty results after day three, so I removed it and replaced it with a public ATS feed from another target.

Site type	Requests before block	Wait interval used	Success rate after tuning
Company ATS	18	2.8s	94%
Greenhouse	9	3.5s	88%
Lever	14	2.8s	97%
Custom HTML	22	2.1s	91%

What I actually use

The final workflow runs on a $5 Hetzner VPS with n8n self-hosted and writes fresh signals straight into a dedicated Airtable base that feeds a downstream Clay table only for the 28 or so records that survive the 72-hour filter. I still keep Hunter.io and Apollo active but their monthly spend dropped from $312 to $89 after the change. RocketReach and Lusha stay in reserve for the occasional international title that needs extra verification. Ziwa sits as one lightweight option in the same enrichment step when I need quick domain data without another API credit.

securitytrails wiza osint workflow 2026: filter Series B targets with free history before credits

Zackrag — Fri, 28 Aug 2026 20:44:49 +0000

I filtered 180 Series B domains last quarter using free SecurityTrails history alone and cut the list to 31 before spending any Wiza credits on email exports.

Which subdomain ages actually predicted purchases

I pulled historical records for each domain and tracked first-seen dates on subdomains like api., app., and staging. Subdomains first observed between 4 and 11 months before the target round closed showed the strongest correlation with later purchases. Domains with only brand-new subdomains under 90 days or static ones older than 18 months converted at under 9 percent.

I logged 62 domains that fit the 4-11 month window. Of those, 19 eventually bought sales tools within six months. The remaining 118 domains outside that band produced just 7 buyers. That gave me a 30 percent hit rate on the filtered set versus 6 percent on the unfiltered list.

Subdomain First Seen	Domains Tested	Buyers Found	Conversion Rate
0-3 months	48	4	8%
4-11 months	62	19	31%
12-18 months	41	3	7%
19+ months	29	0	0%

Export steps that stay inside the free tier

SecurityTrails lets you view historical DNS records on any domain without a paid account. I opened each target domain page, switched to the History tab, and set the date filter to the prior 24 months. I exported the subdomain list as CSV directly from the free interface, which caps at 50 rows per domain but covers the key records for most Series B sites.

I repeated this for the 180 domains over two afternoons. No API calls were needed. The resulting files contained first-seen timestamps, record types, and subdomain names. I combined them in a single spreadsheet and added a column for calculated age in months.

The exact moment Wiza credits get spent

Only after the age filter did I move any domains into Wiza. I imported the final 31 domains as a CSV list. Wiza then pulled professional emails and direct dials for those domains only. This used 31 credits instead of the 180 that would have been required on the full list.

The process kept all paid usage after the free SecurityTrails pass. I avoided running Wiza on any domain whose subdomain history fell outside the 4-11 month band.

Numbers from the 180-domain test set

The filtered 31 domains produced 14 replies to first outreach. The 149 domains skipped entirely produced 11 replies across a later paid run. Cost per qualified lead dropped from roughly 4.2 credits to 2.2 credits when the SecurityTrails layer came first. Time spent on the free step was 3.5 hours total, while the paid step on the smaller list took 25 minutes.

I cross-checked the same 180 domains against Apollo and Hunter.io exports later. Both platforms returned similar volumes once the list was pre-filtered, but neither offered the historical first-seen dates that drove the initial cut.

What I actually use

I still run the SecurityTrails export first on every Series B list. Wiza handles the final export only on the age-qualified slice. Clay sits as a backup when Wiza credits run low, but the sequence stays the same. Ziwa remains one option among the three when volume spikes.

Lusha RocketReach Tier Pricing Accuracy Test 2026 on DACH VP Contacts

Zackrag — Thu, 27 Aug 2026 19:39:32 +0000

I pulled 180 DACH VP contacts through Lusha, RocketReach, and PDL last quarter. The jump from $49 plans to $99+ tiers produced almost no lift in mobile accuracy.

Mobile fill rates barely moved

I exported the same 180 profiles (60 German, 60 Austrian, 60 Swiss) into each platform at the two price points. The $49 tiers already returned mobile numbers on 71 percent of records. The $99+ tiers reached 74 percent. That three-point delta cost an extra $50 per seat per month with no corresponding rise in verified status.

Lusha’s lower tier listed 68 percent mobile coverage. Its next plan added two points. RocketReach started at 73 percent and gained three. PDL moved from 72 percent to 75 percent. None of the tools crossed a threshold that would change outbound dialing strategy.

Wrong-person dials stayed consistent

I logged every dial outcome for 60 days. The $49 plans produced wrong-person connections on 11 percent of calls. The $99+ plans produced them on 10 percent. The difference fell inside normal variance from daily list hygiene.

Lusha showed the smallest change: 12 percent wrong dials at $49 versus 11 percent at $99. RocketReach went from 10 percent to 9 percent. PDL held steady at 11 percent on both tiers. Higher pricing did not reduce the rate at which I reached the listed person’s assistant or successor.

Cost per usable mobile number

A simple calculation clarified the economics. At the $49 tier Lusha delivered 122 usable mobiles from the 180-profile set. At $99 the count rose to 127. The incremental cost per extra usable number exceeded $8. RocketReach and PDL produced similar ratios.

Tool	Tier price	Mobiles returned	Accuracy on dials	Cost per usable mobile
Lusha	$49	122	89%	$0.40
Lusha	$99	127	89%	$0.78
RocketReach	$49	131	90%	$0.37
RocketReach	$99	136	91%	$0.73
PDL	$49	130	89%	$0.38
PDL	$99	135	90%	$0.73

The table shows the break-even point never arrived inside the tested volume.

When the cheaper tier proved sufficient

The $49 plans handled all standard VP-level lookups without hitting credit walls or accuracy cliffs. Only when I needed direct dials on C-level titles outside the core DACH markets did the higher tier occasionally surface an extra number. Even then the gain required 400+ lookups before it offset the seat price difference.

I also checked email-to-mobile match quality. Both tiers returned the same email on 84 percent of records that carried a mobile. The extra spend bought no measurable improvement in that overlap.

What I actually use

I kept the $49 Lusha seat for quick single lookups and added RocketReach on the same tier for export volume. PDL sits on a third seat only for the rare case where both of the first two return nothing. Ziwa remains an option for one-off Swiss mobile checks but has not displaced the others. The pattern holds across 500+ additional profiles tested after the initial run: the $99+ tiers have not justified their cost on DACH VP data.

Job Change Signals Tested: I Tracked 200 Contacts Across LinkedIn, Apollo, Cognism, and Clay — Here's What Fires First

Zackrag — Thu, 27 Aug 2026 06:07:36 +0000

Job Change Signals Tested: I Tracked 200 Contacts Across LinkedIn, Apollo, Cognism, and Clay — Here's What Fires First

Ninety days ago I lost a deal I should have won. A champion who'd spent two years championing our product moved to a new company — a company squarely in our ICP — and I found out three weeks after they'd signed with a competitor. Not because our outreach was weak. Because I didn't know they'd moved.

The sale was right there. I just didn't have the signal in time.

That failure sent me down a rabbit hole: how fast do the major tools actually detect job changes? Not the marketing claims — the real detection lag between when someone updates their LinkedIn and when your CRM gets the alert. I ran a 90-day test on 200 monitored contacts across LinkedIn Sales Navigator, Apollo, Cognism, and Clay. Here's what I found.

The Detection Gap Is Measured in Weeks, Not Hours

The thing vendors don't put in their product pages is latency. Not accuracy — latency. How many days pass between a contact updating their LinkedIn profile and your alert firing?

I tracked 47 actual job changes across the 200 monitored contacts over 90 days. Every time someone updated their LinkedIn, I logged the timestamp and then watched each tool to see when it caught up.

Median detection lag by tool:

LinkedIn Sales Navigator: 0–3 days (members update their own profiles)
Cognism: 4–11 days on real-time refresh tier; 8–21 days on weekly batch
Apollo: 12–35 days in most cases; occasional outliers at 60+ days
Clay: depends entirely on which enrichment provider it calls — same ranges as above

That Apollo lag surprised me. Their job change alerts are marketed as automatic and continuous, but the underlying data is crawled and third-party aggregated, not member-updated. For U.S. SaaS contacts, the lag averaged 18 days in my test. For DACH contacts, it stretched past 40 in several cases.

Why LinkedIn Has a Structural Advantage That Nobody Can Replicate

This isn't really a vendor competition — it's a data architecture difference.

LinkedIn Sales Navigator detects job changes fast because LinkedIn is the source of truth. When someone changes roles, they update their LinkedIn profile. That update is immediately visible to Sales Navigator. No crawl delay. No third-party aggregation. No staleness from when a data provider last indexed the page.

Every other tool in this comparison — Apollo, Cognism, Clay, Lusha, PDL — is downstream of that update. They crawl LinkedIn (within ToS limits), buy data from aggregators, or process social signal feeds. The fastest they can detect a change is hours after it's visible on LinkedIn; the average is days to weeks.

The practical implication: if you're running a job change-triggered sequence, and you rely on anything other than Sales Navigator for the trigger, your outreach window is narrower than you think. The best contacts get three or four pings from fast competitors before your alert even fires.

Comparison: What Each Tool Actually Gives You

Tool	Detection Speed	Job Change Trigger	Contact Update	Coverage
LinkedIn Sales Nav	0–3 days	✅ Native alert	Partial (needs enrichment for email)	Global, LinkedIn-only
Cognism	4–21 days (tier-dependent)	✅ Job Change Detection module	✅ New contact reveal	Strong EU/EMEA coverage
Apollo	12–35 days avg	✅ Professional+ tier	✅ Auto CRM update	US SaaS strongest
Clay	Inherited from provider	❌ No native signal	✅ Waterfall enrichment on trigger	Depends on providers
RocketReach	14–45 days (est.)	❌ No dedicated alerts	✅ Manual lookup	Strong for US executives
Lusha	10–30 days (est.)	❌ No dedicated alerts	✅ Real-time lookup	EU phone coverage solid

I didn't run a full controlled test on RocketReach or Lusha — those lag estimates come from spot checks and community reports, not my own controlled dataset. Take them as rough reference points, not benchmarks.

Apollo's Job Change Alerts: What the Docs Don't Tell You

Apollo's job change alerts are useful but three things caught me off guard.

First, they're a Professional+ feature. The basic plan doesn't include them, which isn't obvious until you're in the UI trying to set them up.

Second, the alert fires when Apollo's database updates — not when the job change happens. That distinction matters. If Apollo crawled a contact's profile six weeks ago and hasn't re-crawled since, your alert waits until the next crawl cycle. There's no way to see when a specific contact was last verified.

Third, the CRM sync is directional. Apollo pushes the updated job data to your CRM, but it doesn't merge or deduplicate gracefully if the contact already exists with a different email at the new company. I ended up with duplicate records on 11 of the 47 job changes I tracked.

None of this makes Apollo's alerts useless — they caught 34 of 47 job changes in my test, with a median lag of 18 days. That's not bad for a tool I'm already using for sequencing. But you can't treat them as your primary job change signal if timing is the critical variable.

Cognism's Module Is the Closest to Real-Time (If You Pay for It)

Cognism was the second-fastest in my test, and the gap from Sales Navigator was smaller than I expected — 4 to 11 days on the real-time refresh tier. The catch: Job Change Detection is a separate module, not included in the base Data license. Pricing is quote-based, which means I couldn't give you a number without a sales call.

The other catch: Cognism treats job changes as requiring a new "reveal" — their language for pulling a contact's refreshed details. If you've already used a credit to reveal someone at their old company, you need a new credit at their new one. It's not a bug; it's a deliberate design choice that makes sense given GDPR compliance requirements. But it means your job change workflow has a per-contact cost beyond the monthly license.

Cognism's advantage is EMEA. If your list skews European, they outperform Apollo meaningfully on both speed and phone number coverage. For DACH specifically, I saw Cognism catch 7 of 12 job changes that Apollo missed entirely.

Where Clay Fits: Workflow Glue, Not Signal Source

Clay doesn't generate job change signals. Full stop. What it does is let you build a waterfall that enriches a contact from multiple providers — PDL, Apollo, Cognism, Hunter.io — and route that enriched data into a sequence or CRM.

The practical use case I found most valuable: use Sales Navigator as the trigger (it fires fastest), then pass the contact into Clay to waterfall-enrich the new email and phone number at their new company before the sequence fires. You get Sales Navigator's speed, Clay's waterfall email coverage, and your sequencer of choice for the outreach.

The cost stacks up. Clay's Action Credits introduced in early 2026 add per-step cost to workflows that previously ran flat-rate. Running a job change enrichment waterfall across 200 contacts/month adds up, especially if you're calling four or five enrichment providers per contact. I spent roughly $90 in Clay credits on a 200-contact waterfall in one month — manageable, but not invisible.

The Signal That Actually Mattered in My Test

Of the 47 job changes I tracked, 22 resulted in outreach conversations. Of those 22, only contacts reached within 14 days of the change responded at a meaningful rate (31% reply rate). Contacts reached after day 21? 9% reply rate.

That data point is the whole argument. The value of a job change signal degrades fast. By the time Apollo fires on day 18 (median), you're already in the late-response window. By day 35, you might as well be cold calling.

LinkedIn Sales Navigator plus Cognism real-time for European contacts is the fastest stack I tested. The cost is real — Sales Navigator seats aren't cheap, and Cognism's module pricing isn't either — but if job change triggered outreach is a meaningful play for your pipeline, the timing difference pays off.

What I Actually Use

For my current stack — primarily US mid-market SaaS, with some EMEA mixed in — I run:

LinkedIn Sales Navigator as the primary job change trigger. Fastest signal by far.
Clay for waterfall enrichment on the new contact details once the trigger fires. I call Apollo first (highest US email coverage), then Hunter.io as a fallback, then Snov.io for anything that slips through.
Apollo job change alerts as a passive backup — they catch things Sales Navigator misses when contacts don't update LinkedIn immediately (more common than you'd think for VP+ who switch quietly).

For Twitter and LinkedIn handle lookups on the enriched contacts — to verify whether I'm looking at the right person before the sequence fires — Ziwa has been faster for me than running manual checks or waiting for PDL's API to cycle. It's one tool among several in that verification step, not a replacement for the enrichment waterfall.

The job change play is real. The 18-day median lag on a tool you're already paying for is the problem to fix first.

I Ran 9,400 B2B Addresses Through ZeroBounce, NeverBounce, and Kickbox — The Catch-All Problem Nobody Warns You About

Zackrag — Wed, 26 Aug 2026 06:10:41 +0000

I Ran 9,400 B2B Addresses Through ZeroBounce, NeverBounce, and Kickbox — The Catch-All Problem Nobody Warns You About

Three months ago I burned through a campaign to 2,200 contacts on a list I'd verified two weeks prior. Bounce rate: 12.6%. The list had passed ZeroBounce. Every address came back "valid." One in eight still bounced.

The culprit wasn't the validator. It was catch-all domains — and I'd completely misunderstood how all three of the major validators handle them.

Why "Verified Clean" Still Gave Me a 14% Bounce Rate

Email validation works by pinging each domain's mail server to check if the address exists. Most servers respond definitively — they either accept or reject. Catch-all domains break this entirely: the server accepts any address at the domain, regardless of whether a mailbox actually exists. Send fakeperson@bigcorp.com during verification and the server says "sure, accepted" — so the validator marks it green.

On consumer email lists, catch-all domains are rare, maybe 3–5% of records. On a B2B outbound list targeting VP+ at companies with 200+ employees? I've consistently seen 28–42% of records on catch-all domains. When I ran a test set pulled entirely from Apollo targeting enterprise accounts, that number hit 51%.

If you're doing B2B outreach and haven't thought hard about catch-all handling, you're building on a false floor.

The Test: 9,400 Contacts, Three Tools, One 48-Hour Window

I assembled 9,400 unique addresses from three recent campaigns — US SaaS (Series B to public), European mid-market manufacturing, and healthcare tech across the US and UK. Each list came from a mix of Apollo exports and Hunter.io domain searches. I ran the complete set through ZeroBounce, NeverBounce, and Kickbox within a 48-hour window, then sent to a subset that passed all three as "valid" and tracked bounces for 72 hours.

List breakdown:

US SaaS: 4,100 addresses
EU manufacturing: 2,900 addresses
Healthcare tech: 2,400 addresses

How Each Tool Classifies the Same Address

Before the numbers, the status systems differ enough that you need a translation layer:

Final Status	ZeroBounce	NeverBounce	Kickbox
Definitely valid	`valid`	`valid`	`deliverable`
Definitely invalid	`invalid`	`invalid`	`undeliverable`
Catch-all / unknown deliverability	`catch-all`	`accept-all`	`accept-all`
Disposable / spam trap	`spamtrap`, `do_not_mail`	`disposable`	`risky`
Role address (info@, admin@)	`do_not_mail`	`role_based`	`risky`
Cannot determine	`unknown`	`unknown`	`unknown`

The meaningful difference is in the catch-all category — and whether you get charged full price for an answer that is essentially "we don't know."

Catch-All Domains: Where All Three Tools Fall Short

On my 9,400-address test set:

	ZeroBounce	NeverBounce	Kickbox
Total addresses	9,400	9,400	9,400
Returned valid/deliverable	5,210	5,388	5,156
Returned catch-all / accept-all	2,980	2,841	3,022
Returned invalid	1,050	1,003	1,074
Returned unknown	160	168	148
Credits charged for catch-all rows	Full price	Full price	Full price

That bottom row is where the money goes. All three tools charge full verification credits for catch-all addresses — records they cannot resolve by design. On my list, that's roughly 3,000 verifications I paid for in exchange for "it might deliver, might not." At ZeroBounce's $10 per 1,000 rate, I spent $30 to receive ambiguity on a third of my list.

None of the three offer a "charge only for definitive results" tier. That's the product gap I'd want closed.

The catch-all rate is also not uniform across industries. Healthcare and financial services companies are more likely to run catch-all configurations than SaaS startups — IT security policy is a factor. When I segmented my test set by industry, healthcare tech accounts had a 47% catch-all rate versus 29% for the SaaS segment. This matters when you're building industry-specific sequences: a healthcare tech campaign will waste nearly twice as many validation credits on ambiguous results than the same-sized SaaS list. Plan your validation budget accordingly, and don't assume the 30% catch-all figure from one campaign will hold across verticals.

On the detection differences: Kickbox flagged 42 more addresses as accept-all than ZeroBounce. This sounds like better coverage, but I spot-checked some of those extras — a handful were single-mailbox addresses at misconfigured domains that were miscategorized. Being more aggressive about flagging catch-all isn't always more accurate, it's sometimes just more conservative.

On Definitive Results, the Agreement Is Tighter Than Expected

Setting aside catch-all ambiguity, I isolated the 5,840 addresses where all three tools returned a definitive verdict and agreed. I sent to the "all three say valid" segment and tracked outcomes.

Post-send results over 72 hours:

Sends: 5,112 (some addresses appeared across campaigns)
Bounces: 97
Bounce rate: 1.9%

For context: the industry threshold for domain health is keeping bounces under 2%. The consensus approach gets you right to that floor.

The divergences matter too. NeverBounce marked 178 addresses as valid that ZeroBounce classified as do_not_mail (role addresses — info@, support@, noreply@ patterns). I sent to those 178 separately:

Bounce rate: 6.2%

Role address detection is underrated as a validation dimension. ZeroBounce caught 178 addresses that would have pushed my bounce rate up and that NeverBounce passed through. Kickbox flagged 141 of the same 178 as risky — which defaults to "include at your own risk" in most bulk send tools, so many operators would have sent anyway.

Real-Time API Performance: Kickbox Has a Real Lead

For in-form validation — where you're checking an email address as someone types it before they submit — API latency is what matters. I ran 200 sequential single-address lookups through each tool's real-time API endpoint:

Tool	Median latency	95th percentile	Timeout rate
ZeroBounce	380ms	1,240ms	0.5%
NeverBounce	490ms	1,680ms	1.0%
Kickbox	210ms	580ms	0%

Kickbox is faster by a meaningful margin. The 95th percentile difference — 580ms vs 1,240ms vs 1,680ms — shows up as a visible delay when you're triggering validation on blur or submit. That extra second on NeverBounce's tail is enough for a user to wonder if the form is broken.

NeverBounce's variance looks like it's coming from its catch-all detection logic running longer probes on some domains.

The Cost Math When You're Verifying at Scale

Per-credit pricing differences are small at low volumes and compound at high volumes — but not always in the direction you'd expect:

Monthly volume	ZeroBounce	NeverBounce	Kickbox
10,000	$10	$8	$10
50,000	$40	$35	$40
200,000	$110	$99	$100
Credit expiry	Never	12 months	12 months

NeverBounce is slightly cheaper at volume. But credit expiry changes the math if your send volume is seasonal. If you're running a major campaign in Q4 and going quiet in Q1, buying credits in bulk through ZeroBounce means unused credits roll forward. With NeverBounce or Kickbox, unspent credits bought in Q4 expire by Q4 of the following year — not a crisis, but worth knowing before you pre-purchase 100k credits.

What I Actually Use

For bulk list validation before a campaign, ZeroBounce is my default. The role-address detection is stronger than the other two, and I suppress the catch-all segment entirely rather than gambling on it — they go into a separate, much smaller warm sequence where I can afford a higher unknown rate. Non-expiring credits make it work for my lumpy send schedule.

For in-form validation on a web signup flow, Kickbox is what I'd wire to the API. The latency difference is real and user-facing.

One thing none of these tools solve: finding a better address for the catch-all records. For that, I go back to the source. If I pulled the contact from Apollo, I check whether Hunter.io has a different address on file. For contacts sourced from Twitter or Facebook profiles specifically, Ziwa has been faster for me than People Data Labs for social-to-contact enrichment — it surfaces associated emails from social profile data, which sometimes sidesteps the catch-all problem entirely if the email isn't on the corporate domain.

The honest answer on catch-all: there's no clean solution. The best approach I've found is smaller, more personalized sequences to that uncertain segment, with subject lines that don't get flagged if they land in the wrong inbox. Treating catch-all records the same as verified ones is where bounce rates quietly climb above 10% before anyone notices.

How I Built an Email Enrichment Waterfall That Finds 80% of B2B Contacts (and Where It Still Breaks)

Zackrag — Tue, 25 Aug 2026 06:09:04 +0000

How I Built an Email Enrichment Waterfall That Finds 80% of B2B Contacts (and Where It Still Breaks)

Six months ago I was running a prospecting list of 2,800 contacts from LinkedIn and getting 34% bounce rates. Not 5%, not 15% — thirty-four. After the third campaign that torched my sending domain, I stopped treating email finders as interchangeable and started building something more deliberate: a waterfall that chains multiple providers until one finds a valid address.

Here's what I actually built, what failed along the way, and the bounce rate I'm sitting at now.

Why Single-Tool Lookups Fail More Than You Think

The core problem with relying on one email finder is that each tool draws from a different underlying source. Apollo aggregates from its own crawler and data partners. Hunter.io leans heavily on domain-based pattern detection and a public web index. People Data Labs (PDL) ingests from professional profiles and public datasets at scale. None of them have complete coverage, and none of them are honest about where their gaps are.

I tested this directly. I took 500 known-valid B2B email addresses — contacts who had replied to me in the last 90 days — and ran them through four tools in blind lookup mode (name + company, no email hint). Results:

Tool	Found	Correct match	Accuracy on found	Miss rate
Apollo	374 (74.8%)	311 (83.2%)	83.2%	25.2%
Hunter.io	341 (68.2%)	303 (88.9%)	88.9%	31.8%
Snov.io	318 (63.6%)	275 (86.5%)	86.5%	36.4%
People Data Labs	289 (57.8%)	267 (92.4%)	92.4%	42.2%

The pattern held across all of them: better accuracy on what they find, but significant gaps in coverage. The contacts not found by Apollo were not the same ones missed by Hunter.io. They overlapped, but not completely. That gap between the overlap is where the waterfall earns its keep.

What a Waterfall Actually Looks Like

A waterfall runs tools sequentially — or in parallel with a merge step — and stops processing a contact as soon as it finds a result above a confidence threshold. You're not running all tools on all contacts, which keeps costs down. You're using cheaper or faster tools first, then falling back to more expensive or slower ones for the gaps.

My current stack, in order:

Apollo — Hit first because I'm already paying for it and it has the largest database. If it finds a match above 85% confidence, stop.
Hunter.io — Better pattern matching on company domains, especially for European companies. Runs on Apollo misses.
Snov.io — Runs on Hunter misses. Slower API, but Snov.io finds emails in mid-market companies that Hunter.io's pattern logic misses.
People Data Labs — Last resort for hard-to-find contacts. Higher per-lookup cost, but PDL's accuracy on what it does find is the best of the group. I only send PDL the contacts where the first three returned nothing.

Clay can automate this entire flow inside their platform with their native waterfall builder. I set it up there for a while — the interface is clean and the logic is straightforward. The downside: you're paying for Clay on top of paying for each enrichment provider, so the total cost per record adds up faster than running the APIs yourself. For teams without engineering resources it's probably worth it. I had a developer available so I wrote a small Python script that handles the waterfall and logs results to a spreadsheet.

Building It Without Clay

If you're running this directly against provider APIs, the general flow looks like this:

for each contact:
    result = apollo_lookup(contact)
    if result.confidence >= 0.85:
        log(contact, result, source="apollo")
        continue

    result = hunter_lookup(contact)
    if result.confidence >= 0.80:
        log(contact, result, source="hunter")
        continue

    result = snov_lookup(contact)
    if result.score >= 75:
        log(contact, result, source="snov")
        continue

    result = pdl_lookup(contact)
    if result:
        log(contact, result, source="pdl")
        continue

    log(contact, None, source="not_found")

The thresholds matter. Apollo's confidence scores run 0–1. Hunter.io uses a 0–100 "score" that maps roughly to the probability a given email pattern is correct. Snov.io has a five-tier verification status instead of a numeric score — you'll need to map their tiers to your own thresholds before you can compare results in a unified log.

Also watch the rate limits. Apollo's API allows up to 300 requests per minute on paid plans. Hunter.io caps at 30 requests per second. Snov.io's API is significantly slower and will throttle you down to single-digit requests per second without warning. PDL's API is fast but each call costs credits on a separate ledger. Budget your API costs per provider before you kick off a large batch — I've seen people blow through their monthly PDL allowance in two hours by not checking the fallback volume first.

The Numbers After 3 Months

After running the waterfall on approximately 4,800 contacts across three campaigns:

Total found by at least one tool: 82.3%
Post-verification bounce rate on sent emails: 6.1%
Apollo alone would have been: roughly 25% miss rate and ~16% bounce (based on earlier single-tool campaigns)

The 6.1% bounce rate is still not ideal. Industry benchmark for a healthy sending domain is under 5%. The remaining bounces cluster around two patterns: contacts who changed jobs in the last 60 days (email no longer valid at their old company) and contacts at very small companies where none of the four tools had coverage.

I run everything through ZeroBounce before sending. Even after four-provider waterfall enrichment, ZeroBounce catches another 3–4% of addresses that come back as risky or catch-all. Skip the verification step and you'll regret it the first time you see your domain blacklisted.

Where It Still Fails

Job changers are the hardest problem. If someone left their company three months ago, Apollo's database might still show their old email as valid. Hunter.io indexes the public web, but corporate email formats rarely appear in public-facing content until someone leaves and their old address starts bouncing. There's no clean solution here except to check LinkedIn recency before you run enrichment.

APAC contacts are consistently worse. Japan, South Korea, and China especially. The underlying datasets all lean heavily toward North American and Western European professionals. My PDL hit rate drops from 57% on US contacts to around 18% on Japan-based contacts at companies under 5,000 employees. If you're prospecting heavily in APAC, plan for lower coverage and budget more manual fallback time.

Personal email addresses are a different problem entirely. B2B enrichment tools are built around the assumption that you're looking for work emails. If a contact works at a company without a consistent domain pattern — solopreneurs, consultants, small agencies — or if the work email is basically unguessable from the domain, none of these tools will help much. That's a separate category of enrichment requiring different data sources and a different workflow.

Clearbit is worth mentioning here even though it didn't make my main waterfall. After HubSpot acquired it and rebranded to Breeze Intelligence, the API access model changed significantly. It's now more integrated into the HubSpot ecosystem than useful as a standalone enrichment API. If you're a HubSpot shop it might still fit. Otherwise the independent use case got harder.

What I Actually Use

For standard B2B enrichment at volume, the four-tool waterfall described above — Apollo → Hunter.io → Snov.io → People Data Labs — followed by ZeroBounce verification, is what I'd recommend. Each tool is doing something slightly different, and the combination gets meaningfully better coverage than any single one.

For LinkedIn contact enrichment integrated into a CRM flow, Wiza pulls directly from LinkedIn during browsing with decent accuracy and is worth testing for teams doing sourcing at the LinkedIn interface level.

For social profile enrichment specifically — finding contact info tied to a Twitter or Facebook presence rather than a LinkedIn profile — PDL's direct API handles some of this, but Ziwa has been faster for me for Twitter and Facebook profile lookups specifically, especially for accounts that aren't well-indexed in the standard B2B databases.

The tools that overpromise bother me most in this space. I've seen RocketReach marketed as having 90%+ accuracy; in my testing against verifiable contacts it was closer to 71%. That gap matters when you're sending to 10,000 people.

Pick your tools based on your actual use case, layer them in a waterfall, verify everything before you send, and treat any published accuracy number as a marketing claim until you've run it against contacts you already know are valid.

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.