On this page本页目录
What are return reason codes?什么是退货原因码？
Return reason codes are stable identifiers that map a customer’s explanation for returning an item to a controlled reporting category. Use a short customer-facing label, an immutable internal ID, a two-level hierarchy, category eligibility, effective dates, and an “other/unknown” path. Keep the raw response, inspection condition, disposition, and root-cause status in separate fields.
退货原因码是稳定标识符，用于把客户对退货的解释映射到受控报告类别。应使用简短客户标签、不可变内部 ID、两级层次、品类资格、生效日期以及“其他/未知”路径，并把原始回答、质检状态、处置与根因状态保存在独立字段。
The objective is comparability without forcing false certainty. A useful code set is mutually understandable rather than mathematically perfect: customers can choose accurately, operations can preserve evidence, analysts can trend versions, and teams can revise the taxonomy without rewriting history.
目标是在不强迫虚假确定性的前提下实现可比性。实用代码集强调共同理解，而不是数学上的完美：客户能准确选择、运营能保留证据、分析可追踪版本，团队也能在不改写历史的情况下修订分类。
Assign one meaning to each data field为每个数据字段赋予单一含义
Systems often expose adjacent fields during one return workflow, which makes them easy to confuse. A customer reason answers why the return was requested. Inspection condition answers what was observed. Disposition answers what will happen next. Outcome records credit, refund, exchange, or rejection. Root-cause status records an analytical claim.
系统常在同一退货流程中展示相邻字段，因此容易混淆。客户原因回答为什么申请退货，质检状态回答观察到什么，处置回答下一步如何处理，结果记录贷项、退款、换货或拒收，根因状态记录分析结论。
Customer-reported motivation at request time, mapped without deleting the original response.申请时客户报告的动机，映射时不删除原始回答。
Observed physical or functional state after authorized inspection.经授权质检后观察到的实体或功能状态。
Restock, refurbish, vendor return, liquidate, donate, dispose, or return to customer.重新上架、翻新、退回供应商、清算、捐赠、报废或退还客户。
Signal, hypothesis, supported mechanism, validated intervention, rejected, or unresolved.信号、假设、获支持机制、已验证干预、已否定或未解决。
Microsoft documents reason codes and disposition codes as different controls. Oracle also treats reason-code history as part of return processing and reporting. Preserve IDs and history even when display wording changes.
Microsoft 把原因码与处置码记录为不同控制；Oracle 也把原因码历史作为退货处理与报告的一部分。即使展示措辞变化，也应保留 ID 与历史。
Use immutable IDs and a customer-readable hierarchy使用不可变 ID 与客户可读层次
Create a stable Level 1 family for cross-category reporting and a limited Level 2 detail for relevant products. The internal code should never carry changing business meaning. Labels, help text, locale, display order, eligibility, and reporting group may change through versioned metadata—not by reusing an old code for a new concept.
建立稳定一级原因族用于跨品类报告，再为相关商品提供有限二级细节。内部代码不得承载会变化的业务含义。标签、帮助文本、语言、展示顺序、资格与报告组可通过版本化元数据变化，而不能把旧代码重新用于新概念。
| Design element设计元素 | Recommended rule推荐规则 | Why it matters重要性 |
|---|---|---|
| Internal code ID内部代码 ID | Immutable, unique, non-semantic identifier不可变、唯一、不含业务语义 | Prevents history from changing when wording changes避免措辞变化时历史含义改变 |
| Level 1 family一级原因族 | Stable across products and channels跨商品与渠道稳定 | Supports company-wide comparison支持全公司比较 |
| Level 2 detail二级细节 | Short and category-relevant简短且适配品类 | Adds operational specificity without a huge flat list增加运营细节，避免巨型扁平列表 |
| Label and help text标签与帮助文本 | Plain customer language; one concept per choice客户易懂语言；每项一个概念 | Reduces guessing and overlap减少猜测与重叠 |
| Eligibility rule资格规则 | Product, category, market, channel, and workflow商品、品类、市场、渠道与工作流 | Avoids irrelevant choices避免无关选项 |
| Version and dates版本与日期 | Effective from/to plus historical crosswalk生效起止与历史映射 | Preserves comparable trends保持趋势可比 |
| Fallback兜底项 | Other with text, unknown, declined, not captured, not applicable其他加原文、未知、拒答、未采集、不适用 | Distinguishes new themes from missing data区分新主题与数据缺失 |
Create and launch codes in seven stages用七个阶段创建并上线原因码
- Inventory current values盘点当前值
Export labels, IDs, volumes, free text, channels, categories, locales, and historical dates.导出标签、ID、数量、自由文本、渠道、品类、语言与历史日期。 - Separate field meanings拆分字段含义
Move condition, disposition, refund outcome, fraud, and analytical causes out of the reason field.将状态、处置、退款结果、欺诈与分析原因移出原因字段。 - Draft the two levels起草两级结构
Use stable families and category-specific detail based on real comments and operating needs.根据真实评论与运营需求建立稳定原因族和品类细节。 - Write customer language编写客户语言
Remove jargon, blame, double-barreled choices, diagnosis, and overlapping labels.去除术语、责备、双重选项、诊断与重叠标签。 - Test comprehension测试理解
Ask representative users to explain choices and code sample comments independently.让代表性用户解释选项，并独立编码评论样本。 - Build the crosswalk建立映射表
Map old codes to new reporting groups with one-to-one, many-to-one, split, and unmapped status.用一对一、多对一、拆分与未映射状态把旧代码映射到新报告组。 - Release and monitor发布并监控
Version metadata, preserve exposure, monitor other/missingness, and document every change.版本化元数据，保留暴露，监控其他/缺失，并记录每次变更。
The CSV includes immutable IDs, labels, levels, eligibility, effective dates, locale, status, and historical crosswalk fields.
CSV 包含不可变 ID、标签、层级、资格、生效日期、语言、状态与历史映射字段。
Download CSV template下载 CSV 模板 ↓Measure code coverage before reason share计算原因占比前先衡量代码覆盖
Then calculate primary reason share among coded returns. If multiple selections are permitted, publish response share separately and state that shares can exceed 100%. Track unknown, other, free-text-only, invalid, deprecated, and changed-after-request records.
然后计算已编码退货中的主要原因占比。如果允许多选，应单独发布回答占比，并说明合计可能超过 100%。追踪未知、其他、仅自由文本、无效、已弃用与申请后更改的记录。
| Output输出 | Required context所需背景 | What it can support可支持内容 |
|---|---|---|
| Capture coverage采集覆盖 | Eligible return requests, required/optional rule, channel合格退货申请、必填/选填规则、渠道 | Whether trends represent the population趋势是否代表总体 |
| Mapping coverage映射覆盖 | Raw responses, mapper version, confidence, invalid values原始回答、映射版本、置信度、无效值 | Automation and crosswalk quality自动化与映射质量 |
| Primary reason share主要原因占比 | One primary code, taxonomy version, coded denominator一个主要码、分类版本、已编码分母 | Composition trend构成趋势 |
| Multi-response share多回答占比 | All selections, response counting rule所有选择、回答计数规则 | Co-occurring customer concerns共同出现的客户问题 |
| Other/free-text rate其他/自由文本率 | Locale, category, channel, theme sample语言、品类、渠道、主题样本 | Taxonomy drift and missing options分类漂移与缺失选项 |
Worked example: version a split without rewriting history示例：版本化拆分而不改写历史
A synthetic taxonomy uses code R120, “Fit issue,” through June. In July, the team introduces child codes for too small, too large, and shape/fit. Old R120 records cannot be reliably split because historical customers were not asked the new question. The crosswalk maps them only to the stable Level 1 family.
一个模拟分类在六月前使用 R120“尺寸问题”。七月团队引入太小、太大与版型二级码。历史客户没有回答新问题，因此旧 R120 记录无法可靠拆分；映射表只把它们映射到稳定一级原因族。
| Source code/version来源代码/版本 | Effective period生效期间 | Level 1 map一级映射 | Level 2 map二级映射 | Treatment处理 |
|---|---|---|---|---|
| R120 / V1 | Through Jun | Fit or compatibility尺寸或兼容性 | Unknown detail细节未知 | Do not infer a split不得推断拆分 |
| R121 / V2 | From Jul | Fit or compatibility尺寸或兼容性 | Too small太小 | New captured detail新采集细节 |
| R122 / V2 | From Jul | Fit or compatibility尺寸或兼容性 | Too large太大 | New captured detail新采集细节 |
| R123 / V2 | From Jul | Fit or compatibility尺寸或兼容性 | Shape or fit版型或贴合 | New captured detail新采集细节 |
A Level 1 trend can continue across June and July. Level 2 reporting begins in July and must show an unknown historical detail bucket. Backfilling old rows with the later distribution would be an estimate, not measured history, and must remain separately labeled if modeled.
一级趋势可以跨六月与七月连续；二级报告从七月开始，并必须展示历史细节未知桶。用后期分布回填旧记录属于估计而非实测历史，如果建模必须独立标注。
All store figures and records in this example are synthetic. They illustrate the method and do not represent InfiniSynapse customer results or industry benchmarks.本示例中的商店数字与记录均为模拟，仅用于说明方法，不代表 InfiniSynapse 客户结果或行业基准。
Treat code distributions as instrument readings把代码分布视为测量工具读数
The taxonomy is part of the measurement. Changing wording, order, eligibility, defaults, required status, channel, or respondent can change the distribution even when products do not. Preserve exposure metadata and use overlap periods or parallel coding when a material redesign must be compared.
分类体系本身是测量的一部分。改变措辞、顺序、资格、默认值、必填状态、渠道或回答者，即使商品未变也会改变分布。应保留暴露元数据；重大改版需要比较时，应使用重叠期间或并行编码。
Same question version, eligibility, denominator, maturity, and coverage.相同问题版本、资格、分母、成熟度与覆盖率。
Wording, order, default, required state, channel, or respondent changed.措辞、顺序、默认、必填状态、渠道或回答者变化。
Other/free text shows a stable, material, understandable concept.其他/自由文本出现稳定、重要且易理解的新概念。
Rare, confusing, overlapping, or no longer eligible—with history preserved.少见、混乱、重叠或不再适用，同时保留历史。
Never delete a used code to make a list look clean. Deprecate it, close its effective period, preserve label history, and define how it maps—or does not map—to current reporting.
不要为了列表整洁而删除已使用代码。应将其弃用、关闭生效期、保留标签历史，并定义它如何映射或不映射到当前报告。
Apply eight governance checks to the code set对代码集应用八项治理检查
- Comprehension: representative customers consistently understand each label and help text.理解：代表性客户对每个标签与帮助文本理解一致。
- Distinctness: no pair of choices describes the same concept for the same eligible product.区分：同一合格商品的任意两个选项不描述相同概念。
- Completeness: other/free text and unknown states preserve information not covered by codes.完整：其他/自由文本与未知状态保留代码未覆盖的信息。
- Stability: internal IDs are immutable and business meaning is never reused.稳定：内部 ID 不可变且业务含义不得重用。
- Eligibility: product, category, market, locale, channel, and workflow rules are explicit.资格：明确商品、品类、市场、语言、渠道与工作流规则。
- Provenance: respondent, raw value, timestamp, version, mapper, and edit history are retained.来源：保留回答者、原始值、时间、版本、映射器与编辑历史。
- Crosswalk: every deprecated code has a justified map, split, or unmapped status.映射：每个弃用代码都有合理映射、拆分或未映射状态。
- Monitoring: coverage, other, missingness, invalid values, overrides, and drift have owners.监控：覆盖、其他、缺失、无效值、覆盖修改与漂移都有负责人。
Avoid seven return reason code mistakes避免七个退货原因码错误
- Treating a customer-selected reason as a verified root cause.把客户选择的原因当作已核验根因。
- Combining customer reason, observed condition, disposition, and refund outcome in one field.把客户原因、观察状态、处置与退款结果混在一个字段。
- Changing code labels without versioning or remapping historical records.更改代码标签却不进行版本化或映射历史记录。
- Ranking percentages without counts, eligible denominators, value, or uncertainty.只按百分比排序，不展示数量、合格分母、金额或不确定性。
- Comparing products, channels, or periods with different question wording and missingness.比较问题措辞与缺失程度不同的商品、渠道或期间。
- Discarding “other,” free text, multi-reason, changed, or unknown responses.丢弃“其他”、自由文本、多原因、已更改或未知回答。
- Acting on correlation before reviewing cases and testing a mechanism.在检查案例并测试机制前就依据相关性行动。
- Encoding mutable label meaning inside an ID and later reusing it.把可变标签含义编码进 ID，并在以后重用。
- Backfilling historical detail that customers were never asked.回填客户历史上从未被询问的细节。
Treat the code dictionary, question configuration, localization, crosswalk, and change log as production data. Review changes with customer experience, operations, analytics, and privacy owners before release.
把代码字典、问题配置、本地化、映射表与变更日志视为生产数据。发布前由客户体验、运营、分析与隐私负责人共同审核变更。
Use governed codes to select an investigation使用受治理原因码选择调查
A code trend can identify a product-reason cohort for inspection, but it cannot prescribe the fix. Review raw comments, coverage, version exposure, condition, disposition, cost, and product evidence; then move the leading mechanism into a root-cause workflow.
代码趋势可以识别值得检查的商品—原因群组，但不能直接规定修复方案。应检查原始评论、覆盖率、版本暴露、状态、处置、成本与商品证据，再把主要机制送入根因工作流。
| Signal信号 | Evidence to check待检查证据 | Safe next step安全下一步 |
|---|---|---|
| Other rate rises in one category某品类其他率上升 | Free-text themes, locale, channel, eligibility, new products自由文本主题、语言、渠道、资格、新商品 | Code a sample and test a clearer option编码样本并测试更清晰选项 |
| One reason jumps after release发布后某原因跳升 | Version, wording, order, required/default setting, coverage版本、措辞、顺序、必填/默认设置、覆盖率 | Separate instrument change from product change区分测量工具变化与商品变化 |
| Reason and condition disagree原因与状态不一致 | Raw comment, inspection quality, images, timing, definitions原始评论、质检质量、图片、时间、定义 | Audit cases; preserve both fields and investigate审计案例，保留两字段并调查 |
Prepare a versioned return reason dictionary准备版本化退货原因字典
Export immutable code IDs, parent/child groups, labels and help text by locale, eligibility, display order, effective dates, status, raw-response link, and historical crosswalk. Return Compass can analyze governed codes; it cannot reconstruct deleted history.
导出不可变代码 ID、父子组、各语言标签与帮助文本、资格、展示顺序、生效日期、状态、原始回答关联与历史映射。逆向罗盘可分析受治理代码，但不能重建已删除历史。
Open Return Compass打开逆向罗盘 →Return Reason Codes FAQ退货原因码常见问题
It is a stable internal identifier that maps a customer-reported return explanation to a controlled category for workflow and analysis while preserving the raw response.它是稳定内部标识符，把客户报告的退货解释映射到受控类别用于工作流与分析，同时保留原始回答。
Use a stable cross-category Level 1 family, a short category-specific Level 2, clear customer language, explicit eligibility, immutable IDs, effective dates, and other/unknown paths.使用稳定跨品类一级原因族、简短品类专属二级、清晰客户语言、明确资格、不可变 ID、生效日期以及其他/未知路径。
A reason code records why the customer reports wanting a return. A disposition code records what action is taken with the item after receipt or inspection.原因码记录客户报告为什么想退货；处置码记录商品收货或质检后采取什么动作。
There is no universal number. Use the smallest set representative users can distinguish that still supports real decisions; add category detail only where it is understandable and actionable.没有通用数量。使用代表性用户能够区分、同时支持实际决策的最小集合；只有易理解且可行动时才增加品类细节。
No. Deprecate codes, close effective dates, preserve labels and history, and maintain a crosswalk. Do not infer historical detail that was never captured.不可以。应弃用代码、关闭生效日期、保留标签与历史并维护映射表，不得推断从未采集的历史细节。
Sources, evidence labels, and limitations来源、证据标签与限制
- Shopify Help Center: Creating and processing returns and exchanges — Official documentation that return-reason choices vary by product category and can be analyzed across Shopify return workflows.Shopify 帮助中心：创建并处理退货与换货——官方说明退货原因选项会因商品类别而变化，并可在 Shopify 退货工作流中用于分析。
- Microsoft Learn: Sales returns in Dynamics 365 Supply Chain Management — Official documentation for customer-selected reason codes, reason groups, return-line references, disposition actions, and inventory/credit implications.Microsoft Learn：Dynamics 365 供应链销售退货——客户选择原因码、原因组、退货行关联、处置动作以及库存/贷项影响的官方文档。
- Microsoft Learn: Return reason codes and disposition codes — Official distinction between why a customer requests a return and the condition/action assigned after physical inspection.Microsoft Learn：退货原因码与处置码——官方区分客户申请退货的原因与实体质检后分配的状态/动作。
- Oracle Retail Order Management: Establishing Return Reason Codes — Official reference for reason-code maintenance, storefront use, authorization/receipt/credit stages, history, counts, and returned merchandise value reporting.Oracle 零售订单管理：建立退货原因码——原因码维护、前台使用、授权/收货/贷项阶段、历史、数量与退货金额报告的官方参考。
Evidence statement: Official commerce-system documentation supports the distinction among reason, condition, disposition, and transaction stages. The example code IDs and distribution are synthetic implementation examples. Examples are synthetic. No customer result, universal reason mix, causal claim, or guaranteed improvement is asserted. Sources were reviewed September 15, 2026; named subject-matter review is required before publication.证据声明：官方商业系统文档支持区分原因、状态、处置与交易阶段。示例代码 ID 与分布均为模拟实施示例。示例为模拟。本文不声称客户结果、通用原因结构、因果结论或保证改善。来源核验于 2026 年 9 月 15 日完成；发布前需要具名领域审核。
Stable codes make return-reason trends defensible稳定原因码让退货趋势更可靠
Use immutable IDs, clear customer language, a two-level category-aware structure, explicit eligibility, effective dates, and a historical crosswalk. Preserve raw responses and keep reason, condition, disposition, outcome, and root-cause status separate. Measure the instrument itself—coverage, other, missingness, overrides, and version exposure—before interpreting a trend.
使用不可变 ID、清晰客户语言、适配品类的两级结构、明确资格、生效日期与历史映射。保留原始回答，并分开原因、状态、处置、结果与根因状态。解释趋势前，先衡量测量工具本身的覆盖、其他、缺失、修改与版本暴露。