Key takeaways
- Approve data for a stated purpose and decision; availability in the warehouse is not permission to use it.
- Classify sensitivity, source, confidence, consent, retention, and whether the customer can correct the signal.
- Cap frequency and novelty, provide a neutral fallback, and test outcomes across meaningful cohorts.
- Keep a decision log showing which policy and evidence—not hidden reasoning—authorized the treatment.
01
Relevant can become unsettling in one sentence
A visitor reads two pages about layoffs and receives a message that assumes financial distress. A CRM field inferred from a third-party dataset changes the offer. The team calls it relevance; the customer experiences surveillance or a wrong conclusion. The problem is not merely inaccurate targeting. It is an undeclared decision made from data the person did not expect to shape that moment.
Write a decision policy for each personalization use: who receives what treatment, for which purpose, from which allowed signals, under which consent or legal basis, for how long, and with what fallback. Review obligations with qualified privacy and legal counsel for the markets involved.
Swipe to compare every column
| Signal question | Safer treatment | Do not assume |
|---|---|---|
| Where did it come from? | First-party event with provenance | A warehouse field is accurate |
| Why is it needed? | Named decision and purpose | More data means more relevance |
| Can it harm? | Sensitivity and cohort review | An inferred trait is harmless |
| Can it be fixed? | Correction, expiry, and neutral fallback | The model will self-correct |
02
Minimize the decision, not only the dataset
The ICO describes data minimization as keeping personal data adequate, relevant, and limited to what is necessary for the purpose. That discipline should extend to derived features and model outputs. If broad intent bands work, do not expose a generative workflow to raw notes or sensitive event histories simply because they are convenient.
Separate direct facts, observed behavior, declared preferences, and inferences. Record source and confidence. Put short expiry periods on volatile inferences and never let an uncertain prediction overwrite a customer-supplied fact.
03
Design for restraint and ordinary fallbacks
Limit how often creative, offer, channel, and timing can change together. Provide a useful non-personalized experience when consent, confidence, or policy is absent. A customer should not receive a broken journey because the system declined to infer something about them.
Test for wrong assumptions, sensitive proxies, repeated pressure, filter bubbles, price or service disparities, and feedback loops. Compare downstream outcomes—not only clicks—across relevant cohorts. A higher response rate can hide more complaints, unsubscribes, or poor-fit sales conversations.
04
Make the policy visible to operators
Show why a treatment was eligible in terms a marketer can audit: allowed signal, applicable rule, confidence, time window, and version. Do not rely on a model’s free-form explanation as the authorization record. Log the actual data and policy decision outside the model.
Review new sources, model versions, market launches, and unexpected cohort differences before expanding use. NIST’s Privacy Framework treats privacy risk as an organizational concern with governance and communication, not a settings panel added at launch.
Primary sources and further reading
Use the source material to validate details against your own context and current platform configuration.
This field note follows the XenGrowth editorial policy: primary sources where available, visible limitations, material review dates, and no invented first-hand experience.
Stay with the problem
