整理了一下我们APP中优惠券模块的设计方案，只谈产品层面如何设计功能，不谈运营层面如何运作券码，兼顾技术层面。初次分享定义为1.0，以后会多次迭代。
作者：吴宝峰
基于我们产品是B2C自营电商的底层架构，所以我设计的优惠券方案至少支持以下使用场景：满减券、打折券、包邮券、商品券、满赠券、全场通用券等等。
一直以来接触的是淘宝店铺的产品体系，根据自己以前的电商运营经验和对优惠券的理解，最终抽象得出一套通用性的优惠券设计方案。
关于优惠券
优惠券本质
优惠券的本质是经济学中的价格歧视。形式上给予消费者心理一定的折扣，然后促成订单。本质上商家向不同的接受者提供相同的商品或相同质量的服务，但是在接受者之间实行不同的销售价格。
优惠券的表象
对于顾客来说，优惠券就是买东西的时候用它来省钱。
对于初级PM来说，优惠券可能就是满减券、打折券、满赠券这3种类型。那从技术层面来说，RD至少需要构建3个类，并且无法兼顾优惠码。并且后续很难去兼顾运营提出的新优惠券类型。
其次淘宝给店铺提供了3种优惠券：订单券、商品券、包邮券，这是平台的策略。我们是独立B2C，不需要做得这样细。京东也类似。
优惠券的分类
从面向对象的技术角度来说，优惠券可以抽象成类，本质上是类的实例化。
优惠券的价值
是优惠，不是现金。
请注意电商领域通俗意义上的优惠券是指下单可以优惠金额的券，使用即作废。不是那种可以充值到账户的现金券，也不是可以使用多张的折扣券。
为什么做优惠券？
简单来说，就是拉新促活。
怎么做优惠券？
先说大概步骤：
▍新建
即你想要什么样的优惠券，包含优惠券的面值，有效期，类型，门槛，使用限制，标签……
新建是指新建了一批优惠券，可能限定了总张数，也可能不限定。本质上就是构建优惠券这个类的属性，具体如下：
优惠券名称：
方便运营标记，可以显示给用户看。
有效期：
即可以使用该券的起始时间。一般有两种：
①运营人员设定，比如2017-01-05~2017-02-05
②从领券之日起x天，比如注册送券一般有效期7天。延展来讲饿了么滴滴还限定了时段，比如仅早上8:00~10:00可用。
应用范围：
指什么范围可以使用券，一般是全场、某店铺、某店铺某品类。甚至还有限定某店铺某商品，注意这个更应该归于应用范围属性，而不是使用条件，比较容易混淆。
使用条件：
即该订单需要满足的条件，比如满x元、满x件、无条件。延展来讲可能是该订单需满足、该订单中商品需满足、该订单的发货地需满足……请注意最终落在该订单层面优惠，减免金额。
优惠结果：即该订单用券后享受的优惠。比如减x元、打x折、免运费、赠礼物、免税费、返优惠券……
优惠叠加：
比如原本是满100元减20元，叠加后就是满100元减20元，满200减40元，上不封顶。
承担部门：
该批次优惠券的费用由哪个部门承担。
是否显示到前端：
设置了之后，商品详情&领券中心&购物车都会显示。一般是第一种券类。本质上应该置于发放层面，不过考虑到总不能运营每设置一批优惠券就得新建一次，发放一次。就把它归属于优惠券的属性。
是否限定级别：
比如普通用户无法领取，高级用户才可以领取。
排除某类商品：
在应用范围的基础上排除某些特殊商品、某个商品。
需要单独说明的是：
-
为了兼顾优惠码，所以尽量不要去限制该批次优惠券的数量。这一点和淘宝店铺优惠券的区别很大。为此其实新增了2种优惠券类。最终有3个优惠券类（class）：①限制总张数，限制每人领取张数②不限制总张数，限制每人领取张数③不限制总张数，不限制每人领取张数。
-
第一种类最终生成的实体是X张，第二和第三类是1张，但是可以使用多次。后者比较适合和第三方平台合作推广，比如和什么值得买。像当年uber发放出去的兑换码应该采用的是第三种券的定义。
-
每张优惠券，只能关联一条使用条件和一条优惠结果，技术实现层面上来说可以关联多条，但是这样会导致业务太复杂。
