Why Lead Lists Decay

People change jobs. Companies reorganize. Titles shift. Emails stop working. Organizations grow, shrink, merge, or restructure. Technology environments evolve. And prospects that once fit an ICP can become irrelevant to a campaign without a single field in the record becoming technically wrong.

Understanding why this happens — and what it means operationally — matters more than finding one decay percentage. Because decay is not one problem. It is several different problems, changing at different rates, with different consequences for outbound execution.

A Lead List Is a Snapshot

A lead list looks static. The underlying market is not.

Consider a record created today:

John Smith / VP Sales / Acme Inc. / john@acme.com / 250 employees / United States

The record may be accurate when created. Six months later: John may have changed companies. His title may have changed. His email may no longer work. Acme may have grown to 400 employees or changed its business model. The company may no longer fit the campaign. John may already have been contacted. The account may now be an active opportunity.

The original record did not necessarily contain bad data. The environment changed.

That distinction is fundamental. Data decay is often the gap between what a record says and what is true now.

The World Changes Faster Than the List

A database records reality at a particular point in time. Business environments continuously evolve. People move. Companies reorganize. Markets shift. Campaign requirements change.

REAL WORLD → DATA COLLECTION → DATABASE → TIME PASSES → REAL WORLD CHANGES → DATABASE DRIFTS

The database does not automatically know that reality has changed. Unless the system detects the change, the old state remains.

Freshness is therefore not a cosmetic property of data. It is part of whether the data can still support a decision. Gartner defines data quality in terms of usability and applicability for specific use cases, and includes timeliness and relevance among its core quality dimensions — recommending that data-quality work be prioritized according to business value and risk rather than attempting uniform quality control everywhere. For outbound infrastructure, this means freshness should be evaluated in relation to what the data is actually being used for.

What Actually Decays?

"Lead decay" sounds like one problem. It is at least four distinct problems:

• Contact decay — information about a person changes

• Account decay — information about a company changes

• Relevance decay — the prospect no longer fits the campaign, even if the record is accurate

• Eligibility decay — the prospect is accurate and relevant but should not be contacted now

These should not be treated as the same thing, because they require different responses.

Contact Decay

Contact decay happens when information about a person changes. The person may leave the company, change roles, change departments, receive a new title, move location, or change email — any of which can make the original record operationally wrong without it ever having been inaccurate when collected.

For example:

January: John Smith / VP Sales / Acme Inc. / john@acme.com

September: John Smith / Chief Revenue Officer / Beta Corp. / john@beta.com

The original record was perfectly accurate. It simply stopped describing the current state.

Contact-level change is the most commonly cited form of decay, and it varies significantly across markets, functions, and geographies. There is no universal refresh interval that is optimal for every contact population — a point covered in more detail when examining field-level decay rates.

Account Decay

People are not the only entities that change. Companies change too.

An account can move from 100 to 500 employees, from startup to enterprise, from independent company to acquired business. Other account attributes that can shift include industry classification, revenue, headcount, geography, ownership structure, business model, technology environment, and market focus.

This creates account-level decay that is independent of contact decay. A contact can remain at the same company while the account itself changes enough to affect targeting eligibility. A company that matched the ICP at 100 employees may no longer fit a campaign designed for 500–2,000 employee organizations. The contact did not become inaccurate. The account context changed.

Relevance Decay

This is one of the most important distinctions in the decay framework.

A record can remain accurate and still become irrelevant. Suppose John Smith, VP Sales at Acme Inc., is still completely correct in every field. But the campaign has changed — it now targets companies expanding into Europe within the next six months, and Acme is not. Nothing in John's record is wrong. The prospect has simply lost campaign relevance.

Relevance decay means:

ACCURATE ≠ RELEVANT

A data system that measures only field accuracy can miss this entirely — and will continue activating technically correct records against campaigns they no longer serve.

Eligibility Decay

Beyond relevance sits a further state. A prospect can be accurate, relevant, and ICP-qualified — and still not be eligible for activation.

Common eligibility blockers include: previously contacted within a suppression window, active opportunity, existing customer status, unsubscribe, do-not-contact status, campaign conflict, client-specific exclusion, or temporary hold.

The prospect remains a valid prospect. The correct operational decision is simply: do not contact now.

This means:

ACCURATE ≠ RELEVANT ≠ ELIGIBLE

