GVKun编程网logo

百万级促销系统架构设计(百万销售系统)

16

最近很多小伙伴都在问百万级促销系统架构设计和百万销售系统这两个问题,那么本篇文章就来给大家详细解答一下,同时本文还将给你拓展(原创)系统架构设计-通用权限模型设计①、APP系统架构设计初探、Java生

最近很多小伙伴都在问百万级促销系统架构设计百万销售系统这两个问题,那么本篇文章就来给大家详细解答一下,同时本文还将给你拓展(原创)系统架构设计-通用权限模型设计①、APP系统架构设计初探、Java生鲜电商平台-促销系统的架构设计与源码解析、PetShop 的系统架构设计等相关知识,下面开始了哦!

本文目录一览:

百万级促销系统架构设计(百万销售系统)

百万级促销系统架构设计(百万销售系统)

促销业务认知

概念

促销是指卖方通过对消费者提供短期激励,以诱使其购买某种特定商品的过程。促销实质上是一种沟通活动,即营销者发出作为刺激消费的各种信息,包括营造出价格优惠、限时限量等氛围,把信息传递给一个或多个特定目标对象以影响其对商品的态度和行为

目的

促销是运营工具,作用是帮助运营者完成其对用户的拉新、转化、促活、留存、传播的目的,完成对商品入市推广、销量提升、客单价提高、滞销库存清理的目的。
促销有别于常态化的销售,它有限时、限量、限消费群体以及优惠等特点。它是业务在运营过程中为了完成某种目标而使用的一种手段。
从电商会员用户的生命周期和商品进行梳理并抽象

场景&手段

业务风险关注点

促销流量入口

外围交互系统

上游系统

  1. 用户会员系统
  2. 商品系统
  3. 商家系统
  4. 库存系统
  5. 供应链系统

下游系统

  1. 购物车
  2. 正向订单
  3. 逆向订单
  4. 支付系统
  5. 财务清算系统
  6. 对账系统
  7. 风控系统
  8. 活动效益分析系统(数仓,OLAP)
  9. CRM

应用系统

百万级架构设计原则

目标

整个架构要满足3个核心目标
  1. 高性能
  2. 高可用
  3. 高并发
  4. 稳定性保障

流量评估

 

架构设计核心思想

网络拓扑架构

三高原则

稳定性保障

总结

  1. 多IDC,上云的话,就多region集群部署,异地多活进行集群分流
  2. 存算分离(对于计算,多采用一些多级缓存结合,异步、异构数据存储等)
  3. 数据存储(根据场景来进行技术选型,是采用RMDB的分库分表,还是采用nosql,newsql来处理)主备->多副本集
  4. 流量管理
  5. 监控以及告警
  6. 中间件产品的高可用评估等
  7. 弹性伸缩(scale-up)

(原创)系统架构设计-通用权限模型设计①

(原创)系统架构设计-通用权限模型设计①

1.1前言
权限管理系统的应用者应该有三种不同性质上的使用,
A,使用权限  B,分配权限C,授权权限 
1.2初步分析
用户和角色 
说到权限管理,首先应该想到,当然要设计一个用户表,一个权限表。这样就决定了一个人有什么样的权限。
做着做着就会发现这样设计太过繁琐,如果公司里面所有员工都有这样的权限呢,每一个人都要配置?那是一件很痛苦的事情。因此再添加一个角色表,把某些人归为一类,然后再把权限分配给角色。角色属下的用户也就拥有了权限。
    用户、角色之间的关系是一个用户可以对应多个角色,一个角色可以对应多个用户。多对多关系。
所以需要一个中间表,相信大家都很熟悉,自然不会有疑问。
应用场景 

有了用户和角色以后,就需要设计应用场景,比如一个应用程序有几大模块(系统模块、项目管理模块、销售模块),

类似这样的模块就是一种应用场景,常见的还有 菜单 、 操作 等等。

