Stale Preferences Are Worse Than No Preferences
A preference a customer set two years ago is not a fact about them now. Systems that treat old preferences as permanent truth personalise confidently toward a person who no longer exists.
Preference data feels permanent because it was explicit: the customer said it, in a form, on a date you can point to. That explicitness is exactly the trap. A stated preference is a snapshot of a person's taste, sizes, household, and circumstances at one moment, and every one of those inputs moves. The customer who set 'no emails about children's products' has a child now. The size preference from three years ago describes a different body. The favourite category from a lockdown hobby is a museum piece. A system with no preference data personalises from recent behaviour, which is at least current. A system holding stale preferences personalises from a fossil, and does it with more confidence, because stated data outranks behavioural data in most rule stacks. The result is the worst cell in the matrix: wrong, and certain. Preferences need expiry, re confirmation, and a standing rule that recent behaviour can overrule an old statement when the two disagree loudly enough.
Give every preference a half life
Not all preferences decay at the same speed, so expiry should be typed, not uniform. Identity facts, name, pronouns, accessibility needs, change rarely and should persist until the customer changes them. Taste preferences, categories, styles, brands, decay in a year or two. Circumstantial preferences, sizes, dietary patterns tied to a phase, household composition, can invert completely and deserve the shortest leash. The mechanics are simple: store the date and the type with every preference, apply a decay window by type, and after the window the preference stops driving decisions until behaviour or a fresh statement renews it. Nothing is deleted. It just stops testifying about the present.
Related reading on this site: PrefEngine and Nobody Wants a Preference Center. They Want the Emails to Stop Being Wrong. cover the neighbouring problems in more depth.
Re confirmation should ride along, not arrive as homework
Nobody completes a preference review task, so do not send one. Re confirmation works when it is folded into moments the customer is already present: a line in the account page they actually visit at checkout, a single question in a post purchase flow, an annual email whose entire content is 'still true?' with the current settings shown. Each touchpoint renews the preferences it touches and lets the customer correct the ones that moved. The stale share of the preference base shrinks without a campaign, a nag, or a settings page redesign.
Watch the disagreement signal as well. When recent behaviour contradicts a stated preference repeatedly, buying the excluded category three times, choosing the size the profile says is wrong, the system should flag the preference as contested and stop enforcing it until a human signal resolves the conflict. Enforcing a preference against the customer's own repeated behaviour is not respect for their choices. It is obedience to their past.
Measure the stale share before you argue about it
The audit is one query: what share of active preferences in the system are older than their type's decay window, and what share of those have been contradicted by behaviour in the last year? Most preference programs have never run it, and the first run usually ends the argument about whether staleness is a real problem on that particular base. Report it next to the metrics preferences are supposed to improve, and the renewal work funds itself.
Frequently asked questions
Why are stale preferences worse than missing preferences?
A system without preferences falls back on recent behaviour, which reflects the customer now. A system with stale preferences actively overrides current behaviour with outdated statements, and usually weights the explicit old data more heavily, so it personalises wrongly with confidence.
How long should a stated preference stay active?
It depends on the type. Identity facts can persist until changed. Taste preferences commonly decay within one to two years, and circumstantial ones like sizes or household based preferences deserve shorter windows. The key practice is storing type and date with each preference and expiring by type.
How should stores re confirm preferences without annoying customers?
By folding single questions into moments the customer is already engaged: checkout, account visits, post purchase flows, or one short annual message showing current settings. Asking for a full preference review as a standalone task gets almost no completions.
What should happen when behaviour contradicts a stated preference?
Repeated contradiction should flag the preference as contested and stop it driving decisions until the customer confirms or updates it. One contradictory purchase might be a gift; a pattern of them means the preference no longer describes the customer.