Article summary
Avoid weekly or monthly full-database rechecks; set differentiated cadence from field decay, decision timing, events, check cost and error consequence.
The most economical time to recheck a phone is not the first day of every month. It is when an old observation is about to affect a real decision and the value of checking exceeds its cost. A fixed full-database cycle repeatedly processes opt-outs, closed cases and records that will never be used, while forcing fields with different lifetimes onto one date.
Give each observation a lifetime
| Observation | Why it decays | Refresh basis |
|---|---|---|
| Phone format | Rule and entry correction | Normalization-version change |
| Platform registration | Accounts can appear, disappear or migrate | Before a business window |
| Platform activity | Time-sensitive by nature | Short-term decision need |
| Nickname/profile | User-controlled and missing | Approved analysis requirement |
| Permission | Revocable or expiring | Read at every action |
Derive cadence from the cost of error
If stale registration merely costs a seller one extra minute, refresh can be infrequent. If it affects an important service notice, verify closer to the event. Profile data usually deserves less frequent refresh because incremental value is low and governance cost is high. Permission never relies on a batch schedule; read current state at action time.
Four event triggers beat a fixed calendar
- A customer resubmits or changes a phone;
- an order, support case or approved campaign is about to begin;
- a national numbering rule or normalization version changes;
- an existing observation enters aging and will still be used.
No business event, ended purpose or opt-out means no trigger.
Create freshness states
| State | Meaning | System action |
|---|---|---|
| fresh | Inside use-case window | May contribute to limited decision |
| aging | Near threshold | Queue only when a decision exists |
| stale | Beyond validity | Stop ranking use |
| unknown | No explicit observation | Never treat as negative |
| suppressed | Purpose or permission veto | No outreach-driven recheck |
Use expected value to decide
A useful expression is: refresh value = reduction in wrong-decision probability multiplied by the cost of that error, minus check, review, storage and governance cost. It need not produce a perfect currency figure; estimating each component shows why “the data looks old” is not sufficient.
Different customer stages need different cadence
An active support customer, a recent voluntary inquiry, a dormant list and a historic opt-out should not share one interval. The first two refresh near a service event. A dormant list first needs a continuing purpose. An opt-out retains only necessary suppression and is never rechecked to find a new marketing opportunity.
Prevent refresh storms with batch design
Shard the aging queue by deadline, platform, country and task, limiting daily budget and concurrency. AIPUSH receives one phone per TXT line. Append the new Excel observation with checked_at and preserve the old one; overwriting history prevents measurement of what refresh changed.
Scheduling another attempt after unknown
Separate input error, system failure and business unknown. Retry a system error with backoff, correct a format error through rules, and recheck a business unknown only when decision value justifies another time. Endless attempts at unknown merely multiply cost.
Backtest the interval
Compare observations separated by different periods and calculate change by platform, country, source and field. Then ask whether change actually altered a business action. If ninety-day change is small and inconsequential, extend the interval; if a critical cohort changes frequently within thirty days, shorten only that cohort.
Guardrails for a refresh policy
Every policy names an owner, maximum frequency, budget, stop condition, allowed task and deletion period. Pause automation when the field definition changes and reaccept the schema first. No activity result can override current permission.
The economical rule
Recheck when three conditions coexist: the data will soon be used, staleness may cause a costly error, and an appropriate purpose still exists. Otherwise wait for an event or let the observation expire. Precise triggers cost less than a full-database calendar job and better support data minimization.
