电商后台产品经理——商品中心(一)
商品中心,对于前端而言,它是承担了商品的数据,订单,营销活动的数据中心;在后端而言,商品中心则是运营者管理维护商品的地方。
商品中心,在电子商务公司一般是后台管理商品的地方。在前端而言,是商家为了展示商品信息给用户的地方,它是承担了商品的数据,订单,营销活动的数据中心。在后端而言,商品中心则是运营者管理维护商品的地方,因此从商品的上传到发货,退货,整个闭环都离不开商品中心的支撑,因此商品中心的重要性毋庸置疑。
本文将从三大模块去讲述商品中心的设计。
一、基本概念
在设计商品中心这一模块前,我们先弄清楚,电商后台常用的一些关键词,有助于我们对业务的理解。
(1)SPU:(stanrdard Product Unit,即标准化产品单元),是一组标准化的信息集合,例如:“iphone 8”就是一个SPU。
(2)SKU:(Stock Keeping Uint,即库存量单位),库存控制的最小可用单位。例如:“iphone8plus256G金色”就是一个SKU。
(3)前台类目(分类):前台类目是为了方便用户筛选查找商品而设置的功能,运营可根据运营需求灵活调整前台类目,用户通过前台类目查找相应的商品时,自动从后台类目中检索相应的商品。
(4)后台类目:是为了方便运营者管理商品的库存,sku,商品规格属性的一个分类管理功能模块。后台类目与前台类目相互映射,后台类目一般不轻易变动。
(5)属性:商品属性是描述商品信息的一组值,通过这类值我们可以建立起对一件商品的基本认知。
属性分为关键属性,销售属性,非关键属性。关键属性属于是指能够唯一确定产品的属性,是必填项,例如手机的屏幕尺寸,型号属于关键属性。销售属性是组成SKU的特殊属性,或称为“规格属性”,例如手机的颜色,内存。非关键属性是指除了关键属性,销售属性外的其它属性,如手机的手机接口类型。非关键属性不一定是必填项,可根据运营需求设置。
二、功能架构
在了解完电商平台的基本术语之后,我们则可以根据平台自身的业务需求商品中心了,后台的基本功能大致有四类——增、改、查、删。因此我们理解该基本功能之后,对商品中心的基本功能就有了大致理解。
在理解这一点的基础上,我们需要理解我们平台的管理者和运营者对商品中心的功能需求:我们可以用简单的用例图的形式将运营人员的功能画出来,便于分析。
根据以上用例图则可以画出商品中心的信息架构图:
三、功能设计
在收集完公司的业务需求之后,我们就可以开始设计每一项功能:
3.1 发布商品
定义:发布商品是运营者在平台库中录入商品数据的基础功能,发布的商品审核通过后则可以直接在前台展示给消费者,在一些平台商家发布的商品需要经过平台的审核才能在前台显示,若需要平台审核,则在商品发布之后再商品中心则需要展示商品审核的状态,以方便运营者知晓商品审核的动态。
需要注意的是:商品的上架和发布需要注意区分,有的平台发布之后则直接展示在前台,用户直接可以在前台展示,有的平台则需要在发布商品过审后需要点击上架后才能展示在前端,这里需要根据自身的业务需求去做设计处理。
3.2 商品审核
定义:商品审核功能是保证商品质量并确保商品合规性的重要措施。审核的对象包含但商家上架的商品,平台自营的商品。审核包含商品性质的合规性,内容的规范性。审核包含商品上传的前置审核,上架后的审核。
前置审核的结果分为通过与未通过两种,审核未通过需返回不通过原因,便于商家或商品发布者修改。后置审核的结果为两种,下架和不做处理。后置审核的一般使用场景较少,本模块着重讲商品的前置审核。
商品发布提交后,商品则在平台方的商品中心展示待审核的商品:
商品审核结果有两种:一种结果是不通过,一种是通过。
审核通过时在在售商品列表,审核不通过时在待售商品列表中未通过状态之列里,审核不通过时后台商品审核人员需要输入商品审核不通过的原因,以便于商家修改。在商品审核不通过时,在该商品的详情里需记录商品的审核记录。在商品审核结束后平台应及时通知商家运营者,以根据审核结果调整。
3.3 商品下架
定义:商品下架是运营者对在售的商品进行移除的功能,在平台方若下架商家商品则需要对下架说明原因。下架的商品则需要在商品中心有单独的区域展示,若是平台的商品下架则需对此功能做权限设置,并且在点击下架时需做二次确认。
3.4 商品修改
定义:商品的修改则在商品列表中添加修改的入口,可以将常用的使用频次较高的功能在从商品修改页面中单独分离出来以保证商品运营人员管理的高效性,例如商品的价格修改,排序修改等等。
3.5 类目管理
定义:运营人员对商品类目进行维护管理的功能,主要包含新增、修改、移动、删除,查看这五大基础功能。
这里以前台类目管理为例:
原型范例:
需要说明的是:在涉及到类目的删除,移动时在该类目下没有商品挂在,否则将会影响前端商品的展示。
本文讲述了电商后台中商品中心的核心框架,下文将继续更新商品中心的相关模块,欢迎关注~
本文由 @老猫丶 原创发布于人人都是产品经理。未经许可,禁止转载。
题图来自Unsplash,基于CC0协议
商品关联是个啥,这里是提前设置好商品了?
商品发布流的星衣橱是啥?是一个商品分类吗?赠品、星衣橱和商品为什么要分开,而不是作为商品的标签/属性呢?
展示类目删除时是否需要添加二次确认呢
肯定是需要的,如果下面有子类目或者挂在商品会有校验,如果没有也需要提示再次确认。
谢谢
用例图部分描述有误。用例采用的是动宾结构,如:属性管理,应该描述为管理属性,包含crud(新增、读取、修改、删除)等待,父用例不一定会被分解,还有审核商品,后面的通过,不通过,不能做为用例。
SPU与SKU还是有争议的,可能应用场景不同解释不同吧。
对分类的增删改查的逻辑还是不太清晰,例如 在某一类后面点击新增,那么进入的界面,是可以选择新增1级 二级 还是三级的是么?
在某一分类上新增的自然是同一分类,新增分类没有复杂的点,删除分类需要考虑此分类下是否有挂载商品。
没看过瘾
SPU图属否提供错误?版本、网络类型等是跟随后台分类的属性,iphone 8 和 iphone 8 plus是对应SKU的属性值。其实图上所示也是SKU,只是部分属性没有给出默认值。真正的SPU如文中所说iphone8是没错,但是却不是图上所示。
(二)呢
在最开始的前言部分有错字,前端不是前段。
这个是小编加的。。。