DEV Community: Zackrag

The Conference Attendee Enrichment Playbook: From Speaker PDF to Booked Meetings in 48 Hours

Zackrag — Mon, 01 Jun 2026 06:04:17 +0000

I ran this against the SaaStr Annual attendee list last spring — 4,200 names scraped from the public speaker page, exhibitor directory, and LinkedIn event RSVPs. After the enrichment waterfall, 1,847 had verified work emails. Of those, 312 matched our ICP exactly. Our SDR team sent 287 sequences (25 bounced on manual review). We booked 41 meetings in the 10 days before the event.

That's a 14.3% meeting rate on a conference we didn't even attend.

Here's every step.

The Data Is Already Public — Most SDRs Just Don't Know Where to Look

Conference organizers publish more than they realize. A typical mid-size industry conference exposes:

Speaker page: Name, company, job title, sometimes LinkedIn URL
Exhibitor/sponsor directory: Company name, booth number, website
Agenda page: Speaker bios, often richer than the main speaker page
LinkedIn event page: "Attending" list (partially public depending on privacy settings)
Mobile event apps like Whova, Bizzabo, Hopin: These often expose attendee lists via their APIs with minimal auth

Speaker and exhibitor data is the cleanest. These people opted in to being listed. LinkedIn event RSVPs are grayer — scraping those requires Phantombuster's LinkedIn event actors or a custom Playwright script running behind your own LinkedIn session. I'd stop there; event apps behind paywalled logins are a different compliance conversation.

The 48-hour window in the title is real but tight. You need the extraction done 5–7 days pre-event, the enrichment waterfall run the same day, ICP scoring done the next morning, and sequences live within 48 hours of extraction. Miss that window and reply rates drop sharply.

Extracting the List Before It Disappears

Conference websites restructure pages post-event and speaker pages sometimes vanish within days. I always extract 3–4 weeks out.

For public pages, I use Apify's pre-built conference scraper actors. They handle pagination, lazy-load JavaScript, and nested speaker grids well. For custom conference sites that aren't covered, a 40-line Playwright script usually handles it:

from playwright.sync_api import sync_playwright
import json

results = []
with sync_playwright() as p:
    browser = p.chromium.launch()
    page = browser.new_page()
    page.goto("https://conference-site.com/speakers")
    page.wait_for_selector(".speaker-card")
    cards = page.query_selector_all(".speaker-card")
    for card in cards:
        name = card.query_selector(".name").inner_text()
        company = card.query_selector(".company").inner_text()
        title = card.query_selector(".title").inner_text()
        results.append({"name": name, "company": company, "title": title})
    browser.close()

with open("speakers.json", "w") as f:
    json.dump(results, f)

Output: name, company, title, sometimes LinkedIn URL or headshot URL. That's your seed data.

For exhibitor lists, the structure is usually a grid with company name and website. Extract those, then normalize company domains (strip www., handle redirects). You now have a list of target companies; finding contacts within them is a separate enrichment step below.

The Enrichment Waterfall (Not a Single API Call)

This is what the generic blog posts skip. No single data provider covers everyone. Running one API and calling it done means missing 30–40% of valid contacts.

Here's the waterfall I've settled on after testing it on ~12 conference lists:

Step	Provider	What you're enriching	Hit rate (approx.)	Cost per record
1	PDL `/person/enrich`	Name + company → full profile	55–65%	$0.04
2	Apollo bulk enrichment	Missed records from PDL	+15–20% cumulative	$0.10
3	Hunter.io domain search	Missed records, email-only	+5–8% cumulative	$0.012
4	RocketReach	Still-missing high-value targets	+3–5% cumulative	$0.25
5	Manual LinkedIn lookup	C-suite / must-have accounts	100% on effort	~$2–5 time cost

Rate limiting matters here. PDL's /person/enrich endpoint allows 1,000 requests/minute on standard plans. If you're batching a 3,000-person list, naively fire-hosing it will hit 429s and corrupt your match confidence scores. I implement a token bucket at 900 req/min with exponential backoff: start retry at 2 seconds, double each time, cap at 60 seconds. That alone recovered an 18% data loss I was seeing in early runs.

Apollo's bulk enrichment is less of a rate-limit concern since it's async batch, but the CSV upload has a 10,000-row limit per job. For large conferences, split the file.

After enrichment, run ZeroBounce on everything before any sequence import. A 3% bounce rate tanks sender reputation on a cold domain. Conference-sourced lists typically run 6–9% invalid without validation — higher than standard purchased lists because job-change lag isn't captured well in most enrichment databases.

ICP Scoring Before You Write a Single Email

Raw enriched data still needs filtering or your SDRs waste sequences on irrelevant contacts. I run a simple scoring function against the enriched output:

Score each record 0–100:

Job title contains VP / Director / Head / C-suite: +40
Seniority level = "senior" or above (PDL field): +20
Company employee count 50–5,000: +20
Industry matches target list: +15
Has verified email (not catch-all): +5

Anything above 60 goes to Tier 1 sequences. 40–59 gets a lighter Tier 2 (2 touches, more generic). Below 40: skip or push to a nurture list.

For exhibitors specifically, Grata is worth a separate lookup. Exhibitors are often mid-market private companies that don't show clean employee counts or funding signals in PDL or Apollo. Grata's private company data fills that gap reliably.

Vendelux is worth knowing if you're running conference-sourced prospecting across multiple events per year. It aggregates attendee and exhibitor signals across 160k+ events and surfaces which target accounts are likely at which shows before registration opens — useful for planning extraction runs in advance rather than scrambling 4 weeks out.

Pre-Event vs. Post-Event: The Timing Window That Changes Reply Rates

Based on tests across five conference cycles:

Outreach timing	Reply rate	Meeting rate	Notes
3–4 weeks pre-event	8–11%	3–4%	Too early, low urgency
5–7 days pre-event	18–24%	10–14%	Best window — people finalizing schedules
Same week (event running)	6–9%	4–6%	Inboxes buried; "Are you at [event]?" helps
1–3 days post-event	14–18%	8–11%	"Caught your talk" framing works here
2+ weeks post-event	4–7%	2–3%	Context fades fast

The 5–7 days before window is consistently the highest performer. Subject lines that reference the specific conference ("Heading to [Event] next week?") outperform generic cold subject lines by roughly 30% in my tests.

Post-event sequences work best when they're personalized — referencing a session the prospect spoke at, a panel they were on, or a topic from the conference hashtag feed. Generic "hope you had a great show" emails perform no better than standard cold outreach.

ROI Math: What a $400 Conference Prep Sprint Actually Buys

For a 2,000-person conference list:

Line item	Cost
Apify scraping (3–4 actor runs)	$12
PDL enrichment (1,200 hits × $0.04)	$48
Apollo enrichment (400 hits × $0.10)	$40
Hunter.io domain search (200 hits × $0.012)	$2.40
ZeroBounce validation (1,800 emails × $0.008)	$14.40
SDR time (3 hrs ICP scoring + list setup @ $50/hr)	$150
Total	~$267

At an average deal size of $25,000 and 10% close rate on meetings, 2 closed deals from 41 meetings = $50,000 revenue. That's a 187x return on the prep spend.

This math degrades fast if your enrichment is sloppy (high bounce rates, low ICP match) or if your timing is off. The quality of extraction and precision of ICP scoring are where most teams leave money behind — not the outreach copy.

What I Actually Use

For the full workflow:

Extraction: Apify for covered conferences, Playwright for custom sites
Company intelligence on exhibitors: Grata for private/mid-market accounts, Apollo for public companies
Enrichment waterfall: PDL first (best programmatic API, highest coverage), Apollo fallback, Hunter.io for domain-based email finding
Email validation: ZeroBounce — tested NeverBounce too and they're comparable; ZeroBounce wins on bulk pricing at high volume
ICP scoring + SDR review: Custom Python script feeding into a Clay table before sequence import
Multi-event planning: Vendelux if you're running this across 5+ conferences per year

For social profile enrichment specifically — when a speaker has only their Twitter or Facebook handle listed, not a company domain — Ziwa has been faster for me than PDL's direct API for matching those social handles back to a verified business email. Worth knowing if you work events where speakers promote primarily on social rather than LinkedIn.

The full pipeline takes 3–4 hours to set up the first time per conference. After that, 45 minutes to run it again for the next event on your calendar.

2026 LinkedIn Prospecting Chrome Extension Shootout: Hunter, Lusha, Kaspr, Apollo, Wiza, and Skrapp Tested on 300 Real Profiles

Zackrag — Fri, 29 May 2026 06:06:32 +0000

Three months ago I sat with a spreadsheet of 300 LinkedIn profiles I'd pulled manually — a mix of VPs, SDRs, and ops managers spread across SaaS, manufacturing, healthcare, logistics, fintech, agency, retail, professional services, construction, and education. I ran each profile through six Chrome extensions, one at a time, logged every result, and cross-checked found emails against our outbound reply data and our ZeroBounce verification runs. The extensions: Hunter.io, Lusha, Kaspr, Apollo, Wiza, and Skrapp.

This is what I found.

The methodology: 300 profiles, 10 industries, three company-size tiers

I split the 300 profiles into three bands: 1–50 employees (small), 51–500 (mid-market), and 500+ (enterprise). Each industry got 30 profiles. I used a fresh LinkedIn account with a Sales Navigator Teams license to avoid personalization effects. Each extension got a clean install, a fresh credit top-up, and I ran them sequentially — not simultaneously — to avoid any cross-contamination from browser state.

"Match" meant the extension returned an email that passed ZeroBounce verification as deliverable. "Hit rate" is matches divided by profiles tested. "Direct-dial match" was only counted if the number returned was a genuine direct line, verified by a quick test-call sample on a subset of results.

This wasn't a sponsored test. None of these vendors knew I was writing this. I bought credits out of pocket.

Email hit rates, ranked

The headline number everyone wants. Here's how they performed on verified, deliverable email addresses across all 300 profiles.

Extension	Overall Hit Rate	Enterprise (500+)	Mid-market (51–500)	Small (<50 emp.)
Lusha	71%	82%	68%	54%
Apollo	68%	79%	66%	51%
Wiza	65%	76%	63%	49%
Hunter.io	61%	71%	60%	44%
Kaspr	58%	63%	59%	52%
Skrapp	52%	64%	51%	38%

A few things worth noting. Lusha led overall, but its advantage is almost entirely the enterprise tier — at companies under 50 employees it drops to 54%, barely ahead of Kaspr's 52%. Kaspr was the only tool that flattened out somewhat across tiers; its small-company rate suffered least relative to its enterprise rate. Hunter.io performs well when there's a clean pattern-matched domain (the firstname.lastname@company.com format), but it struggled on anything with a custom or obfuscated format. Skrapp landed last — it's a capable tool, but the data layer simply isn't as deep as the top three.

Direct-dial coverage is where the gap actually hurts

If you work in SaaS or tech, direct-dial doesn't matter as much — everyone picks up Slack. If you're selling into manufacturing, logistics, or construction, a direct dial is often the only viable cold-call path. Here's where things diverged sharply.

Extension	Direct-Dial Match Rate
Lusha	34%
Kaspr	31%
Apollo	22%
Wiza	14%
Hunter.io	3%
Skrapp	2%

Lusha and Kaspr are in a different league on phone data. Hunter.io and Skrapp are effectively email-only tools — that 3% and 2% figure means they occasionally surface a company switchboard, not a direct dial. Apollo's 22% was a genuine surprise; their phone coverage has improved substantially since 2024. Wiza at 14% was disappointing given its price point — it's clearly optimized for email list-building, not phone coverage.

If cold calling is core to your workflow, the choice practically narrows to Lusha and Kaspr.

Fortune 500 vs. the 40-person agency: the numbers diverge fast

I've seen a lot of articles quote a single "accuracy" number and leave it there. That number almost always reflects Fortune 500 performance, because those companies have the most coverage in every vendor's database. The 40-person agency, the 80-person regional logistics firm — those are where real SDRs spend a lot of their day, and they're where every tool gets worse.

Within my small-company band (<50 employees), Lusha dropped from 82% (enterprise) to 54% — a 28-point fall. Apollo fell 28 points too (79% → 51%). Hunter.io fell 27 points (71% → 44%). Kaspr fell only 11 points (63% → 52%) — its EU-leaning data layer seems to have broader SMB coverage, particularly for Western European companies.

If you're prospecting heavily into SMBs, that 11-point gap versus 28-point gap is meaningful over 200 reveals a month.

LinkedIn ToS risk after the 2024 enforcement wave

In late 2024, LinkedIn ran a significant wave of account restrictions and extension warnings. Not all extensions interact with LinkedIn the same way, and the risk profile genuinely differs.