假设现在我们设计好了,应用场景包括 模块、菜单、和操作,那么应该有以下六种关系

      1. 一个用户可以对应多个模块,一个模块可以对应多个用户。多对多关系。

      2. 一个用户可以对应多个菜单,一个菜单可以对应多个用户。多对多关系。

      3. 一个用户可以对应多个操作,一个操作可以对应多个用户。多对多关系。

      4. 一个角色可以对应多个模块,一个模块可以对应多个角色。多对多关系。 

      5. 一个角色可以对应多个菜单,一个菜单可以对应多个角色。多对多关系。  

      6. 一个角色可以对应多个操作,一个操作可以对应多个角色。多对多关系。
这样设计看起来没什么问题。是的,如果没有加入新的关系的话,这样是已经可以满足大部分的需求了。可是如果就是如果,新的关系(需求)往往会加入到系统进来。这个时候就需要再建立一个新的表。系统的复杂度也随着增加。

可以看出,这样的设计有几个问题:
      1. 数据表设计太复杂
       2. 应对系统方案过于固定
1.3一般的权限模型
用户,角色表,资源表之间是多对多的关系,这样的设计也可以实现权限但是会给t_resource和t_resource_role这张表随着系统中人员的增加数据量将会越来越多,不方便查询。

1.4把问题简单化后的权限模型

   不同的应用场合,你可能会想出不同的需求,提了一个新的需求以后,可能会发现原来的设计没方法实现了,于是还要添加一个新的表。这也是上面所提到的问题。 

 其实不必想得那么复杂,权限可以简单描述为:

   某某主体 在 某某领域 有 某某权限 

         1,主体可以是用户,可以是角色,也可以是一个部门

         2, 领域可以是一个模块,可以是一个页面,也可以是页面上的按钮

         3, 权限可以是“可见”,可以是“只读”,也可以是“可用”(如按钮可以点击)

   其实就是Who、What、How的问题,权限模型如下图所示。

    
转载请注明:www.xujin.org或www.virgocloud.com

APP系统架构设计初探

APP系统架构设计初探

一,图片体验的优化

    在手机上显示图片,速度是一个非常重要的体验点,试想,如果您打开一个网站,发现里面的图片一直显示失败或者是x,稍微做得好一点的,可能是一个不消失的loading或者是菊花等等,但不管如何, 没能快速的拉取和展示图片对用户体验是一个极大的挑战。那么,手机上的图片体验如何做呢?这里笔者有些小总结:

    1,减少图片的大小。在失真度和图片大小中做好折衷,尽量利用工具减少图片的size,也可以考虑利用不同的图片格式。

    2,减少图片的请求数。可以考虑把多个图片利用类似css sprite的方式进行合并,这样可以加载一次即可;

    3,考虑缓存。对图片在客户端进行一定的缓存,设置好缓存时长和更新机制;

    4,考虑使用cdn进行加载图片,做到就近接入访问;

    5,解决DSN劫持的问题。在手机业务上的经验告诉我们,很可能某些地区,某些运营商把我们的域名封掉或者劫持了,这样,图片的域名解释出来的IP却不是我们提供图片服务的IP,并且这种情况很难发现,  因为,如果运营商通过抽样随机劫持,就很难发现。


解决办法有几个思路:

     .去掉dns,改成直接访问IP的方式,但需要解决根据用户的ip获取最近图片服务的ip地址,实现上:这里cgi在吐出访问图片的地址的时候,获取用户的来源网关IP,调用IP地址库判断来源IP所属地和运营商,然后下发对应的图片部署接入IP, 客户端使用IP直连图片服务器,快速的访问资源。问题是,有实现成本,得业务自己去实现类似一个dns解释的逻辑 ,特别是图片放到cdn的话,这样改造就无法使用cdn带来的加速服务能力。

  

     .做好dns劫持的监控,实际上图片dns解释到的vip list肯定是在我们的一个白名单内,如果不是,则肯定属于dns劫持,客户端可以在某个时候拉取一下我们的viplist,作为监控和判断是否dns劫持的问题,如果dns的ip地址 不在白名单内,则替换使用白名单内的ip进行访问。

  

     .考虑备用域名的方式,即如果一个域名拉取不到,改用备用域名进行访问,当然如果备用域名也被劫持,那就不行了。



