The Contact Decay Playbook: Dated Sample to Per-Segment Refresh Interval

This playbook is for recruiting operations, revenue operations, and anyone who has to defend how often person records get re-checked. It takes you from a dated, stratified sample of your own CRM or ATS records to a measured monthly decay rate for each field and segment, with a confidence interval, and then to a written refresh interval for each segment plus a quarterly test that shows whether the interval still holds. Planned well, the fieldwork fits in about a week.

Why do published contact decay rates disagree by a factor of three?

Mostly because of arithmetic and definitions, not because the underlying data disagrees. Vendor pages quote anywhere from about 22% to 70% a year, but two of the high figures are monthly rates multiplied by 12, and the highest is a union of every field rather than any one field's rate.

Here is what the most-quoted figures actually are once you trace them:

Even after cleanup, the per-field ranges stay wide. Published annual figures run from 15% to 65.8% for title and from 15% to 42.9% for phone, and most pages give no methodology at all. The email side has bigger studies behind it: one verification vendor analysed more than 11 billion addresses and reported at least 23% decay a year, down from 28%, and another studied 826,000 addresses verified two or more times. Both measure deliverability only. Neither tells you whether the person still works where your record says they do.

The deeper problem: even a perfectly computed vendor rate describes the vendor's list, not yours. Your segment mix, your record ages, and the way your team defines "changed" all move the number. That is why you measure.

What does the tenure prior predict, and why is it only a prior?

US Bureau of Labor Statistics (BLS) tenure data gives a sanity check for the employer field: a median tenure of 4.1 years converts to about a 15.5% annual chance of employer change and a 7.5-month refresh interval at a 90% accuracy floor. It is a prior to compare against, never the answer, because real job-change risk is front-loaded.

A prior here means an outside estimate you hold before measuring, used to catch results that are implausible. The conversion assumes a constant hazard, the monthly rate at which a still-true field turns false:

• lambda = ln 2 / median tenure (in months)
• monthly change probability = 1 - e^(-lambda)
• annual change probability = 1 - 0.5^(1 / median in years)
• refresh interval at accuracy floor A: T = -ln(A) / lambda

Applied to BLS Employee Tenure Table 5:

The medians are from BLS; every other column is derived. Three limits apply. The table covers the employer field only. BLS measures time elapsed in the current job, not completed job spells. And it describes US workers, so it is a weak prior for other markets.

The biggest limit is the constant-hazard assumption itself. At a 4.1-year median, a constant hazard predicts that 15.5% of workers have been in their job a year or less. BLS observed 20.6%.

One more use of the prior: it absorbs much of the most-cited vendor total. If employer change alone accounts for about 15.5% a year, a 22.5% all-field figure leaves roughly 7 points for email, phone, and title drift among people who stayed put. That decomposition is derived and unverified, but it is a useful check on your own per-field results. To keep the prior current, pull the latest release of BLS Table 5 and recompute the columns above with the same formulas.

What counts as stale? The per-field evidence standard

A field is stale when dated public evidence, newer than the record's last verification, shows the stored value no longer describes the person. It is current when dated evidence confirms it, and unresolvable when no adequately dated evidence exists. No public framework sets this standard per field for contact records, so you write it yourself, before fieldwork starts.

The vocabulary comes from data quality practice. DAMA defines accuracy as "the degree to which data correctly describes the 'real world' object or event being described", and classes currency, latency, and volatility under timeliness. What you are measuring is volatility: how fast a once-accurate value stops describing the person.

Email is the only field with a published definition: an address verified Deliverable that later verifies as Undeliverable, Accept-All, or Unknown. I recommend departing from it on one point. Grade Accept-All and Unknown as unresolvable, keep them out of the denominator, and report their share separately. Whichever convention you choose, write it into the policy, because it moves the measured email rate.

Copy this rubric and log schema into the measurement workbook before anyone opens a record:

GRADES (one per field, per record)
  CURRENT       dated evidence after last-verified date confirms the stored value
  STALE         dated evidence after last-verified date shows a different value
  UNRESOLVABLE  no evidence, undated evidence, evidence older than last-verified, or catch-all / unknown email result

FIELD RULES
  Employer  stale = different legal employer; acquisitions and renames graded current if the person did not move
  Title     stale = material change only (e.g. Account Executive -> VP of Sales, Founder, COO)
            not stale = seniority prefixes, abbreviations, punctuation ("Sr. AE" vs "Account Executive")
  Email     stale = previously deliverable, now undeliverable
            unresolvable = accept-all or unknown verification result
  Phone     stale = [write your evidence rule here before fieldwork]

LOG ROW (one row per field checked)
  record_id | segment | age_band | field | prior_value | observed_value | grade | evidence_url | evidence_date | grader | check_date | second_grader | second_grade

How many records do you need per stratum?

Between about 35 and 369 per stratum at 95% confidence, depending on the stale share you expect and the margin you need. The familiar "pick 100 records" method, with 30 found stale, gives a Wilson 95% interval of 21.9% to 39.6%, which is too wide to set an interval anyone should defend.

