实例分享：B2C自营电商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发放出去的兑换码应该采用的是第三种券的定义。
• 每张优惠券，只能关联一条使用条件和一条优惠结果，技术实现层面上来讲能够关联多条，可是这样会致使业务太复杂。

审核

优惠券实际上是让利提高销量，因此须要业务部门申请预算并提交财务审核。不过咱们APP体量还小，这一步暂时省略。后续能够补充。

发放

审核经过的优惠券须要向目标用户进行发放。发放是个泛概念，分为用户主动领取&系统自动发放。

新建优惠券的时候，已经提供了一个显示到前端的属性，称之为领券。

好比给每个批次的优惠券生成连接，发给用户让他们去领。

另外：注册自动返券，下单自动返券，邀请成功自动返券，属于系统自动发放的类型。

发放这一步是很偏运营的事儿，产品配合好便可。

领取

当用户领取成功以后，个人优惠券列表新增一条记录。此时这张券的状态是未使用，下单的时候若是使用了它，则为已使用状态。

使用

优惠券的使用和订单流程强关联，一种是先用券后生成订单，还有一种是先生成订单再用券。咱们APP采用的是前者，遵循用户被淘宝京东培养出来的认知习惯。

选择优惠券以后生成订单，此时该张优惠券和该订单进行绑定，同时状态变成”已使用”。

注意每一个订单最多使用一张优惠券，一张优惠券只能使用一次。理论上来讲一个订单可使用多张券，一张优惠券可使用屡次好比uber有那种使用x次的晚高峰券，只是这样会让业务变得很复杂，产品设计和技术实现都会变得很复杂。除非业务必须，不然不推荐这样作。

回收

过时未使用的优惠券须要进行回收和做废。

统计

不管是生成优惠券的记录、仍是每一张被领取的记录，以及每张使用的记录，都须要记录日志供查询。

优惠券是否退还

理论上来讲优惠券通常不退，优惠券1.0版本中不支持将未付款而取消的订单绑定的优惠券进行返还，若是之后有时间可能会优化一下。此时会多一个使用中或者锁定的中间状态。

退款的时候优惠的金额怎么处理

若是不处理，那用户下单100+50-20优惠，若是所有退款则是退款150，很明显对商家形成营收上面的损失。

若是处理则按照”哪里优惠回哪里”的规则来处理：

• 若是是指定某件商品/某类商品的优惠券，那优惠金额确定由该商品承担的。当退该商品，需减去优惠券金额。
• 若是是指定某些（分类、商户、活动等），那优惠金额分摊到符合资格的商品上。
• 若是是全店铺通用，那优惠金额分摊到每个购买商品上。

分摊金额的算法有两种：

• 按照符合优惠券的商品金额进行均摊
• 按照订单剩余部分是否符合优惠券

举例：顾客购买了A商品1件90元，B商品1件30元，使用了一张优惠券满100元减20元。若是顾客想退款A商品：

• 按照算法1，提交退款的最多金额为90*(90+30-20)/(90+30)=75元。
• 按照算法2，由于商品B＜100元，则提交退款的最多金额为90-20=70元。

实际状况中方案A和B的金额，有高有低。若是因为特殊缘由须要给用户多退，客服可在后台修改。

咱们APP采用的是第一种，对用户比较公平，体验比较好。

和其余营销功能的兼容性

营销功能我通常分为3大类：对商品的打折、对订单的优惠券、对全场的活动。

1. 打折，针对于商品，能够设置某一商品、能够是某一品类、也能够是全店……
2. 优惠券，针对于订单，能够设置减x元订单金额、减运费、减税费……
3. 活动，针对于全店&订单，通常设置为全场满x元减x元，满x元打x折，满x元包邮，满x元赠礼物……

当确认订单的时候，知足打折、优惠券、活动规则。谁先谁后，最终致使的付款金额是彻底不同的。

咱们设计的整套营销功能的计算规则以下，供你们参考。

优惠券和活动的本质

固然说到底，优惠券和活动本质是同样的。只是促销的外部表现，可是内部规则是通用的。对于初级PM来讲，可能不太可以理解这句话，可是必定要尝试从产品层面理解，也可从技术层面理解。

总结

本质上对于PM来讲，新接手一个从未作过的功能，都是根据本身用其余产品中的该功能认知以及本身的理解、以及产品经验来作的。问题是这样太具象了，须要抽象出核心的模块。

不少讲优惠券的文章太侧重运营层面了，问题是这样实现出来的功能其实只是徒有表象，稍微运营有点新需求就没法扩展了。这实际上是这个PM对优惠券的技术本质理解还不够深入。

说道最后，其实本质上就是优惠券的类如何设计，其余的都是依附于上面的方法，以及其余类的方法。