The Data Freshness Reference: How Fast Each Field Decays

Most public writing on data decay quotes one blended annual number and ends on "enrich continuously." That is not a budget you can defend. This reference gives a separate decay rate, staleness tell, and re-verify interval for each field type across people and company records, so you can decide field by field how much to trust a stored value before it goes into a send or a shortlist. It is for revenue operations, recruiting operations, and anyone answerable for how the data was gathered.

Jump to the row you need. Every field carries three things: how fast it decays, what it looks like when it has gone stale, and how often to re-verify it. Where the evidence is thin or self-reported, I say so and give you a way to check locally.

Why one blended decay rate is the wrong unit

The industry's default number is a database average, and averages hide the fields that actually break. B2B contact databases decay at a blended 2.1% per month, compounding to about 22.5% per year, from the HubSpot Database Decay Simulation that traces back to MarketingSherpa. Applied to your whole list, that math says roughly 12% is lost by six months, 22.5% by twelve months, and after two years barely 60% of the database is still reliable.

The problem is that the fields do not decay together. Work email loses 23-28% a year. An HQ address moves at a small fraction of that. If you apply one rate to everything, you over-refresh stable firmographics and under-refresh volatile emails, spending effort where the data was fine and skipping the fields that are quietly poisoning your sends.

The more useful frame is that decay is correlated at the person, not the field. A single job change can break an email pattern, a direct dial, a reporting line, and a job title all at once. So the deepest lever is not per-field averages; it is job-change velocity for the segment the record sits in. Fields inherit their instability from how often the person moves.

The field-level decay reference

Here is the load-bearing table. Each row names a field, its published annual decay range, the signal that it has gone stale, and the source. Treat the 22.5-30% band as reliable and anything above it as directional.

A few notes on reading this table. Work email is the best-measured field: the largest independent verifier tracked it at 22% in 2022, 25% in 2023, 28% in 2024, and 23% in 2025, so 23-28% is a defensible working range. Direct phone is more fragile and worse-measured; the 25-35% end is attributed to the post-2020 remote-work shift, while a lower 18% figure is attributed to Cognism. Behavioral and intent signals do not have an annual rate because they expire within weeks; the tell is simply the age of the signal.

Company email deactivation lags the job change. A company email typically deactivates 30 to 90 days after the person leaves, which means email decay is a delayed echo of title decay. If you catch the job change first, you catch the email before it bounces.

Sector tenure predicts decay better than a flat rate

If you tag records by how long people stay in their sector, you predict decay far better than any list-wide average. The primary source is the Bureau of Labor Statistics: the median number of years workers had been with their current employer was 3.9 years in January 2024, down from 4.1 in 2022 and the lowest since 2002. But the median hides a wide spread, and the spread is where the leverage lives.

A leisure-and-hospitality contact churns roughly twice as fast as a manufacturing contact. A public-sector record stays usable nearly three times longer than a leisure one. Tagging a record's velocity by sector is the single highest-leverage segmentation you can apply, because it lets you push manufacturing intervals out and pull tech intervals in without measuring each list separately.

Two more numbers sharpen this. LinkedIn's data across half a billion professionals puts all-industry turnover at 10.9% over a trailing twelve months, with HR near 15%. And BLS JOLTS puts the quits rate at 1.9% per month with total separations at 3.2% per month. A named practitioner range holds that annual job-change rates for professionals run 20 to 30%, higher in software, agencies, and professional services. Your senior B2B buyers in tech sit at the fast end of all of these, not the median.

Staleness tells and the thresholds that matter

A staleness tell is the observable signal that a stored value has gone wrong, and the useful ones have published thresholds. The single most important discipline here is to read tells at the domain and record level, never as a list average.

For email, the acceptable bounce rate is under 2% total with hard bounces under 1%. Once decay pushes the bounce rate above 2%, ISPs begin filtering your sends, and a rate of 5% or greater will place a sending account under review. That gives you a hard line: 2% is where reputation starts eroding, 5% is where the platform intervenes.

The second tell is the catch-all share of your list, and it is the one that quietly defeats verification. A catch-all domain accepts every address at the SMTP layer and returns a 250 OK whether or not the mailbox exists. Approximately 15-25% of business domains are configured this way, rising to 40% for enterprise and government, and near zero for consumer providers. On catch-all domains, actual delivery ranges from 50% to 85%. So a "valid" verdict on a catch-all domain can be meaningless: the server said yes to everything.

Catch-all is the silent killer, not hard bounces. The tell is domain configuration, not the bounce log.

The practical response is to isolate catch-all and unknown addresses into their own segment and pattern-score the usernames rather than trusting the verdict. Do not fold them into your "valid" count, and do not send to them on the same footing as confirmed mailboxes.

The re-verify procedure, field by field

The governing principle is one line: verify each field as often as that field actually changes, no more and no less. The steps below turn that into a repeatable cadence you can run and defend. It moves from a one-off measurement to standing intervals to point-of-use checks.