二,优化后台的架构

     后台返回越快,前端的体验就越好,因此,也需要对后台服务的调用链进行梳理,避免循环调用,快慢混杂等问题,基本的原则比较简单,都是一些设计方面的原则

   1、轻重分离。服务中把访问量大,需要速度快的服务和访问量小,但业务逻辑复杂的流程从代码实现和物理部署上进行彻底分离,如用的接入cgi(甚至不同的域名),不同的后台server,不同的集群进行隔离。

      如果放在一起,慢的会拖住快的,这就像木桶原理一样,最终的速度是由最慢的决定的,如果处理不好,可能导致整个服务堵塞不可用。


     2、考虑异步化。异步化相比同步的实现来说稍微复杂一些,或者说需要做的工作可能多些,但异步化的好处也会非常明显,特别是需要高性能的业务流程。常见的异步化实现策略是借助mq作为各个系统的缓冲, 生产者进程或者子系统把消息写入mq即可立即返回,而消费者进程或者子系统则定时从mq读取消息继续处理,并且把处理的结果通过回调通知或者写入返回mq给到生产者查询。当然,如果生产者是不关注结果的,那 就更加简单了,丢到MQ后即可,这里的问题是整个mq是整个业务流程的关键,需要确保服务的高度可用和性能。


3.做好外部依赖的管理。一个业务流程可能往往要调用到外部的系统,并且这些系统可能不是你们团队维护的,如果该系统是非关键路径还好,如果是关键路径,那么做好对外部依赖的管理就显得更加重要了,那么如何做好外部依赖的管理呢?

      这里有几个小的tips:

     . 对外部调用的服务单独进行封装,如设计单独的proxy去调用外部的服务,这样的好处是方便集中监控和容灾逻辑等处理,在设计上把外部因素进行物理隔离的第一步,后续如果外部系统的协议或者ip地址得发生变化,则可以只修改该模块即可 快速修复;

     . 严重建议对外部接口进行错误和超时的监控,一旦出问题,提前预警并快速解决,这里是有血的教训的,某业务和某平台提供者双方在纠结是谁的问题上吵得不可开交,不知道是谁的问题,业务说自己没问题,平台方说自己的服务也很快,如果 你能够拿出你的监控数据,接口超时设置是 1s, 超时的记录有n条,时间是ns,错误的记录有m条,主要错误类型是xxx,那对快速定位是非常有帮助的。


Java生鲜电商平台-促销系统的架构设计与源码解析

Java生鲜电商平台-促销系统的架构设计与源码解析

Java生鲜电商平台-促销系统的架构设计与源码解析

 

说明:本文重点讲解现在流行的促销方案以及源码解析,让大家对促销,纳新有一个深入的了解与学习过程.

促销系统是电商系统另外一个比较大,也是比较复杂的系统,作为一个卖货的,当我们准备好了店铺、商品,那么剩下的就是卖货了。

但是,卖的好不好,有时候并不取决与你的商品质量,而是会不会营销,会不会做活动,甚至说即便你的商品质量不好。但是如果营销活动做得好,那也是可以卖的比别人挣钱的,所以促销活动很重要。它需要分析市场结合自身条件合理的创建促销活动,我们理解的促销活动可能是优惠券,满X减Y,和一些专题活动。

下面对促销活动进行一个系统的总结:广义上来说,一切为了扩大商家销售和用户优势的行为都属于促销活动。

鉴于软件行业和电商系统的特征,电商的促销系统设计应该是分为这几个大的分类:促销活动、CMS系统、优惠券、拼团。

  • 优惠券:这大家可能很熟悉,设置优惠券的规则,然后进行发放,用户可以在购买商品的时候使用优惠券;
  • 拼团:这大家也很熟悉,比如:拼多多大家可能都用过,简单来说需要设置拼团的人数,价格,当拼团人数达到时,拼团成功,然后进行发货。
  • 促销活动:促销活动一般是与CMS系统一起用的,促销活动模块用于设置活动的规则,而CMS系统用户推广活动。其实来说CMS系统对技术的要求是很高的,一些小的电商是不支持CMS的,那么促销活动就会通过广告位进行推广,或者不推广。

先促销活动,再说优惠券,再说拼团,下面详细说说。

一、促销活动

促销活动是什么呢?

接触电商系统设计的产品经理肯定明白,促销活动与优惠券类似,都是在购买商品时如果满足促销条件或者优惠券的条件就会对用户的购买进行优惠。

