Signal Half-Life: 10-Signal Decay Table + When to Stop

TL;DR: A buying signal has no universal shelf life. Teams should measure an operational expiry window for each signal type using source latency, identity confidence, buyer state, and reviewed outcomes. When a signal expires, stop referencing it as current, re-qualify the record, or move the account into a lower-intensity research path.

What is signal half-life in outbound?

Signal half-life is an operating metaphor for how quickly an observed event loses relevance to a specific outbound decision. It is not a universal scientific constant and it should not be copied from another company without validation. A signal may remain historically true while no longer supporting the same next action.

Recency matters because buyer state changes. A product action may be followed by a reply, a meeting, an opportunity, or inactivity. A company event may be accurate for months but lose relevance to a particular message. An engagement event may be noisy from the start. The policy should evaluate meaning, identity, source latency, and later state together.

Unify | Signals describes first-party engagement, third-party data, and AI-discovered signals in one product surface. The breadth of sources makes a typed recency policy necessary. The page supports using these categories as workflow inputs, not fixed expiry windows for each event.

Why are fixed signal-decay benchmarks unsafe?

A fixed benchmark hides differences in source collection, market, sales cycle, identity, and action. A website visit observed in real time is different from a company event discovered later. A product action tied to a known user is different from an account-level match. The same event can justify a notification but not a personalized claim.

Published response-time research can support the general principle that delays matter. The Harvard Business Review article titled The Short Life of Online Sales Leads studied response behavior for online leads, not a universal half-life for every modern B2B signal. Use it as evidence to measure responsiveness, not as proof of exact expiry periods.

The correct window is the one the team can defend from its own records. Start with a conservative policy, review outcomes and overrides, then revise the window. Keep the policy version attached to the decision so later analysis knows which rule was applied.

Which dimensions determine an expiry window?

Use four dimensions: event meaning, source latency, identity confidence, and decision risk. Event meaning asks what the observation actually proves. Source latency asks how long after the underlying event the system receives it. Identity confidence asks whether the event belongs to the person, account, or an uncertain match. Decision risk asks what the workflow will do with it.

A low-risk research task can tolerate weaker or older context than a message that explicitly references behavior. A seller alert can contain a caveat. An automated sequence needs stricter evidence because it may act without a person reviewing the source.

• Meaning: define the event without adding intent, authority, or urgency that was not observed
• Latency: record both event time and time received when the source provides them
• Identity: distinguish person-level, account-level, inferred, and unresolved matches
• Risk: apply stricter recency to automated buyer-facing actions than to internal research
• Supersession: let replies, meetings, opportunities, customer state, and opt-outs override earlier signals
• Policy version: store the window and rule that governed the decision

How do you create a signal decay policy from your own data?

Choose one signal type and one intended action. Pull reviewed examples with stable event times, source times, action times, outcomes, and disqualifiers. Group records by elapsed time between observation and action, then compare routing quality and buyer-state accuracy. Do not treat reply rate alone as proof that the signal caused the outcome.

Review false positives and false negatives. False positives show where an old or noisy event produced an inappropriate action. False negatives show where an overly narrow window hid useful context. Operators should annotate why each sampled decision was correct or incorrect so the next rule reflects evidence rather than aggregate correlation.

Set a conservative initial window and a lower-intensity path after expiry. The expired path might refresh data, check the CRM, notify the owner, or wait for a new event. It should not continue using language that presents the event as current.

How should events be prioritized when several signals appear?

Do not simply add points. Use precedence. Direct buyer states such as replies, meetings, opt-outs, and active opportunities should govern lower-level engagement. A later verified lifecycle event should supersede an older inferred signal. Multiple weak events may justify research without becoming proof of intent.

A compound rule should explain what changed. For example, a verified product event plus a known account owner may create an owner task. The same product event plus uncertain identity may create a research step. The event is identical, but the safe action differs because the surrounding state differs.

What should happen when a signal expires?

Expiry should change the action, not erase the record. Keep the event as history with its source and timestamp, mark it outside the active decision window, and re-evaluate current lifecycle and ownership. If no new evidence exists, move to research, hold, or a lower-intensity account plan.

Remove language that implies the event is current. A company announcement can remain a factual historical reference, but it should not be presented as a fresh trigger after the team policy considers it stale. A page visit should generally not be named to a prospect unless identity and message policy allow it.

