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.
Substitua cada espaço pelos seus próprios dados. Quanto mais específico for, menos o modelo inventa.