Extensions that query their own database when you visit a LinkedIn page — they recognize the profile URL and look it up server-side — carry essentially no risk. Your browser isn't doing anything LinkedIn can't observe a human doing; you navigated to a profile. Hunter.io, Wiza, Skrapp, and Apollo all work this way.

Extensions that actively read DOM content from the page carry more risk. Kaspr and Lusha have historically touched DOM elements beyond just reading the URL. Both updated their extensions post-2024 to reduce this exposure, but I'd still categorize them as moderate-risk relative to the pure-lookup tools.

I didn't lose any accounts during my test, but I was on a fresh account with no volume pressure. Pushing 50+ reveals per day on your primary LinkedIn account is a different situation. The honest framing: risk exists on a spectrum. Use a secondary account if you're pushing high volumes, regardless of which tool you pick.

Credits and pricing at 200 reveals a month

Most comparison articles show entry pricing without accounting for what an individual SDR actually runs. 200 reveals/month is a realistic ceiling for a rep doing solid manual prospecting without Sales Navigator automation.

Extension	Plan for ~200 emails/mo	Monthly Cost	Phone Credits Included?	Overage Cost
Hunter.io	Starter (500 searches)	$34/mo	No	$0.04/search
Lusha	Pro (40 credits base)	$29/mo	Yes (5 credits/phone)	$0.40+/credit
Kaspr	Start (1,200 email / 240 phone credits)	$49/mo	Yes	Per credit
Apollo	Basic (unlimited emails, 600 phone)	$59/mo	Yes	$0.05/phone
Wiza	Pro (500 valid emails)	$49/mo	Limited	$0.10/email
Skrapp	Starter (200 credits)	$30/mo	No	$0.15/credit

Hunter.io is the cheapest path to 200 email reveals, and if you never need phone numbers, it does the job. Lusha at $29/month looks cheap until you realize 40 credits covers 40 emails or 8 phone numbers — if you want phone data at volume, the real monthly cost climbs fast. Kaspr at $49/month gives you the most generous phone allowance for its tier. Apollo at $59/month is the most complete option; you also get sequencing, a dialer, and CRM sync included, which changes the cost math if you'd otherwise buy those separately.

Which extensions don't interrupt your flow

This is the UX factor almost no comparison covers, but it genuinely affects rep productivity. I prospected on real profiles during my test and tracked how each extension behaved in normal use.

Apollo loads its sidebar panel quickly and integrates cleanly into the LinkedIn layout. Lusha pops a small widget on the profile that reveals on click — fast, low friction. Wiza is well-built for list exports but clunky for single-profile prospecting; it wants you in a list context, not browsing profile to profile. Hunter.io shows a small icon in the URL bar — subtle, but the reveal itself took 2–3 seconds consistently. Kaspr had a noticeable sidebar load delay (3–4 seconds) every time I navigated to a new profile. Skrapp was the slowest of the six; I regularly waited 5+ seconds, and in two sessions the extension failed to load without a manual page refresh.

If you're visiting 40+ profiles per day, the 4-second Kaspr delay compounds. Lusha and Apollo won on speed and UI polish.

What I actually use

For email-only prospecting at volume on mid-to-large companies: Apollo. The $59/month includes sequencing I'd pay for separately anyway, hit rates are competitive, and the UX is the least disruptive of the six. If your manager is watching seat costs, Hunter.io is the defensible cheap option — accurate on well-structured domains and genuinely useful for pure email campaigns.

For cold-calling pipelines targeting enterprise accounts: Lusha. The 34% direct-dial rate is simply better than anything else here, and the reveal widget is fast. Accept that phone data at scale costs more per credit than the base plan suggests.

For EU-focused prospecting or heavy SMB books of business: Kaspr. The flatter small-company hit rate (11-point drop vs. 28-point drops elsewhere) and generous phone credit allotment make it the right call for reps working non-US markets or mid-market-heavy territories.

Wiza belongs in workflows that start with a Sales Navigator search and end with a CRM upload — it's excellent at list-mode extraction, weaker for profile-by-profile browsing. Skrapp is a workable fallback if budget is a hard constraint, but the speed issues and lower hit rate make it hard to recommend as a primary tool.

None of these is perfect on SMB coverage — that's the honest truth in 2026. Your best return on time is picking the right tool for your dominant account profile, not searching for a single extension that does everything well. Run a free-tier test on 30 profiles from your actual target list before committing to a paid plan; the numbers will tell you what you need to know.

Build Your Own AI Prospecting Agent for Under $50/Month: A Step-by-Step Walkthrough with Clay, n8n, and Claude

Zackrag — Thu, 28 May 2026 06:08:10 +0000

I spent three months evaluating AI SDR platforms. Landbase quoted ~$1,800/month. 11x wanted more. None of them showed me data lineage — where the contact came from, what signal triggered outreach, what prompt decided this person was worth reaching. So I built my own stack. Total cost after two months: ~$47 in API calls for the lean version. Here's exactly how it works.

The Four Layers You Actually Need

Most DIY prospecting guides skip the first layer entirely. They hand you a static CSV and call it a pipeline. That's a mail merge with extra steps, not a prospecting agent.

A real prospecting agent has four distinct layers. The signal layer is the trigger — something changed in the world that makes this company or person worth contacting right now. Without a real-time trigger, you're guessing. The enrichment layer adds context: job title, seniority, company size, tech stack, funding stage. The scoring and copy layer is where Claude earns its place — it judges ICP fit against your criteria and generates a first-touch line personalized to the trigger. The routing layer pushes approved contacts to your sending tool, logs everything, and deduplicates against your CRM.

Each layer has a clear input and output. The signal layer produces a company or person identifier plus a trigger event. Enrichment adds structured fields. Scoring produces a numeric score and a reason string. Routing produces a sequence enrollment confirmation. When something breaks, you know exactly which layer failed.

Which Triggers Actually Get Replies

I tested three trigger types over eight weeks and tracked reply rates across 600 outreach sequences.

Job posting signal — the company posts a RevOps, Sales Ops, or Head of Growth role — produced a 6.1% reply rate. Funding alert via the Crunchbase API (Series A or B announced in the last 30 days) came in at 4.8%. Website visitor matching via Clearbit Reveal, where I identified the company and guessed the decision-maker, came in at 2.3%.

Job posting won by a clear margin. The logic holds: hiring for RevOps means there's an active project, a budget allocation in progress, and a vendor evaluation window opening. The hiring manager is already thinking about tooling. Pull from the Crunchbase API job postings endpoint and run a Phantombuster LinkedIn scrape every 48 hours. It's not elegant, but the reply rates justify the maintenance overhead.

Enrichment That Costs Less Than a Lunch

Clay makes waterfall enrichment easy to configure. The logic: try the cheapest source first, fall back only when the previous source misses. I run Hunter.io first, then People Data Labs, then RocketReach as last resort.

Here's what the last 1,000 contacts looked like:

Enrichment source	Contacts found	Cost per found contact	Hit rate
Hunter.io (first pass)	612	$0.009	61.2%
PDL (fallback)	201	$0.019	20.1%
RocketReach (fallback)	87	$0.041	8.7%
Not found	100	—	10.0%

Total for 900 enriched contacts: ~$11.40. The 10% miss rate gets written off — chasing those contacts with manual research doesn't pencil out. Fields passed to the scoring layer: job title, seniority, company headcount, industry, funding stage, tech stack (from BuiltWith via Clay), and the original trigger. Everything else is noise that inflates token costs without improving scoring accuracy.

The Claude Prompt That Actually Filters Correctly

The scoring step runs in Clay's AI column using Claude Haiku. Haiku is fast and cheap enough that running it on every enriched contact costs under $2 per 1,000 rows.

You are a B2B sales researcher. Score ICP fit from 1–10.

ICP criteria:
- Industry: SaaS or tech-enabled services
- Headcount: 20–500 employees
- Funding: Seed through Series C
- Trigger: must be hiring for sales, ops, or growth function
- Title: VP/Director or above, or founder

Contact data:
{{title}}, {{company}}, {{headcount}}, {{funding_stage}}, {{industry}}, {{trigger_type}}

Respond in JSON: {"score": N, "reason": "..."}

Contacts scoring 7 or above go to copy generation. Below 7 are dropped. About 38% of enriched contacts make it through, which is the point — high-volume outreach to weak-fit contacts hurts deliverability and wastes sequence capacity.

Copy generation runs on Claude Sonnet:

Write a cold email first line (30 words max) for outreach to {{name}} at {{company}}.
Context: {{company}} recently {{trigger_detail}}.
Tone: direct, no fluff, no "I came across your profile."
Do not use "reach out." Do not mention our product yet.
Output only the first line.

I tested 200 Claude-generated first lines against manually written controls. Open rate: 34% (Claude) vs. 31% (manual). The difference isn't dramatic. But at $0.003 per email versus 15 minutes of my time per contact, it's a straightforward win at volume.

Wiring It Together with n8n Without Losing Your Mind

Clay fires a webhook when a row reaches "approved" status — score of 7 or above and email verified. n8n catches it and does three things sequentially: first, deduplicates against HubSpot by email address; second, POSTs to the Smartlead API to add the contact to the active sequence; third, logs the contact to a Google Sheet with timestamp, score, and trigger type.

I run self-hosted n8n on a $6/month Hetzner VPS. The workflow is 11 nodes. Setup took about four hours the first time, mostly debugging Clay's webhook schema, which isn't fully documented. Smartlead is preferred over Instantly here because the Smartlead API handles programmatic contact insertion more cleanly — Instantly works too if you're already using it, but the API documentation required more trial and error.

What This Stack Actually Costs

Here's the full version, running Clay as the enrichment hub with Crunchbase for signals:

Component	Tool	Monthly cost
Signal source	Crunchbase API	$49.00
Enrichment hub	Clay (Growth, 2,000 credits)	$149.00
Email finding	Hunter.io (Starter)	$34.00
Person data fallback	PDL (pay-as-you-go)	~$4.00
LLM scoring + copy	Claude API (Haiku + Sonnet)	~$6.00
Workflow orchestration	n8n (self-hosted VPS)	$6.00
Sending tool	Smartlead (Basic)	$32.50
Total		~$280.50

And the lean version, for anyone who already has Apollo and wants to call PDL directly:

Component	Tool	Monthly cost
Signal source	Apollo (existing plan)	$0
Enrichment	PDL direct API (500 calls)	$9.00
LLM scoring + copy	Claude API	~$6.00
Orchestration	n8n cloud (free tier)	$0
Sending tool	Smartlead (Basic)	$32.50
Total		~$47.50

Build vs. Buy — Where the Math Actually Breaks

Option	Monthly cost	Contacts/month	Cost per enriched contact	Control over prompts?
DIY lean stack	~$47	~500	$0.09	Full
DIY full stack	~$280	~1,000	$0.28	Full
Apollo AI (basic plan)	$99	10,000	$0.01	None
ZoomInfo Copilot	~$1,500+	Unlimited	varies	None
Cognism AI	~$1,200	Unlimited	varies	None
Landbase (managed AI SDR)	~$1,800	Managed	~$1.80+	None
11x (Alice)	custom (~$2,400)	Managed	unknown	None

Apollo wins on raw cost-per-contact if building large lists is the goal. The DIY stack wins when you need custom scoring logic, transparent trigger attribution, or compliance audit trails. ZoomInfo and Cognism are built for enterprise teams where legal requires clean data provenance — that's a different purchase than a prospecting workflow.

Landbase and 11x are a different category entirely: managed services, not tools. If you don't want to maintain a workflow, that's a rational trade. If you do want control, you're paying roughly six times more for a system you can't inspect or tune.

The honest limitation: this stack breaks when Clay changes its webhook schema (happened once), when n8n updates a node (happened twice), and when the Crunchbase API rate-limits without warning (once). Budget two to three hours per month for maintenance and you'll stay ahead of it.

What I Actually Use

For the core stack: Clay plus PDL waterfall into Claude scoring, routed through n8n into Smartlead. Stable for two months, processed 1,900 contacts, no major breakage. For signal sourcing on Twitter and Facebook profiles specifically — when I want to identify who's posting about a relevant topic rather than relying on job board data — Ziwa has been faster for me than PDL's direct API for pulling enriched social profile data. Phantombuster covers similar ground with more setup time. Neither replaces the core stack; they're signal sources, not the whole pipeline.

The question I get asked most: should I start with the lean version or the full version? Start lean. Call PDL directly without Clay, let n8n handle the routing, and see if the trigger logic actually works for your ICP before paying for Clay's credits. You'll learn more from 300 contacts through a cheap pipeline than from 3,000 contacts through an expensive one you don't fully understand.

5 Things Your US Outbound Team Is Doing Illegally Under CCPA Right Now (And How to Fix Them Without Killing Pipeline)

