实例分享B2C自营电商APP的优惠券设计方案1.0
整理了一下我们APP中优惠券模块的设计方案，只谈产品层面如何设计功能，不谈运营层面如何运作券码，兼顾技术层面。初次分享定义为1.0，以后会多次迭代。
基于我们产品是B2C自营电商的底层架构，所以我产品设计的优惠券方案至少支持以下下列使用场景：满减券、打折券、包邮券、商品券、满赠券、全场通用券等等。
一直以来接触的是淘宝店铺的产品管理体系，根据自己以前电商的电商运营经验和对电话卡的理解，最终抽象得出一套通用性的优惠券设计方案。
优惠券的本质是经济学中的生产成本歧视。形式上给予消费者很强心理一定的折扣，然后促成订单。本质上商家获取向不同的接受者提供相同的商品或相同质量的服务，但是在接受者之间实行不同的销售价格。
优惠券的表象
对于顾客来说，优惠券就是买东西的时候随便用它来小钱。
对于初级PM来说，优惠券可能就是满减券、打折券、满赠券这3种类型。那从关键技术层面来说，RD至少需要构建3个类，并且无法兼顾优惠码。并且后续很难去兼顾运营所提去的新优惠券类型。
其次淘宝给店铺提供更多了3种优惠券：订单券、商品券、包邮券，这是平台的策略。我们是独立B2C，不必需做得这样细。京东也类似。
优惠券的类
从面向对象的技术角度来说，优惠券可以抽象成类，本质上是类的模板化。
优惠券的价值
是优惠，不是现金。
请注意电商领域通俗意义的优惠券是指下单可以优惠金额的券，使用即作废。不是那种可以充值那份到账户的现金券，也不是可以使用多张的兑换券折扣券。
简单来说，就是拉新促活。
先说大概步骤：
app开发实例新建
即你想尽办法什么样的优惠券，包含优惠券的面值，有效期，类型，门槛，使用限制，标签……
新建是指新建了三十多个优惠券，可能限定了总张数，也可能不限定。本质上就是构建优惠券这个类的属性，具体如下：
需要有单独说明的是：
审核
优惠券其实是让利提升销量，所以需要业务部门申请并提交财务审核。不过我们APP体量还小，这一步暂时省略。后续可以补充。
发放
审核通过的优惠券需要向目标用户进行。发放是个泛概念，分为用户主动领取系统自动发放。
新建优惠券的时候，提供支持已然提供了一个显示到前端的属性，称之为领券。
比如给每一个批次的优惠券生成链接，发给用户让他们去领。
另外：注册自动返券，下单自动返券，邀请成功自动沃多，属于系统自动发放的类型。
发放这一步是很偏运营的事儿，产品配合好即可。
领取
当用户领取成功后，我的优惠券列表新增一条记录。休眠状态此时这张券的状态是未使用，下单的时候如果转用了它，则为已使用状态。
使用
优惠券的使用和订单流程强关联，一种是先用券后生成订单，还有一种是先生成订单再用券。我们APP采用的是前者，遵循用户被淘宝京东培养出来的认知习惯。
可以选择优惠券之后生成订单，此时该张优惠券和该订单进行绑定，同时状态变成”已使用”。
订货注意每个订单最多使用一张优惠券，一张优惠券只能使用一次。理论上来说一个订单可以使用多张券，一张优惠券优惠券可以所用多次比如uber有那种使用x次的晚高峰券，只是这样会让业务变得很复杂，产品设计和技术实现都会变得很复杂。除非业务必须，否则不推荐这样做。
回收
过期未使用的优惠券需要进行回收和作废。
统计
无论是生成优惠券的记录、还是每六张被领取的记录，以及每件使用的记录，都需要记录日志供查询。
优惠券是否退还
理论上来说优惠券一般不退，优惠券1.0版本中不支持将未付款而的订单绑定的优惠券进行返还，如果以后有时间可能会优化一下。此时会多一个使用中或者锁定的中间状态。
退款的时候优惠的金额怎么处理
如果不处理，那用户下单100+50-20优惠，如果全部退款则是退款150，很明显对商家造成前面营收上面的损失。
如果处理则按照”哪里优惠回哪里”的规则来处理：
分摊额度的算法有两种：
举例：顾客购买了A商品1件90元，B商品1件30元，使用了一张优惠券满100元减20元。如果顾客想退款A商品：
实际情况中方案A和B的金额，有高有低。如果用户由于特殊原因需要给客户多退，客服可在后台修改。
我们APP采用的是第一种，对用户比较公平，体验比较好。
营销功能我一般拆成3大类：对商品的打折、对订单的优惠券、对全场的活动。
当确认订单的时候，满足打折、优惠券、活动规则。谁先谁后，最终导致的付款金额是完全不一样的。
我们设计的整套营销功能的计算规则如下，供大家参考。
当然说到底，会员卡和活动本质优惠券是一样的。只是促销的外部表现，但是内部游戏规则是通用的。对于初级PM来说，可能不太能够理解这句话，但是一定要尝试从产品层面理解，也可从技术层面认同。
本质上对于PM来说，新出新接手一个从未做过的功能，都是根据自己用其他产品中的该功能认知以及感知自己的理解、以及产品经验来做的。风险问题是这样太具象了，需要抽象出核心的模块。
很多讲优惠券的文章太侧重运营层面了，问题是这样实现出来的功能其实只是徒有表象，稍微运营有点新需求就难于扩展了。这其实是这个PM对赠品的优惠券技术本质理解还不够深刻。
说道最后，其实本质上面就是优惠券的貌似类如何设计，其他的都是依附于上面的方法，以及其他类的方法。