不同点在于:优惠券是具体的东西,他与商品是分离的,优惠券更加灵活,而促销活动一般来说会与商品绑定,并且这种活动的制定可能还会与节日有关——清明节了,我要搞个促销活动,促销活动的目的性更强,既然是“活动”那么也就注定了推广的重要性。

这也就是为什么促销活动要与CMS系统连用,可以达到更好的宣传效果,下面我从几个方面说说促销活动:

  1. 促销活动都有哪些形式,每种形式的规则是什么?
  2. 促销活动具体的创建规则与业务流程?
  3. 促销活动在订单中的问题。
  4. 对促销活动的管理。
  5. 促销活动在产品中的具体设计方法。

1. 促销活动的各种形式

满减促销:

满减促销是最常见的一种促销活动,当订单满足一定金额优惠一定金额,一般会产与多个订单,比如:满200减20。这样,为了能够获得优惠可能就会多买几件,满减促销分为两种形式:每满减和阶梯满减,在创建活动的时候只能选择一种形式。

什么每满减呢?

——每满X元减Y元,比如每满100元减10元,如果订单满足一个100元优惠10元,如果订单满足两个100元,优惠20元,以此类推。

什么是阶梯满减呢?

——满X1元减Y1元,满X2元减Y2元,满Xn元减Yn元,比如满100减10元,满200减300元,满300减50元。

显而易见阶梯满减是消费越多优惠比例越大,设置多个阶梯,如果设置了每满减同时设置阶梯满减肯定会有冲突的,因为订单金额相同时优惠金额可能不一样,也就是说,不能共用。

单品促销:

单品促销就很简单喽,就是一件商品打折。

这里说明一下哈,不仅仅是这里,所有的,你没看错,我是说所有的打折都支持两种选择,百分比打折和金额打折,在设置打折规则的时候进行单选百分比或者固定金额。

那么,百分比打折和固定金额打折不同点在于哪呢?

差异化的造成主要体现在价格的变动上,当价格变动对折扣打折是没有影响的。因为是按比例计算,而对于固定金额打折就会有影响,无论价格的过高或者过低,都会造成优惠金额的不合理。但是,固定金额打折的优势是易于消费者理解,优惠价格可控,对于资金的掌控更加稳定。

在进行百分比打折的时候,前端同时显示折扣比例和折扣金额。

套装促销:

套装促销就是多件商品捆绑销售,设置套餐价格,但是在设置的时候其他促销形式有所不同。不同点主要体现在前端的展示上,其他的促销获得是依附在某个商品之上的,当我们进入商品详情页就会看到促销活动的介绍。然后选择规格当,数量等信息,当选择满足条件后就会实现优惠。

而套装促销是多商品,下面的赠品促销,满赠促销也是一样,这种多商品的促销在展现形式上有所不同。

首先来说,我们在设置套装的时候肯定选择多个商品,而每一个商品肯定会有多个SKU信息,那么说我们在选择商品的时候应该精确到商品的SKU,也就是把规格选出来。

为什么要这样选呢?因为我们最终要设置套餐价格,那么这个套餐价格肯定基于某个确定的原价的,也就是每个套装商品的SUK价格。

其次,我们要考虑到前端的展示问题。

既然是促销活动,我们现在还原一个场景:

小张没有鞋穿了,要去商场买鞋,而鞋子肯定有很多规格,小张要买43码红色的鞋子100元,如果选择43码黑色的鞋子可能就是200元了。

这个时候服务员告诉他:我们现在搞套装活动,红色的鞋子加红色的袜子一共110元,红色的鞋子加红色的袜子一共120元,黑色的鞋子加红色的袜子一共210元,黑色的鞋子加黑色的袜子一共220元,红色袜子单独购买20元,黑色袜子单独购买40元。

那么,在这种场景下,小张的选择是多样化的,他可以选择任意的组合,然后给钱就行了。但是,如果把这种场景还原到产品设计中就会产生很多问题。

原因很简单:我们在线下购买商品,当我们提交订单之前,我们面向的是所有的商品。而在网上购物的时候,我们要进入某一个具体的商品才能看到促销活动——我们在网上看到一双鞋,然后活动是加上某个袜子110元,难道我们要返回首页在去寻找那个袜子吗,显然是不行的。