A stratum is a subgroup sampled separately: here, segment crossed with record age band (0 to 6, 6 to 12, 12 to 24, and 24+ months since verification). The planning formula is n = z^2 p(1 - p) / E^2 with z = 1.96, where p is the expected stale share and E the margin. For small strata, apply the finite population correction (FPC), n / (1 + (n - 1)/N), which shrinks the requirement when the stratum itself is small.

For the interval itself, use Wilson, not the textbook Wald interval. Brown, Cai and DasGupta found that the Wald interval "suffers from particularly erratic coverage properties, and cannot be recommended for general use". Wilson keeps coverage close to nominal even for small samples, while Wald stays below target even for large ones.

To show what undersized strata cost, I drew 25-profile samples from Refolk's index of professional profiles and checked how many people's current title is literally the searched title:

The US and UK Account Executive intervals overlap by about 19 points, so at n = 25 no difference between the markets can be claimed, even though the point estimates differ by 16 points. The non-matches matter too: the 9 US records that differed included VP of Sales, President, COO, and Founder, which are real moves, alongside variants that may be formatting only. That is exactly the distinction the rubric has to settle in advance.

The per-stratum n is the real cost driver. My rule of thumb: buy plus or minus 5 points for the strata that carry most of your volume or your budget argument, and accept plus or minus 10 points for the rest. FPC only helps when a stratum is genuinely small. A segment of 17,905 records gets almost nothing from it.

The decay measurement procedure, step by step

Eight steps, roughly one week of elapsed work for an ops lead, an admin, a DPO, two researchers, and an analyst. All durations are planning estimates; no source publishes timings, so track your own and adjust next time.

On step order. Sources disagree on where the legal check belongs. Compliance-led teams run step 4 first, and if your DPO prefers that, do it; nothing in steps 1 to 3 touches external data.

On the legal check. Article 5(1)(d) requires personal data to be "accurate and, where necessary, kept up to date", and what counts as a reasonable step depends on the nature of the data and its use, which is a decent argument that measuring decay is part of meeting the principle. Article 14 applies to data obtained from publicly available sources, with notice due within a reasonable period and no later than one month, or at first communication if that is earlier. Whether a re-check that finds a new employer counts as newly obtained data that restarts that clock is not established. Put the question to counsel in writing. No public source sets a logging schema for a measurement exercise either. The nearest precedent is the ICO checklist instruction to "record the source of all such information", which comes from law-enforcement guidance but is the right instinct: every grade carries an evidence URL and an evidence date.

On fieldwork. Step 5 is where the week goes. Hand-checking employer and title for several hundred records means searching LinkedIn, GitHub, and the open web one name at a time, and it is easy to drift into grading whatever turns up first. Refolk cuts that search time: a researcher asks in plain English for the population a stratum covers and gets back profiles with current employer and title to compare against the stored values, while still logging the evidence URL and date per field as the schema requires.

On the alternative you will be offered. Vendor pages suggest you "verify your list at two points six months apart and use the difference". That works for email deliverability if you can afford to verify the whole list twice. It gives no per-segment interval, says nothing about employer or title, and invites the linear annualisation error from the first section.

How do you estimate decay when records have different ages?

Treat each re-check as current-status data: you learn whether the field changed by the time the record reached age t, not when it changed. Fit a constant hazard per stratum, using lambda = -ln(1 - p)/t when ages in the stratum are similar, and keep Kaplan-Meier for cases where the evidence dates the change itself.

Current-status data, also called case-1 interval censoring, is what you get from a single look at each record: a yes or no at a known age. For interval-censored data, the Kaplan-Meier estimate cannot be computed, and forcing it produces biased curves. The Turnbull estimator generalises Kaplan-Meier to censored and truncated data if you want a nonparametric curve. For a refresh policy, a one-number hazard per stratum is usually enough.

The math, all derived rather than sourced:

• Closed form, similar ages. lambda = -ln(1 - p) / t, with p the stale share among resolvable fields and t the band's typical age in months.
• Likelihood, spread ages. Choose lambda to maximise the sum over records of y_i ln(1 - e^(-lambda t_i)) - (1 - y_i) lambda t_i, where y_i is 1 if stale and t_i is that record's age. It is a one-parameter solve; a spreadsheet solver handles it.
• Half-life. ln 2 / lambda, the age at which half of records in the stratum have that field stale.
• Confidence bound. Within an age band, convert the Wilson bounds on p through the closed form. The upper Wilson bound gives the upper bound on lambda.

Stratifying by age band also tests the constant-hazard assumption. If the 0 to 6 month band shows a clearly higher lambda than the 24+ band, with non-overlapping intervals, the hazard is front-loaded, as the BLS comparison suggests it will be. In that case set the interval from the band your refreshed records will actually sit in, which after a refresh is the youngest one.