Zackrag — Wed, 27 May 2026 06:06:30 +0000

The SDR at one of my portfolio companies ran cold email to 8,400 California-based contacts last quarter. His sequence was clean — personalized, relevant, solid reply rates. Then legal forwarded him a CCPA deletion request from a VP at a San Francisco firm. Nobody on the team knew what to do with it. When I audited the stack, I found four of the five violations I'm about to describe.

That company hasn't been fined. Yet. But at $2,663 per unintentional violation and $7,988 per intentional one — and with the California Privacy Protection Agency visibly ramping enforcement after the Disney ($2.75M) and Tractor Supply ($1.35M) settlements — "yet" is doing a lot of work in that sentence.

The "B2B is exempt" myth that won't die (and will cost you)

In 2018, when CCPA passed, two temporary carve-outs bought businesses time: the employee exemption and the B2B exemption. The B2B exemption let companies treat business contact data — work emails, direct-dial numbers, job titles — as outside CCPA scope.

That exemption expired January 1, 2023.

Three years later I still find sales teams operating as if it's 2021. The confusion persists because (a) most legal summaries from 2020–2022 are still ranking in search, (b) data brokers rarely advertise this change loudly, and (c) reps in 20 other US states technically have more latitude — California is uniquely strict here.

The practical effect: every California resident's professional contact information is now personal information under CPRA. Your VP of Sales target at a San Jose firm has the same rights as a retail consumer buying shoes online.

Violation #1: Buying contact lists without an opt-out flow in place

If you buy a list of 3,000 California contacts from Apollo, ZoomInfo, or any data broker, you're not just renting data — you're inheriting obligations. Specifically, "Do Not Sell" obligations.

CCPA's definition of "selling" covers transfers for "monetary or other valuable consideration." When you pay a platform for access to California resident data, that exchange triggers a legal chain: the vendor must have a Do Not Sell mechanism, and you must honor any suppression flags that come with that data.

I audited five outbound teams last year. None of them had asked their data vendors for a current opt-out suppression file. Two of those teams were using Cognism or ZoomInfo — both of which actually maintain Do Not Contact registries — but the teams hadn't configured suppression in their sequencing tools.

Fix: Before your next send, download the opt-out suppression file from your data vendor and load it into your sequencer as a global suppression list. For Apollo, this is under Account Settings → Compliance. For ZoomInfo, contact your CSM for a CCPA suppression export. Set a calendar reminder to refresh it monthly.

Violation #2: No data deletion process

A California resident can request deletion of their personal information. Your team has 45 days to comply. That clock starts the moment the request is submitted — via email reply, LinkedIn message, or your company's privacy inbox, if you have one.

Most outbound teams have no documented process for handling this. Reps either ignore it, forward it to an overwhelmed IT team, or try to delete the contact from Salesforce while leaving them in HubSpot, the enrichment vendor, the cold email tool, and the spreadsheet the SDR is working from.

The legal exposure isn't just in missing the 45-day window. It's in the scattered data trail. If a contact's email is still sitting in your Apollo sequences and a Salesforce export you ran six months ago and a Cognism enriched CSV on someone's laptop, you have not completed that deletion.

Fix: Create a privacy@yourcompany.com alias and list it in your email footer. Document every system that holds prospect data — your CRM, sequencer, enrichment API, data warehouse, local exports. When a deletion request arrives, run through every system on that list. Log it. Most teams can build a workable process in a day; Osano automates this across connected systems if you want a compliance tool rather than a manual checklist.

Violation #3: Using scraped mobile numbers

Mobile numbers scraped from public sources — LinkedIn profiles, conference speaker pages, company websites — are a specific minefield.

First, CCPA: scraping is not a consent mechanism. The CPPA has been clear that "publicly available" has limits. If a contact posted their mobile number in a personal tweet and you're using it for commercial prospecting, that falls outside the publicly-available-government-record safe harbor.

Second, TCPA: calling or texting a California mobile number without express written consent exposes you to $500–$1,500 per call, regardless of whether the contact is a business prospect. TCPA doesn't care that you're targeting a CFO, not a consumer.

I ran a test against 500 LinkedIn-sourced direct-dial numbers from a popular enrichment provider. Roughly 22% came back as mobile numbers. Of those, about 60% were for California-area-code contacts. None had documented consent for text or auto-dialed calls.

Fix: When pulling direct-dial numbers from platforms like ZoomInfo, Lusha, or RocketReach, flag numbers classified as "mobile" — most platforms now label these. Create a separate cadence for mobile numbers that excludes auto-dialed calls and SMS. For cold email to the same contacts, you're on safer ground; TCPA doesn't apply to email.

Violation #4: Ignoring do-not-sell requests from California contacts

This one is distinct from deletion requests. A contact can exercise the right to opt out of the sale or sharing of their data without requesting deletion. They still exist in your CRM, but you can no longer:

Share their data with third-party ad platforms for retargeting
Pass their info to a partner for co-marketing
Upload their email to a lookalike audience in Meta Ads Manager

When I look at marketing automation setups, I regularly see CRM contacts synced to ad platforms with zero suppression logic. Someone in Salesforce who replied "please remove me" two years ago is still getting retargeted on LinkedIn because nobody connected the opt-out flag to the ad sync.

Fix: In Salesforce or HubSpot, create a boolean field: ccpa_do_not_sell. Set it to true when a contact submits an opt-out. In your ad platform sync — LinkedIn Matched Audiences, Meta Custom Audiences — filter that field out of every list upload. This takes about two hours to configure and should be part of your standard CRM data model.

Violation #5: Enrichment data sitting in unsanctioned tools

This is the sneakiest violation because it doesn't feel like one. A rep signs up for a free Hunter.io trial, exports 200 California contacts, enriches them with Snov.io, and pastes the results into a personal Google Sheet to work from. That Google Sheet is now:

Outside your company's data processing agreements
Not covered by your vendor's compliance representations
Potentially retained indefinitely — nobody deletes personal Google Sheets

When a deletion request comes in, nobody knows about that sheet. CCPA doesn't care.

Clay introduces a related risk: it's a powerful enrichment hub that pulls from dozens of underlying providers. Each of those providers has their own data sourcing terms, and when you run a California prospect through a 10-step Clay waterfall, you may be triggering transfers to providers who have no data processing agreement with you.

Fix: Audit your team's tool stack for shadow data. Ask reps to list every tool they personally use to find or enrich contact info. Enforce a policy: personal accounts with exported contact data are not compliant. Route enrichment through approved, contracted platforms only. Your vendors should provide Data Processing Agreements on request — Apollo, ZoomInfo, and Cognism all have them.

The actual penalty math

Five violations. Say your last outbound campaign hit 2,000 California contacts:

Violation	Records at risk	Per-violation fine	Unintentional exposure
No opt-out suppression	2,000	$2,663	$5,326,000
No deletion process	Requests received	$2,663 each	Cumulative
Scraped mobile numbers	~264 (22% est.)	$2,663 CCPA + $500 TCPA	$840,132+
Do-not-sell not honored	Ad sync exposure	$2,663	$532,600
Unsanctioned tool storage	Shadow data contacts	$2,663	Unknown

The theoretical maximum is terrifying. The realistic risk is lower — CPPA tends to pursue systemic violators over small teams — but "probably won't get caught" is not a compliance strategy when fines are per-record.

A 3-week remediation sprint that won't pause pipeline

You don't need to stop outbound. You need to route it through a compliant stack.

Week 1 — Audit and suppress:

Pull opt-out suppression files from every data vendor
Load them into your sequencer as global suppression lists
Identify all California contacts by state/area code
Flag mobile numbers in your CRM

Week 2 — Process and documentation:

Stand up privacy@yourcompany.com
Build the ccpa_do_not_sell boolean field in your CRM
Document every system that holds prospect data
Brief SDRs on deletion request handling (30 minutes, not a training course)

Week 3 — Vendor and ad hygiene:

Request DPAs from your top three data vendors
Audit ad platform syncs and add suppression filters
Remove or migrate shadow data from personal accounts
Set monthly reminders for suppression file refreshes

What I actually use

For deletion request workflow management, Osano handles the automation if you have volume — it connects to your CRM and logs every subject rights request automatically. For teams under 20 reps, a simple shared doc plus a monitored email alias covers 80% of the compliance posture at zero cost.

For compliant data sourcing, Cognism has the most mature CCPA/GDPR compliance stack of the major enrichment providers — they maintain their own Do Not Contact registry and their DPA is substantive rather than boilerplate. Apollo works well too once you configure suppression properly; the compliance settings are buried but functional.

For phone number classification, both ZoomInfo and Lusha label mobile vs. direct-dial. Use that flag before dialing California numbers. Free tools and scraped sources don't provide it, which is a real reason to pay for a contracted data platform rather than assembling contact info ad hoc.

None of this is a guarantee against enforcement. What it does is shift your risk profile from "obvious target" to "reasonable effort" — which is where you want to be when the CPPA is looking for enforcement examples to set precedent.

G2 Acquired Capterra: What the Combined Intent Data Actually Means for Your Activation Workflow

Zackrag — Tue, 26 May 2026 06:08:55 +0000

Three weeks after the deal closed on February 5th, I pulled G2 Buyer Intent for one of my SaaS clients. The signal volume looked the same. The categories looked the same. The CSV export looked the same.

That's not a bug — that's the timeline. G2's $110M acquisition of Capterra, Software Advice, and GetApp from Gartner closed in early February 2026, but the data integration is months away. What you're buying today is still the old G2 Buyer Intent product, and what's coming is more complex than the press release suggests. Here's what I actually know, what I tested, and how to build the activation workflow right now — before your competitors figure out what "3x more signals" means in practice.

What Actually Changed on February 5, 2026

The acquisition combined four platforms:

G2 — ~90M annual visitors, strong North American coverage, heavily tech/SaaS
Capterra — ~55M annual visitors, stronger SMB coverage, broader software categories
Software Advice — advisory-focused, smaller volume but higher-intent browse behavior
GetApp — European-skewed, stronger GDPR footprint

Before this deal, a buyer researching CRM software might appear in G2 Buyer Intent but never trigger a Capterra signal — even if they spent 20 minutes on both sites. Those were separate signals sold by separate sales teams at two companies. Post-acquisition, G2 is promising a unified taxonomy that de-duplicates and stacks these signals across all four properties.

The "6 million verified reviews" and "200+ million annual buyers" numbers are real aggregate figures, but don't conflate reach with intent signal quality. A review page visit is not the same as a comparison page visit. A buyer who lands on a G2 grid and reads three competitor profiles is a different signal than someone who reads a Capterra shortlist article from a Google search. G2's challenge now is teaching its intent engine to weight these behaviors differently — and that taxonomy work takes time.

The 3x Signal Claim — What It Actually Means

G2's announcement said "up to 3x more Buyer Intent signals." I've seen this phrasing before, and it almost always means: in the best-case category overlap scenario.

Here's the math that makes more sense than the press release: if your ICP is mid-market North American SaaS buyers, the Capterra audience overlap with G2 is probably 40–60%. You won't triple your signal volume — you'll see meaningful lifts in specific subcategories where G2 was historically thin. Construction software, healthcare IT, nonprofit tech — categories where Capterra dominates — might genuinely see 2–3x signal lift. In pure-play developer tooling or enterprise infrastructure, the lift will be minimal.

The genuinely additive piece is GetApp's European signal data. G2 Buyer Intent has historically been weak outside North America and DACH. If G2 successfully integrates GetApp's French and Southern European traffic, intent programs targeting EU buyers will finally get workable signal density. That's the signal volume worth watching in Q3 2026.

Before You Activate: GDPR and CCPA Obligations You Can't Skip

Every competitor article I read about this acquisition stops at "evaluate the signals." None of them address the compliance layer — which is exactly where marketing ops teams get burned.

GDPR exposure: GetApp's audience is EU-heavy. When you receive an intent signal that a company from Lyon or Warsaw is researching your category, and you then use that signal to identify and contact a named individual at that company, you are processing personal data of EU residents. G2 Buyer Intent signals are technically account-level (company domain, not person), so the signal itself doesn't directly trigger GDPR Article 6 obligations. But the activation step — looking up contacts at that company and adding them to a sequence — is where you enter personal data processing territory. You need a lawful basis. Legitimate interests is the most common, but it requires a Legitimate Interests Assessment (LIA) that documents why outbound contact is proportionate and expected by the data subject.

CCPA exposure: Same logic applies for California-based prospects. If you're using intent signals to target California residents and sourcing contact data from third parties, make sure your sequence enrollment logic excludes contacts who have exercised opt-out rights under CCPA. This should happen at the point of contact lookup, not as an afterthought after they're already in a sequence.

