电商平台优惠券的前后端设计

每一次逛网购商城，咱们总能看见这样那样的促销活动，活动的同时总**“塞”一把优惠**到咱们的账户中。促销是所有电商平台日常运营的重要组成部分，是为了实现拉新、促活、销库存、打造爆款、提高客单价、扩大品牌知名等目的手段。本篇将重点描述关于优惠**前后端模块。

因业务方向和运营促销，优惠**的品类和规则往往**以不同维度更多元的表现形式进行展现。

在设计优惠**系统前后台时，作为产品的我们不仅需要了解市面上绝大部分的优惠**( 跨店铺满减**/ Plus**无门槛**/ Push定向**等等)，认识各种繁琐规则，还需要因地制宜，根据产品业务主体进行剖析找到适合公司产品本身的优惠促活拉新方式。

下面截几个笔者常用的购买B2B的图( 其他考拉/国美/小米等这里不一一展示 )：

了解各大平台电商优惠**的特性和用途后，按照规律以不同的维度进行划分，这样也有助于梳理产品规则和产品流程，防止因为规则碰撞或流程疏漏导致一场满心期待的促销活动变成“黑天鹅事件”。

17年有几个典型案例。某天猫商家电视价格摆错，60英寸4K仅售1999，一小时损失高达400W；京东某商家优惠**叠加，珠串100串合计下单作价2元；猫**、商城品牌店等错价这类事情更是不计其数，羊毛群大哥**薅到你怀疑人生。(Ps：关于优惠**的漏洞可参阅笔者另两篇文章：《从产品流程上，复**拼多多的风控漏洞》、《复**淘宝双十一，我用产品思维薅羊毛》)

 一、发放方式

优惠**发放的途径我们这里为两种，系统发放 和 用户领取。

系统发放 根据行为操作来判断，我们分为 系统自动发放 和 人工手动发放 。

• 系统自动发放：指制定规则，系统程序设置后符合规则就触发发**逻辑。满足条件后，用户主动或被动触发获得优惠**，可以是主动触发( 短信链接 / 销售定向发** )，也可以是被动响应，被动响应有以下几种形式：1.进入页面，新用户条件or满足场景触发弹窗，告知用户获得xxx课程优惠**；2.用户数据行为分析.判断相对应的用户需求,定向push对应的需求**,在合适的时间弹窗促销.(PS：条件触发，弹窗已领，饿了有人送饭到嘴边多美好)。两种方式效果,笔者倾向被动触发。随风潜入夜,润物细无声,自然的方式相较尽不突兀的方式给用户传递优惠.而短信告知的方式不仅需要花钱且常被误以为是诈骗信息。
• 人工手动发放：当有奖励或者赔偿用户时，可由客服或运营人员手动发放。在这块我们特指补偿机制下，做用户关怀以及安抚用户时发送的特定补偿**。

用户领取 根据获取层级来划分，我们分为 一级领取 和 二级领取 。

• 一级领取指的是活动页面直接领取。
• 二级领取指的是通过“任务”形式完成达成条件获取，这里大略的可以有三种方式：分享领取，签到奖励(签到系统)，积分兑换(积分系统)。其中分享领取的内容可以比较多样和灵活，可以有固额万能**，定向优惠**，随机金额**，第N个最大等，具体实施需沟通策划部门。

一级领取简单粗暴，二级领取增加用户黏度，到底哪个更有效个人认为仍需通过数据说话，毕竟不同产品类别其用户人群不同必然导致效果有所差异…年轻人能接受多的花样但是你让一个50+大叔各种计算淘宝优惠规则他一定是不耐烦以及不愿意去做的.二级领取通过和用户的互动促活，拉近与用户之间的距离，个人建议这类获取可以提高一下**的价值。

二、使用规则

发放完优惠**，当然是让用户使用，这里就需要制定严谨的使用规则。使用规则我分为三块 内容显示 、**面规则 、 优惠规则 。

内容显示，简单的说优惠**可以分为三个状态 交易前/交易中/交易后。

交易前：前端部分需要一个优惠**的库，存放用户所有获取的优惠**。交易中：即交易选择规则。这里有三个默认交易选择逻辑：默认使用优惠最大的**/默认使用时间最先过期/手动选择。其中优惠最大又**涉及到定向**和通用**的大小比较。

交易后：即订单完成后所有**的变化。首先不管订单是否成功交易还是取消订单或者退款都表示该订单已完成最终的状态，那么**的状态一定发生改变。如果是退款的完成订单或取消订单，根据开发进度考虑是否添加退**逻辑，即将本已使用失效的优惠**重新重置变成未生效的优惠**( 也可一刀切，没有该逻辑，使用即失效，有需要售后补** )。

优惠规则，是运营的重中之中。

关系到钱，稍有不慎可能就要卷铺盖走人了。So，定制优惠**逻辑且做好后台沟通特别重要。参照目前世面上繁多的优惠**，我大致整理了一下，将其分为三类：叠加规则、满减规则、预付规则。

