经验之谈：电商平台促销活动怎么做？

管理后台

快捷登录

只需一步，快速开始

经验之谈：电商平台促销活动怎么做？

2022-3-13 11:34| 发布者: 元直的心凹| 查看: 3714| 评论: 0

微富网 › ›新闻资讯 › 查看内容

摘要 : 电商平台的促销活动要怎么做，才能吸引用户来购买呢？一、促销活动概念及分类电商平台促销活动多种多样，从促销活动的范围来看，分为单品促销活动、多商品促销活动、店铺促销活动，平台促销活动。从是否对商品的价格 ...

电商平台的促销活动要怎么做，才能吸引用户来购买呢？

经验之谈：电商平台促销活动怎么做？

一、促销活动概念及分类

电商平台促销活动多种多样，从促销活动的范围来看，分为单品促销活动、多商品促销活动、店铺促销活动，平台促销活动。

从是否对商品的价格产生影响来说，又分为两类：

一类是对商品价格产生影响的活动，在交易完成后，由于活动产生的优惠需要分摊到价格中去，因为这些是需要衡量成本的；
另一类则是不对商品价格产生影响。

二、不同类型的促销活动的意义

单品活动包括：买送（买单品送原品）、买降（多买降价）、特价（单品降价）、秒杀（降价幅度大，限时）；店铺活动包括：满减、满赠、店铺券；平台活动包括：平台券。

特价/秒杀活动：特价/秒杀活动都是基于单品的价格做活动，通常情况为一些热门产品设置特价/秒杀，达到为订单引流的作用，尤其是我所在的医药电商领域，通常卖家会设置一个较高的起配金额，未达到起配金额的订单将不会发货，所以为了购买这个引流款，必须购买更多的商品。
买降活动：主要应用于批发的场景，对于批发行业来说，一次性购买的更多的客户更有可能享受到更低的价格。从这方面来说，客户为了节约成本，需要一次性购买更多这个商品。
买送活动：买送即买原品送原品，这个正常情况下比较少，主要是应用于小单价的批发中，因为对于B2B来说，采购的客户基本不需要其他类型的赠品，反而送原品对他们来说肯定是有用的，而且送的原品也会纳入他们成本考虑的范畴。
满减活动：满减活动应用场景比较广泛，对于大单价商品来说可以做单品满减促进该商品的转化率，对于小单价的商品来说，主要是促进店铺的整体转化率并提升客单价。
满赠活动：满赠活动和满减一样，可以设置单品满赠或店铺满赠，玩法与各自的业务场景有关。
店铺券：店铺发送优惠劵，折扣的方式分为满减或满折，更多的是起到提升店铺转化率和客单价的作用，满折更多适用于B2B，因为B端用户更多的会去衡量各个商品的毛利有多少。
平台券：平台发送的平台券，主要是起到为平台引流，提升平台下单成功率的作用，最好的效果是客户最后在使用平台券的时候带动多个店铺的销量。

三、促销活动模块设计方法

下面分别从以下几个维度，分别讲解促销活动的处理办法：

2.1 营销活动后台设计

后台编辑营销活动时，主要分为三大模块信息：活动定义、限制条件、商品范围。

1）活动定义包括：活动名称、活动描述、促销规则

促销规则：

需要注意的是，特价/秒杀活动有可能需要手动设置原价（因为在前端展示的时候如果直接拿商品的真实价格作为原价显示的话，会显得促销力度不够大）；
满赠及满减，买送等活动需要设置多阶梯的促销规则；
满减活动和优惠券需要考虑到折扣类型是满减还是满折，对于客户下单来说是有不同意义的。

2）活动描述包括：活动时间、活动库存、限购数量/次数是否参加满减等

活动库存：主要用于单品活动，运营设置活动的时候，偏向于拿一部分固定的商品参加活动，先到先得，这样也能控制总体成本。活动库存的设置会影响到库存逻辑，这个在库存的专题再详细介绍。

