What is data decay, what causes it, and how to measure the rate on your own list instead of quoting a vendor's number.

Definition

Data decay is the gradual loss of accuracy in a database as the real world changes and the stored records do not.

So what is data decay in B2B? In this page's view it is mostly a people problem. Someone is promoted, leaves, or joins a company that then rebrands, and the contact record you saved a year ago still describes the world as it was a year ago. The record did not change. Reality did.

The question worth answering is not what decay means in the abstract, but what your own rate is. Decay is expressed as a rate: the share of records that stop being true over a period.

That rate belongs to your list, your market and your refresh habits. It is not a constant, which is why this page gives you the arithmetic and the public statistics that measure real change, instead of quoting a vendor's figure at you.

What is data decay, and what it is not

The words around this topic get used interchangeably, which makes measurement sloppy. On this page, decay is specifically about records that were correct and have since become wrong. That is a different problem from records that were never correct, and from files that physically degrade.

Mixing them inflates the number you report. A duplicate contact and a contact who changed jobs both look like a bad record in a cleanup project, but only one of them is decay, and only one of them is fixed by re-verification.

Types of data decay

Articles on this topic sort decay into overlapping labels: natural or external decay, logical decay, mechanical decay and plain ageing. The labels differ, but they reduce to three questions you can actually act on.

• External decay: the world changed. A person moved, a company merged, a domain was retired. Nothing inside your systems went wrong, and only fresh evidence from outside will fix the record.
• Process decay: your own systems changed the value. A migration mapped a field badly, a sync overwrote a newer value with an older one, or an import replaced a verified title with a guess.
• Mechanical decay: the storage or the software failed. Files corrupt, integrations break, and fields go blank. This is rarer in a modern CRM, and it is an engineering problem rather than a data refresh problem.

The split matters because the remedy differs. External decay needs verification and research, process decay needs change logs and field ownership, and mechanical decay needs backups. Buying more enrichment fixes only the first.

What causes data decay in B2B records

• Job changes: the person leaves the company entirely. Their work email can stop resolving, their direct dial may be reassigned, and the account loses its champion in one move.
• Role changes: the person stays but moves teams, gets promoted, or picks up a new remit. The email still works, so nothing bounces, and the record is quietly wrong anyway.
• Company changes: mergers, acquisitions, rebrands, spinouts and closures. Headcount, industry, parent company and the whole email pattern can change on one announcement date.
• Domain changes: a rebrand or migration moves mail to a new domain. Old addresses may forward for a while, then stop, producing a domain not found error months after the change.
• Infrastructure changes: phone systems move to new numbers, offices close, mail routing switches provider, and catch-all settings are turned on or off.
• Your own process: typos on import, duplicate accounts, free-text picklists and forms that let anyone type anything. This is dirty data, not decay, but it lands in the same report.

Only the first four are external decay. Separating them matters because each one is detected differently: an email bounce can catch a job change, and nothing but a profile check or a reply catches a role change.

Which fields decay fastest

Averaging decay across a whole record hides the thing you need to know. Each of the data points in a record ages at its own speed, and the fast ones are the fields outreach depends on.

The ordering below is this page's reasoning from what moves each field. It is not a measured ranking, and your own cohort may order them differently.

The practical reading: contact fields deserve a cadence measured in weeks, firmographics in quarters, and industry classification in years. Treating them all on one schedule wastes credits on the slow fields and misses the fast ones. The same split runs through B2B data generally.

Where data decay sits among data quality dimensions

Data decay is one dimension of data quality, not the whole of it. Salesforce's Trailhead module on data quality lists six dimensions to assess before fixing anything, and it is a useful frame because only some of them are about time.

For age, the module suggests a report on the Last Modified Date of records. That is a fair start, with one caveat: a record is modified whenever anything touches it, including an automated sync, so a recent date does not prove anyone checked the email or the title.

Use field history, not record dates

Field-level history is better evidence. HubSpot's knowledge base documents a property history view that shows, for each property on a record, the value it changed to, the date, and the source of the change, and it lets you filter by property, source or date.

That source column is what decay measurement needs. A title changed by a rep after a call is evidence. The same title changed by an import or an integration is a claim from someone else, and it deserves a different level of trust.

