Data decay

How data decay works

A record decays when the world changes and the record does not. A contact moves to a new employer, and the old work email starts to bounce. A title changes after a promotion. A company rebrands, changes its domain or closes. Nothing in the database shows the change until something fails, such as a bounced email or a call that no longer reaches the person.

A job change breaks several fields at once, because the employer, title, work email and work phone all change together. Public labor data shows how often that happens. The US Bureau of Labor Statistics measures employee tenure every two years as part of the Current Population Survey 2. In January 2026, 20.6% of wage and salary workers had been with their current employer for a year or less 2. That group includes new hires and people who changed employers during the year 2. The figure counts workers rather than database records. Even so, it shows why a contact list cannot stay accurate for long.

Decay is uneven. Median tenure was 6.1 years in management jobs and 2.9 years in service jobs 2. A list of senior buyers therefore goes stale more slowly than a list of junior staff. Fields also decay at different speeds. A work email breaks on the day someone leaves, while a company's industry rarely changes.

Decay makes data enrichment a recurring job rather than a one-off import. Teams pair scheduled re-checks with email verification, watch bounce rate as the early warning, and use job change tracking to catch moves before a send.

How to measure data decay

Published decay figures disagree because they count different things. HubSpot's 22.5% a year is one aggregate for B2B data, and the page names no method 1. The BLS figure counts workers with short tenure, not stale records 2. Neither tells you how fast your own database decays.

Your own list gives a better number, and the method takes three steps.

• Take a random sample of records that were last verified on a known date.
• Re-verify each email and re-check each person's current employer and title.
• Divide the records with at least one changed field by the sample size, then divide by the months since the last check to get a monthly rate.

Run it by segment, because seniority and industry move the rate 2. Between samples, track the hard bounce rate on every send as a running signal. A sudden rise on one segment often points to that segment going stale. Keep the date each record was last checked in its own field, since a record with no check date cannot be aged at all.

Example of data decay

Take a list of 10,000 B2B contacts and apply the two public figures from HubSpot and the BLS as rough ranges 1 2. At the HubSpot rate of 2.1% a month, about 210 records go stale in the first month, and the annualized 22.5% means about 2,250 in a year 1. If the share of contacts on a new job after a year matched the BLS short-tenure share of 20.6%, about 2,060 contacts would hold a different job by then 2. The BLS group also includes people who were not working a year earlier, so treat that second figure as a rough check and not a forecast 2. The two estimates land close together, though they measure different things.

The cost shows up at send time. A work email at a former employer either bounces or reaches nobody, and each hard bounce counts against the sending domain. RichAPI's verifier reference advises verifying immediately before the send rather than at import time 3. Its reasoning is that an address that verified clean eight weeks ago may belong to someone who has since left the company 3.

A refresh cycle follows from those numbers. Re-verify emails before every campaign, since verification is the cheapest call in the chain and the one run in the largest volume 3. Re-enrich person records on a schedule tied to how fast each segment moves. A profile enrichment call costs 1 credit at RichAPI 4. Refreshing 10,000 contacts once a quarter therefore costs 40,000 credits a year 4. Refreshing only the high-turnover segments more often can buy more accuracy for the same spend.

Data decay vs data freshness

Decay and freshness describe the same problem from two ends. Data decay is the rate at which records go wrong. Data freshness is how recently a record was checked or collected. A database can look fresh on paper, with recent import dates, and still decay fast if its segment turns over quickly. Freshness is a field you store, a last-checked date on each record. Decay is a rate you measure from samples. Read together, they tell you which records to re-check first.