Records with no verification date. No public source describes how to handle these, so this is a derived convention. Use the created date as the earliest possible verification date. Since the true verification happened on or after creation, this overstates exposure, and the hazard you estimate is a lower bound. Report these records as their own stratum and never pool them with dated records.

Finally, compare every employer-field lambda with the BLS prior for the closest segment. A measured rate far below the prior usually means profile lag is producing false currents, not that your contacts are unusually loyal.

How do you convert a decay rate into a refresh interval?

Use T = -ln(A) / lambda, where A is the accuracy floor you commit to (for example 0.9, meaning at least 90% of a field still current at refresh time) and lambda is the upper confidence bound of the stratum's hazard. Using the upper bound is what makes the interval defensible: it is the shortest interval the data plausibly requires.

A worked example using the "pick 100" numbers. Suppose the 100 records were all about 12 months past verification and 30 were stale. The point estimate is lambda = -ln(0.7)/12, about 0.030 a month, a half-life of about 23 months, and an interval at a 90% floor of about 3.5 months. The upper Wilson bound is 39.6%, which gives lambda of about 0.042 and an interval of about 2.5 months. That one-month gap is the price of an undersized sample, and finance should see it stated plainly.

Record the result in a form someone else can audit:

Segment:                      [e.g. US Account Executives]
Field:                        [employer / title / email / phone]
Sample:                       n = [ ], drawn [date], seed [ ], age band [ ]
Resolvable fields:            [ ]   Unresolvable: [ ] ([ ]%), reported separately
Stale share p:                [ ]%  (Wilson 95%: [ ]% to [ ]%)
Hazard lambda (per month):    point [ ]  upper bound [ ]
Half-life (months):           ln(2) / lambda = [ ]
Accuracy floor A:             [0.90]
Refresh interval T (months):  -ln(A) / lambda_upper = [ ]
BLS prior for comparison:     [ ] months at 90% (employer field only)
Email convention:             accept-all and unknown graded unresolvable
Grader agreement (10% check): [ ]%
Next re-measurement:          [quarter]
Approved by:                  [ops lead] / [DPO]

A refresh interval you cannot re-test is a guess with a spreadsheet attached.

How decay measurement goes wrong

Most bad decay numbers fail in one of eight predictable ways, and each one has a cheap check. Read this section before step 5 and again before step 6.

1. Linear annualisation. Monthly rates multiplied by 12 turn 3.6% into "43%" and 5.5% into "65.8%"; compounded, they are 35.6% and 49.3%. What it looks like: an annual figure that is exactly twelve times a monthly one. Check: annual = 1 - (1 - m)^12.
2. Catch-all graded as valid. A catch-all domain accepts every address, so an SMTP "valid" result is a false current. One large verification study found over 1 billion catch-all addresses, so this is not an edge case. Check: grade them unresolvable and report them separately.
3. Title variance graded as decay. "Sr. AE" versus "Account Executive" is formatting, not change. In Refolk's index, 9 of 25 US Account Executive profiles differed from the searched title, and some of those differences may be normalisation rather than moves. Check: the rubric's material-change list, frozen before fieldwork.
4. Wald intervals on small strata. Wald coverage is erratic, and at n = 25 even Wilson intervals are too wide to separate markets. Check: Wilson intervals and the per-stratum sizes in the sample-size table.
5. Kaplan-Meier on current-status data. When the change date is unknown, Kaplan-Meier gives biased curves. Check: use it only when the evidence dates the change, such as a start date for the new role.
6. Unknown-date records pooled in. Treating creation as verification inflates exposure and deflates lambda across the whole estimate. Check: keep them as a separate stratum labelled as a lower bound.
7. Public profile lag treated as truth. People update profiles late, which produces false current grades and a hazard that is too low. How common this lag is remains unverified, so do not assume a correction factor. Check: require evidence dated after the stored verification date, and treat a measured employer rate well below the BLS prior as a warning.
8. The BLS prior used as the answer. A constant hazard at a 4.1-year median predicts 15.5% of workers at a year or less of tenure; BLS observed 20.6%. Check: use the prior only to flag implausible results, never to set the interval.

Keeping the interval current: the quarterly re-measurement

Once a quarter, spend about a day sampling records that sit exactly at their refresh interval and test whether the observed stale share is consistent with the predicted 1 - A. If the Wilson interval of the observed share contains 1 - A, the interval passes; if the whole interval sits above it, shorten the refresh; if it sits below, you have room to lengthen it.

This sample can be smaller than the original, because you are testing one prediction per segment rather than estimating from scratch. Use the plus or minus 10 point column of the sample-size table as a floor. The same rubric, log schema, and email convention apply, or the comparison means nothing. Refolk speeds the quarterly re-check the same way it speeds the first one: ask for the segment in plain English and compare current employer and title against the stored values, logging evidence dates as you go.

Re-run the full measurement, not just the quarterly test, when any of these happen: a segment fails two quarters running, your segment mix shifts materially, you change the rubric, or BLS publishes a new tenure release that moves the prior for a segment you rely on.