AI & Automation

A Signal Decay Model for Sales: Why Stale Intent Pollutes Your Queue

Signals accumulate. Left alone, that is a problem: sum them up with no sense of time and your "hottest" accounts become the ones with the most history, not the most heat. The account that poked around your pricing page eight times last quarter and then went silent outranks the one that visited once this morning. That is exactly backwards, and a decay model is the fix. This is the deep dive on one component of the signal-scoring pipeline: the function that ages each signal so your queue ranks live intent instead of a museum of old behavior.

Why summing signals ranks the wrong accounts

Intent is mostly a function of recency. A pricing visit predicts a conversation in the next few days, not the next few months; by week six it is noise. But a naive score - count the signals, add the weights - has no opinion about when anything happened. So it rewards accounts for having a long history with you, which is often the opposite of buying intent. Some of those long-history accounts looked, decided no, and moved on. They sit at the top of an undecayed queue forever, and your reps burn cycles on cold accounts that merely look busy.

Half-life, not expiry

The clean way to model this is an exponential half-life, the same shape physicists use for decay. Each signal type gets a half-life - the time it takes its value to drop by half - and the score fades smoothly from there instead of falling off a cliff. Rough starting bands: Hours to a couple of days: demo request, trial signup followed by an immediate API call - high-velocity behavior that demands a same-day response. Days: a pricing-page visit, a repeat site session, a docs deep-dive. Weeks: sustained product usage, a support conversation, a review-site action. Months: a job change into a buying role, a new VP hire, a funding round - status changes that stay relevant far longer than a single click.

The math, in one line

A signal's current contribution is its base weight multiplied by one-half raised to the power of its age divided by its half-life. A 10-point signal is worth 10 at zero age, 5 at one half-life, 2.5 at two, and so on - it approaches zero without ever quite reaching it, so nothing disappears on a hard edge. The account's intent score is the sum of those decayed contributions, recomputed on a schedule. That is the whole model. It is a few characters of SQL, and it is the difference between a queue ranked on heat and one ranked on history.

Setting half-lives without guessing

If you have outcome data, fit each half-life to the point where that signal stops correlating with conversion - the age past which a pricing visit no longer predicts a closed deal is your pricing-visit half-life. If you do not have that data yet, start with the bands above and tune as you watch the queue: if dead accounts keep floating up, your half-lives are too long; if genuinely interested accounts drop off before a rep gets to them, too short. The point is to make the assumption explicit and adjustable, not buried in a vendor's black box.

Where this leaves you

Decay is one weight in a larger system, so the place it pays off is downstream: the signal-scoring pipeline reorders its queue as signals age, reps stop chasing stale heat, and your speed-to-lead SLA points at intent that is actually current. GTM OS ships with decay wired into the scoring job, and the Operator Playbook has the skills to scaffold the model into your own warehouse. The model is simple on purpose. The judgment is in the half-lives - and those are yours, not a vendor's default.

Frequently asked questions

What is a signal decay model?

A way of weighting a buying signal by how fresh it is. Each signal type gets a half-life; its score halves every half-life of age, so a pricing visit from today outranks the same visit from six weeks ago. Without decay, your queue ranks accumulated history instead of current intent.

What half-life should each signal use?

Match it to how long the behavior actually predicts action. A demo request decays in hours to a couple of days; a pricing-page visit over days; a job change into a buying role over a couple of months; a funding round over a quarter. Shorter for behaviors that demand a fast response, longer for status changes that stay relevant.

Linear decay or exponential?

Exponential (a half-life curve) for almost everything - it never quite hits zero, so an old signal keeps a small residual weight instead of vanishing on a cliff. Linear or step decay is fine only for signals with a hard expiry, like a time-boxed event registration.

Where does the decay live - the database or the app?

In the scoring query, recomputed on a schedule. Decay is arithmetic over time, so it belongs in SQL next to the rest of the score, not in a model call. It is one component of the larger signal-scoring pipeline.