如何创建退货与退款报告:完整指南

某家店铺报告了 12% 的退货率。但其中有三分之一实际上并没有退回任何实物。
这并非数据错误。当退款被记录为退货时,就会出现这种情况,而这恰恰是大多数平台的统计方式。
这种区别听起来有些过于抠字眼,直到运营部门的同事根据你提供的数据来规划仓库容量时,你才会意识到它的重要性。
本指南将介绍退货与退款报告中应包含的内容,以及为什么这两个词描述的是不同的事件。接着,它将探讨悄然破坏月度对比的数据日期问题,并介绍如何通过导出数据来构建该报告。
退货与退款报告必须包含的内容
同一视图中应包含五项内容,而退货率仅仅是其中之一。
退款金额、退款订单数量、统计周期、计算所用的分母,以及全额退款与部分退款的占比。
如果你的平台记录了原因代码,请将其添加进去。率值告诉你问题的严重程度,而原因则告诉你具体遇到了什么问题。
起初可以先排除运费和税费。这两项通常是单独追踪的,混在一起会导致后期数据无法对账。
退货与退款并非同一概念
平台文档对此的解释异常清晰,非常值得仔细阅读其确切表述。
WooCommerce 的 分析文档 直接将两者区分开来。它指出,“退款描述的是将资金退还给客户的交易。”
该定义的另一半才是关键所在。退货指标记录的是退款金额,“无论该退款是全额还是部分退款,也无论货物是否实际退回。”
因此,针对破损商品提供的商誉补偿款即使没有实物退回,也会计入退货中。价格调整也是如此。
仅凭这一句话,就能解释为什么不能直接将电商分析中的退货数据交给仓库团队作为实物退货预测。
运费和税费也被排除在外。退还的运费和退还的税费不包含在退款金额中。相反,它们会以负值形式出现在运费和税费数据中。
日期问题
这个问题会改变你的趋势线,而不仅仅是单个单元格,这使得情况变得更糟。
WooCommerce 将退款记录为“退货发生之日的负数(而非下单之日)”。
想想这对月度对比会产生什么影响。针对 2 月份订单在 3 月份发生的退款会被计入 3 月份,而 2 月份的收入却从未重新调整。
结果,这两个月的数据都出现了相反方向的轻微偏差。2 月份的数据看起来比实际情况要好,而 3 月份则承担了并非由其产生的成本。
有两种合理的解决方法,你必须以书面形式明确选择其中一种。
按退款日期进行报告,并将该报告标记为现金流视角。这能与你的银行和平台数据对齐,但永远无法与同类群组分析相匹配。
或者,将每笔退款重新归入其原始订单日期。这能真实反映每个销售周期的状况,但也意味着上个月的数据在发布后仍会发生变化。
这两种方法都没有错。错的是在发布报告时没有说明你使用的是哪一种。
选择分母
退货率需要一个除数,有三种常用的除数,它们会产生三种不同的数值。
| 分母 | 该率值的含义 | 最适用于 |
|---|---|---|
| 周期内的订单数 | 发生退款的订单比例 | 客服工作量评估 |
| 发货件数 | 退回商品的比例 | 仓库与重新上架规划 |
| 净销售额 | 流失收入的比例 | 财务与利润率分析 |
根据受众进行选择。财务审查需要金额版本,而运营审查则需要件数版本。
此外,还要留意相关的销售数据,因为这些数据也是有定义的。WooCommerce 将总销售额定义为价格乘以数量(不含退款、优惠券、税费和运费),而将净销售额定义为总销售额减去退货和优惠券。
其中的平均订单价值(AOV)是净销售额除以订单数。因此,退款实际上已经包含在你可能在其他地方引用的 AOV 中了。
我们的将原始电商订单转化为销售趋势报告指南涵盖了同一导出文件中关于收入方面的内容。
如何手动操作
方案 1:两个总和,一次相除
将导出数据筛选为该周期内的退款记录,然后使用 SUMIFS 计算退款总金额。
使用 COUNTIFS 统计受影响的订单数量。如果单个订单可能包含多次退款,请先对订单标识符进行去重。
最后进行一次相除。保持这两个总和可见,便于他人复核你的工作。
这种方法的局限性很快就会显现。你只能得到某一个周期的单一退货率,无法了解是哪些产品或原因导致了退货。
方案 2:每行一条退款记录
构建一个表格,每行代表一条退款记录。列包括:订单日期、退款日期、间隔天数、退款金额、全额或部分退款,以及原因。
用较晚的日期减去较早的日期来计算天数差。微软关于 DATEDIF 函数的指南警告称,该函数“在某些特定情况下可能会计算出错误的结果”。
现在可以对报告进行多维度剖析了。可以按产品、按品类、按渠道、按原因或按退款滞后时间进行细分。
滞后时间列是一个常被低估的指标。如果退款集中在购买后 40 天,通常指向耐用性问题;而如果集中在 4 天,则通常指向尺码或描述问题。
这种方法的限制在于数据量和关联操作。将退款与订单明细及产品数据进行匹配,其复杂度已经超出了公式所能轻松应对的范围。
方案 3:定义标签页
记录你报告所依据的日期、所用的分母,以及是否包含运费和税费。
然后记录排除项。未发货的取消订单、测试交易和拒付(chargebacks)都需要明确的处理说明。
拒付是人们最容易遗忘的一项。资金流出了,却没有记录退货,导致两个系统的数据永远对不上。
局限性在于,仅仅写下规则并不等于执行了规则。下个月还是会有人重新构建相同的筛选条件。
共同的瓶颈。 这三种方案都假设导出文件中包含这两个日期。如果文件里只有退款日期,那么就无法从该文件中恢复同类群组视图。
手动流程在何处受阻
制作第一份报告需要一个上午。而到了第四份,耗时会更长,因为有三处地方发生了偏差。
部分退款成倍增加。一个包含三次部分退款的订单变成了三行,此时通过计算行数得出的订单总数就是错误的。
产品目录发生变化。重命名的 SKU 会将一个产品的历史记录拆分为两条,导致退货最严重的商品从你的列表顶部消失。
接着,定义也在悄然改变。这个月有人因为觉得数据更完整而把退还的运费也算进去了,导致趋势线中断。
还有第四种成本,只有在开会时才会显现。当有人问起为什么财务的数据不同时,答案其实藏在你没有带过来的那个标签页的日期约定里。
工具方面也有专门的汇总,详见电商分析 AI 工具。
如何使用 Powerdrill Bloom 构建报告
步骤 1:上传你的订单和退款导出文件
将订单文件和退款文件一起上传。Powerdrill Bloom 会在文件导入时分析各列,因此在计算任何率值之前,缺失的退款日期、重复的订单标识符以及不一致的 SKU 值都会显现出来。
步骤 2:用自然语言描述报告
直接陈述规则,而不是去构建它们。指明你报告所依据的日期、分母、是否包含运费和税费,以及需要排除的内容。
然后提出能够发现错误的问题。询问有多少订单包含多次退款。询问哪些退款超出了其原始订单的报告周期。接着,索取按产品和原因代码分类的退货率。
步骤 3:导出图表、报告或幻灯片
导出包含分母的退货率、按天数计算的退款滞后分布,或者在数字旁注明日期约定的幻灯片。
常见错误
将退货等同于实物退回。 平台指标统计的是退款金额,无论货物是否退回。请明确你指的是哪一种。
报告退货率却不说明分母。 订单数、件数和金额会得出三种不同的结果。请在报告中指明你使用的是哪一种。
混淆退款日期和订单日期。 选择一种约定,做好标记,切勿将两者进行跨维度对比。
默默将退还的运费和税费包含在内。 这两项通常是单独追踪的。将它们加进去会导致无法与财务对账。
计算行数而非订单数。 部分退款会导致每个订单产生多行记录。在计数前请先去重。
忽视拒付。 资金流出却没有退款记录。决定它们应该出现在哪里,并记录下来。
与公布的行业水平进行对比。 其他零售商使用不同的分母和不同的日期规则。请先与你自己的趋势进行对比。
结论
将退款交易与退货金额区分开来,确定日期约定,选择一个分母,并在报告退货率时附带其计算基数。
率值本身并不是最终的交付成果。按产品、按原因和按退款滞后时间进行的细分,才能告诉你应该去修改商品详情、尺码表还是更换供应商。
如果每月重新构建这种细分维度要耗费你一整天的时间,不妨试试用 Powerdrill Bloom 来处理你的订单导出文件。另请参阅 CSV AI 助手和 AI 报告生成器页面。
常见问题解答
退货和退款有什么区别?
退款是指退还资金的交易。而退货作为一个指标,记录的是商品和服务的退款金额,无论是否有任何实物被退回。
如何计算退货率?
用退款活动数据除以指定的基数,然后乘以 100。基数可以是订单数、发货件数或净销售额,每种基数都会得出不同的数值。
我应该按退款日期还是订单日期进行报告?
两者皆可,只要做好标记。退款日期能与你的平台和银行数据对齐,而订单日期则能更真实地反映每个销售周期的状况。
退还的运费和税费算在内吗?
通常不包含在退款金额中。WooCommerce 会将退还的运费和税费分别记录在运费和税费数据中。
为什么我的数据与财务的数据不一致?
最常见的原因是日期约定的不同,其次是是否包含了运费、税费和拒付。在对比数据之前,请先对比两者的定义。