36、生鲜电商平台-积分,优惠券,会员折扣,签到、预售、拼团、砍价、秒杀及抽奖等促销模块架构设计

说明:本标题列举了所有目前社会上常见的促销方案,目前贴出实际的业务运营手段以及架构设计,包括业务说明,仅供参考

促销体系

1.1促销体系

在电商和O2O领域,促销是运营人员的一个主要的让利行为,同时促销活动期间的购买量也较之普通商品更高,不同的阶段,对于促销的要求也是不同的。

促销实质上是一种沟通活动,即营销者(信息提供者或发送者)发出作为刺激消费的各种信息,把信息传递到一个或更多的目标对象(即信息接受者,如听众、观众、读者、消费者或用户等),以影响其态度和行为。

商城促销活动的流程概述(不含优惠券):

  1. 在平台后台创建促销活动
  2. 选择促销方式,对应编辑该促销方式的设置项,选择参与活动的商品,可选择普通购买的单纯用货币支付的普通商品
  3. 设置具体的促销活动规则和投放设置
  4. 用户在商城查看商品,可看到由平台后台发布的优惠信息
  5. 将商品加入购物车,购物车将体现享受满减和直减后的优惠价格,最终的购买订单的实付金额为享受促销活动后的价格。
  6. 可在后台查看到已创建的活动以及活动的效果,关于用户购买订单相关的数据也将展示其享受到的优惠信息。

1.2促销系统

将模块拆分,主要分为三部分:

  1. 促销活动:活动投放的设置管理,负责提供活动方式和商品内容
  2. 促销规则:发布促销活动时选择,负责提供促销玩法,例如限时折扣、满额减等
  3. 优惠券:提供一种相对独立的促销形式

从大的维度来看,优惠券也属于促销的一种方式,在促销规则也和优惠劵的使用有一定关联。这里我们把优惠券也归类到促销系统中,关于优惠券业务将在下次进行迭代

1.3促销活动

活动状态:

  • 未开始,还未到活动开始时间,此状态的活动可进行编辑和的删除,删除活动为逻辑删除
  • 活动中,正在进行中的活动,此状态的活动不能编辑,只能提前结束,结束之后的活动变更为已失效的状态
  • 已失效,已经过了活动结束时间,被删除的以及被取消的活动

从促销类型分为:

  1. 直减类:限时折扣、新用户专享等
  2. 满减类:满额减、满额折、满件减、满件折、满件免等
  3. 赠券类:买单赠券、免费领券等(下次迭代)
  4. 组合优惠类(暂不考虑):套餐
  5. 送赠品类(暂不考虑):满赠
  6. 换购类(暂不考虑):加价购
  7. 预订类(暂不考虑):预售价

直减类(优先实现):

主要设置项包括:

  1. 活动名称:方便运营人员识别活动
  2. 促销方式:可选限时折扣、新用户专享
  3. 商品选择:参加促销的商品以及促销的价格(只选择单纯用货币购买的普通商品)
  4. 投放时间选择:选择开始时间和结束时间
  5. 打标签:商品打促销标识,前端显示促销标签,可选择现有标签或者选择自定义新增
  6. 目标群体(不可编辑): 针对全部用户(限时折扣)、未下单过的新用户(新用户专享)

满减类:

