掌握电商后台设计，这一篇足矣
本文转载自http://www.yixieshi.com/78740.html
本文包括以下几个部分：
- 电商后台系统概述
- 电商后台产品设计：商品中心
- 电商后台产品设计：订单拆单
- 电商后台产品设计：促销活动解析
- 电商后台产品设计：优惠券的设计和妙用
对电商公司来讲，最核心最难做的三部分：商品、订单、库存。
商品与店铺、营销、评价等相关，订单与会员、营销、支付、库存、物流等相关，库存与订单、采购、WMS、营销等相关，系统之间业务逻辑和交互异常复杂，规则多样。
一、 商品常用概念介绍
先介绍几个基本概念：SKU、SPU、属性、类目。
- SKU
stock keeping uint（库存量单位），库存控制的最小可用单位。例如Iphone 7plus 128G 银色就是一个SKU，仓库管理、采购进货、库存显示的都是SKU。
不同的公司都有自己的SKU编码规则，如果有自己的仓库，在商品入库时一般会打上自己的SKU码，这样整一套库存体系就会自上而下打通，当然还有另一种处理方式，设置自有SKU码与供应商条码的对应关系，将订单转化为发货单时，将自有SKU码转化为供应商的条码。
对大公司来说，推荐前一种做法，后一种由于供应商编码规则不同，或者管理规范，在实际操作往往会增加出错率。
仓库和采购管理的都是具体的SKU。
- SPU
standard product unit（标准化产品单元），是一组标准化信息的集合，例如Iphone 7plus就是一个SPU。SPU与SKU的关系有许多种，可以一对多，一对一，如下图所示。
SPU信息中应该包含SPU属性、产品图片、产品描述、产品标签。SPU和SKU之间是通过规格来链接的。
SPU(Iphone 7plus)通过颜色、内容关联到SKU(Iphone 7plus 128G 银色)。SPU的库存是由其对应的SKU库存共同决定的。
- 属性
分为关键属性、销售属性、非关键属性。
关键属性是指能够唯一确定产品的属性，是必填项。例如手机的品牌、型号属于关键属性；销售属性组成SKU的特殊属性，或称为规格属性，如手机的”颜色”、”内存”；非关键属性指的是除关键属性、销售属性外的其他属性，如手机的手机接口类型，非关键属性不一定是非必填项，有时为了商品信息完整，也会设为必填项。
属性定义对于良好的消费体验有着至关重要的关系，对搜索、索引、筛选都有至关重要的作用。
- 类目
分类树，电商常用的有两层类目，前台展示类目，后端商品类目。
前台类目指的是展示给消费者的类目，会根据季节、销售策略、活动进行变动；后台类目属于基础数据，不可随意变动，添加SKU时都需要选择类目，进行绑定。
需要注意的是，类目树的层次不能太深，一般三层或四层，如果太深，不论对于管理还是技术性能来说，都是不利的。前台类目与后台类目可随意搭配，设置前台类目关联时，对前台类目树最深层进行设置，可让其关联后台类目任一层，可一对一、一对多。前台类目还可以对应品牌。
京东的商品标题是加上具体的规格，在选择规格时会跳转SKU，对于落单数据有效率提升，但是对于页面效率和体验是不如淘宝的SPU结构的。现在大部分电商都采用的是淘宝的SPU结构，亦是优质选择。
在淘宝上选择具体的规格后，会发现商品缩略图会发生变化，这就需要在管理商品时，针对某规格单独上传图片。这里有个设计很巧妙的地方，只是不同颜色需要上传对应的商品缩略图，而尺码不需要。
四、电商后台产品设计：优惠券的设计和妙用
优惠券是一种常见的促销方式，在规定的周期内购买对应商品类型和额度的商品时，结算时满足一定条件会减免一定金额。通过发放优惠券，引导用户购买相应的商品，在下单的时候抵扣一定的费用，达到促销、提高客单价的目标。
一、优惠券的类型和应用场景
优惠券有多种分类方式，按照使用门槛、使用范围、发放主体等有不同的分类。
1.1 按照使用门槛分为现金券、满减券、折扣券。
现金券：不限制订单金额，可以直接使用。
满减券：订单金额需要满足一定的最低额度才可使用，例如：满100减10元优惠券。
1.2 按照适用范围分为：单品券、品类券、品牌券。
单品券：购买优惠券指定商品时可使用，这种优惠券一般只针对少量特殊商品可以使用。
品类券：购买优惠券指定类别的商品即可使用，除个别特殊商品。
品牌券：购买优惠券指定品牌的商品时可使用，除个别特殊商品。
一般按照品牌或者品类设置优惠券范围是比较常见的方式。
1.3 按照发放的主体分为平台优惠券和店铺优惠券
平台优惠券：优惠由平台承担，比如平台活动优惠券、平台注册的新人优惠券、平台积分兑换的优惠券。
店铺优惠券：在平台上的店铺自己发放的优惠券，比如淘宝上的店铺优惠券、京东的店铺优惠券。
平台优惠券的金额由平台承担，在店铺使用时优惠金额由平台返给店铺；店铺优惠券的成本由店铺自己承担。
二、优惠券的设计规则
从优惠券的生命周期，来设计优惠券是最恰当的。
2.1 生成优惠券
在生成优惠券时，主要是从优惠券信息和推广信息两方面来考虑优惠券的设计。
2.1.1 优惠券信息
- 优惠券名称
- 类型：现金券、满减券、折扣券
- 面值：例如10元。
- 使用条件：满XX元可用
- 使用平台：客户端、H5商城、主站、各分销渠道
- 有效期时间：绝对时间（时间段）、相对时间（领取之日后多少天有效）
- 发行量：优惠券张数（设置限额）
- 使用范围：平台券（全平台通用）、店铺券（仅在某店铺可用）
- 商品范围：全品类、限制品类、限制商品
2.1.2 推广信息
- 发放方式：可发放可领取、仅可发放(只能由平台发放给用户)、仅可领取（只能用户自己领取或兑换）
- 推广范围：免费领取、积分兑换
- 优惠券是否公开：设置公开后，在领券专区、商品详情页、购物车都默认展示
- 限领：每人仅限一张、每人每天限领一张
- 券领取时间：设置领取时间段（过期）
- 在优惠券生成之后，将优惠券显示在优惠券列表中。
2.2 发送优惠券
优惠券有主动领取和被动领取两种方式。
主动领取：
用户在店铺首页或者平台上看到优惠券，主动进行领取；用户在线下看到宣传推广；朋友圈优惠券分享链接等等。
这种发放方式需要一定的运营成本，需要打动用户，产生兴趣进行主动领取，这种方式需要做好防作弊机制，真正获取到的用户价值较高。
被动领取：
系统主动给用户发送相应的优惠券，但是这种大面积分发的方式，用户精准度低，转化率较低，只能很少促进客单量。
系统发放优惠券场景有很多种：1.用户注册；2.大促活动；3.还有客服发券，主要是售后补偿（平台责任导致售后，发券补偿客户），或者好评返现。
除了以上的方式，还有许多平台电商的一项业务：大客户团购，主要是给一些单位提供的福利卡，例如京东卡。可以通过优惠券（平台币）的形式实现，生成相应的卡密（或兑换码），制作实物卡售卖给一些公司发福利、送礼。用户输入卡密兑换之后，兑换成平台的交易币（相当于给购物卡充值），可以用来抵扣订单金额。
发送优惠券虽然在前端页面只是简单的一个交互，但是后端有大量的逻辑需要处理。
校验用户登录状态 → 优惠券信息读取（是否在有效期、是否可发放、剩余数量） → 优惠券绑定用户
2.3 优惠券核销
在用户下单时，肯定是需要系统从其账户中的优惠券选择合适的优惠券推荐给其使用的。我思考的推荐算法应该分三步：
- 从用户优惠券列表中选择出当前订单可用的优惠券（包括通用券和相应产品优惠券），主要是从有效期、商品范围等条件判断
- 若有多种可用优惠券，但是金额不同，默认选择可抵扣最高的优惠券。
- 如果金额相同，先匹配同类优惠券的优惠券，但当优惠券的额度（现金券）大于支付额度弹出提醒框，确认是否使用。
注：在用户的优惠券列表中，优惠券是否失效也是实时拉取的（失效过长应清除此优惠券），下单时优惠券选择应仅显示用户可用优惠券。
2.4 优惠券统计
主要统计优惠券的发送张数、使用张数。深度数据挖掘可以统计优惠券对应的客单价、复购率等等。
三、优惠券的前端展示
优惠券的前端露出窗口主要有五处：用户优惠券列表、订单提交页、购物车、商品详情页、领券中心（或优惠券分享链接）。
前端展示的难点在于商品详情页和购物车中展示可用优惠券。需要高效率的算法来计算匹配商品对应的优惠券，主要有两点好处：1.优惠券来促进用户消费；2.在用户消费时帮助用户省钱。告知用户有优惠可以享受，避免用户下单之后看到相关优惠没有享受到产生不平衡心理。
优惠券（京东）的前端透出
四、优惠券在订单中的处理
下单时优惠券的匹配在前面已经叙述过，主要是分为三步，详见2.3优惠券的核销。本节重点讲解优惠券的逆向流程。
在订单完成售后（退款或退货）时，优惠券应有一定的返还机制。
- 统一设置成不可返还，用了之后就不退。
- 订单中全部退款时，优惠券全部退还。
- 订单中部分退款时，普通优惠券不返还，现金券按金额比例退还。
优惠券有着一套很成熟的产品设计方案，介绍之后，再提一个目前绝大部门产品难以解决的问题：基于日常优惠券的使用情况，运营人员如何平衡发放优惠券所带来的成本增长，商品销量增长和单品毛利下降之间的矛盾？在申请促销活动经费时，怎样的数据更具说服力？