Practical rule: Treat the intent signal as a targeting trigger, not a consent grant. The signal tells you when to reach out; your CRM's consent records and suppression lists tell you whether you can.

The Full Activation Workflow: Signal to Sequenced Outreach

This is the workflow I built for two clients after the acquisition closed. The architecture assumes Salesforce or HubSpot as the CRM, Apollo.io for contact enrichment, and Clay for routing logic — but the pattern works with any comparable stack.

Step 1: Signal ingestion
G2 Buyer Intent delivers signals via daily CSV or via native integrations with Salesforce, HubSpot, Marketo, and Pardot. Use the native connector. The CSV workflow introduces too much latency and too many manual steps to be sustainable at volume.

Step 2: Account matching
G2's signal fires on company domain. Match on domain, not company name. Name matching breaks on "Inc." vs "Inc" and on parent/subsidiary relationships. Your CRM probably already has 60–70% of these accounts — match first, create net-new records only for the remainder.

Step 3: Routing logic in Clay
Build a Clay table that ingests matched accounts and applies three filters before anything touches your sequence tools:

Open opportunity in the last 90 days? → Route to AE for a "warm nudge" touch, not SDR outbound
Account in ICP tier 1 or 2? → Route to SDR for active outreach sequence
Account tier 3 or unscored? → Drop to marketing nurture; do not touch sales queues

This prevents intent signals from flooding SDR pipelines with accounts that will never convert.

Step 4: Contact lookup with GDPR suppression
For accounts that qualify for SDR outreach, run a contact lookup via Apollo.io to surface 3–5 relevant contacts (typically VP or Director level in the likely buying function). Apply your GDPR/CCPA suppression list at this step, before anyone gets enrolled in a sequence.

Step 5: Sequence enrollment
Enroll qualifying contacts in a dedicated "high-intent" sequence — shorter, more direct, fewer generic check-in touches. Reference the category they were researching: "I noticed [Company] is evaluating [Category] solutions right now..." That sentence lands differently than a cold opener because it's true.

Step 6: Signal decay logic
Intent signals have a half-life. A 7-day-old G2 signal is actionable. A 45-day-old signal is probably stale. Set a decay rule in your routing: any signal older than 21 days gets downgraded to marketing nurture, not active SDR outreach. Without this rule, your SDRs will eventually ignore the entire intent feed because the hit rate drops.

How G2 Intent Stacks Up Against Bombora, 6sense, and Demandbase

Platform	Signal Source	Coverage Strength	CRM Integration	GDPR Signal Clarity	Pricing Model
G2 Buyer Intent (post-acquisition)	First-party (own properties)	North America strong, EU growing	Native (SF, HubSpot, Marketo)	Account-level only	Vendor subscription
Bombora	Co-op network (4,000+ B2B publishers)	Broad, category-heavy	Via most MAPs	Account-level only	Platform + signal credits
6sense	First + third-party + predictive AI	Enterprise-strong	Native SF/HubSpot, deep	Account + contact signals	Platform (premium pricing)
Demandbase	First + third-party	ABM-focused	Deep SF/HubSpot	Account-level	Platform

The G2/Capterra advantage is first-party signal purity: when a buyer is on G2 comparing your product to a competitor, that's explicit category intent — not inferred from a trade publication they glanced at. Bombora's co-op signals are inferred from content consumption across third-party sites, which makes them broader but less precise. 6sense layers predictive AI scoring on top of both, which is powerful but expensive and, frankly, hard to audit.

For software and SaaS categories specifically, G2's post-acquisition footprint is hard to beat on signal quality. For everything outside software — manufacturing, financial services, professional services — Bombora still wins on category breadth. I run both in parallel for clients with mixed ICPs; the two signal sources rarely overlap, so the coverage is genuinely additive.

What I Actually Use

For the full activation loop: G2 Buyer Intent for the signal, Clay for routing logic, Apollo.io for contact enrichment, and HubSpot sequences for outreach. Clay is where the real work happens — it lets you apply ICP scoring, GDPR suppression, and deal-stage routing all before anything touches your CRM or sequence tools.

For accounts that clear the routing logic but aren't in my existing contact database, I start with Apollo.io, fall back to Hunter.io for email verification, and for companies where I need to find contacts via social profiles before a clean business email is available, Ziwa has been faster for me than PDL's direct API for pulling LinkedIn-style contact data on contacts that haven't surfaced elsewhere.

For a complete Bombora + G2 combined intent stack, I use Clay as the single ingestion point for both feeds — it normalizes the account-level data into one routing table, which is far cleaner than managing two separate Zaps or webhook flows.

The 3x signal claim from G2 will eventually be real, but right now the deal is 90 days old and the data pipelines aren't fully merged. Build your routing workflow today so you're ready to absorb the volume when it arrives. The teams who win aren't the ones who subscribe to more intent feeds — they're the ones who have a workflow that doesn't break when signal volume triples.

The Dark Funnel Prospecting Playbook: How to Surface Buying Signals from Reddit, Discord, and AI Assistants Before Your Competitors Do

Zackrag — Mon, 25 May 2026 06:13:02 +0000

A deal we closed in Q1 showed up as "direct traffic" in HubSpot. When I traced it back manually — asked the AE to interview the buyer — the actual path was: a Reddit thread in r/salesops where someone asked for CRM alternatives, a comment mentioning us by name, six upvotes, and the buyer quietly checking us out three weeks later. None of that appeared anywhere in our attribution stack.

That's not a tracking gap. That's the dark funnel doing exactly what it does.

Why the dark funnel is bigger in 2026 than it was two years ago

Buyers in 2024 had two or three places to research outside your control. Today it's five channels compounding simultaneously:

Reddit — professional communities like r/salesops, r/hubspot, and r/saastr have grown 40–60% in active users since 2023, and buyers there explicitly ask for vendor comparisons
Discord servers — RevOps communities, SaaStr's server, and Pavilion's Discord have thousands of members comparing tools in #vendor-reviews channels daily
G2 and Capterra — the conversation depth in reviews has increased; buyers now tag specific use cases, not just overall ratings
AI assistants — when a buyer types "best [category] tool for [use case]" into Perplexity or ChatGPT, they're 70–80% through their buying decision before they touch your website
Private Slack groups — Pavilion alone has 12,000 revenue leaders. You are being discussed in channels you cannot see.

The average B2B deal in the $20K–$100K ACV range now involves 8–12 informal peer touchpoints before a demo request. That's not a Gartner figure — that's from post-deal interviews I ran across 47 closed-won deals over 6 months.

The 5 channels ranked by signal-to-noise ratio

Not every dark funnel channel is worth monitoring equally. After pulling signals from each channel for 90 days, here's what I found:

Channel	Signal quality	Volume	Monitoring effort	Monthly cost
Reddit keyword mentions	High — intent is explicit	Medium	Low (automated)	$0–$49
AI assistant visibility	Very high — buyer is shortlisting	Low (hard to measure)	High	$200–$500
Discord communities	High — peer recommendation	Low	Medium (manual)	Free
G2/Capterra comparison views	Medium — competitive research	Medium	Low	Free with account
Private Slack groups	Very high	Very low	Very high	Invite-only

Reddit gives the best ROI on monitoring effort by a wide margin. Discord and private Slack require actual community participation — no tool automates that.

The 5-tool stack I run for under $400/month

I tried the full ABM route. 6sense and Bombora are both solid, but at $2,000–$4,000/month minimum, they're hard to justify below $5M ARR. This stack replaced them:

1. SparkToro — $50/month Indie plan

One question I use this for: where does my target audience actually spend time online? Run an audience query for "VP of Sales at SaaS companies" and SparkToro maps the subreddits, podcasts, newsletters, and websites they engage with most. This is how I found three subreddits worth monitoring that weren't on my radar. I run this quarterly to recalibrate, not weekly.

2. Brand24 — $79/month

Monitors Reddit, news, and the open web for keywords in near real-time. I set up alerts for: our brand name, our three main competitors, and three category phrases ("best [category] tool," "switching from [competitor]," "[category] alternatives"). Brand24's sentiment scoring filters noise well enough that I don't need to manually review every alert — maybe 15 minutes of triage per day.

3. Syften — $19/month

More granular than Brand24 for Reddit specifically. I can monitor individual subreddits, filter by post flair, and get digest emails at whatever cadence I want. Where Brand24 covers breadth across the web, Syften covers Reddit depth. The two overlap, but Syften's Reddit-native filtering catches threads Brand24 sometimes misses.

4. Keywords Everywhere — $10/100K credits

Chrome extension. When I'm manually browsing a subreddit or Discord thread, it shows search volume context around topic clusters. Cheap, zero friction, useful for spotting whether a conversation is an isolated question or part of a broader search trend your competitors are optimizing for.

5. Clay — from $149/month

This is where signal converts to action. When Brand24 or Syften flags a Reddit thread where someone asks about our category, I pull the commenter's profile into a Clay table, enrich it with company data via Apollo or Clearbit, and route to the right AE by company size. The whole workflow runs in under 5 minutes. Clay's HTTP request blocks also let me pull G2 review data without a separate integration.

How to score signals without a $3K/month intent platform

The instinct is to build a complex scoring model. I tried that. It creates analysis paralysis and the SDRs ignore it. What works is a three-tier system that anyone can actually use:

Tier 1 — Act same day:

Reddit comment explicitly asking for tool recommendations in our category, from an account with 3+ years of history
Discord message comparing us to a competitor by name
G2 review from a company in our ICP mentioning a pain point we directly solve, posted in the last 7 days

Tier 2 — Add to sequence within 48 hours:

Category mention without naming us, where the commenter works at a company in our ICP
Job-change alert: a champion from a churned account moves to a new company
Three or more G2/Capterra profile views from the same company domain in one week

Tier 3 — Log and watch:

General category conversations not tied to a purchase decision
AI assistant citations where our brand appears (hard to act on immediately, but the trend matters)

Clay handles enrichment and CRM routing for Tier 2 and 3 automatically. Tier 1 lands as a manual task for the AE within the hour. That's the only thing the AE sees as an action item.

The weekly cadence that keeps this from becoming a second job

This doesn't work if it requires a dedicated analyst. The whole system runs in 90 minutes a week:

Monday (30 min):
Review the Brand24 and Syften weekly digest. Flag Tier 1 signals and drop them into Clay for enrichment. Check SparkToro Trending for new communities gaining traction in my audience segment — this occasionally surfaces a new subreddit or Discord worth adding to my monitoring list.

Wednesday (20 min):
Manual browse of the top 3 subreddits I identified via SparkToro. Drop anything worth actioning into a shared Slack channel with the SDR team. This stays manual because automated tools miss context — a thread might not contain my tracked keywords but still be a clear buying-signal conversation.

Friday (40 min):
Spot-check AI assistant visibility by manually querying Perplexity and ChatGPT with 5–6 variations of category searches. Note where my brand appears versus competitors. Update Tier 2 and 3 sequences with new signals from the week. Log the signal count in a spreadsheet — volume trends over 30-day windows matter more than any individual signal.

After 90 days of this cadence, our SDR team had 22 Tier 1 signals they acted on that would never have appeared as inbound leads. Eight converted to pipeline. That's not a controlled study, but it's real pipeline from a $400/month monitoring stack.

The AI assistant problem is a content problem

You cannot directly measure how often buyers find you through ChatGPT or Perplexity. But you can influence the outcome.

What drives your brand appearing in AI-generated vendor shortlists:

Volume of fresh, specific content — AI models weight recency and use-case specificity
G2 and Capterra reviews with detailed, outcome-focused language (not "great product, 5 stars")
Being cited in industry newsletters and publications that AI crawlers index regularly

I audited our G2 profile and added 15 new customer reviews with explicit use-case language, then published 4 comparison posts targeting "[us] vs [competitor]" search patterns. Three months later, spot-checking ChatGPT and Perplexity responses for our category showed us appearing in roughly 60% of shortlists where we previously appeared in 20%. Not a controlled experiment, but the correlation is strong enough to keep doing it.

What RocketReach, Hunter.io, and Lusha won't tell you is how someone found you before they became a contact in your CRM. The dark funnel lives upstream of every contact enrichment tool in the stack.

What I actually use

For web and Reddit monitoring in one dashboard, Brand24 is my daily driver. Syften runs alongside it for Reddit depth. SparkToro I run quarterly to recalibrate which communities deserve attention. Clay is the glue layer — it turns raw signals into enriched CRM entries using Apollo for company and contact data, with Clearbit filling gaps on company-level enrichment.

6sense and Bombora are genuinely better at account-level intent at scale. If you're past $10M ARR with dedicated RevOps headcount, go there. Below that threshold, this stack gives you 70% of the signal at 15% of the cost, and the weekly cadence above keeps it from becoming overhead.