• Refresh: inspect current CRM, identity, and source data before deciding again
• Downgrade: move from automated outreach to research, owner alert, or account monitoring
• Suppress: stop when permission, customer, partner, or opportunity state requires it
• Replace: let a newer verified event become the active context
• Archive: retain the original event for audit without treating it as actionable

How should a Play enforce recency?

The Play should read event time, received time, signal type, source, identity level, current lifecycle, owner, and policy version. It should calculate whether the event is inside the approved window and then choose research, alert, task, sequence, hold, or stop.

Unify Products | Plays describes workflows using signals, qualification, enrichment, AI research, alerts, and sequencing. That structure supports a recency gate before execution. Unify Products | Sequencing describes coordinated channel steps, which should stop when a higher-priority state appears.

Idempotency also matters. A source may send the same event more than once or update it later. Use a stable event identifier and do not restart the active window because a duplicate payload arrived. Only a genuinely new event or corrected authoritative time should change recency.

How do you measure whether the policy works?

Measure decision quality by signal type and elapsed-time band. Useful views include eligible records, held records, expired records, overrides, identity conflicts, duplicate events, replies, meetings, disqualifications, and opportunities. Interpret outcomes as association unless the design supports a causal conclusion.

Unify Products | Analytics describes attributing opportunities to Plays and triggering signals. Preserve signal, Play, policy version, and decision identifiers so teams can review which rule acted. Do not combine unlike signals into one blended benchmark that hides source quality.

Sample losing paths, not only successful ones. Review messages sent on expired context, useful opportunities discovered after expiry, and owner overrides. These examples reveal whether the window, identity gate, or action policy needs adjustment.

What are common signal-decay mistakes?

• Copying universal half-lives: calibrate windows against the team source and action
• Using received time as event time: preserve source latency
• Resetting recency on duplicate payloads: deduplicate by stable event identity
• Letting weak engagement outrank buyer state: apply explicit precedence
• Deleting expired evidence: retain history while changing actionability
• Optimizing only for response volume: review message accuracy, ownership, and suppression

How should each signal source be documented?

Create a source card for every signal used in production. The card should define the underlying event, collection method, source owner, payload fields, event time, received time, identity level, expected latency, update behavior, retention, permitted decisions, and known failure modes. Link the card to representative payloads and the current workflow configuration.

A source card separates facts from interpretation. The event definition explains what was observed. The permitted-use section explains what the organization allows the workflow to do. The two should not be collapsed into a label such as high intent because that label hides the evidence and the policy choice.

How should time zones and delayed events be normalized?

Store timestamps in a consistent machine-readable form while preserving the original source value and time zone when available. Recency should be calculated from the underlying event time, not the time an operator viewed the record. If the source provides only a date or an estimated window, keep that uncertainty visible.

Delayed events need a separate rule. A newly received payload does not necessarily describe a new buyer action. Compare event time with received time and decide whether the event is still inside the approved action window. If timing cannot be trusted, route to review or research rather than resetting urgency.

What should operators see when a signal is stale?

Show the source, observed time, active window, current status, and the reason it expired. Operators should also see whether a newer event, reply, meeting, opportunity, or owner action superseded it. A simple stale badge without the underlying policy is not enough for a defensible decision.

Provide explicit next actions: refresh data, inspect the account, notify the owner, wait for new evidence, or stop. Do not make users guess whether stale means false, unavailable, or merely outside the buyer-facing action window. Clear states reduce manual workarounds and inconsistent treatment.

How should manual overrides be governed?

Allow an authorized operator to override an expiry decision when they can provide current evidence. Require a reason, supporting source, new owner if applicable, and a timestamp. The override should not silently rewrite the original event time or source.

Review overrides by source and policy version. Repeated justified overrides may show that the window is too narrow or that another event is missing. Repeated unsupported overrides may show that training or permission controls need improvement. Preserve both the original automated decision and the final human decision.

Expire the override itself when the supporting evidence is no longer current. A human decision should not create permanent actionability from temporary context.

Teams that want to govern signal recency inside qualification and Plays can explore Unify and start with one source, one decision, and a reviewed expiry policy.

Frequently asked questions

What is the half-life of a B2B buying signal?

There is no universal value. It is an operational window that should be calibrated for the signal source, identity quality, intended action, and observed buyer-state changes.

Do old signals become false?

Not necessarily. They may remain historically true while no longer supporting the same current action or message.

How should teams set an initial expiry window?

Choose a conservative window, review labeled examples by elapsed time, and revise the policy using false positives, false negatives, and overrides.

