CRM Data Decay: Rates by Field, Real Costs, and How Often to Refresh

There is a number that gets quoted in every article about CRM hygiene, and it comes from a real place. HubSpot's database decay work, built on long-running MarketingSherpa research, puts monthly B2B contact decay at about 2.1%, which compounds to roughly 22.5% a year.

Then you read a different article and the number is 70%. Another one says Dun and Bradstreet puts it at 30 to 40 percent annually, accelerating in high-mobility sectors like technology and financial services.

Most people read that spread as vendors disagreeing, or as marketing inflation, and move on. It is neither. The gap reflects how differently decay behaves across field types, which is why a single aggregate figure systematically understates the problem for fast-moving sectors.

That is the whole insight, and almost nobody acts on it. A CRM does not rot uniformly. Some fields are nearly stable for years. Others are unreliable within months. An aggregate number averages those together into a figure that describes none of your fields and gives you no idea what to refresh first.

This post is about building a refresh strategy on field-level decay instead. It takes longer to set up than a quarterly cleanup and it costs considerably less to run, because you stop paying to re-verify things that were not going to change.

Why the aggregate number is actively unhelpful

Suppose you accept 22.5% and decide to refresh everything annually. You have made two mistakes at once.

You are refreshing stable fields too often. A company's founding year does not change. Its industry classification changes rarely. Its headquarters city changes occasionally. Paying to re-verify those on the same schedule as job titles is spending money to confirm things you already knew.

And you are refreshing volatile fields far too rarely. Work email is tied to employment, so it breaks the moment somebody leaves. Published estimates put 5% to 10% of B2B email addresses as invalid at any given moment, well above the blended rate for a full contact record. An annual refresh on a field like that means you spend most of the year working from addresses you know are partly wrong.

The aggregate is the average of a field that barely moves and a field that moves constantly. Optimizing for the average gets you the worst of both.

Build a field-level half-life table

The useful mental model is half-life. For each field, how long until half the values you hold are wrong?

You can reason your way to a rough version. Average job tenure sits at roughly 2.8 years, which puts somewhere around 30 to 40% of your contacts in a new role each year. That single fact drives most of what is volatile in a CRM, because a job change simultaneously invalidates title, employer, work email, direct phone, seniority, and every piece of firmographic data you attached to the person through their employer.

Here is a starting table. Treat it as a hypothesis to test on your data, not as a finding:

Two things about this table.

Segment it. Decay rates are not uniform across industries. Technology contacts are commonly estimated to rot at around 40% annually while manufacturing sits closer to 20 to 30%, largely because average tenure in manufacturing roles runs five to seven years, roughly double the tech average. If you sell into both, one refresh policy will be wrong for one of them.

Seniority matters too. Junior roles turn over faster. Very senior roles turn over slowly but their changes are worth far more to you when they happen, which means high-value contacts deserve a shorter refresh interval than their raw decay rate justifies.

The failure mode that makes this invisible

Here is why data decay does not get fixed until it causes a visible incident.

Most CRM systems display decayed records as valid. The problem stays invisible until it surfaces as pipeline failure, misrouted leads, or a scoring model quietly built on wrong inputs.

A stale record and a fresh record look identical in the UI. There is no visual difference between a title that was verified last week and one that was typed in 2021. The rep sees a filled field and trusts it. The scoring model consumes it as fact. The routing rule fires on it.

So the first fix is not enrichment at all. It is storing verification timestamps per field and surfacing them.

If you take one thing from this post, take that. Every enriched field should carry three pieces of metadata: when it was last verified, what the source was, and what confidence it carried. Without those, you cannot prioritize a refresh, you cannot audit a bad decision, and you cannot tell your reps which fields to trust.

Most CRMs do not do this natively for custom fields, so it usually means a parallel table keyed on the record ID. It is unglamorous plumbing and it is the foundation everything else in this post sits on.

One thing that makes it less painful is a provider that hands you the metadata rather than making you invent it. Renidly returns a confidence tier on resolutions and reports what each individual call consumed, so "verified on this date, at this confidence, for this cost" is something you record from the response rather than reconstruct. Whatever you use, check that you can capture those three things per field before you design the schema, because retrofitting provenance onto a table that was not built for it is a migration nobody enjoys.

Measure your own decay rate

Published benchmarks tell you what to expect. They do not tell you what you have. Your decay rate depends on your industry mix, your seniority mix, and how old your database is, and those combine into a number that can easily be double or half the published figure.

The measurement is straightforward and takes about two hours of setup plus a wait.

Take a random sample of 300 to 500 records across your CRM, weighted to match your real distribution rather than cherry-picked from your best accounts.

Snapshot every field value today, with the date.

Re-verify the same records in 90 days. For each field, count how many values changed. Multiply by four for a rough annualized rate per field.