主要设置项包括:

  1. 活动名称:方便运营人员识别活动
  2. 促销方式:满额减、满额折、满件减、满件折、满件免件
  3. 商品选择:参加促销的商品((只选择单纯用货币购买的实际商品,可选择全场、按品类、或者自主选择多个商品,由于虚拟商品不能加入购物车,所以虚拟商品的满减类虽然可以添加多个SKU,但是最终享受该优惠的虚拟商品订单只会包含一个SKU)
  4. 金额/件数设置:满XX减(折、免)XX,可设置多层级的满减活动(支持两种货币类型的情况)
  5. 投放时间选择:选择开始时间和结束时间
  6. 打标签:商品打促销标识,前端显示促销标签,可选择现有标签或者选择自定义新增
  7. 目标群体: 针对全部用户、未下单过的新用户

二、促销业务逻辑

2.1创建多个活动

方案1:实现此方案,一个商品只能关联到一个正在进行的活动,已经被添加至一个活动的时候,可以先解绑再将其添加至另一个活动

方案2:同类型促销可创建多个活动,同个商品可参与多个同类型的活动,但是一个商品不能同时被添加至多个活动时间重叠的活动(考虑这样处理逻辑会比较清晰)

一笔订单不能同时享受两个及以上相同类型的优惠。(这里的类型指的是直减类、满减类)

2.2订单金额计算

方案1:本次实现此方案,一个用户一笔订单只能享受一种优惠,如果一笔订单有多个优惠活动,用户可进行选择其中一个。

方案2:促销方式有很多,针对商品或订单的满减、折扣、优惠券等,对这些促销类型进行任意组合,将会有非常多样化的场景,为了防止系统发生重叠甚至冲突的情况,从整体上设计促销逻辑才能保证各子系统流程顺畅流转。

将促销视为订单金额的变化,将促销活动区分为三种类型:改商品价格、改商品小计价格、改订单价格,无论什么促销都可以描述成改价格。

判断条件:

  1. 上面的流程图,是否可享受的判断条件是只要有优惠活动就享受
  2. (讨论是否在这一阶段加上多活动时的控制)通用设置或者是针对于活动的设置,同一笔订单是否可以同时享受多个不同类型的促销,即同时可以享受修改商品的优惠(直减类),修改商品小计的集合(满减类)或修改订单的价格(优惠券)

具体例子:(京东)

  1. 享受商品价格的活动,这里是秒杀价单品价格24.9元
  2. 计算商品小计之后,引入针对指定商品的价格,满2件总价打5折,24.9*28件*0.5=348.6元
  3. 累计商品小计价格之后,介入针对于订单的促销:优惠券

优惠券为全品类满200减10,满足条件,即最终订单价格(免邮)为348.9-10=338.6元

所以最终这笔订单先后享受了三重优惠。

2.2.1修改商品价格

一笔订单被提交时,系统必然首先查找出订单中的所有商品,并判断此商品是否具备特殊价格(促销价格)。如果没有,则取正常的商品零售价;如果有,则取当前商品所处促销活动价格。

直减类:限时折扣、新用户专享等

遵循促销核心原则:同类型促销通过同一实体进行互斥、不同类型促销可以叠加。这里的实体指的是商品,类型指的是前文说到的值减类、满减类、赠券类,下文也是,不再说明。

所以这条原则也可以表述为:不同商品可以享受相同的(限时折扣、新用户专享)活动;但是相同商品进行互斥,同一个商品不可以同时享受同一类型的活动,例如:同一个SKU不可以同时享受(限时折扣、新用户专享)活动。

2.2.2修改商品小计的集合价格

当系统完成了对商品价格的查找之后,就需要将查找出的商品价格分别乘以订单中的每个商品数量,从而计算出每个商品的小计金额。当系统计算出所有商品的小计金额之后,这时候,就可以介入一些促销活动,例如指定商品的:满额减、满额折等。

满减类:满额减、满额折、满件减、满件折、满件免件

例如:全场生鲜类,满100减10,满200减30;就是第二种类型活动,因为它是针对某种/某类商品的小计金额来匹配满足哪种类型的活动,并在满足活动的商品小计金额基础上进行减、折、免。

同类型通过实体进行互斥、不同类型可以相互叠加。此处的实体是商品,所以这对第二种类型的促销活动,我们就可以得出以下结论:

同一个商品,不能同时享受指定商品的(满减、满赠、折扣 等)活动,不同的商品没有限制。

例如:SKUA 不能同时享受多个满减、满赠、折扣;但是SKUA 享受满减,SKUB享受满赠 这种是被允许的。

而不同类型可以相互叠加,也就是说,同一个商品虽然不能同时享受同种类型的活动,但是却可以同时享受不同类型的促销活动,例如:SKUA 可以同时享受限时折扣和指定SKUA的满减活动,也就是折上折。

2.2.3修改订单金额

当系统完成了对商品小计金额的计算之后,就会将所有优惠后的商品小计金额进行叠加,生成一个初步的订单总金额,当系统得到初步的订单总金额之后,又可以介入一些促销活动,例如指定订单的:优惠券等。

针对订单类的:优惠券(下次迭代)

例如:京东招牌活动全场满88包邮;就是典型的第三种类型营销活动,因为它是针对订单的总金额来匹配满足那种类型的活动,并在满足活动的订单金额基础上进行减、折、优惠券和包邮券等。

同类型通过实体进行互斥、不同类型可以相互叠加,此处的实体就是订单。

所以,针对第三种类型的促销活动,我们就可以得出以下结论:同一笔订单只能使用一张针对于订单的优惠券。

三、功能需求清单(促销活动)

转载自-- https://www.cnblogs.com/jurendage/p/9165594.html

原文地址:https://www.cnblogs.com/lu-manman/p/10052444.html

时间: 2024-08-06 01:40:03

36、生鲜电商平台-积分,优惠券,会员折扣,签到、预售、拼团、砍价、秒杀及抽奖等促销模块架构设计的相关文章

Java开源生鲜电商平台-Java后端生成Token架构与设计详解(源码可下载)

Java开源生鲜电商平台-Java后端生成Token架构与设计详解(源码可下载) 目的:Java开源生鲜电商平台-Java后端生成Token目的是为了用于校验客户端,防止重复提交. 技术选型:用开源的JWT架构. 1.概述:在web项目中,服务端和前端经常需要交互数据,有的时候由于网络相应慢,客户端在提交某些敏感数据(比如按照正常的业务逻辑,此份数据只能保存一份)时,如果前端多次点击提交按钮会导致提交多份数据,这种情况我们是要防止发生的. 2.解决方法: ①前端处理:在提交之后通过js立即将按钮

Java开源生鲜电商平台-OMS订单系统中并发问题和锁机制的探讨与解决方案(源码可下载)

Java开源生鲜电商平台-OMS订单系统中并发问题和锁机制的探讨与解决方案(源码可下载) 说明:Java开源生鲜电商中OMS订单系统中并发问题和锁机制的探讨与解决方案: 问题由来     假设在一个订单系统中(以火车票订单系统为例),用户A,用户B都要预定从成都到北京的火车票,A.B在不同的售票窗口均同时查询到了某车厢卧铺中.下铺位有空位.用户A正在犹豫订中铺还是下铺,这时用户B果断订购了下铺.当用户A决定订下铺时,系统提示下铺已经被预订,请重新选择铺位.在这个系统场景中,我们来探讨一下,火车票

Java生鲜电商平台-小程序或者APP优惠券的设计与源码实战

Java生鲜电商平台-小程序或者APP优惠券的设计与源码实战 说明:Java生鲜电商平台-小程序或者APP优惠券的设计与源码实战,优惠券是一种常见的促销方式,在规定的周期内购买对应商品类型和额度的商品时,结算时满足一定条件会减免一定金额.通过发放优惠券,引导用户购买相应的商品,在下单的时候抵扣一定的费用,达到促销.提高客单价的目标. 优惠券不论在线上还是线下,适用范围都比较广泛.例如滴滴发的专车券.外卖平台发的外卖券.京东淘宝的优惠券等. 1.优惠券的类型和应用场景 优惠券有多种分类方式,按照使

20、生鲜电商平台-优惠券设计与架构

说明:现在电商白热化的程度,无论是生鲜电商还是其他的电商等等,都会有促销的这个体系,目的就是增加订单量与知名度等等 那么对于Java开源生鲜电商平台而言,我们采用优惠券的这种方式进行促销.(补贴价格战对烧钱而言非常的恐怖的,太烧钱了) 1. 优惠券基础信息表 说明:任何一个优惠券或者说代金券都是有一个基础的说明,比如:优惠券名称,类型,价格,有效期,状态,说明等等基础信息. CREATE TABLE `coupon` ( `id` bigint(20) unsigned NOT NULL AUT

30、生鲜电商平台-电商促销业务分析设计与系统架构

说明:Java开源生鲜电商平台-电商促销业务分析设计与系统架构,列举的是常见的促销场景与源代码下载 左侧为享受促销的资格,常见为这三种: 首单 大于或等于某个会员级别 特定会员组:比如女性,月消费满1000等等,都是通过查询条件查询出来的特定分组. 优惠类型,对于电商网站主要是下面4类: 金额 赠品:商品.优惠券.现金券.积分等 包邮(实际上也是钱) 其它:如送精美包装等. 对于其它业务类型的平台,则估计会有其它形式的优惠,比如赠送三个VIP会员等等. 范围,无非就是: 整单 指定品类或特定品类

32、生鲜电商平台-商品价格的设计与架构

说明:Java开源生鲜电商平台-商品价格的设计与架构,主要是对商品的价格进行研究与系统架构. 一.常见的电商价格 市场价(List Price):这个价格仅是用于显示,用于衬托网站销售价格的优惠程度: 销售价(Sales Price):亦称我们的价格.零售价等,如果没有任何优惠的(包括促销优惠.会员等级优惠等), 就按这个价格进行销售.所有的优惠规则均是基于这个价格进行计算. 特价(Special Price):优先级最高的定价,忽略所有的价格规则. SKU价格(SKU Price):同一个产品

Java开源生鲜电商平台-系统简介

1.生鲜电商平台的价值与定位. 生鲜电商平台是一家致力于打造全国餐饮行业智能化.便利化.平台化与透明化服务的创新型移动互联网平台,连接买家与卖家之间的一个平台 看以下的图标:(商业模式) 名称解释: 买家:所有的大中小型餐馆,酒店等餐饮行业都属于我们常说的买家. 生鲜电商APP: 买家通过在APP上点菜,然后支付相应的费用的一种交易平台. 卖家:附近10公里内,在集贸市场有摊位的所有卖菜的商户 物流平台:公司平台运用自己的物流车辆把买家所需要的菜从卖家手里运输到买家手里的一种交通工具. 总体流程

Java开源生鲜电商平台-系统架构与技术选型(源码可下载)

Java开源生鲜电商平台-系统架构与技术选型(源码可下载) 1.  硬件环境 公司服务器 2.   软件环境 2.1  操作系统 Linux CentOS 6.8系列 2.2 反向代理/web服务器 Nginx 2.3 应用服务器 Jdk7+ Tomcat 7 2.4 数据库 Mysql 5.6.x 2.5 消息队列(可选) Rabbitmq/rocketmq 2.6 缓存(可选) Redis 3.x 3.工程构建和管理工具 1.Maven 开发人员已经很熟悉了.此处略 2.Jenkins Je

Java开源生鲜电商平台-用户表的设计(源码可下载)

Java开源生鲜电商平台-用户表的设计(源码可下载) 说明:由于该系统属于B2B平台,不设计到B2C的架构. 角色分析:买家与卖家. 由于买家与卖家所填写的资料都不一样,需要建立两站表进行维护,比如:buyer,seller. 这样进行数据库的解耦,任何一方的变动都互不影响,但是我想集中式管理,以及一些业务个性化要求,我就增加了一个users表.表结构如下: 账号唯一键,所以做了唯一键索引, 账号的准确性采用手机短信验证. 根据类型区分买家与卖家,登陆的时候,采用的就是users这种表进行维护