Why there is no vendor decay percentage on this page

Search for a data decay rate and you will find the same handful of figures repeated widely, often a yearly percentage for B2B contact data, sometimes split by field. They are quoted so often that they read like physics. They are not.

Four things are wrong with borrowing someone else's number. First, the sample is the vendor's database, not yours, and it reflects the roles and regions they cover. Second, "bad record" is rarely defined, so an unverifiable address and a genuinely dead one can be counted together.

Third, the party publishing the figure often sells the remedy, which is not fraud but is a reason to check the method. Fourth, decay rates can vary widely by segment. A list of startup founders and a list of hospital administrators have no reason to age at the same speed.

You do not need the industry figure. You need yours, and you already hold the raw material to calculate it. Where you want an outside reference, use a public statistical series with a published method, covered next.

What public statistics measure instead

Government statistics do not measure contact data decay. They measure the real-world change that causes it: people leaving jobs, how long people stay with an employer, and businesses opening and closing. Each one has a stated method, which is more than many published decay figures offer.

Reading the JOLTS separations rate

The JOLTS technical note says the separations rate is computed by dividing separations by employment and multiplying by 100. Separations include quits, layoffs and discharges, and other separations such as retirements. The survey is a stratified random sample of about 21,000 nonfarm business and government establishments.

Two cautions stop it becoming a fake decay rate. It is monthly, and you cannot multiply it by twelve, because some people separate more than once in a year. And it counts separations from every kind of job, while your list holds a narrow slice of roles.

What tenure tells you about segments

The tenure release is the clearest public reason to segment. BLS reported that median tenure for workers ages 55 to 64 was more than three times that of workers ages 25 to 34. Age is not seniority, but the gap is large enough to expect parts of your list to age at different speeds.

BLS also notes that median tenure is affected by the age profile of workers and by changes in hires and separations. That is a reminder that a single national median describes no particular list, including yours.

What business dynamics tell you about account records

The BDS defines an establishment opening as a location with employment this year and none the year before, and a closing as the reverse. Those openings and closings are the account-level half of decay: a closed location makes an address, a phone number and sometimes a whole account record obsolete.

Use all three series as a sanity check, not a benchmark. If your measured quarterly employer change rate is far below what continuous labor turnover would suggest, the likelier explanation is that your detection is missing changes, not that your list is unusually stable.

How to calculate your own data decay rate

A data decay rate is a fraction: records that went bad, divided by records that were good at the start of the window and were actually checked. The work is in defining both terms precisely enough that the number means something next quarter too. This is the formula used on this page.

1. Freeze a cohort

   Pick every record that was verified good on a single date, say the first of the quarter. Record the count and do not add to it. A cohort with new records flowing in cannot produce a rate.

2. Define a failure

   Write down what counts: a permanent bounce, a confirmed job change, a reply saying the person left, or a title that no longer matches. Ambiguous outcomes go in a separate bucket, not in the numerator.

3. Expose the cohort

   You only learn about records you touch. Send to them, call them, or run them through verification and profile checks. Untouched records are unknown, not good.

4. Count failures at the window edge

   At the end of 30, 60 or 90 days, count confirmed failures inside the cohort. Divide by the cohort size that was actually exposed, not by the whole database.

5. Split the number by field

   Report email decay, title decay and employer decay separately. One blended figure cannot tell you whether to buy verification, enrichment or both.

6. Repeat with a new cohort

   One quarter is a data point. Several quarters give you a rate you can plan a refresh budget around, and it will move when your target market moves.

The denominator is where many attempts break. If you divide failures by the entire database while you only emailed a tenth of it, you have measured your send volume, not your decay.

Segment before you average

A single blended rate for a whole database is the least useful form of the number. Split the cohort along lines you can act on, then compare. The splits below are hypotheses worth testing on your own data, not findings.

• By seniority or age band: the public tenure gap between age groups suggests these can differ, and senior moves can invalidate more of a buying group at once.
• By company size: small and large companies may change different fields, for example employers at one end and titles at the other.
• By source: records you collected yourself, records from a vendor and records from an old list can age differently, partly because they started at different quality.
• By record age: compare the oldest untouched records with recent ones. If they fail more, that argues for retiring them rather than refreshing them.
• By region and function: both can affect turnover, and both change which detection method works.

