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

*Draw a dated, stratified sample, grade employer, title, email and phone against public evidence, and set a per-segment refresh interval with a confidence bound.*

- Canonical URL: https://www.refolk.ai/guides/contact-decay-measurement-playbook
- Pillar: Process, data, and compliance
- Format: Playbook
- Published: 2026-11-09
- Last reviewed: 2026-11-09
- Reading time: 21 min
- Keywords: how to measure crm data decay rate, contact data decay rate by field, how often to re-verify contact data, b2b contact data refresh cadence, candidate database stale records how to measure, last verified date field re-verification policy

## Key takeaways

- Much of the threefold spread in published contact decay rates comes from arithmetic: a 3.6% monthly email rate quoted as 43% a year compounds to 35.6%, and a 5.5% monthly title rate quoted as 65.8% compounds to 49.3%.
- BLS median tenure of 4.1 years implies a 15.5% annual employer-change rate and a 7.5-month refresh interval at a 90% accuracy floor, but this is only a prior because observed one-year churn (20.6%) is 1.33 times what a constant hazard predicts.
- A 100-record sample with 30 stale records gives a Wilson 95% interval of 21.9% to 39.6%, too wide to set a refresh interval; a 30% stale stratum needs about 323 records for a margin of plus or minus 5 points.
- In Refolk's index, 25-profile samples of Account Executives gave Wilson intervals of 44.5% to 79.8% (US) and 60.9% to 91.1% (UK), which overlap by about 19 points, so samples that small cannot tell two markets apart.
- A single re-check is current-status data, so fit a constant hazard with lambda = -ln(1 - p)/t per age band and reserve Kaplan-Meier for evidence that dates the change itself.
- Set each refresh interval as T = -ln(A)/lambda using the upper confidence bound of lambda, then test it every quarter on records sitting exactly at their 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:

| Published claim | What it actually is | Corrected reading |
|---|---|---|
| Email ~3.6%/mo, "~43%/yr" | Monthly rate x 12 | 35.6%/yr compounded |
| Title 5.5%/mo, "65.8%/yr" | Monthly rate x 12 | 49.3%/yr compounded |
| 70.8% "some change" in 12 mo | Union of all fields | Not a per-field rate |
| 2.1%/mo, 22.5%/yr | Compounded correctly | Method not public |
| "70.3%/yr, per Gartner" | Traced by a vendor | No Gartner source found |

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.

> **Rule:** Compound, never multiply by 12
>
> Annual change = 1 - (1 - m)^12, and monthly = 1 - (1 - a)^(1/12). Any figure built as "monthly x 12", including one sales tool's worked formula (78 / 500) x (12 / 6), overstates the annual rate.

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:

| Segment | Median tenure (yrs) | Implied annual change | Refresh at 90% floor |
|---|---|---|---|
| All workers | 4.1 | 15.5% | 7.5 mo |
| Private sector | 3.9 | 16.3% | 7.1 mo |
| Management occupations | 6.1 | 10.7% | 11.1 mo |
| Ages 25 to 34 | 3.0 | 20.6% | 5.5 mo |
| Leisure and hospitality | 2.4 | 25.1% | 4.4 mo |

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%.

**1.33x - Observed share of US workers at one year or less of tenure, versus what a constant hazard predicts**

BLS shows 20.6% against a predicted 15.5%, so people who just moved are likelier to move again, which is why this playbook stratifies by record age.

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.

| Field | Graded stale when | How it lies |
|---|---|---|
| Employer | Dated evidence of a different employer | Profile lag shows a false "current" |
| Title | A change the rubric calls material | Formatting variance ("Sr. AE") looks like change |
| Email | Was deliverable, now undeliverable | Catch-all domains return a false "valid" |
| Phone | Rubric-defined evidence it no longer reaches the person | No published standard exists |

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.

> **Rule:** Evidence must postdate the stored verification date
>
> A grade of "current" needs evidence dated after the record was last verified. Undated evidence, or evidence older than the verification, makes the field unresolvable, not current.

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