All three states are distinct. A prospect must satisfy all three before it should enter a campaign — and a record can pass two while failing the third. This is why a mature outbound data system needs state management, not just data storage. The database needs to know not only what a record says, but what operational state it is currently in.

Data Decay Is Not One Number

There is a strong temptation to summarize data decay with a single percentage. The frequently repeated claim that B2B data decays at roughly 30% per year is widely cited but does not have a clear primary source.

More rigorous recent measurement produces a different picture. Lusha's September 2026 study of 140,284 US sales leaders found that 12.25% changed roles over 12 months and 25.67% changed roles over 24 months. The study also found meaningful variation across countries and functions: UK sales leaders showed a 21.40% twelve-month change rate; US marketing leaders showed 13.73%; US engineering and technical leaders showed 9.9%.

Two important caveats apply to these figures. First, the study measures detected employment changes in specific cohorts — not every possible form of data error. A job change is only one form of decay; an email becoming invalid, an account shifting ICP status, or a prospect becoming suppressed are different events entirely. Second, Lusha explicitly notes that recency of a refresh is not necessarily the same as accuracy — a point addressed in more detail below.

The useful principle is: there is no single decay rate that applies equally to every field, market, persona, or use case. Acting as if there is leads to refresh policies that are simultaneously too aggressive for some data and insufficient for others.

Decay Happens at the Field Level

A record should not be classified simply as fresh or stale. Consider:

John Smith / Acme Inc.

Job Title: VP Sales

  Source: Company Website / Verified: September 2 / Confidence: High

Email: john@acme.com

  Source: Provider A / Verified: September 10 / Confidence: Medium

Employee Count: 250

  Source: Provider B / Verified: August 20 / Confidence: High

Technology: Salesforce

  Source: Provider C / Verified: January 12 / Confidence: Low

Different fields have different sources, verification dates, change rates, confidence levels, and operational importance. The record has a field-level freshness profile — and that profile is more operationally useful than a single record-level label.

The more important question becomes: which fields are sufficiently fresh for the specific decision we are about to make?

Freshness Is Not Accuracy

These two concepts are often conflated, and the difference matters.

Freshness answers: when was this information last checked? Accuracy asks: does the information still reflect reality? A record verified yesterday is not necessarily accurate today. A record verified three months ago is not necessarily inaccurate.

Lusha's 2026 study noted that its three-month observed role-change rate was lower than longer-window rates, and interpreted this partly as a detection-lag issue — employment changes can take time to surface in a dataset even after they occur. A recent verification timestamp is therefore evidence of a recent check, not proof that reality has not changed.

The operational implication: freshness metadata tells the system when to re-check. It does not tell the system that reality has stood still.

Risk-Based Refresh

Not every field deserves the same refresh cadence. Fields change at different rates:

• Company founding year — usually slow-changing

• Employee count — medium-changing

• Job title — higher-changing

• Employment status — higher-changing

• Email deliverability — potentially high-changing

This points toward a better model: data freshness should be risk-based, not calendar-based. A quarterly database refresh assumes that every field changes at approximately the same rate — which is unlikely to be true across a mixed dataset.

The appropriate refresh policy for any given field depends on how quickly it changes, how important it is to downstream decisions, how costly an error in that field is, and how the data will be used. A stable company attribute like founding year may need no active refresh cycle. A high-mobility contact's email deliverability may need verification close to every activation event.

Gartner recommends the same principle more broadly: prioritize data-quality efforts according to the value and risk of the relevant business use cases, not an abstract goal of uniform quality everywhere.

Point-in-Time Validity and JIT Revalidation

Outbound data does not need to be permanently verified. It needs to be sufficiently reliable at the moment it is used.

A record verified in June that enters a campaign in September raises a specific question: is it still reliable enough for this activation event? Historical verification is not the same as current reliability. This creates the concept of point-in-time validity — the pipeline evaluates freshness relative to the action about to be taken, not relative to when the record was originally created.

Just-in-time revalidation is the operational mechanism for this. Before a prospect enters a sendable campaign list, the system re-checks the fields that matter most for that specific activation: employment status, email deliverability, suppression state, and required fields. The goal is not to rebuild the entire database. The goal is to re-verify what matters before the system acts.

Decay Propagates and Compounds