也就是说,套装的选择要在鞋子这个商品的详情页面完成,可是鞋子的商品详情页只能展示鞋子的,比如:尺码,颜色;是无法选择袜子的规格信息的。

所以,一般来说有两种处理方式:

  1. 直接把套装做成商品。
  2. 在商品详情页面增加套装选项。

直接把套装做成商品:

这个跟商品的编辑流程是一样的,我们在定义商品标题的时候,直接把它写成某个套餐,比如:化妆品套餐,然后利用规格设置不同的套餐价格。

比方说:套餐一牙刷+牙膏10元,套餐二牙刷+牙膏+杯子12元,套餐三单个牙刷5元,以此类推。但是,这种也可以实现套装促销的效果,但是这种方式却偏了促销系统的设计规则。其实根本没有促销规则,商品本身的设定就是套装也就没有规则可言。

在商品详情页面增加套装选项:

这种方式就是设置完套装后,在相关商品的详情页面在选择规格的时候增加套装选项。当选择某个套装后显示套装信息,套装信息是某个具体的SKU信息,套装和主商只能二选一,选择商品就不能购买套餐,选择套装就不能在选择商品信息了。

下面举一个例子:

有A B C D E 五个SKU信息,要进行不同的套装组合,AB AC AD AE BC BD DE ,这是7个套装。

那么,在我们进入A商品的详情页面时,套装信息就会显示所有的,因为跟它都有关。当我们进入B商品的详情页面时,显示AB BC 两种套餐,因为B只有这两种套装。同理,当我们进入E时,显示AE DA ,也就是说只显示跟当前商品有关的套装信息。这是这种设置方式,其实来说产品的设计形式没有固定的,我们也总在寻求更好的解决方案。

赠品促销:

赠品促销也是多商品,当我们在购买主商品满足赠品条件后,就会获得赠品,有两种方式:

  1. 只要购买主商品就会获得赠品。
  2. 购买一定数量才能获取赠品。

而赠送的形式也有两种:全部赠送,赠送一件或者N件。

在设置的时候我们首先要选择主商品、满赠条件——购买即赠还是制定购买数量赠送。

然后选择赠品——可以选择多个,是全部赠送还是部分赠送,对于赠品只需要在专题页面说明就可以了,然后在详情页面介绍赠品信息。

加价优惠:

加价优惠是当我们满足了一定金额,如果在多付一定的金额就会优惠多少,或者免费赠送什么。

比如:我们一共花了120元想去结账,然后系统提示你,当订单金额达到150元就是享受-20优惠,或者赠送某某商品。对于加价优惠要选择商品,然后设置当满X元,在加Y元时,优惠N元或者免费送F商品,这样设置。

多买优惠促销:

多买优惠促销就是买的越多,优惠越大,可以设置一定金额随便买几件,或者当几件的时候极则,规则的核心是商品的件数——也就是多买。

这个地方既然是多买,那么在设置活动的时候肯定要设置活动的商品池——可以逐个拉去,也可以按分类拉去,多买优惠只有在这些商品上才能生效,其他商品不生效,在设置规则的时候可以设置。

  1. 订单满X件N折
  2. 订单金额X元内任意购

根据具体情况设定。

定金促销:

定金促销一般会出现在商品预售的时候,当商品进行预售时,设置定金促销,用户提前付定金可以抵扣一定金额。

比如:定金30抵扣50,相当于优惠50元,当商品进行发售的时候付尾款即可完成订单。

2. 促销活动的创建规则与业务流程

促销活动的创建分为三个步骤:

  1. 设置活动基本信息:比如活动的标题,活动时间?
  2. 设置活动的规则:满赠促销还是单品促销,规则是什么?
  3. 设置活动商品:参与活动的商品是什么?

创建完成。

2.1 设置活动的基本信息

活动标题:设置活动的标题,可以设置多个标题,不同标题的作用不同,根据需求看你需要几个标题,然后每个标题展示在哪里。

活动编码:活动的唯一编码,创建活动是自动生成,这种编码很常见,不仅仅是这里,比如订单的编码,账单的编码,这些编码的规则,一般与时间,用户,商品等联系进行组合设置。

