Every list vendor sells the same premise: filter by a trigger event, write to the company while the event is warm, get a better reply rate. The premise is testable, so we tested it on our own pipeline, and the results are less flattering to trigger events than the sales page for one. Below are the numbers with their denominators, the mechanical reason the most popular signal decays, and the one measurement that tells you when a list has been picked clean. All of it is reproducible on your own data by Friday.
What four signals actually returned
We tag every batch with exactly one signal type and one segment, so the funnel can be sliced later. Here is the invitation-to-connection stage across all sending profiles, counting only invitations old enough to judge, which for us means at least five days old:
- plain profile filter, no event at all: 81 connections from 459 invitations, 17.6%
- person recently in a new role: 22 from 120, 18.3%
- company has an open role that implies our buyer's pain: 29 from 216, 13.4%
- a property or lease event on a known horizon: 6 from 40, 15.0%
The third line is the one everyone buys. The hiring signal, the most widely resold trigger in B2B data, came in below the control group that ran on no trigger at all.
Now the honest part. On 216 invitations, a rate of 13.4% carries a standard error of about 2.3 points, and the 17.6% on 459 carries about 1.8. The gap between them is roughly one and a half standard errors, which sits inside the noise band. So the fair conclusion is narrow: at this sample, the hiring filter has yet to show any premium over a well-built profile filter, and it costs real money and real enrichment credits to run. That is enough to change what you buy, and it is short of proving the signal is worthless.
One stage further: across 165 accepted connections, 23 people wrote back, 13.9%, and the replies came from all four groups.
The date on a hiring signal is usually a crawl date
Once the hiring numbers came in soft, the question became mechanical: is the signal real when it reaches us?
We checked candidates against the source that has authority over the fact, which is the company's own careers page and its applicant tracking system. On one batch, a company was flagged as having opened a business development role on 14 July. Its own hiring system returned a publish date in January, so the role had been sitting there for close to six months. A second case was milder: a role sold to us as under four weeks old had been live for 29 days.
The mechanism fits both cases: the date in a resold hiring field is often the date the crawler saw the posting, and a crawler sees a page whenever it visits, including on the two hundredth day the page has existed.
That matters for copy more than for targeting. An opener built on freshness ("saw you just opened this role") gets checked by the one person guaranteed to know, the person who posted the role. A stale claim in the first sentence spends the whole message.
Two things follow, and both are cheap:
- Verify at the source, or drop the time claim. Where a company runs a public hiring board, the publish date is right there in its feed. Where it does not, write the fact without a clock on it.
- Measure how often verification is even possible in your segment before you plan around it. Across 12 candidate domains in one segment, a public board existed for 5, and a live sales role posted within the last 45 days existed for 2. In another segment we checked about 60 domains: 14 had a public board, and all 14 sat in the same vertical, technology outsourcing. The neighbouring vertical, business process outsourcing, returned a public board zero times out of the dozen we sampled by hand.
So the workable version of the hiring signal belongs to a segment rather than to the market. Where a vertical publishes its own boards, run the signal from the board towards the people, and the fact holds up roughly whenever the board exists. Where a vertical keeps hiring private, take the fact from the person's own posts or a company announcement, and spend zero hours hunting for boards.
The dedup rate is the health metric for a list
Here is the number that predicts when a source stops producing, and almost nobody logs it.
Our own standard slice is narrow: founder or CEO title, two English-speaking markets, 11 to 50 employees, founded in a fixed window, plus an exclusion list of categories we have learned to skip. It returned 512 people on the last run. We deduplicated the first page against our database of people already touched: 62 of the 80 were already there, so that slice is 78% consumed. Six more fell out because we had already worked a different person at the same company.
A run that scrapes the dregs of a slice looks identical to a run that opens a fresh one. Same tool, same duration, same log line saying leads were found. The only place the difference shows up is the dedup percentage, so make it a reported metric rather than an internal step, and put a threshold on it. Ours: past 70% the slice needs a new source, and the next page of the same one buys a week at most. Page three of any list reads worse than page one, and in our case it drifted into adjacent job titles and unrelated industries.
The same effect showed up on a client segment. After 235 companies there had been touched, a technique that had previously found a public hiring board at one domain in four found two in thirty, with zero live roles inside the window. The collector was healthy, verified against two control domains. The good domains had been used already. A yield figure is a property of a moment in a list, and treating it as a property of the method is how a team keeps running a play for a month after it stopped paying.
Half the work is the fact, and it is the half that gets skipped
A signal picks the company. The sentence that earns a reply is separate work, and it is the work that gets skipped. In our loop, a candidate becomes a lead only when there is one checkable fact about that specific person or company, with a source recorded next to it, and candidates missing one get dropped rather than patched with a template.
We keep the dropped ones on purpose, with a reason code attached at the moment of the decision, because that negative space is unrecoverable afterwards and it is the part of the dataset a competitor cannot buy. Across the last 38 batches, 388 candidates were rejected. Sorted by reason:
- 211 for fit: wrong persona, wrong seniority, wrong size, wrong geography, an excluded industry, a competitor, a company since acquired
- 97 for the fact: nothing checkable to say, the profile had been dormant for months, only reposts, the signal itself was stale
- 53 for duplication: already in our base, already touched at that company, already in a live sequence
- 27 for everything else
Look at the middle line. Roughly one candidate in four passed every targeting filter and was still dropped for the plain reason that there was nothing true and specific to say to that person. Any list vendor would have counted all 388 as matches, and would have been right by their own definition. Buying a bigger list moves the top number and leaves that middle line where it is.
The warmest signal is the one you did not choose
One row in our data outperforms everything above, on a sample small enough to belong in a footnote: people who sent us the connection request themselves. Six inbound requests, accepted by hand, six replies. Six events prove nothing statistically, and the row is still worth building towards, since the intent came from their side and cost zero enrichment credits.
The nearest thing under our own control is the role change signal, which returned the highest accept rate of the four groups above, 18.3% on 120 invitations. The logic is human: somebody eight weeks into a new job is rebuilding a stack, reviewing vendors, and looking for a win they can put their name on. Their inbox is the same size as everyone else's and their appetite is temporarily larger.
That is a fair description of a good signal: it says something about the person's week, and it comes with a short window in which a message lands as timely. Company-level triggers are attractive because they are easy to filter, and easy to filter is exactly why the whole market already has them.
What to do with this tomorrow
Three moves, in the order that gives you the most information per hour spent.
- Put a denominator next to every signal you run. Tag each batch with one signal type, keep the tag through the funnel, and compare cohorts of the same maturity. Under 30 sends or 3 replies in a slice, the difference between two signals is noise, so hold the sample before you act on it.
- Log the dedup rate on every sourcing run and set a threshold. It is a two-minute change and it is the earliest honest warning that a source is finished. Ours is 70%.
- Verify one signal at its source this week. Take ten companies from your last list, open their own hiring pages, and compare the publish date to the date your provider gave you. Whatever the answer, you will know whether your copy can carry a time claim, and that single sentence is doing more work than the filter that found the company.
What stays yours is the fact you check and the negative space you record, and both of those compound. The filters are rented, and everyone renting them has the same ones.
We run this loop as a service: sourcing that reports its own dedup rate, one checkable fact per person, replies handled within a day, and a weekly number with its denominator attached. The tiers are laid out on the levels page, the shape of the work is in the playbooks, and if you would rather point your own assistant at the pipeline and ask it these questions directly, MCP access does that for $500 a month.