Glossary · Data and enrichment
What is data decay?
The short answer
Data decay is the way stored records go out of date as the world they describe changes: people change jobs and titles, companies move, merge or rebrand, and mailboxes close. A B2B contact list is right on the day it is built and drifts after that, so it has to be checked again on a schedule.
Real data
When 361 VPs of Sales started the job they hold today
Every profile whose current title is exactly VP of Sales and whose city is named Atlanta, Boston or Denver, in the United States: 361 profiles, read in full, not sampled. The field read is the start date of the current job.
Returned by the BlitzAPI API on
/v2/search/peopleYear the current job started (profiles)
Atlanta 154, Boston 119, Denver 88. Counted by year, not by month, because many profiles give only the year. 94 of the 304 profiles with a date started their current job in 2025 or 2026.
What causes data decay?
Data decay starts outside the record: nothing in it changes, but the world it describes does. In a B2B database, the usual causes are:
- Job changes: a contact leaves for another company, and the employer, title, email and phone in your CRM now describe someone who is gone.
- Promotions and new titles: same company, different role, sometimes a different budget.
- Company changes: moves, rebrands, mergers, acquisitions and closures change names, domains and headquarters.
- Closed mailboxes: when someone leaves, their work email usually stops working, and messages to it start to bounce.
Problems that were there from the start are not decay. A typo, a duplicate or an empty field is a data hygiene problem, and two records for the same company is a matter of entity resolution.
How fast does B2B data decay?
B2B data has no single decay speed: it depends on who and what you store. The measurement above takes one population, every profile titled exactly VP of Sales in three US cities, and asks when each person started the job they hold today.
Of the 304 profiles with a start date, 94 began their current job in 2025 or 2026. Read it as a list. Had you saved these same 304 people at the end of 2024, the job on file would now be wrong for 94 of them, about one in three, after less than two years, without anyone touching the list. And 30 of them started in 2026 alone, so a list saved on January 1, 2026 is already out of date on 30 records.
What this measurement does not say matters as much:
- It is one title in three cities. SDRs, CFOs and engineers change jobs at other speeds, and so do other regions. These counts are not a rate for your database.
- It only sees changes already on file. A job change reaches a database when the person updates their profile, so the newest months are undercounted.
- It follows the people who hold the title today. VPs of Sales who left the role since 2024 are not counted, although a list saved back then would include them.
Treat any decay rate quoted without its population, its field and its date with care, this one included.
How do you measure data decay?
To measure data decay, choose a population you care about, a field that carries a date or can be checked, and a window. Then count what changed. Two methods work:
- Read a dated field, as above. The start date of each person’s current job tells you how many changed jobs since any date you pick.
- Re-check a random sample of your own records. Take a few hundred contacts, enrich them again from a fresh source, and count how many changed employer, title or email since they were last checked. That share, over that time, is your decay rate for that population.
For email, bounces are the visible part: a bounce rate that climbs on an old list is decay showing up in your sending tool. Whatever the method, publish the population, the field, the dates and the sample size with the result. Without them, a decay rate cannot be compared with anything.
Data decay, data hygiene and data enrichment: what is the difference?
Data decay is the reason data hygiene and data enrichment are never finished. Data enrichment and hygiene run on a schedule because the people and companies in your records keep moving.
| What it is | What it deals with | |
|---|---|---|
| Data decay | Records going out of date as the world changes | Nothing: it is the problem |
| Data hygiene | The routine that keeps records clean: merge duplicates, fix formats, flag stale records | Duplicates, formats, records known to be stale |
| Data enrichment | Adding or refreshing fields from an outside source | Missing values, and values that decayed |
Show the answer key
- A contact was saved with a typo in her last nameThe record was wrong from the day it was entered, and nothing changed in the world: that is a hygiene problem.
- A VP of Sales who changed companies in March still shows his former employerThe record was right when it was saved; the person moved and the record did not. That is decay.
- The same company appears twice, as acme.com and as Acme Inc.Two records for one entity is a matching problem, solved by entity resolution, not decay.
- Many contacts have no phone numberA field that was never filled is incomplete data: enrichment fills it, but nothing decayed.
How do you keep CRM data from decaying?
You cannot stop CRM data from decaying; you can shorten the time a wrong record stays wrong. Refresh on a schedule that follows the value of the records, with the accounts in active deals and your target accounts first and the rest of the database on a slower cycle. Refresh on events too: a bounce, a reply from someone new, a company that changes its domain.
With BlitzAPI, Profile Enrichment returns a person’s current role and employer from their profile URL, and the CRM hygiene use case shows how to run that refresh on events from a CRM or a workflow tool such as n8n, Make or Zapier.
Sources and method
- Written by
- Antoine Blitz, Founder, BlitzAPI
- Published
- API calls run on
- BlitzAPI API reference, Find People
- BlitzAPI guide, Find People (filters and experiences fields)
- BlitzAPI Field Normalization, Keyword Filters (exact title match)
The calls ran on October 28, 2026 through the BlitzAPI MCP server, which calls the same endpoints; they are shown here as the equivalent REST requests.
The title is matched exactly, letter case aside. The city filter matches the city name on each profile, so a few profiles live in other towns named Atlanta, Boston or Denver.
The counts are profiles as they stood on that day. A job change appears once the person updates their profile, so the most recent months are the least complete. No person is shown: the page publishes counts by year only.