运营后台之商品管理篇:B2C电商(自营)是如何

2020-02-28 08:26
发布人:和记娱乐
来源:h88平台官网
        

  读大学那会还真没有想过自己最后会涉足互联网。不过命运就是这么奇妙,兜兜转转,最终我这个当初看不起互联网的屌丝也臣服在IT的皮鞭蜡烛之下,驱遣了。进入这个行当,就一直在做电商,从前端APP、H5页面等的设计,到后台的运营后台,以及中台ERP/WMS,都有涉及。眼看着很多做电商的小伙伴们,设计前端APP模块的时候还有竞品还分析,设计运营后台就没多少竞品可供参考了,故趁着最近心情还不错,本着独乐乐不如众乐乐的,就分享些个人的经验,免得大家踩不必要的坑吧。

  计划是写一个长篇系列,以自营的B2C平台为例,剖析运营后台主要框架,如果兴致高,可能还会包括WMS。不过我素来是懒癌患者,大家就求多福吧。以下是预计撰写但不一定写的文章,收好,不谢:

  使用户在前端能快速的发现商品(主要依赖于搜索以及商品列表页的筛选、前台分类的运营、促销活动的结构化以及精准化推荐等,这方面就要求商品管理模块能提供结构化的特征属性);

  使运营童鞋方便的商品信息(例如尽可能的简化步骤,使需要的信息尽可能的简洁而又完备);

  使运营童鞋能够结构化的管理整个平台的商品库(一个平台少则几千几万个SKU,多则几百万几千万个SKU,要分门别类,为运营提供品牌,基础分类等多个维度来管理商品库);

  对于上图的手机页面,前端呈现的各种信息怎么样通过后品管理模块一步步,请带着瓜子板凳,听我慢慢道来。

  对于未接触过电商的童鞋,可能对基础类目没什么概念。其实这个东西很好理解,基础类目就是商品属于什么基础分类,是手机,还是平板,还是笔记本电脑,换言之,商品的基础类目就是定义商品是什么。类似于生物学的门纲科目属。不同的基础类目之间实际上是描述这个类目的特征的不同。

  例如手机这个类目,对应的特征就是:前摄像头像素,后摄像头像素,屏幕尺寸,网络制式等;而裤子这个类目,对应的特征就是:腰围,裤长,面料材质,厚度等。对于电商,习惯上把描述不同类目的特征称之为属性,每一个类目的时候,就要选定该类目的属性,然后新增商品的时候,先选中该商品的类目,则会出现对应的属性供运营者。以属性为区分维度建立适合粒度而又不耦合的类目树,所有的商品,是商品管理的核心所在。

  一个电商APP的运营后台基础类目树只能有一颗,任一个商品只能属于该类目树上的一个基础类目。具体的类目管理包括:类目节点的新增/编辑/删除、类目节点的排序和类目节点的属性。

  每个平台默认有一颗基础类目树,点击菜单进入该类目树详情页,以选中的“休闲零食”这一节点为例,第一个页签“节点详情”为当前节点的明细,包括三个信息:名称(必填),描述,是否最小分类(必填,单选)。最小分类的概念是指在运营维度该分类已达到平台所需的最小粒度,没有必要在其下继续细分分类。

  对于非最小分类的节点,选中该分类还会有额外的两个页签,第二个页签是在当前分类下新增子分类,第三个页签是当前分类下一级子分类的排序操作。具体的界面下图:

  万一一个分类刚创建的时候被定义为了最小分类,例如上图中的“油炸商品”,后续商品SKU太大,运营需要继续细分,就需要变更这一定义,同时也有可能有分类创建的时候是“非最小分类”,后来需要变更为“最小分类”,这个时候需要校验一个逻辑:当前分类及其子分类有无关联商品。如果有商品,则不允许变更,若无商品,则可以变更。

  删除某分类时,需校验该分类及其各级子分类下是否有关联商品,若有,则不可删除;若无,则可以删除

  对于是最小分类的节点,则其没有子分类的新增和排序的页签,而是有额外的页签:分类属性。具体页面如下:

  属性分组:由于一个分类的属性有时会很多,可能几十上百个,所以又引入了属性分组的概念,把形容某一类特征的几个属性归属于一个组,这样在前端的规格参数里可以按后台设置的属性分组按序展示。

  属性的用途:分为基本、系列和导购。基本属性是指该属性会被展示在前详页的规格参数里。如下图:

  解释了上述概念,编辑和排序的具体细节操作不一一讲了,只讲比较重要的,就是对于最小分类,如何添加和删除属性。

  添加属性:分类的属性必须从已好的属性库里去选择。具体的操作界面如下,点击添加后弹出查询弹窗,查询到需要的属性后,选择该属性在当前分类下的用途,点击添加,即添加到当前分类。

  删除属性:若当前分类无商品,则属性可直接删除;若有商品,属性无法真正删除,从某属性组删除后会自动跳入默认的属性分组(每一个分类都有一个默认的属性分组);

  品牌管理的意义在于,一个平台共有的品牌库,商品新增和编辑的时候,只能从品牌库勾选已有可用的品牌,从而避免前台一个品牌多个名称,同时在运营过程中也能清晰的按品牌维度操作。

  属性管理主要是建立一个属性库,以精确描述商品,为用户提供必要的商品信息。就像我们形容一个人,会用身高、年龄、性别等属性来描述一个人。从前文讲基础类目的时候,聪明的读者应该已经领了每一个基础分类实际上就是一个属性集合(不要告诉我你不是),其实这才是暗合真理。哲学几大问,第一问就是“What”,要回答what是what,必然是用一个属性集来拆招的。

  和品牌库一样,属性库主要也是满足属性的查询、新增/编辑和删除的功能。主要讲下属性的新增/编辑吧。下图就是属性新增/编辑的页面。其中属性的编辑方式是“单选”或者“多选”的时候,下方必须可选择的值。

  经过的步骤,建好基础分类,建好品牌库和属性库,好基础分类的属性,就可以来新增一个商品了。商品管理模块同样离不开商品的查询、新增/编辑、删除以及商品的状态控制。

  首先讲下商品的状态控制。一个商品,从商品运营童鞋在后台新增,到上架以便前端用户可见可购买,不仅仅是上架下架这么简单。一个规范的商品管理模块,应该将涉及到商品运营的工作人员的工作流程化。具体来看,需要承担的工作有:商品的新增/编辑/删除(商品库),商品的审核(审核内容及售价),商品的上架和下架(日常销售运营),商品的巡查(即通过审核后的抽查)。不同的公司有不同的做法,有的是把职责综合起来,有的是分开来,但不管怎样,上述四个职责,是一定要体现的。下图是商品的管理流程:

  本来自营的B2C平台没有商家和平台之分,但为了大家更好的理解商品的新增/编辑/删除、审核、上下架、巡查(即上图中的锁定)各种操作,故特意假定自营也是一个特殊的商家,故上述流程引入了商家和平台的概念。具体对应的商品状态有新增、待审核、待上架、审核不通过和已下架5种。

  这么多操作中,具体讲下普通商品的新增和系列商品的新增。(参考前文给出的商品管理脑图,互相映照)

  商品新增的入口在商品查询页面,或者商品详情页。点击新增按钮,出现如下弹窗,其中商品类型分为普通和虚拟,仓库性质为国内仓,直邮仓,保税仓,商品分类为欲新增商品的基础分类。这三个字段决定商品的信息不同,以及含该商品的订单处理流程不同,故需要在新增第一步定义。

  要完成商品信息的,需将六个页签都完毕。其中商品图片主要是上传商品的图片,商品描述是一个富文本输入框,用来输入商品的文描。其余三个页签界面如下(商品页面的操作按钮随着商品的状态变化):

  库存运费页签:主要该商品在各地区的所属仓库以及各仓库中的库存控制,还有当前商品适用的运费规则。

  每个商品可选择一种运费规则,购物车结算时,遵守同一运费规则的商品按照规则计算该组用户运费,综合不同规则算出来的运费即为本次结算的总运费;

  一个商品可存放多个仓库,每个仓库需要设置该仓库的销售范围,这样可以根据前端用户的地址判断库存及订单的拆单与推送;

  每个仓库可以单独设置该商品的库存管理方式(简单起见,也可以同一设置,各仓库存单独和WMS同步)

  价格设置页签:主要该商品在不同平台(APP价格可以设低,以吸引用户转移向移动端),不用会员组别(新用户可低价以吸引用户下单,高等级用户可以享受低价以提升用户忠诚度)之间的售价。

  系列品的概念前文已经讲过,简单举例再说下,就是一件衣服S/M/L不同的尺码,或者不同的颜色。对于这样的商品,有的平台运营后台在后面成一个SKU,但带有不同的销售属性,个人认为比较好的做法是,把每个最小物理单位在系统中都成一个的SKU,只是在前台展示的时候按属性做下聚合,做到同一个页面点击不同属性就切换到不同的商品。如此,价格和库存等所有商品信息,都是每个的SKU控制。

  上图是平台所有系列商品的查询界面,点击新增,则弹窗如上图右侧,选定系列品的基础类目,品牌以及用哪个系列属性(即前文定义的属性,其用图包含系列)作为聚合维度,点击确认,跳转到系列品的新增页面如下图所示:

  还有一种商品形态,组合商品(即将两个的SKU A和B 打包在一起卖,同时A和B也在售卖),不过组合商品现在的应用实际上也没有那么广泛了,就简单讲下吧。

  对于组合商品通常有两种实现方式,一实一虚。实的是指组合商品C=A+B是一个的SKU,与普通商品一致有必要的商品信息(例如图片和文描),用户下单时系统里生成的订单商品直接记录该SKU=C的信息,只是在该订单发往WMS履行时,才将A和B而不是C推给WMS,该方式会带来一系列例如库存,销量统计等的不便;故个人认为可行的方式是走虚的线。即在新增组合商品时,实际只是新增了一条价格设置,当用户在前台搜索到A时,A的详情页会告知A+B的组合优惠价,用户一起将A和B 加入购物车结算时优惠的组合价生效。该种方式组合的商品没有的商品信息,但库存管理简单,下单主流程改动较小,对于系统而言,轻而且方便,也实现了以优惠带动目标商品销量的根本目的。

  前端分类是指PC或者APP中便于消费者定位某商品而又运营童鞋管理的一种分类,此分类与基础分类最大的不同,在于基础分类是定义一个商品是什么,有什么属性,不同基础分类之间的属性按理是不一样的,一个商品只能属于一个最小基础分类。

  前端分类是与消费者联系比较密切的一个分类,与消费者的认知趋同,贴近消费热点,比如Iphone7 128G黑色这款手机,即可能出现在前端“双摄像头手机”分类下,还可能出现在“大屏手机”分类下,或者将各个品牌最新旗舰手机聚合成一个分类,归属于“畅销旗舰“分类下。

  前端分类不局限于一颗,有可能PC是一颗,H5和APP是一颗,也有可能APP上不同的频道页的都有的分类树。

  前端分类树及其分类节点的查改增删就不一一细说了,这里只简单讲一个问题,怎么把商品聚合到某个前端分类节点下?其实这无外乎一个选品的功能,按照基础分类、品牌、和单个SKU三种不同维度筛选出商品,然后聚合即可。

  前端分类建好了,商品也关联好了,怎么展示在前台相应的?这个简单点的,可以由前端页面接口中写死;更进一步,可以由CMS模块来做配置,指定某页面展示某分类树,这一块,就要在以后的文章中谈到了。

  B2C电商(自营)运营管理平台之商品管理模块至此介绍完了。以上只是笔者从业以来经验的总结,不同的公司有不同的使用场景,其中细节部分大可斟酌,但万变不离其,就看大家怎么去架构了。希望上文能给大家带来帮助,坑能少踩就少踩,毕竟出来混,坑自己不要紧,坑了队友那就悲剧了,是吧?

  哲学几大问,第一问就是“What”,要回答what是what,必然是用一个属性集来拆招的。哈哈哈可爱

  待上架是指平台审核通过的商品,需要商家手动上架;已下架是商品通过了平台的审核,商家也手动上架了商品然后又进行了下架操作!

  不好意思,楼主17年的主旋律就是创业,后面实在太忙,文章基本没有再写了,另外,后面加微信朋友也基本没再加了,希望筒子们原谅楼主~~~

  当用户通过网站的前端分类,定位到某前端分类末级节点的商品列表页时,对应展示的属性是否是当前前端分类末级所关联的全部基础类目末级下绑定的属性的集合?

  人人都是产品经理(是以产品经理、运营为核心的学习、交流、分享平台,集、培训、社群为一体,全方位服务产品人和运营人,成立9年举办在线+期,线+场,产品经理大会、运营大会20+场,覆盖北上广深杭成都等15个城市,在行业有较高的影响力和知名度。平台聚集了众多BAT美团京东滴滴360小米网易等知名互联网公司产品总监和运营总监,他们在这里与你一起成长。

      和记娱乐,和记h88,h88平台官网