A returns dashboard can place six different problems inside one cell labeled “didn’t fit”: too small in a specific area, too large, unexpected ease, confusing size guidance, the wrong item, or a product-page mismatch. The total looks precise while hiding what the team could actually fix.
A useful taxonomy does three things: it gives the customer clear, non-accusatory choices; it preserves enough operational evidence to investigate; and it keeps the customer’s reason separate from what the warehouse finds and what the business eventually does.
Keep four facts in different fields
One return event should not be reduced to one overloaded dropdown. Separate:
- primary customer reason: what the customer says prompted the return;
- supporting detail: optional structured area, location, or event detail;
- item disposition: restock, rework, quality review, damage, liquidation, donation, recycle, or other controlled outcome;
- resolution: refund, exchange, credit, denial, partial adjustment, or manual review under the applicable policy.
The four fields answer different questions. A customer can report “too small” while the item is restocked in perfect condition. A customer can change their mind while inspection reveals damage. Neither fact should overwrite the other.
Write labels for customers, codes for systems
Use plain labels such as “Fit was too small,” “Received a different item,” or “Did not match the description.” Avoid “customer error,” “wardrobing,” “abuse,” or “fraud” as customer-facing reasons. A return form is not an adjudication system.
Behind each label, maintain an immutable code, reason group, minimum evidence, owner, and default investigation route. Version the taxonomy. If a definition changes, store the version used on the event so historical comparisons remain interpretable.
Offer “Reason not captured” rather than forcing a false answer. Review that queue regularly. New codes should require repeated evidence and an owner, not one memorable complaint.
Design the hierarchy around actions
A compact first level could include:
- fit;
- preference;
- condition on arrival;
- fulfillment error;
- description or image mismatch;
- possible quality issue;
- delivery timing;
- policy review;
- unknown.
The second level should support an action. Fit can distinguish too small and too large, followed by an optional garment area. Description mismatch can distinguish color, material, opacity, proportion, detail, or care information. Quality can record the reported location without declaring a manufacturing defect before inspection.
Do not create dozens of choices because the database allows them. If reviewers cannot consistently distinguish two codes or no one owns the resulting action, combine them until better evidence exists.
Preserve the denominator and cohort
Raw return counts favor high-volume products. Calculate return rate against eligible delivered units and define the observation window. Keep order date, ship date, delivery date, return request date, received date, and refund date distinct.
Compare cohorts with care:
- style, color, and size;
- production lot or supplier material code;
- market and channel;
- first purchase versus repeat purchase;
- promotion or full-price state;
- product-page and size-guide version;
- fulfillment location and carrier;
- return-policy version.
Small cohorts need counts alongside percentages. Do not rank a style with two deliveries against one with two thousand as if the rates had equal stability. Avoid inferring sensitive traits or proxy categories that are unnecessary for the operational question.
Limit free text and personal data
Free text can reveal contact details, health information, measurements, financial disputes, or allegations. Use controlled options first, state why optional text is collected, restrict access, set retention, and provide a secure route for sensitive service matters.
The FTC’s security guidance recommends collecting only what is needed and retaining it only for a legitimate purpose. Do not send entire support transcripts to an AI model merely to classify one reason. Minimize the input, confirm vendor terms, and let a person review low-confidence or consequential cases.
A reproducible taxonomy check
FashionMember’s fictional file content/data/FM-149-return-taxonomy.csv contains ten controlled reasons. It includes codes for fit-small, fit-large, changed mind, arrived damaged, wrong item, description mismatch, possible quality issue, late delivery, policy review, and unknown.
The script scripts/fm149-return-taxonomy.php checks that codes are unique, customer labels and owners exist, minimum evidence and default disposition are defined, blame language remains disabled, free-text controls are valid, and an unknown fallback exists. All ten synthetic rows pass.
The validator tests schema completeness only. It does not prove that customers understand the labels, that warehouse inspection is consistent, that a refund is correct, or that a policy complies with law. It makes omissions visible before implementation.
Connect policy facts without confusing them with reasons
Return policy data needs its own authoritative record: applicable country, return window, accepted condition, methods, fees, refund types, seasonal exceptions, and product-level overrides. Do not infer policy from historical resolutions.
Google’s MerchantReturnPolicy structured-data documentation supports organization-level policies and certain product-level overrides. Google Merchant Center also documents offer-level return attributes and account-level policy relationships. The public policy, checkout, support script, feed, structured data, and refund operations should agree.
Validate structured data with the current platform tools, but remember that eligibility does not guarantee display. A taxonomy for internal reasons is not a replacement for a clear public return and refund policy.
Shipping events also need independent handling. The FTC’s Mail, Internet, or Telephone Order Merchandise Rule requires sellers within its scope to have a reasonable basis for the stated shipping time—or generally 30 days when no time is stated—and to obtain consent to delay or refund unshipped merchandise when the promised time cannot be met. A “late delivery” return code does not resolve those obligations.
Create an investigation loop
Each week, review unknown, description mismatch, wrong item, possible quality, and delivery exceptions. Each month, review fit patterns using adequate cohorts. Route findings to the team able to change the system:
- product development for measurement and grading questions;
- merchandising for assortment and size-curve decisions;
- content for copy, color, imagery, and size guidance;
- quality for lot and construction investigation;
- fulfillment for pick, pack, and item identity;
- operations for carrier and promise logic;
- customer care for policy language and resolution consistency.
Record the action, owner, date, affected product/page/process, and expected measure. After the change, compare a new cohort using the same definition. Do not claim causation when promotions, season, traffic, product mix, or policy changed at the same time.
The purpose of a return taxonomy is not to make customers explain themselves more precisely for the brand’s convenience. It is to reduce repeated failure while keeping the interaction understandable, respectful, and proportionate.
Sources and verification
- Google Search Central: Merchant return policy structured data — official properties, organization and offer relationships, validation, and deployment guidance.
- Google Merchant Center: Returns attribute — official product-level return-policy attribute documentation.
- Google Merchant Center product data specification — official return-policy-label and product-data context.
- FTC: Mail, Internet, or Telephone Order Merchandise Rule — official shipping-promise, delay-consent, and refund rule summary.
- FTC: Start with Security — official data minimization, retention, access, and disposal guidance used for free-text and record design.
How this story was checked
- Sources
- 5 linked records · View list
- Last verified
- Reporting desk
- FashionMember Business Desk
- Format
- Analysis
- AI assistance
- Used with editorial review; disclosed above.