{{ p.title }}

The reason “warm · evening · luxury” is three words long, and each word is the result of a decision about language. Someone had to decide that the first word is warm rather than amber, that evening comes before luxury, and that there is no number anywhere in it. A reason is a piece of product copy written by a system thousands of times a day, so its rules have to be set down before the first one is shown.

This article covers those rules. It assumes the reason is already built from the inputs that moved the score, an engineering requirement we cover in Why explainable AI is an engineering problem. Here the question is editorial: given a reason that is true, how should it read.

A controlled vocabulary for each category

Each dimension value maps to a word or short phrase from a fixed vocabulary, written in the shopper’s language for that category. Perfumers describe a scent as an amber accord; shoppers call it warm. Apparel teams talk about silhouettes; shoppers say relaxed or fitted. The vocabulary is drafted with the merchandising team, who know how customers describe products, and reviewed like any other customer-facing copy.

A fixed vocabulary has practical advantages beyond tone. The same dimension always produces the same word, so a reason reads identically on the product page, in an email and in a support tool. Legal and brand review happens once, on the vocabulary, instead of on every generated phrase. And changes are deliberate: renaming a word is a reviewed edit with a known effect, rather than a side effect of a model update.

Word order carries meaning

Words in a reason appear in order of how much each dimension moved the score, so the first word is the strongest reason the product was chosen. This makes the reason readable as a ranked explanation, which matters most to the people behind the storefront. A support agent looking at “evening · warm · luxury” can see that the occasion drove the choice more than the scent family, and answer a customer’s question accordingly.

Three to five words

A reason has to fit wherever the decision appears: under a product name on a card, in an email, beside a support ticket. In practice that limits it to three to five words. Longer explanations tend to be skipped on a storefront, and the detail they would carry is better kept in the decision record, where the team can see every input and its weight.

Separators matter at this length. A middle dot reads as a list of independent factors. A full sentence such as “Because you like warm scents for evenings” reads as the system addressing the shopper directly, which some brands want and others find intrusive. The choice is a brand decision, made once and applied everywhere.

Saying less when the system knows less

Early in a session, the system is confident about only one or two dimensions, and the reason should name only those. Showing “evening” when that is all the system has learned is honest. Padding it to three words with low-confidence guesses teaches shoppers that reasons are decoration, and they stop reading them.

For the same reason, shopper-facing reasons should not contain numbers. A “92% match” suggests a precision the system does not have, invites comparison between products scored on different dimensions, and gives the shopper nothing to act on. Confidence scores belong in the decision record, where the team can use them.

What a reason must never say

Some content is excluded from reasons regardless of what the data suggests:

• Sensitive characteristics. A reason never refers to health, ethnicity, religion, sexual orientation or similar characteristics, and the dimensions are designed so that such inferences are not made in the first place.
• Identity. Reasons describe the purchase. “Gift · under $100” describes a purchase; a phrase about the shopper’s age or gender describes a person, and is excluded.
• Claims the product data cannot support. “Long-lasting” can appear only if longevity is a scored attribute with reliable data behind it.
• Pressure. Stock levels and countdowns are a different kind of message. Mixing them into the reason makes every reason read as a sales tactic.

Reviewing reasons like copy

Because reasons are generated continuously, review has to be continuous too. A practical routine is a regular sample: a merchandiser reads a set of recent decisions in the operations console, checks whether each reason matches what they would have said about the choice, and flags mismatches. Most mismatches point to a vocabulary problem or a badly defined dimension, both of which are fixed at the source instead of by editing individual reasons.

Whether showing reasons changes shopper behavior is a separate question, and it should be measured like any other change, against a holdout. We do not assume that reasons raise conversion. We show them because they make decisions checkable, and we measure their effect wherever it matters to the business.

Trade-offs

A controlled vocabulary limits nuance. Some products are chosen for combinations of factors that three words cannot capture, and the reason will be a simplification. The vocabulary also needs maintenance: new product lines bring new dimensions and new words, and stale entries accumulate. Localization multiplies the work, since a vocabulary that reads naturally in American English has to be drafted afresh for each additional market; literal translation rarely produces the words shoppers use.

Recent decisions and their reasons can be browsed in the Decision Console demo.

Open the Decision Console