电商交易后台：优惠券系统的产品实操记录
在电商交易中，优惠券发放是互联网企业常会使用的促销手段，而优惠券系统也已经成为电商后台体系相对重要的模块。那么关于优惠券的核心问题，比如金额分摊等问题，你知道多少？本篇文章里，作者便关于优惠券系统、以及优惠券核心问题等方面做了解答，一起来看。
本文描述下搭建一套优惠券系统，产品所需要做的一些事情，和一些优惠券系统的一些关键问题。其实现在写优惠券系统的文章已经很多了，不过比如金额分摊这些优惠券的核心问题，很多文章没有涉及到，本文会用案例来写一下这些方面。
优惠券用于运营，负责优惠券的通常是运营部门，所以我们做优惠券系统前需要先从运营的视角来看，优惠券如何运用到业务上，和运营部门对优惠券的使用需求。
优惠券的价值，是商家或平台通过让利的方式降低价格，促进用户做消费转化。让利会让商家少赚一些，甚至亏损，但在各行各业都很卷的今天asp教程，为了抢用户，优惠券这种老土的方式依旧是最常见的。
和直接降价促销的形式相比，优惠券使用的场景会更广一些，主要原因是第一优惠券更灵活，可以针对每个用户设置不同的优惠券，发放、领取的手段和渠道也很多，满足不同的运营场景需要；第二优惠券可以给用户一种得利的心理感受，而降价促销容易让用户以为原价只是个没用的标价，降价的价格才是正常价格（事实上也经常是这样的）。
比如双 11 等各种平台大大小小的营销活动，可以是平台发起的，也可以是商家发起的。平台自动给用户发优惠券，或者通过领券页面让用户自己领优惠券。一些大的平台可能长期会有各种活动，各种类型的优惠券也是不间断的会有
比如第一次登录的新用户、一段时间没消费即将流失的用户、有售后投诉行为的用户等，具体的用户范围就看这次发券的目标。发券的形式通常是用户进入页面后弹窗发券，或者无感知发券，给用户一个短信站内信的通知。
好友裂变的方式，优惠券作为吸引用户的条件。现在拼多多的好友砍一刀也是类似的玩法，只是用的不是优惠券。
这种通常是和外部平台合作，用户在其他平台的积分商城、会员等渠道获得了这个平台的优惠券，拿到兑换码后在平台兑换优惠券。兑换的操作不一定用兑换码，但逻辑是这个逻辑。
运营做一个营销方案，发完优惠券之后，肯定需要通过数据观察优惠券的效果。所以运营部门的需求，会需要看这几个数据：
优惠券的领取和使用数量：每张优惠券，有多少被领取和使用，以此推算优惠券领取率、使用率，看用户对优惠券的接受程度。如果是系统发放的优惠券，看发放和使用率。
下单转化率：有下单行为的用户占总用户的比例。优惠券的目的是引导用户下单，所以需要通过观察下单转化率是否有提升asp源码文件用什么软件编辑好用、提升了多少，来看优惠券的运营效果。
优惠金额：通过优惠券给订单的优惠金额，运营部门通常有营销活动预算，用在这些优惠订单上，所以要统计优惠金额用来算钱，看实际的成本和预算是否匹配。
这是第一步，需要在后台创建优惠券，完善优惠券的各种信息。优惠券信息，比较简单的比如名称、使用说明就不详细列了，这里列几个相对关键的信息：
2）可用商品 / 商家范围，可以设置商品维度和商家维度。有些公司的商品和商家之间会关联，商品本身已经包含了商家维度，这时候商家商品需要同时选。一些大的电商平台，会区分平台券和商家券这两种类型的券，平台券可能是所有商家可用，商家券由商家自己发售，单个商家可用，其实也是可用商家范围的逻辑；
4）用户领取和使用的限制条件，比如是否只有新用户可领可用，每个用户同时可领几张，APP/ 小程序 /M 站哪些渠道可用，和哪些其他优惠不能同时使用等。
营销活动模块表示一场营销活动的相关信息，可以是双 11 这种促销活动，也可以是日常的比如新用户活动。在营销活动模块会定义活动的时间、用户范围、展示位置等信息，和这场活动要用的优惠形式，可能是单张优惠券，可能是组合优惠券，也可能是折扣促销等其他优惠方式。
有些公司可能会把优惠券和营销活动这两个模块做在一起，我个人建议这两个模块最好分开，降低耦合度。活动和优惠券各自的定义有一些差别，优惠券模块只定义优惠券本身的发放、使用信息，不需要定义优惠券用在哪个活动上。而且优惠券可以用于多个地方，不一定通过活动发放，一场活动也可能不用优惠券用其他优惠形式进行，所以尽量将优惠券和活动解耦。
系统发放指的是制定相应的系统发放规则，用户触发规则后，给用户自动发放优惠券。比如平台营销活动、新用户优惠等，都属于系统发放。
这个模块的实现方式，通常是先制定一条发放规则，具体规则直接代码写死，然后优惠券再去关联这条发放规则。这样把优惠券和发放规则解耦，可以支持一条发放规则用于多个优惠券的情况。
还有一种人工发放，主要针对用户售后、投诉时，人工给用户发优惠券作为补偿的场景，同样也属于发放这一类。
用户领取指的是在用户端设置领券页面、弹窗后，由用户主动去领取优惠券。从运营角度来看，和系统发放的不同点在于多了个领取动作，用户可以主动领取自己想要的券，而不用系统一股脑塞给他。
产品实现方式是用户端做个领券页面，在这一条发放规则中直接填写这个领券页面的链接即可。至于这个领券页面出现在哪、什么条件出现，可以在用户端页面里去定义。
用户端的下单页面需要支持使用优惠券。用户下单时，要有个选择优惠券的入口和选择优惠券页面，注明哪些优惠券是可以用的，哪些是不能用的以及原因，然后帮用户自动选择一张优惠券，通常是选择可用面额最大的优惠券。
选优惠券时还有限制条件，比如优惠券可用几张，不同类型的优惠券、或者优惠券和其他类型的活动是否能同时使用，如果有冲突需要在下单页面中说明。
除了下单页面，购物车和商品详情页面也需要计算优惠券，因为这两个页面也会涉及到订单金额。商品详情比较简单，显示可用的券和优惠后的金额即可，购物车页面就会复杂一些，需要根据用户勾选的商品，计算这些商品可用的券、和每个商品优惠后的金额，比如用户经常会在购物车凑满减。
订单中需要显示用户下完单后使用的优惠券和优惠金额。通常订单金额相关的字段有商品金额、优惠金额、应付 / 实付金额，优惠金额就是用来记录该订单所有优惠的金额。如果订单有多项优惠，那么还需要几个细分的优惠金额字段，来记录各项优惠金额。
订单的逆向流程也需要考虑优惠券，也就是订单退款的时候优惠券要不要退。这时需要看第一优惠券是否可退，第二优惠券是否已过期，如果可退且未过期，就可以正常退给用户。给用户退的具体金额就是优惠后的实付金额。
只要对订单金额有影响那对财务就有影响。财务需要记录订单的资金明细，实际收入金额，和优惠金额。优惠后的金额如果涉及到和商家分账，那需要记录优惠后分账的结果。
前文提到运营在做优惠活动的时候，需要分析优惠券的领取和使用数量等数据，因此需要在 BI 上做优惠券数据统计。常见的数据有：
优惠券领取量 / 领取率：一个批次优惠券的领取情况，如果是系统发放，就统计发放数量。这个数据主要是看当前发的优惠券和预算是否匹配，一般申请的优惠券总数是按预算来申请的，如果看比例可能会多了或者少了就要做相应调整。
订单 GMV：结合转化率，看在转化率提升和客单价下降的情况下，总的订单 GMV 有多少提升。如果 GMV 在下降，说明是赔钱做吆喝（当然不是不可以）。
以上都是一些大框架，优惠券产品设计过程中相对比较重要、也比较麻烦的，其实是算钱的一些问题。常见的关键问题主要有以下 3 点：
如果一个订单有多个商品，订单使用优惠券后，需要将优惠金额分摊到每个商品上。分摊后才能计算每个商品的实际支付金额，商家分账或者订单退款时都会影响到。分摊时需要分摊到订单最小颗粒度，常见的是单个 SKU 维度。
金额分摊不是简单的四舍五入就行，因为四舍五入后总金额可能会对不上。这里介绍两种常见的分摊方法：
方法一：将订单所有商品按照商品金额大小正序，即金额低的排前面，然后前面几个商品按四舍五入计算优惠金额，最后一个商品再用总优惠金额减去前面已经优惠的金额。
这种算法的好处是，保证总金额对的上的同时让误差最小。如果金额最大的商品在前面四舍五入，那分摊到最后一个商品的误差会相对比较大。不过这个方案会出现一种极端情况，就是前面商品分摊的优惠总金额已经大于订单的优惠金额，导致最后一个商品不够分了。这种极端情况只会在订单金额小到几分钱的时候才会发生。
方法二：优惠金额不四舍五入，直接取前两位小数，前面的商品计算完成后最后一个商品再用总优惠金额去减。
这种方案同样会有极端情况，前面商品的优惠金额分的不够多，导致订单优惠金额大于了最后一个商品的商品金额。这种情况也只会在订单金额几分钱的时候发生。另外这个方案会让前几个商品的优惠略微偏低一些，最后一个商品优惠偏高一些。其实优惠金额分摊并没有一种很统一且直接的方案，具体就看选择哪种方案了。
有时候一个订单中会有多种不同的优惠方式，比如优惠券、满减 / 折扣、平台会员、支付优惠等，优惠券本身可能还分为平台优惠券、商家优惠券、运费 / 配送费优惠券。比如外卖平台，就有商家的满减、平台的优惠券、商家的优惠券，这里面规则让人感觉有点复杂，有时候我点外卖时会觉得我明明已经凑单了半天达到了优惠券使用门槛，怎么还是提示优惠券不能用。这个原因就是不同优惠的使用顺序和门槛不同。
如果订单有多种优惠，就需要制定优惠计算规则，每项优惠之间能不能一起用、优惠计算的顺序和门槛。假如某个平台有这几类优惠：商家的商品优惠、商家优惠券和平台优惠券。
首先，需要在优惠券中定义这几项优惠之间是否可同时使用，如果不能同时使用，那么在下单的选择优惠券页面上需要注明和商品优惠不能一起用，如果用户选了其中一项优惠，另一项就不生效。通常同一项优惠券只能使用一张，不同的优惠券就要看平台怎么定了。
然后看优惠金额的计算顺序和门槛。这里有两种规则，平行式优惠和递进式优惠。递进式优惠意思是订单的 A 优惠先计算完后，再用优惠后的金额作为 B 优惠的门槛和起始金额。平行式优惠指的是 A 优惠和 B 优惠用同样的门槛和金额进行计算。
假如这 3 项优惠是递进式，商品优惠 - 商家优惠券 - 平台优惠券依次递进，那么首先计算商品优惠，订单优惠后金额为 300-50=250，然后再在 250 基础上算商家优惠券，250 × 0.8=200，最后在 200 基础上算平台优惠券，由于平台优惠券门槛为 250 元因此无法使用，最终订单金额为 200 元；假如这 3 项优惠，两个优惠券是平行式，商品和优惠券是递进式，那么计算商品优惠后订单金额 250 元，同时用商家优惠券折后减 50 元，和平台优惠券减 50 元，最终订单金额为 300-50-50-50=150 元。
订单成交后，平台和商家之间需要按照一定的比例进行分账结算。订单使用优惠券后，由于优惠券的成本分担比例和订单分账比例不一样，因此有优惠券之后，订单的分账规则需要同时计算优惠成本的分摊，和订单收入的分账。
我们常见的优惠券有平台券和商家券，平台券是平台发的，平台会和商家约定互相成单的成本比例，也可能都由平台承担。商家券一般是商家自己发行自己承担成本。本质上不管什么券，都需要定义平台和商家的分账比例这一信息，平台券需要定义哪些商家愿意参与这个优惠。这个信息在优惠券创建的时候就需要设置完成。
举个例子，一个订单金额 300 元，订单的分账规则为七三，商家七成平台三成。订单用了平台优惠券 50 元，优惠比例二八，即平台承担 40 元商家承担 10 元。订单又用了商家优惠券减 20 元，都由商家承担。订单实付金额为 230 元。那么订单最终的分账结果，商家获得 300 × 0.7-10-20=180 元，平台获得 300 × 0.3-40=50 元。
优惠券系统不复杂，这么多年来已经是常见的电商后台系统之一了，有不少现成的案例可以参考。具体公司要做优惠券的时候，还是需要根据公司自己的业务特征和业务阶段进行调整。
潘帕斯雄鹰，人人都是产品经理专栏作家，进击、踩坑中的产品狗一枚，关注互联网，写过小说，看过哲学。简书：潘帕斯雄鹰。