**Grading rubric and evidence log schema**

```
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
```

*Replace the example material-change list with your own, and freeze it before fieldwork starts.*

## 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.

| Expected stale share | n for +/-5 pp | n for +/-10 pp | +/-5 pp, stratum of 1,000 |
|---|---|---|---|
| 10% | 139 | 35 | 123 |
| 20% | 246 | 62 | 198 |
| 30% | 323 | 81 | 245 |
| 40% | 369 | 93 | 270 |

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:

| Segment | Population in index | Title matches search | Wilson 95% CI |
|---|---|---|---|
| US Account Executive | 248,476 | 16/25 (64%) | 44.5% to 79.8% |
| UK Account Executive | 17,905 | 20/25 (80%) | 60.9% to 91.1% |
| US Software Engineer | 353,257 | 23/25 (92%) | 75.0% to 97.8% |

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.

#### From dated sample to written refresh interval

1. **Write the per-field grading rubric** - With the data steward, define current, stale, and unresolvable for employer, title, email, and phone, and list which evidence counts. About half a day; done when two reviewers would grade the same record the same way.
2. **Inventory verification dates into three bins** - The CRM or ATS admin sorts every record into true last-verified date, created date only, or no date. About half a day; done when the count in each bin is recorded.
3. **Stratify and size the sample** - Build strata as segment by age band, set n per stratum from the sample-size table, and draw with a recorded random seed. About half a day; done when the sample file and seed are frozen.
4. **Clear the legal basis and freeze the log schema** - With the DPO, confirm lawful basis and the Article 14 position, and fix the log fields. Half a day to a day; done when the DPO has signed off.
5. **Re-check fields blind against public evidence** - Researchers grade every sampled field without seeing the stored value where possible, and a second grader re-checks about 10% of records. Two to three days; done when every field has a grade and evidence and the agreement rate is reported.
6. **Estimate stale share and hazard per stratum** - Compute the stale proportion per field and stratum with a Wilson interval, then lambda and half-life, and compare employer results with the BLS prior. About half a day; done when there is a table of lambda with confidence bounds.
7. **Convert each rate into a refresh interval** - Apply T = -ln(A)/lambda using the upper confidence bound of lambda. About two hours; done when the written policy lists an interval per segment.
8. **Re-measure at the interval every quarter** - Sample records sitting exactly at their interval and test whether the observed stale share is consistent with the predicted 1 - A. About a day per quarter; done when a pass or fail is recorded.

**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.