活动时间:设置活动的时间,只有在时间范围内活动才生效,如果活动时间未到但是活动开启了,需要在前端进行倒计时提升。

推广渠道:商城一般会有很多用户端,选择活动在哪里投放:H5,公众号,微信小程序,支付宝小程序,APP,PC端商城。

限购数量:商品的限购数量,从这几个方面来考虑,每项都是默认不限购,之所以进行限购主要是考虑到库存的原因:

  1. 每个商品的限购数量:当此商品卖出X件不在参与活动。
  2. 商品的总数量:参与活动所有的商品一共多少?
  3. 每个用户的限购数量:每个用户最多可以购买多少件,达到上限不可继续参与活动,

用户范围:活动的用户范围,当用户在范围内才能参与活动,否则无法参与活动,默认不限制用户范围。

  1. 选择指定用户:从用户列表进行获取多个用户。
  2. 用户会员等级:选择那个等级的会员才可以参与活动。
  3. 用户分组:那个用户组才可以参与活动。

对于用户范围的限定,主要看后台是如何对用户进行分类的,根据这些分类记性限购,如果用户有标签;也可以根据标签进行限购——如果分新用户,老用户,也可以根据此限购,主要取决于系统的设置。

是否与优惠券通用:一般来说促销活动是不与优惠券通用的,现在市面上的电商促销活动又不会与优惠券通用,所以这个地方可以再后台写死,只要是参与促销活动的商品都不与优惠券通用。

推广链接:创建活动时会自动生成活动链接和活动二维码用户推广使用。

 

2.2 设置活动的规则

在上面已经介绍了活动的形式以及它们不同的规则,但我们设置完活动的基本信息后就要设置活动的规则分类两步:

  1. 选择活动类型:满减,单品,套装,赠品,加价,多买,定金。
  2. 不同的活动其规则肯定是不同的,然后设置活动的规则。

满减:

选择满减类型:阶梯满减、每满减

设置满减规则:

  • 阶梯满减:满X1减Y1、满X2减Y2、满Xn减Yn……
  • 每满减:订单每满X元减Y元

单品:

选择打折形式:百分比、指定金额

设置打折程度:

  • 百分比:X%
  • 指定金额:X元

套装:设置套装价格——X元

赠品:

  1. 设置赠送条件:买即赠、买X件即赠
  2. 选择赠送数量:全部赠送,部分赠送(赠送几件)

加价:

  1. 设置当满X元时加Y元时生效
  2. 设置奖励形式:减N员或者送F商品

多买优惠:设置多买形式——M件N折或者X元任意购

定金:设置定金金额X抵扣金额Y

2.3 设置活动商品

当我们设置完促销规则的时候就要选择活动商品了,不管是什么类型的活动都要选择活动商品。只是不同的活动选择商品的规则不一样,我们来看下:不同促销活动他们选择活动商品时,有什么不同?

  • 满减:选择全部商品或者部分商品,部分商品可以根据分类,品牌进行筛选,可以手动制定某些商品。
  • 单品:选择某一个商品。
  • 套装:选择多个商品组合,每个组合代表一个套装,这里注意,套装商品的选择需要精确到SKU。
  • 赠品:选择主商品,然后选择赠品,赠品可多选可单选,赠品要精确到SKU。
  • 多买优惠:这个选择商品的形式有所不同,要选择商品池,构建一个商品的水池,水池里的商品即为活动商品的范围,用户参与活动必须到水池里选择商品。
  • 加价:设置商品范围,如果奖励形式是赠品,需要设置赠品。
  • 定金:选择定金商品。

2.4 活动创建完成

KO,到现在为止促销活动的创建已经完成,我们总结一些:

首先,定义活动的基本规则,这些基本规则肯定是通用的,它不影响活动规则。

然后,设置活动规则,不同的活动有不同的形式,而不同的形式有不同的设置规则。

最后,根据不同的活动规则选择参与活动的商品。

这样活动就创建完成了,这是促销活动的创建方式与流程。不管什么样的促销活动都可以这样来设置,要把基本设置,活动规则,参与商品相互分开,这样有利于我们理解。下面,最后说说促销活动在订单流程中的问题。

3. 促销活动在订单流程中的问题