What should happen after a signal expires?

Refresh current state, downgrade to research or monitoring, replace it with newer evidence, or suppress the action. Keep the event for audit.

Can multiple weak signals restore actionability?

They can justify more research, but adding weak events does not automatically create verified intent. Apply identity, lifecycle, and decision-risk checks.

Which states should override signal recency?

Opt-outs, replies, meetings, open opportunities, customers, ownership changes, and corrected identity should supersede earlier signals.

How should decay policy be measured?

Review decisions by signal type, source, elapsed time, policy version, identity level, outcome, and operator override.

Glossary

• Signal half-life: An operating metaphor for how quickly an event loses relevance to a specific decision
• Expiry window: The approved period in which a signal may support a defined action
• Event time: When the underlying event occurred
• Received time: When the workflow or platform received the event
• Source latency: The delay between event occurrence and receipt
• Supersession: Replacement of an earlier signal by a newer authoritative state
• Identity confidence: The evidence that an event belongs to a person or account
• Policy version: The recorded rule set used for a specific decision

Sources

• Unify | Signals, Unify, accessed September 2026
• Unify Products | Plays, Unify, accessed September 2026
• Unify Products | Sequencing, Unify, accessed September 2026
• Unify Products | Analytics, Unify, accessed September 2026
• The Short Life of Online Sales Leads, Unify

How should signal recency and expiration policy be documented before launch?

Document the policy as a decision contract that another operator can reproduce. The contract should name the input event, the fields required for evaluation, the owner allowed to approve the action, and the states that stop or transfer the workflow. Avoid screenshots as the only record because screenshots do not show field ownership, default behavior, or later changes.

Keep the contract next to the workflow configuration and link it from the CRM field dictionary. Each rule should answer three questions: what evidence triggered the decision, which policy was applied, and what state was written back. If any answer is missing, the team cannot distinguish a routing defect from a messaging or data problem.

• Purpose: use buying signals only while their evidence remains relevant to the next action
• Eligible population: first-party, third-party, product, website, people, company, reply, and CRM events used by outbound workflows
• Required evidence: event source, observed time, identity confidence, lifecycle, subsequent events, and reviewed outcomes
• Owner: RevOps with source owners, Sales, Marketing, and compliance
• Excluded states: events without provenance, unresolved identity, superseded lifecycle states, opt-outs, customers, and active opportunities outside the play
• Audit fields: event identifier, rule version, decision, timestamp, owner, and stop reason

How should signal recency and expiration policy be tested before expanding it?

Test the decision path with controlled records before the rule can affect buyers. The test set should include an eligible record, a record that should be suppressed, an ownership conflict, missing data, a late event, and a record whose lifecycle state changes while the workflow is running. These cases reveal whether the policy fails closed or continues with partial information.

The test should inspect both the visible outcome and the written state. A correct task with a missing rule version is not fully testable later. A correctly suppressed message with no stop reason leaves operators guessing. Pass only when the action, ownership, audit fields, and downstream state all match the expected result.

How should changes to signal recency and expiration policy be reviewed?

Treat every rule change as a versioned operational change. Record the old behavior, the new behavior, why the change is needed, the records affected, the rollback condition, and the approver. A change that improves one path can break exclusions or attribution elsewhere, so the review must cover the complete decision chain.

Roll out one material change at a time when possible. If trigger logic, ownership, message policy, and measurement all change together, the team cannot isolate the source of an error. Keep the previous version available long enough to compare decisions and restore the known behavior if the new path creates conflicts.

• Change request: describe the buyer or operator problem, not only the requested configuration
• Impact review: list affected sources, CRM fields, owners, sequences, reports, and suppression paths
• Controlled test: replay the standard cases against the proposed version
• Approval: require the accountable policy owner to accept the behavior
• Monitoring: review holds, overrides, duplicate actions, and unexpected state transitions
• Rollback: define the condition and responsible operator before release

What should a recurring signal recency and expiration policy review cover?

Review the decision quality, not only throughput. Sample records from every path and compare the observed input, chosen action, owner, message context, and final state. Investigate overrides because they show where the policy does not match the operating reality. An override may be correct, but repeated overrides usually indicate a rule, data, or ownership gap.

Separate data failures from policy failures. Missing identity, delayed events, and stale lifecycle fields need data fixes. Correct data paired with the wrong action needs a policy change. Correct policy paired with an unhelpful message needs content work. This separation keeps the team from rewriting sequences to compensate for bad routing.