Split the results by segment. Industry, company size, seniority. This is where the useful signal is, because it tells you which parts of your database need a different policy rather than a different budget.

Two refinements worth the extra effort. Separate genuine changes from corrections, since a value that changed because the person got promoted is decay while a value that changed because your original data was wrong is an accuracy problem and needs a different fix. And track which fields changed together, because job changes cluster: title, employer, and email all flip at once, which means detecting one lets you infer the rest.

If you want to run this comparison rigorously, including how to build a golden set so you are measuring truth rather than vendor disagreement, that method is in how to test a B2B data vendor.

Refresh by priority, not by schedule

Now the part that saves money.

The instinct is to refresh everything on a cycle. Quarterly hygiene is the standard recommendation, and cleaning on a 90 day cycle does reduce bounce rates meaningfully. But refreshing everything quarterly on a database of any size is expensive, and most of that spend goes to confirming that stable records are still stable.

The better model is a priority score per record, refreshed against a fixed budget. Something like:

1refresh_priority = decay_likelihood × business_value × staleness

Where:

• decay_likelihood comes from your field half-life table, adjusted for the segment the record sits in.
• business_value is whatever your company already uses. Open pipeline, account tier, ICP fit, lifetime value.
• staleness is time since last verification, which is why the timestamp table matters.
  Sort descending, refresh until the budget runs out, repeat next cycle. Records that are both volatile and valuable get refreshed often. Records that are stable and low-value get refreshed rarely or never, which is the correct outcome and the one a calendar-based policy cannot express.

In practice this usually means you refresh 10 to 20% of your database per cycle and capture most of the value, because decay concentrates in a minority of records.

1from datetime import date
2 
3# Half-lives in months, from your own measurement rather than a blog post
4HALF_LIFE = {
5    "email": 15, "title": 24, "employer": 30,
6    "phone": 30, "headcount": 18, "industry": 60,
7}
8 
9SEGMENT_MULTIPLIER = {"technology": 1.6, "financial_services": 1.3, "manufacturing": 0.7}
10 
11 
12def decay_likelihood(field: str, months_since: int, segment: str) -> float:
13    hl = HALF_LIFE[field] / SEGMENT_MULTIPLIER.get(segment, 1.0)
14    return 1 - 0.5 ** (months_since / hl)
15 
16 
17def refresh_priority(record) -> float:
18    months = (date.today() - record.last_verified).days / 30
19    worst_field = max(
20        decay_likelihood(f, months, record.segment) for f in HALF_LIFE
21    )
22    return worst_field * record.business_value

Scoring on the worst field rather than the average is deliberate. A record where the email is probably dead needs refreshing even if everything else is stable, because the dead email is what breaks the workflow.

Detect change instead of re-verifying everything

Here is the structural improvement most teams miss, and it is a bigger lever than any scoring tweak.

Re-enriching a record asks "what is true now?" Detecting change asks "did anything happen?" The second question is far cheaper to answer at scale, and job changes drive most of the decay in the table above.

If you can subscribe to movement rather than polling for state, you invert the whole economics. Instead of refreshing 50,000 records to find the 4,000 that changed, you watch for the 4,000 events and refresh only those.

This is what job change signals are for, and it is worth building before you optimize your refresh scoring, because it removes most of the records from the queue entirely. Renidly exposes movement as a queryable event stream with joined, left, and title_change types, an organization filter, and a recency window, so a daily poll against your customer and pipeline accounts surfaces the records that need attention without touching the ones that do not. The implementation, including the deduplication problem that trips up every first version, is in job change signals.

The same logic applies to your own customer base, and this is the version people underrate. A champion leaving an account is a renewal risk you want to know about the day it happens, not at renewal. That is a left query against your customer org IDs, run daily, and it is probably the single highest-return thing in this entire post.

Write policy: the part that causes incidents

Detecting staleness is the easy half. Deciding what to write is where teams damage their own data.

Four rules, learned expensively:

Never let an empty result overwrite a populated field. If a rep manually entered a title in March and today's refresh returns nothing, the manual value must survive. Enrichment should fill unknowns and correct stale values, never destroy known ones. This sounds obvious and is violated constantly, usually by a bulk update that treated null as a value.

Never let low confidence overwrite high confidence. This requires that your provider actually expresses confidence, which not all do. Renidly returns a four-tier value rather than a boolean specifically so you can write different code paths for certain, probable, and unsure, and so a low result can be staged for review instead of silently replacing something better. If a provider only tells you "found" or "not found," you have no basis for this rule and your only safe options are to accept everything or accept nothing.

Preserve human edits. Flag manually entered values and require higher confidence to override them. A rep who spoke to the person last week knows more than any dataset.

