Use when filters are named after database fields and shoppers are not touching them.
facet-label-rewrite-shopper-language.md
You are renaming filters on a listing page so shoppers understand them. You are not changing which products match.
Facets and their values exactly as they render now:
{{CURRENT_FACETS}}
Use rate per facet and whether use leads to a sale: {{FACET_USAGE}}
Words shoppers use for these things, from search and support: {{SHOPPER_VOCABULARY}}
Platform constraints on label length and casing: {{LABEL_CONSTRAINTS}}
Output a table: Internal facet | Current label | New label | Value renames | Verdict (keep, merge, reorder, remove) | Reason.
Then an ordered list: the facet order you recommend top to bottom, with a reason each sits where it does.
Rules:
- Never change what a value matches. A rename that shifts the matched set is a data change, not a copy change, and must be flagged as one.
- Take wording from {{SHOPPER_VOCABULARY}} where it exists. Where it does not, mark the label unverified and name the term you would test against it.
- Recommend removal only where {{FACET_USAGE}} shows both low use and low sale rate, and quote both figures.
- Respect {{LABEL_CONSTRAINTS}} and show the character count for any label near the limit.
- Do not propose a facet absent from {{CURRENT_FACETS}}. List wanted facets separately as a data request.
- Keep the internal name in every row so engineering can map it. No em dashes.
Replace each placeholder with your own detail. The more specific you are, the less the model invents.
When is renaming better than adding more filters?
When filters are named after database fields and shoppers are not touching them. Adding facets is the reflex, and it makes the panel longer without improving use rate. This renames what is already there and recommends an order, while changing nothing about which products each value matches.
What data do I need about the current facets?
The facets and values exactly as they render, use rate per facet and whether use leads to a sale, the words shoppers use from search and support, and your label constraints. Both usage figures are needed, because a facet with low use and a high sale rate is not a removal candidate.
What comes back, and what should I read first?
A table keeping the internal name against each rename and verdict, then the facet order you should use with a reason per position, then the facets you want but cannot build. Read the order list before the table: facet order moves more revenue than facet wording, and the data request is often the real finding.
How should I release the changes?
Shipping the renames and the reordering in the same release. The number will move and you will not know which change did it. Watch as well for a rename that shifts the matched set, which the prompt flags as a data change because that is what it is, and it needs engineering rather than copy approval.