Personalization gets written as a research problem. Find something true about the person, put it in the first line, and the message earns a reply. The part that decides the outcome comes later: whether the thing you found is still true at the moment they read it.
We run outbound as an operator, on our own profiles and on client campaigns, and every message we send carries one fact with a named source. Between 1 July and 9 September 2026 we sourced 4,887 people and put 2,088 of them into a first touch. This article covers what we measured about the shelf life of a personalized fact, which sources hold up, and the checks that keep a compliment from turning into an apology.
The fact is about four days old when they read it
There is a gap between the moment a fact enters your notes and the moment it lands in someone's inbox. Sourcing runs on one day, enrichment on another, the sending queue paces itself across the week, and the platform sets its own ceiling on daily volume. Nobody plans that gap. It appears on its own.
We measured it on 839 first touches where we hold both timestamps, capture and delivery. The median fact was 3.6 days old on arrival. Three quarters of them were 4.5 days old or more, the top tenth crossed six days, and 23 landed more than a week after we wrote them down. Put another way, 524 of those 839 messages described something we had checked at least three days earlier.
Four days is survivable for most claims and lethal for a few. A funding round from last month reads the same on Tuesday and on Friday. A job opening can close in that window. A person can change employers in that window, and the platform will show the new logo while your note still praises the old one.
So we sort facts by how fast they spoil before deciding which one goes in the message. Anything about a person's current role counts as perishable. Their history, their published work and their company's product stay usable for months.
A claim becomes a fact when it carries its source
Of the 4,887 people we sourced, 2,860 carried both a fact and a named source: the page it came from, the system that returned it, and the date it was read. Another 1,969 carried neither. Almost none of the second group ever received a message, because the gate that fills the sending queue reads the source field and drops the row when it is empty. Fifty six of them slipped through, out of 2,088 touches.
That rule started as a sentence in our own handbook and stayed decorative for a while. It became real the day a lead asked where we had seen the thing we quoted, and the answer was missing from our records. On that day eleven of twenty messages in the outgoing log opened with a version of "saw that you", and none of the eleven stored a link. The rule now lives in the schema: the queue has a column for the source, and a row without one stays put.
Two things follow from writing the source down. Any claim in the message can be defended when the person pushes back, which happens more often than the reply-rate charts suggest. And the whole batch becomes auditable after the fact, so a bad source can be traced across every message it touched in a single pass.
Of 597 candidates we dropped in the same ten weeks, 80 went for a missing or thin fact and another 111 for an employer or a role we could not confirm against a live source. Those 191 people were reachable, in segment, and one sentence away from a message. The sentence would have been a guess.
Facts about the present decay, facts about the past hold
Role facts are the most tempting material for personalization and the fastest to spoil. They also produce the worst failure mode, because getting one wrong tells the reader exactly how the message was made.
We check employer records against a second live source whenever a message is about to quote a current role. Across 302 such checks, 284 confirmed and 18 came back wrong, close to one in seventeen. Every one of those 18 would have shipped a sentence congratulating somebody on a job they had left.
We know the shape of the failure because we shipped it. Two replies in one week from the same campaign were corrections rather than conversations. One asked whether we were sure about the title or would like to double check that the position was still current. The other said we were probably the sixth or seventh person that year to get it wrong. A stale database punishes everybody who reads from it, and the person on the other end has learned to spot the pattern.
The rule we run now: for anything about a current role, the only acceptable source is the person's own profile read live, at a timestamp we store. Database records are excellent for choosing who belongs in a segment and unreliable as a quotation. Facts about the past, a career path, a talk, a shipped product, hold their value for months.
Hiring facts sit in the same category and deserve their own check. When we compared a large database's hiring filter against the company's own careers page, the company page disagreed seven times out of seven: some had closed the roles, some had posted them months before the crawl date the database reported.
The source of the fact matters less than its freshness
We expected the origin of the fact to move the numbers. Sorted by where the fact came from, the acceptance rates land within a few points of each other:
| Where the fact came from | People | First touches | Accepted |
|---|---|---|---|
| Live profile read | 1,029 | 676 | 127 (18.8%) |
| Their own post or reaction | 686 | 514 | 102 (19.8%) |
| The company's own job board | 268 | 190 | 42 (22.1%) |
| A contact database record | 202 | 152 | 27 (17.8%) |
At these volumes those gaps are noise. The reply counts sit between three and fifteen per family, which decides nothing. We publish them because the honest read is useful: the origin of a fact earns you very little on its own, and the effort belongs on the freshness check instead.
One slice does separate, and it separates on recency. When we sourced people from a public action taken in the previous few days, someone reacting to or commenting on a post in our market, 68 of them reached a first touch, 20 accepted (29%) and 7 replied (10%). Compare that with database sourcing over the same weeks: 1,729 touches, 358 accepted (21%), 39 replied (2.3%). Sixty eight touches is a small sample and the difference is directional. It points the same way as everything above. The fact was hours old, the person had just done the thing we mentioned, and the whole decay problem disappeared.
Templates leak, and the reader can tell
A checkable fact does its work only when the sentence around it was built for one person. We audit our own outgoing drafts against that standard, and the numbers are humbling. Across 634 drafts checked for template assembly, 333 came back flagged, over half. Across 1,866 drafts checked for text that had already gone to somebody else, 160 matched.
The common shape is a fact slotted into a fixed frame: an opener, a variable, a pitch line, a closing question that appears in every message. The variable is genuinely researched. The frame around it is what gets read, and one person forwarding a message to a colleague is enough to expose it.
We also mark prepared messages that sat in the pool too long. In this window, 495 first messages were flagged as stale before they were ever sent, then rewritten. Writing text in advance is efficient. Writing it in advance and shipping it unread three weeks later is how a good fact becomes an embarrassing one.
What to do with this tomorrow
Take your current sending queue and add a column for the date each fact was checked and the page it came from. Then sort the queue by that date. Whatever sits at the bottom, older than four or five days and describing somebody's current job, deserves a live look before it goes out. That single sort will find your role-change misfires before your prospects do.
After that, split your facts into perishable and durable, and write the rule down: current role, open positions and anything with a date belong to the live check; career history, published work and company products can be researched once and used for months.
This is the discipline behind everything we run for clients at the managed levels, and it is available directly through our MCP access, where your own model reads the same sourcing stack we use and stores the source alongside every fact it finds.