Refresh Cadence and Decay
Outcome: a written refresh cadence per field, a detect-then-refresh loop that costs a fraction of re-enrichment, and bounce feedback wired back into the table.
- Surface
- App and MCP server
- Level
- Beginner
- Uses
- verify_email · check_job_change
- Credits
- ~0.3 per row re-verified
- Prerequisite
- Lesson 07
How fast each field decays
| Field | Annual decay | What causes it |
|---|---|---|
| Work email | ~20–30% | People change jobs; roughly 2% a month move |
| Job title | ~30% | Promotions, reorgs, role changes |
| Company | ~20% | Same job-change driver |
| Mobile number | ~10% | Numbers are portable and persist |
| Work phone | ~25% | Tied to the desk, so it dies with the job |
| Company firmographics | ~10% | Headcount and funding move; identity does not |
| Personal email | ~5% | The most durable contact field there is |
The headline consequence: a contact list is worth roughly three quarters of its original value after a year, and the decay is concentrated in exactly the fields you send to.
Detect, then refresh
The pattern that makes this affordable. Re-enriching a contact costs about a credit. Checking whether they moved costs about the same but tells you which rows need it — so you re-enrich a fraction instead of everything.
Run a job-change check across the list
Weekly or monthly, depending on list size and value.
Split the result
Moved, not moved.
Re-enrich only the movers
New company, new title, new email, then verify.
Leave the rest alone
Their data has not changed. Paying to re-fetch it produces the same values at full price.
On a list where 2% move per month, this is roughly a twentieth of the cost of blanket monthly re-enrichment — and it produces a job-change signal as a by-product, which is one of the highest-converting triggers there is. See Job Changes & Champions.
This is the single most valuable idea in the lesson: the change check is not overhead on top of the refresh. It is the refresh, and it doubles as a lead source.
Re-verify on bounce, not on a timer
Blanket re-verification of a whole list quarterly is expensive and mostly redundant — most addresses are still fine.
Better triggers:
| Trigger | Action |
|---|---|
| Hard bounce | Mark invalid immediately, remove from all lists, flag for re-enrichment |
| Soft bounce, repeated | Re-verify that row |
| Job change detected | Re-enrich and verify |
| About to enter a campaign after 6+ months idle | Re-verify that batch only |
| Nothing has happened | Do nothing |
The last row is the one that saves the money. An address that has not bounced and whose owner has not moved does not need re-checking.
A cadence table to copy
| Field | Cadence | Trigger |
|---|---|---|
| Job change check | Monthly | Scheduled |
| Work email | On job change, or before a campaign after 6 months | Event |
| Verification | On bounce, or pre-campaign for idle lists | Event |
| Job title | On job change | Event |
| Company firmographics | Quarterly | Scheduled |
| Phone | On failed call | Event |
| Personal email | Annually, if at all | Scheduled |
Note how much of it is event-driven. Scheduled refresh is the fallback for fields with no available change signal, not the default.
Bounce feedback has to close the loop
A bounce that only exists in your sequencer is information you paid for and did not keep.
- Pull bounce data back from the sending tool.
- Mark the row invalid in the source table.
- Trigger re-enrichment for that person.
- Suppress the address permanently, everywhere.
Without step 4 in particular, the same dead address gets re-imported from a different list next quarter and bounces again.
Do this now
Write the cadence table
Per field, with the trigger.
Schedule the job-change check
Monthly for most lists.
Build the moved/not-moved split
And the re-enrichment path for movers only.
Wire bounce data back
From your sequencer into the table.
Build the permanent suppression list
Hard bounces and unsubscribes, checked on every export.
Add a pre-campaign verification step
For batches idle more than six months.
Compare costs
Blanket quarterly refresh versus detect-then-refresh, on your own list size. Write both numbers down.
Check your work
- Every contact field has a cadence and a trigger
- Refresh is driven by change detection, not by a timer
- Bounces flow back from the sequencer into the table
- Suppression is permanent and applies across every list
- You can state the cost difference between the two refresh strategies
Where this breaks
Blanket monthly re-enrichment of a full contact list is one of the most expensive habits in GTM automation, and it looks responsible rather than wasteful. On a 5,000-row list it costs roughly twelve times a year what a change-driven refresh does, to produce identical values for the 98% of people who did not move. Detect first. Always.
Course complete
You now have a waterfall with a measured hit rate, verification separating real addresses from guesses, a written catch-all policy, defensible fallback paths for personal email and phone, reverse lookup for bare-address lists, honest unit economics, and a refresh loop driven by change rather than by a calendar.
Where to go next:
| You want | Course |
|---|---|
| To send to what you built | Automated Outbound |
| To fix the records you already own | CRM Enrichment |
| The job-change signal as a play in itself | Job Changes & Champions |
| The concepts behind the economics | GTM Engineering Foundations |
Reference for this lesson: Job change, check_job_change, Verify email, CRM integrations.