I ran this search: `Software Engineers at Google in Seattle who changed employer in the past 6 months` - [see the full result list](https://www.refolk.ai/s/3f5hmdeabs).

*Returns matching profiles with their current employer and title, a fast way to see what employer-field decay looks like in one segment before you grade your own sample.*

**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.

#### Choosing the decay estimator

Horizontal axis runs from Change date unknown to Change date evidenced. Vertical axis runs from Ages clustered in band to Ages spread widely.

| Quadrant | What it means |
| --- | --- |
| Fit constant hazard by likelihood | Solve the one-parameter likelihood across all record ages, or use Turnbull for a curve |
| Kaplan-Meier is valid | The evidence dates each change, so a survival curve is unbiased |
| Use the closed form | lambda = -ln(1 - p)/t with t the typical age in the band |
| Either method works | Closed form for the policy, Kaplan-Meier as a cross-check |

*Whether your evidence dates the change and how spread your record ages are decides which estimator is valid.*

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.

#### From measured stale share to written interval

1. **Stale share** - Resolvable stale fields over resolvable fields, per stratum, with a Wilson interval
2. **Hazard** - lambda = -ln(1 - p)/t, or the likelihood fit across ages
3. **Upper bound** - Convert the upper Wilson bound into the upper bound on lambda
4. **Interval** - T = -ln(A)/lambda at the chosen accuracy floor
5. **Policy and test** - Write T per segment and re-test it quarterly at that age

*The interval in the policy comes from the upper bound of the hazard, not the point estimate, so it survives being questioned.*

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:

**Refresh policy entry (one per segment and field)**

```
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]
```

*One block per segment; attach the stratum table and the evidence log as appendices.*

> 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.

> **Watch out:** The email rate depends on your grading convention
>
> Because part of every email sample cannot be resolved by verification, the same list can show very different decay rates depending on whether accept-all and unknown results count as stale. Compare email rates only between measurements graded the same way.

## 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.

#### Before you call the interval done

- [ ] The rubric defines current, stale, and unresolvable for all four fields, and was frozen before fieldwork.
- [ ] Every record is assigned to a verification-date bin, and the bin counts are recorded.
- [ ] The sample was drawn with a recorded seed, and each stratum meets its planned n.
- [ ] Unknown-date records are reported as their own stratum and labelled as a lower bound.
- [ ] The DPO has signed off on the lawful basis, the Article 14 position, and the log schema.
- [ ] Every graded field has an evidence URL and an evidence date later than its last-verified date.
- [ ] A second grader re-checked about 10% of records, and the agreement rate is reported.
- [ ] Catch-all and unknown email results are excluded from the denominator and reported separately.
- [ ] All annual figures are compounded from monthly rates, never multiplied by 12.
- [ ] Every interval uses the upper confidence bound of lambda, and the policy states the accuracy floor.
- [ ] The first quarterly re-measurement is scheduled, and the pass or fail rule is written down.

## Frequently asked questions

### How often should I re-verify contact data in my CRM?

Re-verify each segment at T = -ln(A)/lambda, where lambda is your measured monthly decay hazard for that segment and A is the accuracy floor you commit to. Until you have measured, the BLS tenure prior gives a sanity check for the employer field at a 90% floor: about 7.5 months for all workers, 4.4 months for leisure and hospitality, and 11.1 months for management occupations. Treat those as starting points to test, not as the policy.

### How many records do I need to sample to measure data decay?

Per stratum, between about 35 and 369 records at 95% confidence, depending on the stale share you expect and the margin you need. A stratum expected to be 30% stale needs 323 records for plus or minus 5 points, or 81 for plus or minus 10. If a stratum holds only 1,000 records, the finite population correction cuts 323 to 245. The total cost is per-stratum n multiplied by the number of strata.

### What do I do with records that have no last-verified date?

Use the created date as the earliest possible verification date and put these records in their own stratum. Because the true verification happened on or after creation, this overstates how long the record has been exposed, so the hazard you estimate is a lower bound. Never pool these records with dated ones. Going forward, add a last-verified date field and write to it every time a field is confirmed.

### Why not just use a published vendor decay rate?

Published annual figures disagree too much to defend: from 15% to 65.8% for title and 15% to 42.9% for phone, mostly with no methodology. Some are monthly rates multiplied by 12, one is a union of all fields, and one widely repeated figure attributed to Gartner could not be traced to any Gartner source. None reflects your segment mix or how old your records are.

### Should catch-all email addresses count as decayed?

No. Grade them unresolvable, keep them out of the denominator, and report their share separately. A catch-all domain accepts every address, so a valid result proves nothing, and one large verification study counted over 1 billion catch-all addresses. The one published email decay definition counts Accept-All as decayed, so state in your policy which convention you used, because it moves the measured rate.

### Does re-checking records against public profiles create GDPR obligations?

It can, and you should clear it with your DPO before fieldwork. Article 5(1)(d) requires personal data to be accurate and, where necessary, kept up to date, and Article 14 applies to data obtained from publicly available sources, with notice due within a reasonable period and no later than one month. Whether finding a new employer counts as newly obtained data that restarts that clock is not established and needs counsel.

---

*From the Refolk guide library. I revise these guides rather than replacing them, so the current version is always at https://www.refolk.ai/guides/contact-decay-measurement-playbook*