聊聊一个电商优惠券产品形态

待我称王封你为后i 2022-12-22 00:46 124阅读 0赞

### 优惠券形式 ###

我们经常浏览淘宝、京东等电商平台，可以领取优惠券来购买商品，像双11有很多满减优惠券，及无门槛的叠猫猫购物红包等，这些其实都是一种营销手段，本文来解析如何来实现一套优惠券方案。

### 优惠券方案后台 ###

#### 1、优惠券基本信息 ####

优惠券基本信息主要分为两个方面：派发 和 使用

*  派发  
    派发是指优惠券可以领取的时间范围、领取方式（唯一兑换码、通用兑换码）、总的派发数量、单日派发数量、领取指定用户（会员、新用户等）、每人领取限制、派发渠道（app、小程序）等。
 *  使用  
    使用就是具体的优惠券的使用时间、满足条件及优惠金额、是否叠加使用等。这些属于核销阶段，用户优惠券有的是满减券、打折券、每满减等形式，优惠券叠加的场景较复杂，有使用前叠加、使用后叠加、不叠加只能使用一个商品等情况，京东的优惠券有时候可以叠加，有京东优惠券、BU优惠券、店铺优惠券等，可以叠加使用。

这属于优惠券的基本信息，这些信息也足够满足对优惠券的需求，但更高层次的会有一些运营、品牌的考虑。

#### 2、优惠券商品信息 ####

基本信息可以适用于整个电商平台的所有商品，但有些商家不想参加、有些商品不想参加，所以还需要一个圈商品的动作，所以在商品信息这里可以做到：

*  指定商品品牌
 *  指定商品BU，运营角度，因为运营是按照Bu来划分的
 *  pop商家，与pop商家合作，双11的购物津贴基本是跨店铺的使用
 *  跨境方式，跨境电商可能对跨境也有要求
 *  黑名单：剔除掉某些满足上述条件，但依旧不想参与的商品，一个店铺里只允许10个商品参加，其他的商品都不允许参与，就需要把其他商品弄成一个黑名单。
 *  不适用的品牌，对BU级别来说，一个BU部门负责多个品牌，也可以剔除掉某个品牌。

#### 3、其他 ####

还有一些信息是关于优惠券成本的，这个优惠券是谁来承担成本、用途是那些、申请理由是那些，这些来做一些复盘，帮助了解运营的优惠操作，整体来看每个BU对优惠券的使用。

#### 4、审核优惠券 ####

优惠券的创建成功后，需要人工审核，一方面是二次确认，另一个方面是跨店铺和Bu的优惠券成本的问题，需要各个BU的主管来确认，防止无故将其他BU的商品做优惠卖出，影响毛利等，会有一些电商弄一个活动提报部门，每次大促让商家自主报名参与其中，这就涉及到优惠券、双十一主会场等，大促时期会有引流。

### 优惠券前台：面向用户 ###

#### 用户领取优惠券 ####

可以领取的优惠券是带有方案信息的，所以用户点击领取优惠券，我们要校验用户能不能领取，比如他已经领取了一张优惠券，再领取的时候会被限制，所以展示给前台用户的就是一个优惠券展示界面，但内部其实是一个优惠券ID，用户领取优惠券就是将优惠券id和用户id传给后台，后台来做存储。并且可以给用户领取的这个优惠券生成一个优惠券Id，包括日期、优惠券方案id、用户id、uuid等，当然要对一些进行转换加密，一般是把方案id加密，用户id 不带上，加密可以把数字转换为16进制、32进制等，这样不返回数据库主键id给前台，而且涵盖更多非敏感信息，之后的流程都会使用这个优惠券Id。

#### 订单预览选优惠券 ####

用户下单的时候，我们会让用户来选择优惠券使用，这里就主要是把符合条件的优惠券返回过来，包括系统自动选择优惠额度最大的优惠券，但可能用户并不想用，这个预览就是为了让用户可以选择自己想使用的优惠券，这里选择了对应的优惠券后，在下单页面就会直接使用。

#### 下单扣优惠券 ####

将用户的优惠券状态置为核销状态，这里要订单加幂等，避免用户重复提交数据。

#### 商品金额分摊 ####

这个属于优惠券做的分摊，交易也可以做。2件商品满足满100元减20，那么这20元怎么分摊到2件商品上，特别是一件是20元，一件是80元，这样优惠的20元应该怎么分摊到单个商品上，这样在财务那边算商品毛利的时候才能更直观，一般的做法是按照商品金额比例来承担优惠比例，20:80等于1:4，20元的优惠额也是按照这个比例，那么20元商品优惠了4元，80元商品优惠了16元。其他策略就看从那个角度来思考问题。

#### 退货 退优惠券 ####

如果用户下单后、下单付款成功后、收到货物后 等情况下，取消订单、退款等操作，需要退优惠券，但同时也要考虑优惠券的使用时间。

### 技术难题 ###

#### 1、派发阶段问题：几千万的优惠券怎么保证不超发 ####

派发优惠券的时候，很多人同时抢，如何做到数量不超发，因为每次用户只能抢一张优惠券，利用悲观锁来保证数据库优惠券总数数据每次减1，这样就可以避免超发，但问题是这样的并发不大，因为每次就更新派发数量，这一条记录肯定会被数据库加锁，整体来说并发量难以提升。

#### 2、如何提高派发性能 ####

缓存，提高并发的一大利器，就是利用内存来做事情，利用redis这种远程缓存来做数据的更新会比直接操作数据库提高更多性能。但派发的时候也需要将用户和优惠券绑定起来，这样用户也可以看到自己领取的优惠券，所以需要需要将用户领取的优惠券信息落到数据库中，那么派发的时候也需要插入数据库数据，优惠券计数可以在缓存里加减，但数据库插入记录可能会失败，失败后，缓存里可能已经扣减成功，这样数据就不一致了，所以如何保证缓存里扣减和插入数据库一致？有一个解决方案就是利用lua脚本来实现单线程处理，缓存里存派发总数，然后每个用户领取的做流水表。利用一个兜底的定时任务来比较缓存和数据库的一致性。当然网上还有另一个版本：

*  缓存计数+MQ  
    优惠券总数是在缓存里实现，然后把用户id和领取的优惠券方案id 利用消息队列发送处理，异步来实现用户和优惠券的绑定关系和插入数据库，后台处理，但这处理时效性如何，还是不太能保证超发。

#### 3、后续 ####