The dark funnel isn't a problem you solve once. It's a monitoring habit. Ninety minutes a week, the right tools, and a simple scoring model will surface pipeline your competitors are walking past blind — and crediting to "direct traffic" when it closes.

The Global Coverage Myth: Why Your Enrichment Stack Returns 15% Match Rates in Asia-Pacific (And What to Use Instead)

Zackrag — Fri, 22 May 2026 06:07:05 +0000

The Global Coverage Myth: Why Your Enrichment Stack Returns 15% Match Rates in Asia-Pacific (And What to Use Instead)

Six months into our APAC expansion, I pulled a match rate report from our enrichment tool and stared at it for a while. Japan: 31%. Vietnam: 22%. Thailand: 19%. Singapore was the lone outlier at 67%. For context, our US contact lists were hitting 84%.

This wasn't a configuration problem. It wasn't dirty input data. The tools we trusted — tools that work beautifully for North American GTM — were structurally blind to large parts of the region we were betting on.

Here's what nobody writing enrichment comparison pieces actually explains: why APAC coverage is this bad, and why it's not going to improve for most major platforms anytime soon.

Three Structural Reasons Your Stack Was Never Built for APAC

1. LinkedIn is the source graph — and it barely exists in most of APAC

Nearly every mainstream B2B enrichment tool — Apollo, PDL, Lusha, ZoomInfo, Clearbit — aggregates data from public web sources, with LinkedIn as the backbone. That works in markets where LinkedIn penetration is high and professionals actually post their work history publicly.

In mainland China, LinkedIn was effectively forced out; WeChat dominates professional networking. In Japan, Line and domestic networks like Sansan handle business card exchanges. In Thailand and Vietnam, Facebook Messenger is where business relationships live, but it's not a public graph these tools can reliably index. Indonesia, the Philippines, and Malaysia have a mix of platforms, none of them optimized for scraping by US-centric data companies.

When the foundational data source doesn't exist in a market, no amount of validation or AI enrichment fixes a zero-record problem.

2. Regulatory fragmentation is genuinely non-trivial

APAC has no equivalent of GDPR — a single framework that data providers can build compliance around once and apply across a continent. Instead you're dealing with:

Japan: APPI (Act on the Protection of Personal Information) — amended in 2022, requires purpose limitation and data subject notification before cross-border transfer
China: PIPL — aggressive data localization, effectively making Western data scraping illegal for Chinese nationals
Thailand: PDPA — enforced since 2022, modeled on GDPR but with local nuances
Indonesia: UU PDP — passed 2022, still being operationalized
Vietnam: PDPD — passed 2023, with strict limits on data processing without explicit consent
Singapore: PDPC/PDPA — actually relatively permissive compared to its neighbors, which partly explains Singapore's higher match rates

Each of these creates legal risk for data providers who want to index that market. Most US-headquartered enrichment tools quietly avoid markets where their data collection methods would be non-compliant. They don't advertise this. They just return no results, or return stale data they collected before regulations tightened.

3. Character encoding breaks name-matching in ways that compound quietly

Most enrichment APIs match on email + name pairs. When a Japanese contact's name is stored as Yamamoto Kenji in one system and 山本健二 in another, the fuzzy match fails silently. Vietnamese names with diacritical marks (Nguyễn Thị Hương vs Nguyen Thi Huong) produce inconsistent results depending on how the tool normalizes inputs. Thai names don't follow Western first/last conventions.

This isn't a solvable problem for general-purpose tools without significant localization investment. Most haven't made it.

How Coverage Actually Breaks Down by Sub-Region

I tested the same list of 500 verified contacts across six APAC sub-regions using five different tools. The pattern was consistent enough that I'd generalize it this way:

Sub-region	Typical match rate	Notable exception
Australia / New Zealand	60–72%	Near-Western pattern; strong Hunter.io performance
India	45–62%	Ampliz significantly outperforms peers
Singapore	55–68%	Best-performing SEA market; most tools work adequately
Japan	28–36%	Worst major economy in region; structural not fixable
SEA ex-Singapore (Vietnam, Thailand, Indonesia, Philippines)	18–38%	High variance; AroundDeal best option
China	< 15%	Effectively inaccessible for Western tools under PIPL

Australia and New Zealand are essentially the North American equivalent — high LinkedIn adoption, English-first, permissive data environment. Any tool that works well in the US will work adequately there.

India is the interesting middle ground. The data exists, professionals use LinkedIn, but the quality varies enormously by industry and seniority. IT services are well-covered; manufacturing, infrastructure, and regional finance are not.

Japan is the one that catches teams off-guard most. Senior decision-makers at Japanese enterprises often have zero public web footprint. Business card exchanges happen in person, contact details don't get posted publicly, and APPI compliance-aware Japanese companies have been systematically purging their employee data from public directories since 2022.

Tool Comparison: APAC Sub-Region Coverage

Tool	India	ANZ	Singapore	Japan	SEA (ex-SG)	Pricing tier
Apollo	Good	Good	Good	Poor	Poor–Fair	$
PDL	Fair	Good	Fair	Very poor	Poor	$$
Ampliz	Best	Fair	Fair	Poor	Fair	$
ZoomInfo	Fair	Good	Fair	Poor	Poor	$$$$
Lusha	Poor	Fair	Fair	Very poor	Very poor	$$$
AroundDeal	Fair	Poor	Good	Poor	Best	$
SMARTe	Good	Fair	Good	Fair	Good	$$
Hunter.io	Poor	Good	Fair	Poor	Poor	$
Cognism	Poor	Fair	Poor	Very poor	Very poor	$$$
Kaspr	Very poor	Poor	Very poor	Very poor	Very poor	$

A few notes on this table:

Apollo is not bad for APAC overall — it's fine for Singapore and Australia. The problem is teams using it as a single source when prospecting across all of APAC. Vietnam and Thailand are consistent weak spots; email deliverability runs 10–15% lower than equivalent US data even when the contact exists.

ZoomInfo costs four times as much and delivers nearly identical APAC coverage to Apollo in my testing. If you're paying ZoomInfo enterprise rates hoping for better global coverage, that expectation isn't being met in SEA or Japan.

SMARTe is the underrated phone-first option if you're running direct dial outreach rather than email. Their mobile number fill rate for APAC contacts is around 70%, which blows every other tool I tested out of the water. If your sales motion involves calling, SMARTe is worth evaluating specifically for India and SEA.

Cognism and Kaspr are European-first tools that happen to have APAC listings. I wouldn't build an APAC enrichment strategy around either of them.

Building a Region-Specific Enrichment Fallback

The approach that actually worked for us was a waterfall by geography, not a single-tool enrichment step. Here's the rough logic:

For ANZ contacts: Apollo first, Hunter.io fallback for email verification.

For India: Ampliz as primary, Apollo as fallback. Ampliz consistently returned 20–25% more matched contacts for Indian IT, SaaS, and BFSI roles.

For Singapore + Malaysia + Philippines: Apollo is adequate. AroundDeal catches edge cases.

For Vietnam, Thailand, Indonesia: AroundDeal primary. Treat any result as requiring manual verification before outreach.

For Japan: Honestly, automated enrichment is largely unreliable. We ended up using a combination of local trade directory lookups, event attendee lists (Tokyo SaaS conferences publish rosters in Japanese), and targeted LinkedIn connection requests before any enrichment step. PDL's API is worth a pass for enterprise-sized companies — they have some coverage for Nikkei 225 companies — but for sub-enterprise or regional Japanese firms, plan for high manual effort.

For China: We didn't prospect into China. The legal and practical data access situation makes automated enrichment a non-starter for most Western tools.

If you're using Clay as an orchestration layer, this waterfall approach is straightforward to implement — route contacts by inferred country code before the enrichment step and hit different providers per branch. It adds complexity but significantly improves overall match rates.

What I Actually Use

For our specific APAC motion — which spans India, Singapore, and Australia with occasional work in SEA — the working stack is Ampliz for India contacts, Apollo for ANZ and Singapore, and AroundDeal as the SEA fallback when Apollo comes up empty.

For social profile lookups — specifically Twitter/X and Facebook — where I need to go from a company name or professional profile to contact-level data, Ziwa has been faster for me than PDL's direct API for those specific source types; PDL is more comprehensive for resume-style enrichment, but slower on social-first lookups.

The honest summary: there is no single tool that handles all of APAC at the match rates you're used to in North America. The region is too fragmented legally, linguistically, and structurally. Budget for a waterfall, account for 30–40% lower match rates than your US benchmarks, and build manual enrichment time into your Japan pipeline specifically.

Anyone who tells you they have 80%+ match rates across all of APAC is either measuring ANZ only or selling you something.

Enriching Free Trial Signups: The PLG Data Stack for Turning Inbound Users Into Qualified Pipeline

Zackrag — Thu, 21 May 2026 06:06:29 +0000

Of your last 100 signups, I'd bet 30–40 came in as @gmail.com. Maybe another 10 as @yahoo.com, @hotmail.com, @icloud.com. Your Segment event fired, your CRM got a new contact record with a name and a city, and then nothing. No company. No title. No way to know if this person runs engineering at a 300-person Series B or is a student experimenting on a weekend.

This is the PLG enrichment problem that nobody writes about. Every piece of B2B enrichment content assumes you start from a company domain — firstname@acme.com — and work backwards to firmographics. That model breaks the moment your product grows virally and people sign up with whatever email they happen to check.

I've spent the last six months wiring enrichment pipelines for PLG SaaS companies ranging from 2,000 to 80,000 monthly free users. Here's what actually works.

Why standard enrichment breaks for PLG inbound

The typical enrichment stack — Clearbit, Apollo, PDL in waterfall — is built around the assumption that your email domain is your company proxy. When that assumption holds, you get 80–90% match rates and clean firmographic data flowing into your CRM within seconds.

Personal email domains destroy this. Clearbit's Enrichment API returns a null company when it hits gmail.com. Apollo routes personal domains straight to a consumer bucket and skips B2B fields entirely. Even PDL's /person/enrich endpoint — the most permissive of the major providers — gives you around 32% hit rate on Gmail addresses versus 74% on corporate domains. I measured this across 6,200 signups for a developer tooling company last quarter.

The enrichment vendors aren't wrong to do this. Their products are optimized for outbound SDR workflows. They designed around sales reps who start from a target account list, not inbound products where users self-select with whatever email they happen to use.

The three signals that define a PQL when you have no company email

Before throwing API calls at the problem, get clear on what you're actually scoring. A PQL in a PLG context is the intersection of three things:

Identity fit — Is this person likely to be a B2B buyer in your ICP? Title, seniority, company size, industry.

Engagement depth — Have they hit your activation threshold? Not just "logged in," but reached the moment your product delivered value — uploaded a file, ran a query, invited a teammate, connected an integration.

Expansion signal — Are they bumping against limits? Viewing upgrade prompts, hitting API rate limits, inviting more users than their plan allows.

When someone signs up with a personal email, you still have their name, behavioral data from Mixpanel or Amplitude, and whatever they self-reported in onboarding. That's your starting point before enrichment APIs enter the picture.

Which APIs actually resolve personal emails to company identity

There are three approaches that work, each with real tradeoffs.

Approach 1: Graph-based reverse lookup

Datagma is the tool I keep coming back to for this. Their /enrich endpoint accepts a personal email, cross-references it against social graph data — primarily LinkedIn activity, public profiles, and email correlation patterns — and returns a company match with title, seniority, and LinkedIn URL. In my testing across 500 Gmail signups from a fintech tool, Datagma resolved 41% to a confident company match, nearly double what PDL returned on the same set.

PDL still earns a place in the stack because its depth on resolved matches is better — when PDL knows the answer, the data is richer. I run Datagma first, then fall through to PDL for the misses.

Approach 2: Name + self-reported data triangulation

If your onboarding flow asks for a job title and company name (even optionally), you can join that self-reported data against enrichment APIs to validate and expand it. Clay is designed for exactly this — you set up a table that takes {name, company_name} and waterfalls across 10+ sources to build the firmographic profile. The limitation: you're depending on users self-reporting accurately, which happens less than you'd expect for optional fields.

Approach 3: LinkedIn URL matching

If you can get a LinkedIn profile URL — through OAuth login, a "connect LinkedIn" optional step in onboarding, or by prompting users to enter it — you bypass the personal email problem entirely. RocketReach and PDL both accept LinkedIn URLs directly and return full firmographic profiles at 85%+ match rates.

Some teams use Phantombuster to automate LinkedIn outreach to unresolved users. I don't recommend this — it violates LinkedIn's ToS and creates legal exposure faster than it creates pipeline.

Comparing enrichment APIs on personal email resolution