限购数量/次数：限购的角度可以分两种，一种是针对于商品限购，一种是针对于订单限购。

针对于单品限购的情况下，只允许客户买指定的数量，超出的数量不参加活动；
针对于订单的限购的情况下，至允许客户前多少次下单才享受活动（一般用于满减）。

是否参加满减：适用于单价低，sku比较多的品类，这个时候一般商品进行特价活动时，会涉及单品毛利计算的问题，所以该部分商品不能参加满减。

另外优惠券需要包括发放张数，每人限领取数量及优惠券使用时间，如果券的发放和领取是一起的话，还需要设置该张优惠券是否显示在前端，这样可以将该张券单独作为线下发放使用。优惠券设计层面，部分平台倾向于先设计好优惠券再创建活动使用该张优惠券，根据不同的业务场景可以考虑不同的方式。

3）商品范围：按照商品范围可以设置全店铺商品、部分商品（多商品）、类目、单品

只有店铺活动和平台活动，才可以选择设置全店铺商品、部分商品（多商品）、类目，单品活动则只需要选择对应的商品即可。对于满减，店铺券，平台券活动，如果运营不希望某个/某些/某店铺/某分类商品不能参加活动时，可以加一个不参加活动商品的功能。

店铺券和平台券不建议设置不参加活动的商品，因为使用店铺券和平台券时客户已经到确认订单页了，这个时候说不满足优惠券使用条件，那么客户得重新计算金额。并且如果不知道是哪个商品不符合用券条件的话，那么客户这个时候不知道怎么操作，会比较沮丧。

4）赠品设置：某些活动需要设置赠品

赠品处理有两种解决方案：

一种是做单独做SKU，赠品到时候也会作为一个商品被摆上货架，下单的时候将会自动加到商品列表，这样比较依赖于业务条件。因为对于小单品且sku比较多的商品来说，商品都是自动同步的，这个时候erp不一定有单独的赠品的sku。而且像我所属的医药电商平台，所有的店铺卖的都是平台的标的，对于赠品这种无法准备定义的商品，平台是无法去专门维护基础库的；
另一种则是做一个假SKU，那么在前端显示的时候只显示赠品的名称，也不会有专门的商品的详情页，这样处理的话比较简单。但是对于用户来说，无法准确评估赠品的价值，另外还需要单独维护一套赠品库和赠品库存（赠品库存逻辑在后面的库存专题中会讲到）。

5）活动效果统计

正常情况下，每次进行活动时运营需要知道有多少人参加了这个活动，统计的维度根据活动性质定义，如果是单品活动，就统计这个单品采购数量，关联订单数量；如果是满减或用券活动，那么就统计对应的订单数和客单价。

优惠券还可以分别统计领券的人数和用券的人数。

2.2 活动之间的互斥规则

活动之间需要设计互斥，尤其是单品活动，因为一个单品只能由一个特价活动。

处理方式分两种：

一种是在后台创建活动时处理，挑选商品时前端控制不能选择已参加过互斥活动的商品；
另一种是后台创建活动时不做限制，如果活动互斥的话，那么用户可以选择享受什么优惠（对于大型平台更加适用）。

2.3 前端页面处理

前端页面的信息展示主要是在三个层面：

一个是商品卡片，涉及展示的价格，活动标识，原价的展示；
一个是商品详情，商品详情中需要展示活动信息，领券入口，特价商品标识等；
另一个是购物车：购物车中需要展示领券入口，满减入口即享受的满减折扣，单品活动价格等，尤其需要注意不参与满减活动的商品及单品活动，超出限购的数量的展示。

其他页面还包括如活动专区专区：适用于多个商品的活动，如：满减、满赠；领券中心：展示可以的优惠券；确认订单：使用店铺券和平台券，其他H5专题页，但是这种方式只能展示有限的商品。