Reading bounce codes so the number means something

Email is the cheapest decay detector you have, but only if you read the response codes rather than counting every non-delivery as a dead record. RFC 3463 defines the enhanced status codes that mail servers return, and it separates permanent from temporary failures.

The standard states that a permanent failure "is not likely to be resolved by resending the message in the current form", while a persistent transient failure means the message is valid and a temporary condition delayed it. Only the first kind can be evidence of decay.

A 5.1.1 only counts as decay when the address once worked. If it was never verified, the failure is dirty data from collection, not decay. That is why the cohort starts from records verified good on a known date.

The wider mechanics of hard and soft failures, and the exact replies large mailbox providers send, are covered in email bounces.

What verification can and cannot prove

Verification tools ask a mail server about an address without sending a real message, and the protocol limits what that can prove. RFC 5321 says a server that disables the VRFY command for security reasons must return a 252 reply, which neither confirms nor denies the address.

The same standard notes that some servers do not verify recipients until after the message text is received, and then report failures by returning a message. So an address can pass a check in the conversation and still bounce later.

A catch-all domain goes further and accepts mail for addresses that do not exist, producing silence instead of a bounce. Both gaps mean verification understates decay. A clean verification result is evidence, not proof.

Measuring the job change rate on your own list

Bounces catch some people who left. They miss people who moved desks, and they miss people whose old mailbox still forwards. For those you need a second measurement, run on a sample rather than the whole list.

The sample audit

Take a random sample from the cohort, large enough to be worth the effort and small enough that a person can actually check it. Open each contact's public profile, compare employer, title and department against the record, and mark one of four outcomes.

• Unchanged: employer, title and department all match the record.
• Role changed: same employer, different title, department or seniority.
• Employer changed: the person is somewhere else, which often means the work email is dead or soon will be.
• Not found: no profile to check. Count it separately and never as unchanged.

Sample decay is the changed records divided by the checked records. Two rates come out of one pass: a role change rate and an employer change rate. In this page's view the second is the better predictor of email decay, since a mailbox at a former employer rarely stays open for long.

Continuous detection

Sampling gives you the rate. Alerts give you the individual records. LinkedIn's Sales Navigator help documents two alert types for saved leads: "Lead changed jobs", when a saved lead has moved to a new company, and "Lead changed roles", when a saved lead has changed roles within a company.

The same page documents account alerts such as merger or acquisition events, senior hires and growth changes, which is the firmographic half of the problem. Saving your target list in Sales Navigator turns decay from a quarterly discovery into a daily feed.

One caveat: profile data is self-reported and may be updated late. A profile that still shows the old employer is weak evidence of no change, while one that shows a new employer is strong evidence of a change.

Signals a record decayed before it bounced

• Engagement collapse on one domain: replies stop across several contacts at the same company, which can point at a mail migration rather than your copy.
• Out-of-office from a different name: the reply comes from a colleague covering the desk, sometimes naming the replacement for you.
• A reply that says "I no longer handle this": the cleanest role change signal there is, and one that is easily lost in an inbox.
• Website redirects: the company domain now forwards somewhere else, which can mean every email pattern you hold is obsolete.
• Hiring for the role you sell to: a posting for your contact's job is a hint the seat may be empty.
• Support and billing contacts changing: for customers, the first sign a champion left can arrive in a ticket, not in the CRM.

Routing these back into the record is the part teams skip. A reply that names a replacement is worth more than a verification credit, and it is free, but only if someone updates the system of record instead of the inbox.

A worked example of the arithmetic

This example was written for this page, and its figures are invented round numbers to show the calculation. They are not measured, not a benchmark, and not a claim about any real database. Replace every number with your own.

Three things follow. The denominator is 3,000, the exposed part of the cohort, not 4,000. The 41 temporary failures are excluded because nothing about them says the record is wrong. And the 1,000 untouched contacts are unmeasured, so no claim is made about them.

Run the sample audit on the same cohort and you get the second half. If 200 profiles are checked and 34 show a different employer or title, the sample change rate is 17 percent for the quarter, against 4 percent measured by bounces alone.