Stale data does not stay in the database. It propagates errors into every downstream decision.

Consider a single stale job title:

Wrong Title → Wrong Persona → Wrong Segment → Wrong Campaign → Wrong Message → Poor Outcome

The campaign result may then be interpreted as a messaging problem. But the root cause was data. Without diagnostic feedback, teams optimize the wrong layer — improving copy, adjusting sequences, or changing send times when the actual problem is upstream targeting data.

The compounding effect makes this especially costly. Each layer of the pipeline that operates on stale information makes a decision that is slightly more wrong than the one before it. By the time the error reaches execution, it may look like a channel problem, a positioning problem, or a creative problem — any of which is more expensive to investigate and fix than the original data issue.

The Feedback Loop

Outbound execution produces evidence about the quality of upstream data. That evidence should flow back into the data system.

DATA → QUALIFICATION → CAMPAIGN → OUTREACH → OUTCOME → DIAGNOSTIC → DATA UPDATE ↺

Different outcomes point toward different upstream problems:

High bounce rate suggests email freshness issues, weak validation, domain changes, or contact changes.

High wrong-person rate suggests problems in contact mapping, persona qualification, job-title normalization, or account-contact relationships.

High irrelevant-response rate suggests weakness in ICP definition, account qualification, segmentation, or campaign eligibility logic.

Strong engagement from a specific segment may reveal a stronger ICP sub-segment, a more predictive account characteristic, or a persona pattern worth prioritizing in future targeting.

The principle: outbound outcomes are evidence about the quality of the upstream data process. A system that does not route this evidence back into data operations will continue making the same targeting errors at scale.

The Pipeline Should Learn From Decay Patterns

A mature pipeline should not only repair individual records. It should learn from recurring patterns to improve the system itself.

If a large percentage of records from one source repeatedly fail validation, the problem may not be individual records — it may be the source. If a particular persona consistently produces wrong-person outcomes, the problem may be the targeting rule, not the contacts. If one market shows significantly faster contact movement, the problem may be the refresh policy applied to that segment.

This creates a higher-order feedback loop:

DATA ERROR → PATTERN DETECTION → ROOT-CAUSE ANALYSIS → PIPELINE ADJUSTMENT → FEWER FUTURE ERRORS

At this level, data infrastructure begins to function as an operating system — one that learns from its own failures and adjusts the rules that govern future decisions. The distinction between a database and infrastructure is most visible here: a database stores records; infrastructure improves its own accuracy over time.

From Static Lists to Living Data

A static list operates like this:

RECORDS → EXPORT → OUTREACH

A living data system operates like this:

DATA → QUALIFICATION → VALIDATION → FRESHNESS → ELIGIBILITY → ACTIVATION → OUTCOME → FEEDBACK ↺

The second model recognizes a simple reality: the market does not stop changing when the list is exported. The data system cannot stop operating when the list is exported either. Maintaining a static export and running outreach against it for months is not a data strategy — it is a decay schedule.

Conclusion

Lead lists decay because the world they represent changes. People change companies. Roles change. Companies evolve. ICP definitions shift. Campaign objectives change. And prospects that were once ready for outreach can become inaccurate, irrelevant, or ineligible without any obvious failure in the data collection process.

The solution is not a universal decay percentage. It is understanding what changes, how quickly it changes, and what happens to outbound decisions when the information becomes wrong.

The four-layer decay model provides that structure:

CONTACT DECAY + ACCOUNT DECAY + RELEVANCE DECAY + ELIGIBILITY DECAY → DATA DRIFT → REVALIDATION → UPDATED PROSPECTS

A mature outbound data system treats freshness as an operational property, not a database checkbox. It does not apply one refresh cadence uniformly to every field. It does not treat a recent timestamp as proof of truth. It does not discard entire records when one field changes. And it does not wait for a failed campaign to discover that its targeting data has drifted.

Instead, it connects data to qualification, qualification to freshness, freshness to eligibility, eligibility to activation, and activation outcomes back to the data layer — continuously.

The objective is not to build a list that never changes. The objective is to build a system that detects change before it becomes an outbound problem.

A lead list is not a permanent asset. It is a snapshot of a changing market.

Sources & References

1. Lusha — B2B Data Decay Rate Measured

2. Gartner — Data Quality

3. HubSpot — Database Decay