购物车的排列：购物车的商品先按照店铺的维度，把不同的店铺商品聚合在一起，再按照店铺活动的维度把参加同一活动的商品聚合在一起，最后是单个商品。

金额之和：是在支付环节的购物车和确认订单页面，按照分摊的顺序分别是单品活动、店铺活动、平台活动，其中店铺活动的满减更多的是展示在购物车，用券更多的是在确认订单页。

另外由于单品只能展示一个价格且该价格在前端页面会直接显示出来，如果定义这个价格为销售价的话，那么本页面的商品的价格为：销售价*数量之和-满减优惠金额之和。

而在确认订单页，每个店铺的小计=销售价*数量之和-满减优惠-店铺优惠，总的结算金额为：店铺小计之和-平台券优惠。

2.4 价格分摊

价格分摊的最主要目的一个是便于运营核对成本，还可以作为与商家对账的根据，尤其是可以作为退款的依据（即优惠平摊到每个商品上，这样可能会引起部分客户为了满足优惠条件而先凑够订单金额，之后再进行退款，但这样更透明，体验会更好。如果平台为了规避这种问题，采取其他办法如先退还优惠券，这样又会导致客户的信息不对称）

价格分摊的顺序：先以销售价作为商品在订单中展示的价格，当存在满减活动时，参加满减的活动的商品针对满减金额进行分摊。当存在店铺券活动时，全店铺的商品的商品基于满减分摊后的金额，继续进行分摊，平台券的分摊同理是基于店铺券分摊之后的金额进行分摊。

分摊算法：

由于价格不管怎么样分摊，都是会存在误差的，所以尽量让误差最小，如果按照最简单的方式分摊的金额=单价*优惠金额/符合优惠条件商品总金额，然后进行向下取整，那么每一个单品都会产生一个误差。如果这个误差定义为小数点后三位的话，那么每一个商品都会有一个最大不超过0.01的误差，100件商品可能会存在一个最大不超过1.00的误差。

那么只能优化算法尽量让误差更小，刚刚分析误差大的原因是100件商品都有一个误差，那么我们缩小这个数量即可。所以我们肯定是需要将优惠一步步按照商品的维度（一个商品可能买了多个）分摊下来的，最终的误差取决于最后分摊的一批商品数量有多少。

每一步的每个商品需分摊误差=单价*待分摊优惠/待分摊商品总额，所以制定商品分摊排序的时候，最后分摊的一批商品数量越少越好，具体商品分摊时应该怎么排序可以视业务情况而定。

另一个维度：我们需要确保每一个商品被分摊的误差的公平性，如果分摊不均的情况下，在退货时候，可能因为实际享受到优惠的偏大或偏小而影响商家或客户的利益，所以算法也需要照顾到这一点。（这个意义不大，而且不太好处理）

误差处理：我们之前遇到的很大的一个问题就是我们的误差处理方式有问题，导致最后财务大规模无法对账，我们之前的逻辑是店铺优惠分摊下来的误差全部放到子订单中，平台券的误差全部放到母订单名下。这样的处理的话一个是退款的时候，可能会导致多退给采购商钱了（因为平台券优惠没有分摊完，导致子订单金额比母订单金额要大）。

但是我们给钱的时候却又少给了采购商钱，财务对账的时候没办法平这个误差，所以最后把平台券误差直接放到一个金额较大的供应商名下，那么无论如何都是平的。

2.5 其他重要问题

无论是前端还是后台的订单，订单中一定要显示商品，否则采购商不知道赠品到底有没有显示，而供应商也不知道到底有没有赠品，这一点容易被遗漏。

赠品处理：上文已说过，如果赠品直接和ERP是同步的，那么在订单同步时赠品一定要同步过去；如果赠品和ERP没有同步，那么订单同步时赠品只能通过备注来提醒买家。

取消订单/退款：取消订单或整单退款时，对应的订单中使用的优惠券和限购数量，限购次数一定要回滚，否则客户取消订单之后再购买则会产生体验的问题。