Provider	Gmail hit rate	Fields returned	Avg latency	Price per call
Datagma	~41%	Name, title, company, LinkedIn, seniority	800ms	~$0.04
PDL	~32%	100+ fields on match	400ms	$0.05–$0.10
Clearbit	~8%	Deep firmographic on match	200ms	$0.08
Clay waterfall	~55%*	Composite, varies by source	3–8s	$0.15–$0.40
RocketReach	~18%	Name, title, company, email	600ms	$0.06

*Clay's higher rate comes from combining multiple providers — you're paying for 2–3 API calls per resolution.

Hit rates measured across 500+ Gmail signups per provider. Numbers will vary based on your user base demographics.

Building the scoring formula

Once enrichment comes back — or a best-effort partial match — you need a score. Here's the model I use for most PLG B2B tools:

Identity score (0–40 points)

Company size 50–500 employees: +20
Company size 500+: +15 (larger isn't always better — enterprise sales cycles can kill PLG deals)
Title matches your buyer persona (e.g., "engineer", "developer" for dev tools; "head of", "director", "VP" for business software): +10
Industry match against ICP list: +10
Enrichment confidence below 60%: −10

Engagement score (0–40 points)

Activation event fired: +25
Invited ≥1 teammate: +10
Used product on 3+ distinct days in week 1: +5

Expansion signal (0–20 points)

Hit a hard limit at least once: +10
Viewed pricing page: +5
Started upgrade flow (even if abandoned): +5

Total ≥ 60: route to sales. Total 35–59: high-touch nurture. Total < 35: self-serve nurture only.

Calibrate these weights against your own historical conversion data after the first 90 days of running the pipeline. The weights above are starting points, not gospel.

The webhook trigger that hands off to sales

The cleanest implementation: Segment as the event bus, a serverless function (Vercel or AWS Lambda) doing enrichment and scoring, then pushing a qualified lead into HubSpot or Salesforce with the score attached.

The trigger event is whatever you define as your activation moment — not "signed up," but the first event that proves the user got value. For a data tool, it might be query_executed. For a collaboration product, first_team_invite. For a file tool, first_export.

Segment event → Lambda
  → Datagma enrich (personal email)
  → PDL fallback if no match
  → Score calculation
  → If score ≥ 60: POST to CRM, set owner = SDR queue
  → If score 35–59: trigger nurture sequence

The latency on this full chain runs 1.5–3 seconds end-to-end, fast enough to fire before the user finishes their onboarding flow. Some teams surface a "your account manager will reach out" message in-app immediately after the score threshold is hit — which works well when the user's in the product and receptive.

Clay can replace the Lambda and API chain if you'd rather avoid custom code. You set up a Clay table as the enrichment layer, trigger it from Segment via webhook, and it handles the waterfall and CRM push without writing a function. The tradeoff: less control over scoring logic and higher cost per enriched contact.

What I actually use

For teams just starting out with PLG enrichment: Datagma as the primary personal email resolver, PDL as fallback, Segment as the event bus, Mixpanel for behavioral event storage (the SQL explorer makes it easy to export activation cohorts for offline scoring analysis without touching production code), and whatever CRM you already have.

Don't use Clearbit as your first call on personal emails — the hit rate doesn't justify the cost at that step, though it's excellent for work email enrichment downstream once you've resolved a user's company identity.

If you're doing more than 5,000 enrichment calls per month, Clay starts to make sense as a no-code orchestration layer, especially if your ops team prefers spreadsheet-style tooling to writing Lambda functions. The per-credit cost is higher, but you save on engineering time.

Skip ZoomInfo for this use case. It's enterprise-contract priced, built for outbound prospecting from company lists, and adds zero value for personal email resolution. Same story with Lusha — excellent for Chrome extension-style lookups starting from a LinkedIn profile, wrong tool for an automated inbound pipeline.

The honest ceiling: even with the best waterfall stack, you'll resolve 45–55% of personal email signups to confident company matches. The other half you're scoring on behavioral data alone. That's not a tooling problem — it's a data reality. Design your scoring model to handle the no-enrichment case gracefully rather than assuming every user will resolve cleanly.

Clearbit Is Now HubSpot-Only: A 1-to-1 API Migration Map for Teams Getting Locked Out

Zackrag — Wed, 20 May 2026 06:08:24 +0000

Your GET https://company.clearbit.com/v2/companies/find?domain=example.com started returning 401s sometime in late 2025. If you're here, you either just hit that wall or you got the deprecation notice and have a sprint to plan. Either way, here's the substitution table that every "best alternatives" card-grid article didn't write.

HubSpot acquired Clearbit in November 2023, rebranded it as Breeze Intelligence in mid-2024, and progressively killed standalone API access through 2025. The Logo API sunset December 1, 2025. Enrichment v2 endpoints are on legacy infrastructure with no roadmap. Prospector is dead for new customers. Getting API access today means negotiating an enterprise HubSpot contract — typically six figures annually — whether you use the CRM or not.

The Five Clearbit Endpoints Teams Actually Used

Be precise about which surface you depended on before choosing a replacement:

Company Enrich — GET https://company.clearbit.com/v2/companies/find?domain=example.com
Firmographic data (name, industry, headcount, revenue range, tech stack) by domain.
Person Enrich — GET https://person.clearbit.com/v2/people/find?email=person@company.com
Individual profile (name, title, LinkedIn URL, social handles) by email address.
Combined Enrich — GET https://person.clearbit.com/v2/combined/find?email=person@company.com
Person + company data in one round-trip.
Prospector — GET https://prospector.clearbit.com/v1/people/search?domain=example.com&role=ceo
Find contacts at a target company by role or seniority — the engine behind most outbound workflows.
Reveal — GET https://reveal.clearbit.com/v1/companies/find?ip=1.2.3.4
De-anonymize website visitors by IP address.

The Logo API (GET https://logo.clearbit.com/example.com) is a separate case — replace it with Logo.dev today. It is a single URL string change and requires no authentication.

The 1-to-1 Replacement Table

Clearbit Endpoint	Best Direct Replacement	Replacement API Path	Auth Change	Match Rate Delta
`/v2/companies/find`	PDL	`/v5/company/enrich?website=`	`X-Api-Key` header	~same (+1–2%)
`/v2/companies/find`	Apollo	`/v1/organizations/enrich?domain=`	`X-Api-Key` header	−3%
`/v2/people/find`	PDL	`/v5/person/enrich?email=`	`X-Api-Key` header	+3–5%
`/v2/people/find`	Hunter.io	`/v2/email-enrichment?email=`	`api_key` query param	−5–8%
`/v2/people/find`	RocketReach	`POST /v2/person/lookup`	Bearer token	~same
`/v2/combined/find`	PDL	Two calls: person + company	`X-Api-Key` header	~same
`/v2/combined/find`	Enrichlayer	`/v2/people/profile` (LinkedIn URL)	Bearer token	Varies by data source
`/v1/people/search` (Prospector)	Apollo	`/v1/mixed_people/search`	`X-Api-Key` header	+10–15% more results
`/v1/people/search` (Prospector)	PDL	`/v5/person/search`	`X-Api-Key` header	Larger DB, less curated
`/v1/reveal`	Warmly	JS snippet + webhook	No direct API equiv.	Intent signals included
`/v1/logos`	Logo.dev	`img.logo.dev/[domain]`	None	N/A

Match rate deltas are from my own validation run on ~500 SaaS company records (US/EU/APAC mix) in January 2026. Your mileage will vary by industry and geography.

The Code Diff Is Smaller Than You Think

The authentication pattern changes more than the request shape. Here's the actual diff for the two most common endpoints:

Company Enrich — Before (Clearbit):

import requests

resp = requests.get(
    "https://company.clearbit.com/v2/companies/find",
    params={"domain": "stripe.com"},
    auth=(CLEARBIT_API_KEY, "")  # Basic auth: key as username, empty password
)
company = resp.json()
name = company["name"]
employees = company["metrics"]["employees"]

Company Enrich — After (PDL):

import requests

resp = requests.get(
    "https://api.peopledatalabs.com/v5/company/enrich",
    params={"website": "stripe.com"},
    headers={"X-Api-Key": PDL_API_KEY}
)
company = resp.json()
name = company["display_name"]      # was: company["name"]
employees = company["employee_count"]  # was: company["metrics"]["employees"]

Person Enrich — Before (Clearbit):

resp = requests.get(
    "https://person.clearbit.com/v2/people/find",
    params={"email": "alex@stripe.com"},
    auth=(CLEARBIT_API_KEY, "")
)
person = resp.json()
full_name = person["name"]["fullName"]
title = person["employment"]["title"]
linkedin = person["linkedin"]["handle"]

Person Enrich — After (PDL):

resp = requests.get(
    "https://api.peopledatalabs.com/v5/person/enrich",
    params={"email": "alex@stripe.com"},
    headers={"X-Api-Key": PDL_API_KEY}
)
person = resp.json()
full_name = person["full_name"]         # was: person["name"]["fullName"]
title = person["job_title"]             # was: person["employment"]["title"]
linkedin = person["linkedin_url"]       # was: person["linkedin"]["handle"]

Prospector Replacement — Apollo /v1/mixed_people/search:

resp = requests.post(
    "https://api.apollo.io/v1/mixed_people/search",
    json={
        "organization_domains": ["stripe.com"],
        "person_seniorities": ["c_suite", "vp", "director"],
        "person_titles": ["engineering", "product"],
        "page": 1,
        "per_page": 25
    },
    headers={"X-Api-Key": APOLLO_API_KEY, "Content-Type": "application/json"}
)

Build a thin field-mapping normalizer at the ingestion layer and the rest of your application doesn't need to know which vendor you're using.

Match Rate Reality Check

I validated against 500 records from a SaaS prospect list — mix of US, EU, and APAC companies, 10-person startups through mid-market.

Tool	Company Match Rate	Person Match Rate	Avg Latency
Clearbit (Jan 2024 baseline)	81%	74%	~320ms
PDL	83%	79%	~280ms
Enrichlayer	80%	75%	~310ms
RocketReach	77%	73%	~350ms
Apollo	78%	71%	~410ms
Datagma	71%	68%	~240ms
Hunter.io	74%	66%	~190ms

A few things worth flagging: PDL beats Clearbit's historical rates for US and Western European companies, but drops to ~52% match rate for Japan and South Korea specifically. Apollo underperforms on raw company matching but returns significantly more contacts per domain in Prospector-style queries than Clearbit's Prospector ever did — the tradeoff is more stale titles in the result set. Hunter.io is fast and cheap but shallow: you get title and company reliably, seniority signals and social handles inconsistently.

Rate Limits and Pricing at a Glance

Another thing competitor articles skip: Clearbit had no published rate limit on Enrichment v2, which teams leaned on for real-time enrichment in signup flows. Replacements have explicit limits you need to design around.

Tool	Free Tier	Rate Limit	Entry Paid Tier
PDL	1,000 free credits	100 req/min (default)	~$99/mo for 1K credits
Apollo	50 enrichments/mo	200 req/min	$49/user/mo
Hunter.io	25 req/mo	10 req/sec	$49/mo
RocketReach	5 free lookups	Not published	$53/mo
Datagma	Pay-per-result	300 req/min	~$49/mo
Enrichlayer	10 free credits	300 req/min	Custom

PDL's 100 req/min default is plenty for batch enrichment pipelines but hits the ceiling fast in synchronous signup flows. They'll raise it on request — I got 500 req/min approved within 24 hours on a free account by emailing support with a brief description of the use case.

Prospector Replacement: The Part Everyone Skips

Most migration write-ups focus on enrichment and ignore Prospector. That's where outbound pipelines actually break.

Apollo's /v1/mixed_people/search is the closest behavioral replacement. Filter by organization_domains, person_titles, person_seniorities, and num_org_min_size. Volume is higher than Prospector returned — sometimes 3–4× — but you'll need to tune quality thresholds, because Apollo's database includes more out-of-date role data than Clearbit's was.

For teams that need freshness guarantees on Prospector-style queries, Clay is worth evaluating as an orchestration layer rather than a direct API replacement. It waterfalls multiple enrichment sources, so stale data from one provider gets patched by another. It's not a REST API swap, but the practical result for prospecting workflows beats any single-source provider.

Reveal: The One With No Clean 1-to-1

Clearbit Reveal has no perfect drop-in REST equivalent. The closest current options:

Warmly — JavaScript snippet that sends webhook events when target accounts visit your site. It adds intent signal layers from Bombora and G2 that Clearbit Reveal didn't have. Not a REST API, but functionally better for sales use cases. Budget ~4 hours for a middleware architectural change.
6sense — enterprise-tier Reveal equivalent with rich intent data. Pricing reflects that.
IP info APIs (ipinfo.io, ipapi.co) — return a company name but no enrichment. Fine if you just need "what company is visiting" without any contact context.

If your workflow built Reveal into server-side middleware for real-time enrichment mid-request, the Warmly webhook approach requires a small architectural rethink but gives you more signal than Clearbit did.

What I Actually Use

For company and person enrichment (the /v2/companies/find and /v2/people/find replacement), I've standardized on PDL. Match rates are marginally better for US/EU tech companies, the API is clean, and at $99/month for 1,000 API credits it's dramatically cheaper than what Clearbit was charging before the HubSpot lock-in. The field name changes are annoying once, then you move on.

For prospecting (Prospector replacement), I use Apollo's search API. The free tier is generous enough for development and testing, and the paid tiers make sense above 10K lookups per month.

For Reveal, I switched to Warmly after testing three alternatives. The intent signal layer turned out to be more useful operationally than a bare IP-to-company lookup — I'm getting qualified account alerts with context, not just anonymous company names.

For OSINT-style individual lookups that go beyond standard enrichment — particularly when the use case involves Twitter or Facebook profile data — Ziwa has been faster for me than PDL's direct API, which doesn't cover social profile data as thoroughly. Worth knowing about if social enrichment is part of your workflow.

For logos: Logo.dev. The migration is one URL string change. Don't spend a sprint on this.

The mental model shift that makes the migration easier: Clearbit was a single vendor that handled all five endpoint types reasonably well. The post-HubSpot world means accepting you probably need two vendors — one for enrichment and prospecting, one for Reveal and intent. That's not necessarily a downgrade. The specialists are better than Clearbit was in most individual categories. You just have to stop looking for the one drop-in replacement that covers everything.

From Job Posting to Booked Meeting: A 5-Step Hiring-Signal Prospecting Automation

Zackrag — Tue, 19 May 2026 06:14:46 +0000

Four SDR job postings in two weeks from a mid-market SaaS company. Most sales teams flag it in their CRM and move on. What they miss: those four postings don't just signal a hiring need — they signal an approved headcount budget, a VP of Sales under quota pressure, and a company about to need sequencing software, training, data subscriptions, and CRM seats. That's a buying committee event, and the job board is the press release.

I've been running hiring-signal prospecting for about 18 months. The workflows I see most teams using are broken in the same place: they monitor signals but don't filter them, so reps waste cycles on backfill hires (replacing someone who quit) instead of genuine expansion hires (net-new headcount). That distinction alone dropped my false-positive rate by 61% when I started enforcing it. The second problem is that nobody wires the full pipeline — most automations stop at "generate a list," leaving the enrichment → segmentation → sequencer handoff as a manual step that gets skipped under pressure.

This article covers the end-to-end architecture. Five steps, zero manual handoffs.

Backfill vs. expansion: the filter no one builds

Every article I've read on hiring signals treats them as uniform. They're not. When a company posts one SDR role, it's probably a backfill. When they post three SDRs, a Sales Ops Analyst, and a Sales Enablement Manager within 30 days, that's a department build-out.

Backfill signals:

Single IC hire matching a title the company has hired for before
No adjacent enablement, tooling, or management roles posted alongside it
LinkedIn headcount flat or declining in the same period

Expansion signals:

Three or more roles in the same department within 30 days
New role types appearing (first-ever Sales Ops hire, first RevOps hire)
Leadership hire (VP, Director, Head of) followed by IC roles within 60 days
Company headcount growth >15% quarter-over-quarter on LinkedIn

I operationalize this in n8n: a single IC hire scores 1, a department cluster (3+ same-function roles in a 30-day window) scores 5, a leadership hire followed by a cluster scores 8. Only accounts scoring ≥5 move forward. It sounds arbitrary until you see the data — accounts scoring ≥5 booked at 4.1x the rate of accounts scoring 1–2 across my last two quarters.

Step 1 — Signal monitoring that catches postings before your competitors do

Most teams scrape LinkedIn or Indeed, which introduces a 3–7 day lag. By then, the account is already talking to someone else.

PredictLeads monitors job postings directly from ~50,000 company career pages — not just LinkedIn or Indeed reposts. This matters because mid-market companies often post to their own careers page 5–7 days before syndicating to the boards. PredictLeads also exposes a first_seen_at timestamp and posting velocity, so you can distinguish "4 roles posted in 10 days" from "4 roles spread across 90 days." Those are completely different signals. Coverage also goes back to 2016, which means you can audit a target company's historical hiring patterns before you even build an outreach strategy.

Setup: Connect PredictLeads to n8n via webhook. When a new posting matches your ICP filters (role function + target company list or firmographic criteria), PredictLeads fires an event. n8n receives it and writes to a staging table — not your CRM. Filtering happens here before anything is enriched or sequenced.

Step 2 — Filter out the noise (where most automations break)

Raw PredictLeads events contain role title, department function, seniority level, company ID, and posting date. I run a daily aggregation job in n8n that groups postings by company + department + 30-day window, then applies the scoring logic above.

The step that made the biggest practical difference: cross-referencing LinkedIn headcount delta. Clay can pull a company's current and 90-day-prior headcount from LinkedIn. If a company posted 2 SDR roles but their headcount dropped 8% in the same window, that's almost certainly restructuring — skip it.

In Clay, this looks like a formula column:

IF(linkedin_headcount_90d_delta > 0.05 AND job_cluster_score >= 5, "Active", "Skip")

Only "Active" rows proceed to enrichment. I ran this filter against 500 accounts across three months and found that 34% would have been false positives without it — companies that were actively contracting while simultaneously posting to backfill departures. Without this filter, your reps are burning time on accounts that are reorganizing, not investing.

A second filter worth adding: job description freshness. PredictLeads tracks when postings are taken down. If a role was posted and removed within 7 days without being filled, it was likely frozen — remove the account from the active queue until a new cluster appears.

Step 3 — Enrich and find the right contact

Once an account passes the filter, I need three things: the right contact title, a verified email, and a LinkedIn URL. Clay handles this with a waterfall: tries Apollo first, then People Data Labs, then Hunter.io, stopping when it lands a verified result.

The key is matching the contact title to the signal type — not defaulting to CEO. A VP of Sales hire plus SDR cluster means the buyer is the CRO or VP of Sales. A Head of Data hire plus 3 data engineering roles means the buyer is the Head of Data or VP Engineering. I have about 12 signal-type → title combos pre-built in Clay as "find person" columns with priority title lists. This eliminates the generic CEO fallback that most templates use and that tanks reply rates in mid-market accounts where the CEO isn't touching tooling decisions.

Enrichment runs in about 15–30 seconds per account. Output: verified email (~82% match rate across my target segments), LinkedIn URL, and direct phone where available.

Step 4 — Segment by urgency before the sequencer sees it

Not all qualifying accounts deserve the same treatment. An account that posted 7 roles in 10 days with a VP hire is not the same as one that posted 3 roles over 28 days.

Track	Criteria	Sequence type
Hot	Score ≥8, cluster posted within 7 days	3-touch: day 1/3/7, manual call day 3
Warm	Score 5–7, cluster posted 8–30 days ago	5-touch: day 1/4/8/14/21, automated only

Hot accounts: n8n pushes them to CRM immediately with a Slack alert to the account owner. Warm accounts: queue into Instantly as a bulk upload. The segmentation field lives in Clay and drives the branch logic in n8n — one field, two completely different downstream paths.

Timing matters more than you'd expect. I tested reaching out to Hot accounts within 24 hours of the cluster forming versus 48 hours — reply rate dropped from 14.3% to 9.1%. The window is real.

Step 5 — Sequencer handoff with signal-native personalization

The signal is the personalization. I don't write bespoke first lines for every account — I write signal templates with merge fields.

Template for "VP Sales hire + SDR cluster":

Saw [company] just added [X] SDR roles around [VP name]'s hire as VP of Sales — congrats on the build-out. When you're standing up that team, [specific pain point] usually bites around week 6. Happy to share how we handled it.

[X], [company], and [VP name] come directly from the enrichment payload. n8n assembles the personalized first line using a string template before the payload hits Instantly's API. No LLM required at this stage — template precision beats generated prose for signal-triggered outreach because the signal context is already inherently specific.

Results from my last 90-day cohort: 14.3% reply rate on Hot accounts, 6.1% on Warm, against a 2.4% baseline for non-signal-triggered sequences to the same personas. Meeting-booked rate on Hot: 4.1%.

Signal source comparison

Tool	Coverage	Update lag	Backfill history	Approx. cost
PredictLeads	50K+ career pages direct	Hours	2yr history	~$400/mo
Apollo	LinkedIn + major boards	24–48hr	Limited	Included in Apollo plan
Clay	Aggregates 75+ sources	Source-dependent	Partial	~$250+/mo (credits)
Phantombuster	LinkedIn only	Manual/scheduled	No	~$70/mo
Native LinkedIn	LinkedIn only	Live	No	Recruiter plan required

PredictLeads is the only purpose-built option here. The others surface job data as one signal among many — useful as enrichment layers, weak as primary monitors. The 2-year historical backfill is also a meaningful differentiator: you can audit a company's hiring cadence to understand whether their current cluster is normal seasonal activity or a genuine inflection.

What I actually use

For signal monitoring: PredictLeads webhook → n8n. Nothing else gets close on posting velocity accuracy or career-page coverage.

For enrichment waterfall: Clay with Apollo → People Data Labs → Hunter.io cascade. When a hiring signal points to a specific named person — a VP who just joined and is publicly announced on LinkedIn — I use Ziwa to pull their LinkedIn profile data directly. It's faster for name-based lookups than running the full Clay waterfall and meaningfully cheaper per credit in that narrow use case.

For sequencing: Instantly for Warm track, manual-plus-automated hybrid for Hot.

For orchestration: n8n. I've evaluated running the whole pipeline inside Clay but found n8n more controllable for branching and filtering logic. Clay is better as an enrichment layer than as a complete workflow engine.

Total stack cost: ~$750/month. Weekly throughput: 300–400 signal events, with about 30 minutes of human attention on Monday mornings to review queue anomalies. The backfill filter is non-negotiable — without it, you're targeting companies that are contracting, not growing, and your reply rates will tell you exactly that within a week.

The Phone Enrichment Waterfall: How to Stack Providers to Hit 85%+ Mobile Direct Dial Coverage

Zackrag — Mon, 18 May 2026 06:05:26 +0000

I ran our SDR team's call list through Cognism alone for six months. Hit rate on mobile direct dials: 34%. Then I built a 4-provider waterfall. Same list type, same ICP, three months later: 81%.

That 47-point gap is money. At 50 dials per day per rep, the difference between 34% and 81% connect-readiness means your team either leaves messages for ghosts or actually talks to people.

The frustrating part? Every article comparing phone enrichment tools treats them as alternatives. You pick one. But that framing is wrong — these databases don't overlap the way you'd expect, and stacking them in the right order is what actually moves the number.

Why a Single Provider Caps Out

Every phone data provider has coverage sweet spots:

Cognism's Diamond Data is strong in EMEA and human-verified — but US SMB coverage is thinner than the pitch deck suggests
Apollo covers US companies well, especially tech and SaaS, but mobile numbers (vs. direct dials) degrade fast outside major metros
Lusha is consistently good for VP-level and above in North America; hit rate drops sharply below director title
People Data Labs (PDL) has the deepest raw record count but ships whatever's in the database — verified or not

None of them is lying. They have different coverage shapes. When you run one provider against 500 contacts, you're leaving the other 60-65% of reachable records blank.

The Cascade Architecture (Order Matters)

The sequence in which you query providers is not arbitrary. Get it wrong and you're burning credits on a provider that would have caught the record anyway with a cheaper call.

Here's the ordering I landed on after testing across ~3,000 contacts over four months:

Tier 1: Cognism Diamond
Query first for any contact in EMEA or senior IC/director+ roles at companies over 200 employees. Cognism's human-verified numbers have a materially lower wrong-number rate than unverified databases — you pay more per credit, but you waste fewer dials on dead numbers.

Tier 2: Apollo
Fire next for any contact where Cognism returned nothing, plus all US-based contacts regardless of Cognism's result. Apollo's coverage of US SMB and mid-market is strong, and at its price point you can afford to check it broadly.

Tier 3: Lusha
Run on any VP-and-above contact where neither Tier 1 nor Tier 2 returned a mobile number. Lusha tends to have distinct sourcing from Apollo for senior titles — it regularly surfaces numbers Apollo misses at the C-suite level.

Tier 4: PDL as Fallback
PDL's bulk API is cheap per lookup. Use it as a final pass on everything that fell through. Treat any PDL-sourced number as unverified and route it to a validation step before dialing.

What Triggers the Next Provider (Cutoff Logic)

The cascade only fires the next tier when the current one returns nothing or returns a number flagged as low-confidence. Here's the decision logic:

IF cognism_phone IS NOT NULL AND cognism_verified = true → STOP
ELSE IF apollo_phone IS NOT NULL → STOP
ELSE IF lusha_phone IS NOT NULL AND seniority >= 'VP' → STOP
ELSE → pdl_phone (mark as unverified, route to validation)

Two things that matter here:

Don't short-circuit to the cheapest provider first. I tried starting with PDL to minimize upfront credit spend. The problem: lower-precision providers produce more wrong numbers, so your reps burn dial attempts on ghosts. The cost of a wasted dial (rep time, sequence disruption, prospect impression) is higher than the credit cost delta between Cognism and Apollo.

Validate PDL numbers before they reach a dialer. ZeroBounce and NeverBounce both do phone validation. ZeroBounce is cheaper per unit for batch runs. Route all PDL-sourced numbers through a validation step — bad numbers from an unverified database will tank your connect rate and flag your caller ID as spam faster than you'd expect.

The Cost Math Nobody Publishes

Here's what the cascade actually costs per found number at realistic hit rates from our data:

Provider	Cost/lookup	Hit rate (our data)	Cost/found number
Cognism Diamond	~$0.45	38% of total list	~$1.18
Apollo	~$0.08	29% of remaining	~$0.28
Lusha	~$0.18	22% of remaining VP+	~$0.82
PDL	~$0.02	14% of remaining	~$0.14

Running all four tiers on 1,000 contacts:

Cognism (all 1,000): $450 → 380 numbers found
Apollo (remaining 620): $49.60 → 180 more numbers
Lusha (VP+ subset of remaining ~220, so ~80 contacts): $14.40 → 18 more numbers
PDL (remaining 422): $8.44 → 59 more numbers (pre-validation)

Total: ~$522 for ~637 numbers → $0.82 per found number

Apollo alone on 1,000 contacts: ~$80 for ~290 numbers → $0.28 per found number.

Apollo is cheaper per found number. So why use the waterfall?

Because the 637 numbers from the waterfall cover contacts Apollo never would have found at all. The 347 additional numbers you surface via Cognism, Lusha, and PDL exist nowhere in Apollo's database. Coverage is the point — you're not replacing Apollo, you're filling in the 71% it misses.

Building the Waterfall in Clay

Clay makes this genuinely straightforward. The setup:

Create a Table, import your contact list
Add enrichment column → select Cognism; condition: run only if phone_number is empty
Add another enrichment column → select Apollo → condition: run only if previous column is empty
Add Lusha column → condition: previous empty AND seniority ∈ {VP, SVP, C-suite}
Add PDL column → condition: previous still empty
Add a phone_validated column using ZeroBounce integration, filtered to PDL-sourced rows only

The critical Clay setting: in each enrichment step, check "Only run if previous column is empty." This is what creates the cascade instead of running all four providers in parallel — which would multiply your credit spend by 4x with no coverage benefit.

Export cadence: for lists under 500, I run the whole cascade at once. Above that, I batch in 200-row chunks to stay within Cognism's rate limits.

Building It in n8n

If you're on n8n, the same logic expressed as a branching workflow:

HTTP Request node → Cognism API phone lookup
IF node: cognism.phone is not empty → route to CRM push
HTTP Request node → Apollo API
IF node: apollo.phone is not empty → route to CRM push
HTTP Request node → Lusha API (filter: only if seniority ≥ VP)
IF node: lusha.phone is not empty → route to CRM push
HTTP Request node → PDL API
HTTP Request node → ZeroBounce validation (PDL numbers only)
Set node: tag phone source on each contact record

Tagging the source matters. After 30 days you'll have empirical data on which tier is hitting for which segment of your ICP — and you can adjust ordering or skip tiers accordingly. The cascade architecture I described is a starting point, not a permanent configuration.

Provider Coverage by Segment

Provider	EMEA	US SMB	US Enterprise	Verified	API	Approx. cost
Cognism	★★★★★	★★★	★★★★	Yes (Diamond)	Yes	$$$
Apollo	★★★	★★★★★	★★★★	Partial	Yes	$
Lusha	★★★	★★★	★★★★	Partial	Yes	$$
PDL	★★★	★★★★	★★★	No	Yes	$
RocketReach	★★★	★★★	★★★	No	Yes	$$
Wiza	★★	★★★★	★★★	Partial	Yes	$$

What I Actually Use

For most mid-market prospecting lists (US-heavy, SaaS/tech ICP, director-to-VP seniority), the Cognism → Apollo → Lusha → PDL stack in Clay consistently lands between 78-83% of contacts with at least one phone number. That's the range I've seen across different client lists over the past several months.

Honest caveat: that 81% opening number came from a list skewed toward US enterprise with high VP+ density — exactly where this stack performs best. For lists heavy on individual contributors in Europe, the hit rate drops to the high 50s unless you lead with Cognism more aggressively and accept the higher per-unit cost.

Wiza is worth testing if your contacts are LinkedIn-sourced — it pulls numbers at the point of LinkedIn profile lookup, which can catch records that have decayed in static databases. I haven't stacked it into a persistent waterfall yet, but it's worth a controlled test against your specific ICP.

For phone validation on PDL-sourced numbers, ZeroBounce is my default for batch runs. NeverBounce has a better UI but equivalent accuracy in my experience — pick based on your existing integrations.

The goal isn't 100% coverage — it doesn't exist. The goal is knowing your actual hit rate by tier so you can stop guessing why your connect rate is stuck and start tuning the variables you can control.

How to Use Tech Stack Data for B2B Prospecting Cost Reduction: A Pre-Enrichment Filter That Cut My Clay Spend by 42%

Zackrag — Fri, 15 May 2026 11:23:25 +0000

I ran 500 target accounts through a Clay enrichment workflow last quarter and watched $340 evaporate on contacts that had zero chance of converting — companies running legacy on-prem stacks with no appetite for SaaS tooling, enriched in full because I hadn't filtered upstream. That mistake taught me the most useful cost-reduction move in B2B prospecting isn't negotiating better API pricing. It's deciding which accounts never enter the enrichment pipeline in the first place.

Tech stack data from BuiltWith and Wappalyzer is cheap or free. PDL and Clay credits are not. The workflow I'm going to walk through reduced my enrichment spend by ~42% over 90 days without touching my ICP definition or removing a single genuinely qualified account.

Why Enrichment Costs Spiral Before You Notice

Clay's per-row pricing sounds manageable at $0.006–$0.012 per credit until you realize a single contact enrichment waterfall — pulling company data, finding work email, validating it, and appending LinkedIn — burns 8–15 credits per row. At PDL's individual API pricing, a successful person match costs $0.10–$0.15. Run 3,000 accounts through that and you've spent $300–$450 before a single reply.

The problem isn't the unit cost. It's that most teams enrich indiscriminately. They pull a list from Apollo or a LinkedIn Sales Navigator export, dump it into Clay, and let the waterfall rip. Nobody stops to ask: does this company actually use the category of software we're replacing or integrating with?

For tech stack data B2B prospecting cost reduction, the intervention point is before the Clay table. Not inside it.

Pulling Tech Stack Signals from BuiltWith and Wappalyzer

BuiltWith is the more complete option for programmatic access. Their API costs $295/month on the lowest paid tier, but the Lookup API returns the full detected tech stack for any domain in one call. For a one-time pull on a defined account list, you can also export from their List Builder UI without touching the API.

Wappalyzer has a free browser extension that detects stack signals one site at a time — useful for manual qualification — plus a paid API at around $250/month with a 500-lookup free trial. Their data skews toward frontend and analytics tech, where BuiltWith catches more backend signals (CDNs, payment processors, CRM embeds).

For a list under 2,000 accounts, I use Wappalyzer's trial credits combined with a Phantombuster scraper for batch domain lookups. For anything larger, BuiltWith's Lookup API is worth the monthly spend because one month of BuiltWith ($295) offsets far more than that in prevented Clay/PDL spend.

Here's a minimal Python snippet to hit the BuiltWith API and parse tech categories:

import requests

def get_tech_stack(domain, api_key):
    url = f"https://api.builtwith.com/v21/api.json?KEY={api_key}&LOOKUP={domain}"
    response = requests.get(url).json()
    techs = []
    for result in response.get("Results", []):
        for path in result.get("Result", {}).get("Paths", []):
            for tech in path.get("Technologies", []):
                techs.append({
                    "name": tech.get("Name"),
                    "category": tech.get("Tag"),
                    "first_detected": tech.get("FirstDetected")
                })
    return techs

The Tag field is what you filter on — values like "crm", "marketing-automation", "analytics", "payment-processing". That's your ICP-fit signal.

The Filtering Logic in Google Sheets or Airtable

Once you've pulled tech stack data for your account list, structure it as one row per domain with boolean columns for each relevant tech category. In Google Sheets this looks like:

Domain	Has_CRM	CRM_Name	Has_Marketing_Auto	Has_Analytics	ICP_Fit
acmecorp.com	TRUE	HubSpot	TRUE	TRUE	YES
widgets.io	FALSE	—	FALSE	TRUE	NO
techventures.co	TRUE	Salesforce	FALSE	FALSE	MAYBE
buildfast.dev	TRUE	Pipedrive	TRUE	TRUE	YES
oldschool.net	FALSE	—	FALSE	FALSE	NO

The ICP_Fit column is where your scoring logic lives. For a CRM integration tool, my filter looks like: IF(Has_CRM=TRUE AND Has_Marketing_Auto=TRUE, "YES", IF(Has_CRM=TRUE, "MAYBE", "NO")). Only YES rows enter Clay. MAYBE rows go into a cheaper shallow-enrichment pass first (just company data, no contact lookup). NO rows get archived.

In Airtable, you do the same thing with a formula field and a view filter — show only records where ICP_Fit = "YES". That filtered view is what you connect to Clay via the Airtable integration.

The filtering step costs you roughly 20 minutes of formula setup and zero additional API spend beyond the BuiltWith/Wappalyzer pull.

The Cost Math on 3,000 Accounts

Here's the actual comparison I ran, with real numbers:

Scenario	Accounts Enriched	Clay Credits Used (avg 10/row)	PDL Matches (est. 70% match rate)	Estimated Spend
No pre-filter	3,000	30,000	2,100 @ $0.12	$180 Clay + $252 PDL = $432
With tech stack filter (42% eliminated)	1,740	17,400	1,218 @ $0.12	$104 Clay + $146 PDL = $250
Savings	—	12,600 credits	882 contacts	$182 saved per run

Clay credit pricing above uses their mid-tier estimate. PDL pricing uses their individual API rate. Your exact numbers shift based on your plan, but the ratio holds: filtering out 42% of accounts before enrichment produces roughly 40–42% cost reduction. That's not a projection — that was my actual Q3 result on a 3,000-account pull targeting marketing ops teams.

The 42% elimination rate came from filtering on HubSpot, Marketo, Pardot, or ActiveCampaign presence. Companies with none of those signals don't buy marketing automation add-ons. Simple logic, but you have to check it before you enrich, not after.

The other angle competing articles miss entirely: tech stack data also tells you which contacts to prioritize inside qualifying accounts. If BuiltWith shows a company added Segment three months ago, the data engineering hire or growth PM who drove that decision is far more likely to respond than a cold VP outreach. That signal sharpens your contact selection inside Clay, which reduces the number of contacts you enrich per account — another cost lever.

What I Actually Use

My current stack for this workflow, honest assessment:

BuiltWith API — primary tech signal source for accounts over 500. Worth the $295/month when you're running this regularly. Their data freshness on enterprise domains is better than Wappalyzer's.

Wappalyzer free tier + Phantombuster — for smaller one-off pulls or when I want a second signal source to cross-reference. Phantombuster's web scraper automation runs the Wappalyzer extension headlessly at about 200 lookups/hour.

Google Sheets — filtering logic lives here. I've tried Airtable and it's fine, but Sheets is faster for the formula iteration when you're tuning ICP-fit criteria.

Clay — enrichment waterfall for qualifying accounts only. I use Hunter.io as the first email-finding step inside Clay because Hunter's domain search is cheaper per credit than Clay's native email finder. PDL fills gaps for contacts Hunter misses.

Apollo — initial list-building before tech stack filtering. Export domains, run BuiltWith, filter, then re-import qualifying domains into Clay. Apollo's built-in technographic filters exist but they're blunt and not granular enough for the filtering logic I need.

Ziwa — worth testing if you want a combined signal-plus-enrichment approach rather than assembling this pipeline yourself. I haven't moved my primary workflow there yet, but it's one of the cleaner options for teams who don't want to manage the BuiltWith/Clay handoff manually.

The workflow isn't complicated. Pull cheap signals first, pay for expensive enrichment only on accounts that pass. The tooling is almost beside the point — the discipline of filtering before enriching is where the savings come from.