当用户进行下单的时候,首先要判断:商品是否参与促销活动?参与哪个促销活动?

然后,判断:是否满足促销规则?满足哪个促狭规则?

最后,计算满足情况下,优惠的金额是多少?在用户订单付款页面要告诉用户优惠金额是多少?

  • if(活动商品){哪个活动}
  • if(规则1){优惠金额计算}
  • else if(规则2){优惠金额计算}
  • erse if(不是活动商品)(不计算优惠)

当用户下单完成后,多个商品可以放在一个订单下统一发货,不能统一发货需要进行拆单,订单的详细问题现在先不说,以后会专门讲订单。

4. 对促销活动的管理

促销活动的管理是管理已经创建出来的活动列表,主要管理的是活动的状态和编辑活动,删除活动。

编辑活动:当活动创建完成后可能因为一些原因需要修改,这个时候需要去编辑。

删除:删除活动后,活动将直接终止。

活动状态管理:未开始,活动中,以结束,是否投放。

  • 未开始:活动时间未到。
  • 活动中:处在活动时间内。
  • 已结束:活动时间已过。

是否投放:当投放之后活动才会生效,投放状态与活动时间状态(其他三个状态)相互独立,互不影响,无论是否投放都有可能处在其他三个状态中的一个,时间状态是无法操作的,可以操作投放状态。

删除:直接删除活动,如果活动正在活动中,那么活动将直接终止。

5. 促销活动在产品中的具体设计方法

5.1促销活动的前端展示

促销活动在用户端的展示主要体现在详情页面和列表页面,当满足促销活动是要在商品的列表页面加上标签。

比如:

  • “满减”:在商品的详情页面要加上促销栏目。
  • “促销:满100件10元”,让用户可以看到,如果是套装商品和赠品,需要展示每个商品的SKU信息、商品图片、价格、规格等。

5.2 促销活动的后台设计

促销活动属于促销系统的一部分,对于后台的设计,活动管理和创建活动两个部分。

创建活动:一个创建活动的菜单,点击进去就是创建页面、填各种表单、最后保存,表单的内容上面已经说了,就是促销活动的创建流程。

活动管理:一个活动管理菜单栏,点击进去是活动列表,管理活动状态、投放状态、删除。

二、优惠券

优惠券与促销活动的不同点是:优惠券突出的是商品。

当我们要买哪个商品时,我们会考虑用哪个优惠券,而从设计上来说,专题活动要比优惠券难度高。

1. 优惠券的各种类型

现金券:优惠券直接抵扣现金,不设置使用门槛,比如:50元现金券,现金券之所以称之为现金券,就是因为它可以当做现金直接使用,相当于你自己的钱,没有订单金额的限制。

满减券:与促销活动的满减类似,当订单满足一定金额才可以使用优惠券,比如:满200减20元。

折扣券:在购买某些商品是可以进行打折,比如8折,那么100块钱的东西就是80元。

单品券:单品券是针对特定的商品才可以使用,指定特定商品后可以设置满减或者折扣或者现金券。

分类券:分类券是针对特定分类的商品才可以使用,指定分类后设置满减或者折扣或者现金券。

品牌券:品类券是针对特定品牌的商品才可以使用,指定品牌后设置满减或者折扣或者现金券。

平台券:平台券适用于所有的店铺的优惠券,无论在哪个商家,哪个店铺,都可以使用,优惠金额由平台承担。

店铺券:店铺券是入驻平台的商家自己发布的优惠券,只在本店铺有效,优惠金额由店铺承担。

2. 优惠券的设计规则

优惠券的设计规则分为三步:

  1. 创建优惠券
  2. 领取优惠券
  3. 优惠券核销

2.1 创建优惠券

在创建优惠券的时候需要填写相关的信息,以及选择一些信息。

优惠券名称:给优惠券起一个名称。

选择优惠券类型:现金券,折扣券,满减券。

优惠券面值和使用条件:现金券(X元)、折扣券(满X元Y折)、满减券(满X元减Y元)。

推广渠道:优惠券的发放渠道:公众号、小程序、app、PC端商城。

有效时间:优惠券的有效时间,这里有两种时间的设置方式,相对时间和绝对时间;相对时间(用户领取后X天内有效)、绝对时间(开始时间——结束时间内有效),时间的设置应该应该精确到某年某月某时某分。

