Direct answer: ask when the preference materially changes the experience, the customer can answer with little burden, and error carries real cost. Observe when behavior is repeated, contextual, and attributable. Infer only when the action is low-impact, reversible, and useful despite uncertainty. In CRM, keep declared choice, observed event, and inferred hypothesis as separate evidence; apply precedence and expiration; never let an inference silently overwrite what the customer stated.
For a midsize company, this is an implementation decision rather than an abstract privacy debate. A typical stack mixes registration, click, purchase, segment, and score into one “preference” field. The result is confident but wrong personalization: a gift purchase becomes personal taste, an accidental click becomes affinity, silence becomes rejection, and an old choice remains permanent after the context changes.
Use the Ask–Observe–Infer Matrix
- Ask when the answer is stable enough to use, easy to explain and update, and costly to get wrong. Size, preferred channel, language, topic, or current objective can merit an explicit choice—if the company will actually honor it.
- Observe when the signal has time, context, identity, and repetition: categories visited across sessions, recurring replenishment, product use, or response to a sequence. One event remains weak evidence.
- Infer when ordering options creates value, the action can be reversed, and a generic fallback is acceptable. A content recommendation may tolerate a hypothesis; blocking an offer, determining eligibility, or changing terms requires substantially stronger evidence and governance.
- Do not personalize when identity, permission, catalog, availability, service state, or operating capacity makes the recommendation inappropriate. Sometimes the best action is a neutral experience plus a request for confirmation.
Google's recommendation documentation distinguishes explicit feedback from implicit feedback. AWS also models explicit and implicit impressions separately and documents explicit precedence when the inputs conflict. Those mechanisms do not set company policy, but they support a practical rule: behavior is evidence; it is not an equivalent declaration.
Write the Preference Evidence Contract
- Domain and value — what preference is represented, allowable values, and the decision that will consume it.
- Subject and context — person, account, household, market, brand, device, session, or occasion; a preference may not transfer across them.
- Evidence class — declared, observed, inferred, operating constraint, or unknown; never collapse these classes into one Boolean.
- Origin and time — form, conversation, purchase, event, model, or rule, with event and ingestion timestamps.
- Confidence and explanation — pattern strength, event diversity, rule or model version, and a readable reason.
- Effective period and expiry — start, half-life, refresh condition, and correction or deletion path.
- Permitted use — authorized decisions and channels, maximum impact, exclusions, and fallback.
- Conflict and outcome — precedence, review, action taken, later feedback, and mature outcome.
A declared choice usually prevails in the same domain and context. It should not become eternal. Record when it was collected, enable correction, and define expiry. Recent behavior may justify asking again; it should not erase the prior choice without evidence. The permission layer at https://makinai.co/insights/en/ai-permission-layer-consent-preferences-crm remains separate: interest in a topic is not authorization for a channel or purpose.
Example: a gift, a preference, or an occasion?
Consider a U.S. retailer where a customer buys a child's running shoe, visits running content across three sessions, and chooses email-only alerts. The current stack writes “children,” “running,” and “SMS” because historical SMS click-through is higher.
The Contract separates an observed children's purchase that may belong to an occasion; inferred running affinity from three sessions; declared email channel; SMS unavailable for this purpose; and size inventory as an operating constraint. The next experience can rank running content on the site, invite the customer to adjust interests, retain email, and avoid asserting that the customer is a parent. If the customer corrects the preference, the hypothesis loses precedence and the correction becomes model feedback.
Pilot one decision—not a universal profile
- Week 1 — select one decision, such as ordering three content modules; record baseline, fallback, and counter-metrics.
- Week 2 — inventory fields, events, forms, consent, identity, context, delay, and destinations; sample real conflicts.
- Week 3 — implement the Contract, unknown states, precedence, expiration, and a simple correction experience.
- Week 4 — produce three comparable paths: generic rule, observed signal, and inference; run in shadow without external changes.
- Week 5 — release to a small low-consequence cohort with sampled review; log exposure, correction, and outcome.
- Week 6 — compare utility, error, labor, cost, and trust; expand, improve the question, keep generic, or stop.
Deliverables include a preference and context map, event dictionary, versioned contract, conflict rule, expiry policy, tests, return integration, dashboard, review queue, runbook, rollback, and scale decision. The minimum loop at https://makinai.co/insights/en/cdp-ai-marketing-minimum-customer-data-loop-revenue may be enough; do not buy a CDP merely to hold more hypotheses.
Cost and architecture choices
Cost grows with preference domains, countries, brands, identities, capture points, volume, history, latency, models, channels, correction interfaces, languages, permission, experiments, and support. CRM fields and rules can support a few stable choices. Batch features can support daily recommendations. Streaming and a custom model are justified only when fast updates change a valuable experience and the company can operate monitoring, replay, incidents, and fallback.
Marketing owns the experience and acceptable impact. CRM and data preserve class, origin, and effective time. Product designs a low-friction question and correction path. Engineering integrates and monitors. Service and sales return context. Privacy and counsel validate purpose, notice, and market boundaries. Merchandising or operations owns availability and eligibility. A vendor may calculate affinity; it should not unilaterally decide which evidence wins.
Measure correction and decision—not just clicks
Measure declared, observed, inferred, and unknown coverage; conflicts by domain; preference age; correction rate; reversed inferences; unavailable items recommended; fallback use; propagation time; complaints; and cost per executed decision. Then track discovery, conversion, margin, retention, or service reduction over an appropriate window.
Click lift does not prove that the preference was correct or that personalization created incremental value. Position, offer, availability, novelty, and audience selection interfere. Compare against the fallback and use a controlled design where feasible. The next-best-action workflow at https://makinai.co/insights/en/ai-next-best-action-crm-personalization must consume evidence, identity from https://makinai.co/insights/en/ai-customer-identity-resolution-crm-duplicates, and constraints—not only a score.
If your company already has interest fields, event data, and a personalization engine, bring MAKINAI at https://makinai.co/services/en/crm-ecommerce-commerce-transformation one preference domain, an anonymized conflict sample, and the decision that should improve. We can scope the smallest pilot that separates choice, observation, and hypothesis before expanding the stack.
The sources describe product capabilities and limits plus a voluntary framework. They do not prove a preference is true in your data, replace legal review, or guarantee revenue. The Matrix, Contract, pilot, thresholds, and responsibility model are MAKINAI editorial recommendations for local validation.