The gap between those two invented numbers is the point of the exercise. It is the share of a list that is wrong in a way email delivery will never report, and it is the reason a clean bounce report is not proof of a clean database.

Turning a quarterly rate into an annual one

Decay compounds on the records that are still good, so you cannot multiply a quarterly rate by four. The formula used on this page: if q is the quarterly decay rate, the share still accurate after a year is (1 minus q) to the power of four, and annual decay is one minus that.

Using the invented 4.0 percent above: 0.96 to the power of four is about 0.849, so annual decay is roughly 15.1 percent, not 16 percent. The difference is small at low rates and large at high ones, which is exactly when you are making budget decisions.

The same formula runs the other way. A monthly rate m gives an annual figure of one minus (1 minus m) to the power of twelve, and an annual rate a gives a monthly figure of one minus the twelfth root of (1 minus a).

Where data decay shows up in your CRM

Many teams meet data decay as a CRM problem, because the CRM is where outdated information is stored, reported on and acted upon. It is worth knowing which objects carry the risk, and which reports go wrong first when data quality slips.

Sales teams tend to feel it as wasted time on the phone. Marketing teams feel it as engagement falling on a list that looks the same size as last quarter. Revenue operations sees both at once, and is often the function with the tools and the mandate to fix the underlying data.

The reporting problem is the quiet one. Every dashboard built on company data inherits that data's quality, so an outdated headcount or industry field produces a confident chart about your customers that nobody thinks to question. In this page's view, wrong information is more expensive than missing information.

Two CRM habits prevent much of this over time. Store a verified-on date beside every field that matters, and never let a tool write to a field without recording where the value came from. The one-off cleanup project is covered in CRM data cleansing, and the wider practice in customer data management.

How often to refresh, by field

Once you have a rate, cadence stops being a guess. The rule used on this page is simple: refresh a field before enough of it has decayed to damage the work that depends on it, and no sooner.

Adjust each row once your own rate exists. The slow fields rarely justify quarterly spend, and moving that effort to contact verification is, in this page's view, the better use of it. The routine side of keeping a mailing list clean is email hygiene.

Enrichment versus re-verification

These get treated as one purchase and they answer different questions. Verification asks whether what you hold is still true. Enrichment asks what you are missing. A decayed database needs both, in that order, because enriching a record you are about to delete is wasted effort.

A refresh schedule can run enrichment through an API so the CRM updates without manual imports, which is covered in data enrichment API, while the strategic side sits in lead enrichment.

One rule prevents much of the damage: never let an enrichment job silently overwrite a field a human verified more recently than the vendor did. Keep a verified-on date per field, and let the newer evidence win.

Tool categories that reduce decay

No vendors, no ranking and no prices here. These are the categories that do the work. In this page's view, a team usually needs a few of them rather than one platform that claims all five.

The field that makes all of them measurable costs nothing: a verified-on date, per field, written every time a value is confirmed. Without it you cannot build a cohort, and without a cohort you cannot calculate a rate.

The cost of acting on stale data

Decay is not expensive because records are wrong. It is expensive because people act on them. The costs show up in several places, and only the first is visible in a data quality report.

• Deliverability: sending to dead mailboxes drives bounces, and mailbox providers watch how senders handle them. Gmail's sender guidelines tell senders to automatically unsubscribe recipients who have multiple bounced messages, and to keep spam rates reported in Postmaster Tools below 0.10 percent and avoid ever reaching 0.30 percent.
• Wasted selling time: a rep working a stale list spends the hour on research, voicemail and the wrong person. That hour does not appear as a data cost anywhere in the budget.
• Wrong targeting: segmentation runs on firmographics. Stale headcount, technology or industry fields quietly route accounts to the wrong campaign, the wrong owner and the wrong offer.
• Bad decisions: forecasts, territory plans and scoring models all consume the same fields, so decayed inputs produce confident, wrong outputs.
• Credibility: writing to someone about a job they left two years ago tells them precisely how much research went into the message.

The deliverability cost is the one that compounds, because it degrades the channel for the records that are still good. Protecting it is a routine, not a project, and the routine starts with the measurement above.

Data decay in scoring, routing and AI tools