叠加规则可以分为两块：同类叠加/满额累减/唯一使用。

同类叠加这里比较复杂，有购买一种产品可以使用多种优惠**，也就是通用万能**或者是运费**，可以参考京东，例：手机原价2000元运费6元，可以使用100的手机优惠**且可以使用6元运费**，那么结算就是2000+6-100-6=1900远。

另一种是同一类商品购买两个及以上归属为一类商品，这一类的商品金额叠加满足类优惠**条件即可减免。

例：电器A价格200元，电器B价格400元，电器类通用优惠**规则是满600减100，那么购买电器A和电器B，结算200+400-100=500元。满额累减即字面理解，总金额达到即减去多少金额，有一点类似同类叠加满减，但是逻辑简单的多。

例：参与活动的任意商品满1000减200，像商城买衣服满减活动一样。最后就是唯一使用，没有叠加其他优惠都不可行。

满减规则这里我们分为三块：限额优惠/指定优惠/**面优惠。

限额优惠通常适用于折扣万能**，比如全场9折**，上限是优惠200。

例：我有一张全场9折**，最多优惠200元，那么我购买一款价格为20000元的电脑，实际最高也只能优惠200元。制定优惠指某商品特定的优惠**，该优惠**只能作用某一个编号的商品。**面优惠最易理解，就是**面上的优惠金额，是多少即优惠多少即可。

预付规则，这有别于我们所说的通用优惠**。

有一点类似于万能**，指的是预付固定金额在一定条件后可以抵扣更高金额。笔者不推荐预付和万能**叠加，并在业务种需要进行预判隔离，这种情况经常**造成巨大的业务漏洞。

**面规则，分为三块内容 — 状态、范围、时间。

状态分为四个类，已使用/已过期/已失效(退费以取消订单产生的**)/未使用。范围分为两个类，全品类和指定类(指定类可以作很多衍生，搭配不同的规则，这里不一一展开)。时间分为两个类，领取时间和使用时间。

三、后台设计

通过对一和二两个大块的陈述，程序员对优惠**后台搭建能够有了初步的架构方案，个人建议后台设计一定灵活多变可以变换。不然当业务影响产品导致运营形态发送改变时，开发的成本**异常的大。

后台设计主要有三块：制** 核销 退订**处理。其中购物车逻辑和合并支付逻辑难度相对低一些，可以参考市面上很多现有的逻辑去开发。

1. 制**，优惠**诞生的第一步，一套复杂的规则往往是运营的噩梦。举例：当**面向商城、店铺、单一产品、组合产品的适合，再与**本身的规则相叠加，很容易出现**漏洞。运营在设置价格时，对业务不了解，不熟悉其中的规则和具体各类产品价格容易出现“摆乌龙”事件。所以也有了某些电商平台在搭建商家后台时做了价格提醒。
2. 核销主要存在付款场景种，这时就需要后台对用户**信息进行二次核对，匹配相关用户优惠**，当订单完成后及时改变**的状态。除此，还存在优惠**过期的这种情况，后台也需要及时进行过期状态变更。
3. 退订**处理，主要针对用户完成订单后进行售后(退款或退货)时,优惠**的返还机制。简单的说有以下几种情况：

• 订单取消优惠**全部不返还；
• 订单取消优惠**等比例返还(使用规则不变)；
• 订单取消优惠**全额返还。

这里笔者建议第三种，也就是全额返还。不过遇到特殊情况比如拆单退款中跨店铺优惠**又要特殊处理，如果订单取消就全部退货则优惠**全部返还，若允许部分退货则按比例返还跨店铺优惠**不退还其他叠加优惠**。

四、其他：优惠**和分润

除此之外，针对一些特殊情况，当公司存在分公司、经销商(代理)，那么优惠**的使用又**涉及到代理的分润。简单的做就是一刀切，优惠**活动由集团统一使用，分润规则参照集团之前制定的各类按照销售\数量等情况进行分润,优惠**优惠金额不由集团独自承担。具体的实施仍需各部门讨论。

优惠**作为运营常用的策划促销活动，相信大伙儿的公司都有一套成熟的产品设计方案。不过笔者在最后插一句，不论如何优惠**都必须根据业务实际情况制定相对应的优惠规则和策略，并且明确各种优惠之间的边界，常驻风控思维。

同时，优惠**促销活动也是一把双刃剑，实现拉新、促活、销库存、打造爆款、提高客单价、扩大品牌知名等目的才是优惠**的价值所在。任何一场优惠**活动，前期需要对运营活动成本进行核算以及预估活动效果，中期根据“A/B Test”及时进行调整，后期对活动进行复**，对整体活动的价值进行分析，判断投入产出比，选择最合适的促销手段。

本文由 @四月春波 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自Unsplash，基于CC0协议

给作者打赏，鼓励TA抓紧创作！

**赏

1人打赏