Log every write. Old value, new value, source, confidence, timestamp. When someone asks why a record changed, and they will, you want an answer. This log is also how you audit whether your enrichment is actually improving things or just churning fields.

Here is the write gate as code:

1def should_write(field: str, current, incoming, confidence: str) -> bool:
2    if incoming is None or incoming == "":
3        return False                              # never overwrite with nothing
4    if current is None or current == "":
5        return confidence in ("high", "medium")   # filling a gap
6    if field_was_human_edited(field):
7        return confidence == "high"               # respect the human
8    if current == incoming:
9        return False                              # no-op, do not churn the log
10    return confidence == "high"                   # replacing good data needs certainty

1function shouldWrite(
2  field: string,
3  current: string | null,
4  incoming: string | null,
5  confidence: "high" | "medium" | "low" | "none",
6): boolean {
7  if (!incoming) return false;
8  if (!current) return confidence === "high" || confidence === "medium";
9  if (fieldWasHumanEdited(field)) return confidence === "high";
10  if (current === incoming) return false;
11  return confidence === "high";
12}

The asymmetry is the point. Filling an empty field is low risk, so medium confidence is acceptable. Replacing a value that someone may already have acted on is high risk, so it requires certainty.

Budget the whole thing explicitly

A refresh program without a ceiling becomes a line item nobody understands. Decide the monthly spend first, then let the priority score allocate it.

The number to track is not credits consumed. It is cost per corrected record: total refresh spend divided by the number of fields that actually changed. If you refresh 10,000 records and 400 fields change, you paid for 10,000 lookups to fix 400 things, and that ratio is the honest measure of whether your prioritization is working.

Watch that ratio over time. If it degrades, your scoring is sending you at records that were not going to change, and the fix is in the half-life table rather than the budget.

This is easier when your provider reports cost per call rather than a monthly invoice you have to reverse-engineer. Renidly returns credits consumed on every individual response, so cost per corrected record is something you compute from your own logs rather than reconstruct at month end. Whatever you use, insist on that visibility before you build a program on top of it, because a refresh program you cannot measure will quietly become the largest unexplained line in your data budget.

For the mechanics of running large refresh batches without hitting rate limits or losing your place halfway through a 50,000 record job, see batch enrichment at scale.

Fix the intake, not just the database

Everything above is remediation. The cheapest record to keep current is the one that entered clean.

Enrich at the point of capture. A record created from a form submission with an email address and nothing else will be incomplete forever unless someone fixes it later, at a cost. Resolving it at intake means it starts complete and starts its decay clock from a known date. The patterns for doing this without slowing down your signup flow are in reverse email lookup in your signup flow.

And store stable identifiers alongside the human-readable values. If you key records on a company name or a profile handle, your refresh pipeline will break silently when those strings change, and you will attribute the breakage to the vendor. The reasoning is in the primer on identity resolution.

The argument against most of this

Now the honest part.

If your database is under about 5,000 records, ignore the scoring model. Refresh everything quarterly, accept the cost, and spend the engineering time elsewhere. The prioritization machinery only pays off at a scale where refreshing everything is genuinely expensive.

If your sales motion is inbound-heavy and your reps verify contacts on the call anyway, your effective decay rate is much lower than the published numbers, because the humans are doing continuous correction for free. Outbound teams working from lists are the ones who eat the full cost of decay.

And be suspicious of the cost-of-bad-data figures, including the ones in the research above. Gartner's frequently cited figure of about $12.9 million a year per organization is an average across enormous companies and tells you almost nothing about your situation. It is a useful number for getting budget approved and a bad number for deciding how much to spend.

The defensible business case is narrower and stronger: measure your own bounce rate, your own rep time spent on research, and your own misrouted leads. Those are numbers you can verify, and they are usually sufficient on their own.

Finally, there is a real risk of over-refreshing. Every write is a chance to overwrite something good with something worse. A team that refreshes aggressively without the write gates above will degrade its own data while believing it is improving it, and the damage is invisible for months.

The one-line version

Stop treating decay as one number. Build a field-level half-life table, segment it by industry and seniority, store per-field verification timestamps so staleness is visible at all, prioritize refresh by decay likelihood times business value times staleness, detect change events instead of blindly re-verifying, and gate every write so nothing empty or uncertain can overwrite something good.

The highest-return single action in that list is the smallest one: run a left query against your customer accounts, daily. Everything else is optimization. Finding out that a champion walked out of a renewal account three months before the renewal conversation is the kind of thing that pays for the whole program by itself.

If you want to measure your own decay rate before committing to any of this, there are 100 free credits with no card required, which covers a 300-record baseline snapshot comfortably. Take the snapshot now, run it again in 90 days, and you will have a number that describes your database rather than the industry's.