Automation does not create decay, but it removes the person who might have noticed it. A rep reading a record might spot that a title looks old. A routing rule, a scoring model or an AI writing assistant acts on the stored value without hesitation.

• Lead scoring: a score built on title and seniority keeps scoring a contact as a decision maker after they moved to a different role.
• Routing: territory and owner assignment run on headcount, country and industry, so a stale firmographic quietly sends an account to the wrong team.
• Trained models: a model trained on past outcomes learns from the field values stored at the time, and if those were stale, it learns the wrong pattern.
• AI-written messages: a tool that personalizes a first line from stored fields writes a fluent, specific and wrong sentence about a job the person no longer holds.

The defense is to make freshness an input. Pass the verified-on date to any automation that reads a field, and set a rule that values older than your measured refresh window are not used for personalization or scoring until they are checked again.

Accuracy is a legal principle, not only a sales problem

Where the records identify a person, accuracy is written into data protection law. Article 5(1)(d) of the GDPR requires personal data to be "accurate and, where necessary, kept up to date", with every reasonable step taken so that inaccurate data is erased or rectified without delay.

Article 16 adds the individual's side: a person has the right to obtain rectification of inaccurate personal data concerning them without undue delay. A reply saying "I left that company" is information you are expected to act on, not just a bounce to log.

The UK ICO's guidance adds a nuance worth knowing. It says that just because personal data has changed does not mean a historical record is inaccurate, as long as you are clear that it is a historical record. Whether you must update depends on what you use the data for.

The ICO also says you do not need to take extreme measures to keep records up to date unless a corresponding privacy risk justifies it, but that if you learn data may be wrong, you should reconsider it and correct or erase it as soon as possible.

That maps cleanly onto practice. An old title stored as "title as of March 2025" is a historical record. The same value sitting in the field your sequence merges into a first line is a live claim, and a wrong one. Keep history marked as history. Nothing here is legal advice.

What to do with a record you know is stale

The instinct is to delete. That can destroy information you paid for, because a person who changed jobs is not a lost record. They are two pieces of intelligence: an open seat at one account, and a familiar contact at another.

Stopping the sends first is what protects the channel. Everything after that is upside: the new person in the seat is a fresh opportunity at an account you already understand, and the person who moved may be the warmest contact you will get at their new employer.

Keep the old record, archived, dated and clearly marked as history, rather than overwriting it. It is the evidence of who used to own the relationship, and it is what lets you calculate next quarter's rate at all.

Who owns data decay

Decay keeps returning in teams where everyone uses the data and nobody owns a field. Ownership does not mean one person fixes everything. It means each kind of evidence has a named place to go and someone who checks that it arrived.

The split is this page's suggestion, not a standard. What matters is that the person who hears a contact left has a fast way to record it, and the person who reports the rate can see that record.

Common mistakes when measuring data decay

• Quoting a published decay percentage as if it described your list. It described someone else's database, often measured by someone selling the fix.
• Counting every bounce as decay. Temporary failures, full mailboxes and policy rejections say nothing about whether the record is true.
• Counting an address that never worked as decay. That is dirty data from collection.
• Dividing failures by the whole database instead of by the records you actually contacted.
• Reporting one blended rate, when email decay and title decay call for completely different spending.
• Treating a clean bounce report or a clean verification run as a clean database. Role changes and catch-all domains never bounce.
• Using a national labor statistic as your decay rate, instead of as a sanity check.
• Deleting records on the first hard bounce, and losing both the open seat and the contact's new employer.
• Letting an enrichment job overwrite values a human verified more recently.
• Refreshing industry and country on the same schedule as direct dials, which spends effort on the fields that barely move.

In a sequence

When a bounce or an alert tells you the person moved, the next message is not a retry. It is a short note to whoever holds the role now, written for this page, that says openly how you got there and asks one question.

Subject: You picked up {{roleArea}} at {{companyName}}?

Hi {{firstName}},

I had {{previousContactName}} down as the owner of {{roleArea}} at {{companyName}}, and it looks like that is you now.

Rather than guess, one question: is {{problem}} still on the list this quarter, or has the priority moved since the change?

If it is someone else entirely, say the word and I will fix my record.

{{senderName}}
{{senderCompany}}

Frequently asked questions