The date on a signal is not the date of the event

Every buying signal has two dates. There is the moment the thing happened in the world — the job went live, the round was announced, the executive started. And there is the moment a monitoring tool first saw it.

Most products show one date. Some show the first, some show the second, and almost none say which one you are looking at. That sounds like a pedantic distinction. It is not: the whole promise of working from signals is that you arrive while something is still in motion, and a date is the only thing in the record that tells you whether it is.

Two clocks with one label

The two dates answer different questions, and both questions are legitimate.

"When did this happen" is what you need to judge whether a signal is still worth acting on. A role posted in spring and a role posted on Monday are not the same fact, even though both may be sitting in a feed today.

"When did monitoring see it" is what tells you the watch is alive. If nothing has arrived in three weeks, you want to know whether the market went quiet or the pipeline broke.

The problem is not that there are two clocks. The problem is that both are usually printed as a bare date with no label, so the reader supplies the meaning — and the meaning they supply is almost always the first one.

What the confusion costs

Three consequences, in rising order of expense.

You arrive with a reason that has expired. A role that closed two months ago, a round that was announced in spring — cited as though it happened this week. The person on the other end knows their own timeline better than you do, so the mistake is legible to exactly the audience you were trying to impress. It does not read as a data problem. It reads as someone who did not check.

You arrive after the decision has hardened. This is the expensive one, and it is measurable. 6sense's 2025 Buyer Experience Report found that 94% of buying groups have ranked a shortlist before they contact any seller, that four of the five shortlist places are filled on the first day of the process, and that the vendor ranked first wins around 80% of the time. Forrester's 2024 buyers' survey, reported by Digital Commerce 360, puts it from the other side: 92% of buyers begin with a vendor already in mind. A signal that is three months old is not an invitation — it is a notification that the shortlist was drawn without you.

You spend your attention in reverse order. This is the quiet one. If the feed is sorted by a date that means "newest to us", the oldest events on the board drift to the position your eye treats as most urgent. A small team's scarce resource is attention, and this inverts how it is spent — the accounts that genuinely moved this week sit below the accumulated backlog of accounts that moved in spring.

None of the three is a display bug. They are the difference between a list of companies and a list of companies that are doing something, which is the only difference that makes signal-based work worth the effort at all.

What the gap actually looks like

We went looking for the size of this gap in our own data, because we are in a position to check both halves: what a company published, and when our watch picked it up.

Two findings, both stated as proportions because the proportions are the part that transfers to anyone else's data:

• Around nine in ten job postings are already more than a week old at the moment monitoring first encounters them.
• More than four in five news items are too.

The job-posting number sounds alarming until you see the cause, which is arithmetic rather than lag. When you begin watching a company, you do not receive its next posting — you receive its current board. A board is an accumulation: some roles went up last week, others have been open since spring. Averaged across a board, postings have been live about three months by the time a watch first records them.

That is not a delay in noticing. It is the difference between a stock and a flow, and every tool that reads company career pages inherits it. The mistake is not having the backlog; the mistake is displaying it as though it arrived this morning.

The news number has a different cause and a sharper edge. Coverage of an announcement keeps arriving for weeks, and each republication looks exactly as new as the first report did.

Why this hides so well

Here is the part worth knowing whether you build this kind of tooling or buy it.

An empty field does not announce itself. When a system has nowhere to put the event date, the display falls back to the date it does have — the moment of discovery — and produces a confident, precise, plausible answer. Nothing looks broken. The dates are well-formed. A months-old posting rendered with today's date raises no flag at all; it simply reads as urgent.

This is the failure mode that makes date provenance worth auditing rather than assuming. A missing value does not show up as a gap. It shows up as a number that looks like a fact.

We found this in our own feed by going to check it, and it is the reason both clocks now carry labels on the surfaces that show them — each label saying explicitly what it is not, so no reader has to guess which question a date is answering.

When an aggregator restamps a story

The news side produces the sharpest version of the problem, and it is worth a concrete case.

Our monitoring picked up a funding item for the AI coding company Cognition carrying an August date. The round itself was announced on 27 May — by Bloomberg and TechCrunch on the day. What had surfaced was an aggregator rewriting a three-month-old story and stamping it with the date of the rewrite.

Our source check before publication caught it, and the company was dropped from that week's funding roundup. A second case the same week was gentler: a press release from early August resurfaced in a republication ten days later, carrying the later date. That one made the issue, with the real date restored.

Nobody in this chain is lying. An aggregator's publication date genuinely is the date it published. It just is not the date of the event, and once the two are printed identically, nothing downstream can tell them apart. Only a check against the original source can.

That check is why our roundup runs on verified rounds rather than on whatever the feed offers, and why an issue sometimes carries fewer companies than a rounder number would suggest.

What we concluded from it

Four things changed on our side, and all four are the reason this post exists rather than sitting in an internal document.

Both clocks are labelled, and each says what it is not. The event date states that it is not the moment we found it; the discovery date states that it is not the moment it happened. A date with an unstated meaning is where this whole class of error lives, so the label is the fix.

The two questions were separated rather than merged. It is tempting to pick one clock and standardise on it. That is wrong: freshness ranking needs the event date, and "is the watch running" needs the discovery date. Collapsing them would fix a display bug by deleting a real signal.

Anything published gets checked at its original source. The aggregator case above is not rare enough to handle by intuition, so it is handled by procedure.

Published measurements are frozen at their measurement date. Production data moves. Re-running a query to refresh a figure quietly produces a third number matching neither the article nor the original finding, so we publish a new measurement with its own date instead.

What it means for your list

You do not need our data to check any of this. Three tests, in rising order of effort:

1. Open a signal's source link and find the date on the page. Compare it with the date the tool showed you, across ten signals. If they match every time, you are looking at event dates. If they never match, you are looking at discovery dates.
2. Watch what arrives in the first week on a new account. A burst that immediately goes quiet is a backlog surfacing, not a company suddenly becoming active. Judge the account's tempo from week two onward.
3. For news, check whether the link is a first report or a rewrite. Search the headline; if earlier coverage exists, the earlier date is the event.

One caution on what to do with the answer: the consequence is about ordering, not discarding. A posting from spring is still evidence of a plan — our post on reading a job posting like a buyer is about exactly that kind of reading. It is simply not evidence that anything changed this week, and those two belong in different places on your list.

The takeaway is smaller than it looks and matters more. On a signal, the date is not a field attached to the record — it is most of the information the record carries. "A company posted a sales role" is not a signal; every company has posted a sales role at some point. "A company posted a sales role this week" is one. Strip the date of its meaning and what remains is an ordinary list of companies, which is the thing signal-based selling exists to replace. Our post on why timing beats volume covers the research behind that premise; this one is about the single field the premise rests on.

If you want to see how the two-clock version looks in practice, the pricing page sets out what each plan monitors. For the wider map of which signals are worth watching in the first place, our guide to B2B buying signals covers each type and how long it stays useful, and what a funding round actually tells you goes into why the loudest signal type is also the most often misread.