Sources disagree on one point, and you should know where they split. The whole-list camp says clean the entire database monthly regardless of field; the field-level camp, argued by Derrick, says do not, because that over-refreshes stable fields. Practitioner cadence guidance lands in between: verify at the point of entry, re-verify the whole list quarterly (monthly for fast-churning B2B data), and always before a major campaign. Tech and SaaS lists should plan refresh cycles around a minimum of 90 days and expect annual decay closer to 30-35%. My read is that the field-level approach wins on effort, and the quarterly whole-list pass is a safety net, not the primary mechanism.

The reason point-of-use verification matters more than any schedule is arithmetic. A documented vendor test had two researchers manually enrich 10,000 contacts from a HubSpot export; it took 143 hours to reach 91% accuracy, about 14.3 researcher-hours per 1,000 records. That is a full researcher-week for one mid-size list, and the list is already decaying as the pass finishes. Manual verification cannot outrun decay, so the record you are about to use is the record to check.

Asking Refolk for the people who just changed jobs is the inverse of a cleaning pass: instead of re-checking a whole list to find the movers, you find the movers directly and repair only what moved. That is the field-level principle expressed as a query.

How this goes wrong: failure modes and false positives

This is the section to read before you trust your own freshness numbers. Each failure mode below has a false positive it produces and a specific check that catches it.

• The blended-rate trap. Applying one 22.5% figure to all fields over-refreshes stable firmographics and under-refreshes volatile emails. Check by measuring decay per field, using the reference table, not per database.
• Catch-all false "valid." SMTP returns 250 OK for every address on 15-40% of domains, so a "valid" verdict can be meaningless. Check by isolating catch-all and unknown verdicts and pattern-scoring usernames instead of trusting the flag.
• Bounce complacency. A low aggregate bounce hides a defunct-domain cluster; ten contacts at one dead domain is ten hard bounces in a single send. Check the domain-level bounce distribution, not the list average.
• Tenure is not your list. The BLS 3.9-year median describes all workers, while senior B2B buyers in tech churn faster. The false positive is assuming a four-year safe window. Check against sector tenure and role.
• The "91% accuracy" mislabel. Vendor accuracy figures often exclude catch-alls or measure one narrow field. Check the safe-to-send delivery rate, not the headline accuracy number.
• Stale on arrival. A 143-hour manual pass is decaying before it finishes; "we just cleaned it" is a false positive. Check the elapsed time between verification and send.
• Firmographic drift missed. Headcount and funding shift silently with no bounce to alert you. Check by re-pulling live company signals rather than waiting for an error.

The top-right quadrant is where most damage hides. Firmographic drift decays fast and produces no bounce, so nothing in your send logs will ever flag it. The only defence is to re-pull live company signals on a schedule rather than treating firmographics as set-and-forget.

Small, concentrated markets decay louder

When a talent or contact pool is small and geographically concentrated, each job change removes a larger share of the reachable people, so your intervals should be shorter. This is a segmentation rule that the blended rate cannot express, and Refolk's own index makes it concrete.

In Refolk's index of professional profiles, the US Revenue Operations pool is 1,429 people against 244 in the UK, a 5.9x difference. And the UK pool is about four times more concentrated in a single metro: London accounts for roughly 68% of the sampled UK records, while no single US metro exceeds around 16%.

The practical consequence is that a London RevOps shortlist decays louder than its raw rate suggests. When 68% of a 244-person pool sits in one metro, a handful of moves within London strips out a meaningful fraction of everyone you could reach. Shorten the re-verify interval for small-geo, concentrated shortlists, and lean on live job-change signals rather than a stored snapshot.

Before you call the data fresh

Run this checklist before a stored record goes into a send or a shortlist. It is the field-level standard compressed into pass-or-fail statements.

To keep this reference current, re-run the baseline audit each quarter and recompute your own per-field decay rates against the published ranges in the field-level table. The ZeroBounce email series shifts year to year, sector tenure moves as BLS updates its release, and your list's velocity mix changes as your ICP does. The mechanism stays fixed - measure per field, tag by velocity, verify at point of use - even as the numbers drift. When you next re-verify, use a query that surfaces the recent movers directly rather than re-checking records that never changed. That is the difference between chasing decay and getting ahead of it.

Here is a rubric you can paste into your own runbook and adapt to your fields.

BEHAVIORAL / INTENT   -> weekly (expires in weeks; treat as ephemeral)
WORK EMAIL            -> 90 days high-velocity / 180 days low-velocity; verify at point of use
DIRECT PHONE          -> 90 days high-velocity / 180 days low-velocity
JOB TITLE / EMPLOYER  -> track job-change signals; re-verify on any detected move
FIRMOGRAPHICS / HQ    -> 6 to 12 months; re-pull live, do not wait for a bounce
VELOCITY TAG          -> high = tech, SaaS, HR, sales | low = manufacturing, financial, public sector
SMALL-GEO SHORTLIST   -> halve the interval when one metro holds >50% of the pool
POINT-OF-USE OVERRIDE -> always re-verify immediately before a send or shortlist submission