使用范围:设置优惠券的使用范围,全部商品可用,还是部分商品可用,如果是部分商品可用可以通过分类品牌进行筛选,最后可以选择指定商品不可用;也可以直接指定某些商品可用。

返还规则:返还规则主要考虑到退款退货的情况,从订单的流程上来说分为正向流程和逆向流程。

  • 正向流程是指:用户正常下单最后收获,没有退款退货操作。计算订单金额时需要减去优惠券的金额,告诉用户优惠金额是多少
  • 逆向流程是指:用户付款之后发生退款,退货操作

逆向流程主要考虑到优惠券的返还问题——怎么返还?

因为可能有很多个商品才同时满足优惠,用户如果仅仅退某款商品该怎么办,退款的细节以后讲订单的时候再说还涉及到一些结账分佣的问题,那么现在在这个地方优惠券的返还规则。

  1. 统一不返还:优惠券用了就不能退了,不管你退货还是退款。
  2. 优惠分摊:当多个商品满足优惠券使用条件但是用户退款某个商品时,以优惠券的形式返还给用户改商品分摊的优惠金额。优惠券的使用条件不变,比如用户用了一张满200减60的优惠券,订单有两个商品——一个60元,一个120元,根据权重,这减的60元属于60元商品20元,属于120元商品40元,用户退120元商品的就返还给用户一张满200减40的优惠券,那个也一样。

2.2 领取优惠券

优惠券的领取方式有两种:主动领取和被动领取。

主动领取:用户需要在我的优惠券界面主动领取才可以使用优惠券。

被动领取:直接发送给用户,默认领取。

2.3 优惠券核销

当用户下单时需要判断提示用户使用哪种优惠券,逻辑上分为以下几个步骤:

  1. 从用户的优惠券列表中筛选可用的优惠券,是否是有效时间,是否在商品范围之内,这里用户未领取的优惠券一同计算。
  2. 如果有多种优惠券满足使用条件默认给用户使用优惠金额最高的。
  3. 如果金额相同默认为用户选择使用快过期的优惠券。

3. 优惠券的管理

优惠券的管理,主要是:统计优惠券的使用情况。

优惠券发放了多少?用户领取了多少?核销了多少?剩余多少?这些操作对应的时间是什么时候?

4. 优惠券的产品设计方法

4.1 优惠券的前端展示问题

我们主要考虑:优惠券在什么地方展示?展示的形式是什么?

——展示的位置主要有商品详情页面,个人优惠券中心页面。

商品详情页面需要展示用户领取的和未领取的包含在商品下的优惠券,只要是属于商品下的优惠券都需要展示出来。

个人优惠券中心展示用户所有的优惠券,已用的、没有用户,提供领取入口,用户进入可以领取优惠券。

4.2 优惠券管理的后台设计方法

优惠券的后台设计,分为两个菜单:创建优惠券,优惠券管理

  1. 创建优惠券:点击创建优惠券菜单进入编辑页面,须填写先关信息,选择相关信息,表单内容为 2.2.1创建优惠券的各种信息可以去上面看;创建完成点击保存优惠券创建成功,在优惠券管理菜单里显示
  2. 优惠券管理:主要以列表的形式展示优惠券。

优惠券的管理,主要是对优惠券的统计作用列表信息为下:

  • 优惠券信息:优惠券名称,优惠券金额,使用条件
  • 推广信息:展示推广的渠道
  • 发放量、领取量、核销量。

如果是没有发放完成的优惠券可以执行停止发放或者继续发放操作,还可以执行删除操作,删除后前端的领券中心将没有优惠券,同时从后台的优惠券管理中删除。

 

PetShop 的系统架构设计

PetShop 的系统架构设计

http://www.cnblogs.com/wayfarer/archive/2006/04/14/375382.html

关于百万级促销系统架构设计百万销售系统的介绍现已完结,谢谢您的耐心阅读,如果想了解更多关于(原创)系统架构设计-通用权限模型设计①、APP系统架构设计初探、Java生鲜电商平台-促销系统的架构设计与源码解析、PetShop 的系统架构设计的相关知识,请在本站寻找。

本文标签: