非小型电子商务系统设计经验分享

Posted 2021-03-05 cdchencw

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了非小型电子商务系统设计经验分享相关的知识，希望对你有一定的参考价值。

来源：https://www.cnblogs.com/mmmjiang13/archive/2012/07/05/2575538.html#!comments

前言

做了两年多针对淘宝的电子商务数据线下数据系统，越到后面越觉得自己还没入门，不管技术上还是业务上，这篇文章既是对自己的积累的一次梳理，更想的是能在和各位朋友交流中，互相进步。
ps:所有字段并不是正式项目所使用字段，请根据自己的业务需求进行酌情查看处理,类目属性，商品，订单结构可以参考淘宝API数据接口进行查看具体字段。

商品模块设计

商品模块是支撑整个架构的核心，如果这块没设计好，那么所有后期的复杂的统计需求基本都满足不了。

为什么这样子设计属性看这里和这里，把品牌从类目中剥离出来是为了降低程序针对商品属性这块的复杂度。这里通过淘宝的添加宝贝的操作来说明上面的数据结构如何满足下面的需求:

PS:本来要截玉兰油沐浴露的图，结果发现淘宝取消了以前选择毫升*买的多送得多组合SKU的添加商品方式，改成了一个SKU就是一个宝贝的编辑手段，呵呵，没办法，只有上面截个衣服的图，下面的数据却是快消品的。淘宝这样做这也是没办法的，这种快消品不同SKU，图片还不能用一样的，而且大部分用户搜索的时候呢，会喜欢直接搜索具体的毫升数,这也给我们提了个醒，不同的类目可能会是不一样的处理方式，就算是服装这种SKU相对标准的类目，也会有说在展示和搜索结果中，会放置一个产品的多个SKU，比如凡客的网站，一件衣服的几个颜色都会出现在类目搜索结果中，增加曝光度，吸引用户点击购买。

页面属性的编程实现可以参考这里。SKU存放在产品SKU表中，按我们的实际需求增加修改字段，比如我的表中多了ProductCode和BarCode字段，SKU的属性会拆分后存入产品基本属性值表，便于搜索或统计等需求。商品的基本属性全部打横存入商品的基本属性表中，那么SKU表的存储如下：

那么这个item是4013的产品在基本属性值表中的数据存储如下：

这里我是把所有的属性都打成一条一条存储在这个表中，那么能满足我们在日常业务的属性搜索，统计等需求。按属性搜索，这里必须要注意以下几点：

1.不可能所有的属性都开放给用户或者我们的客户进行搜索，所以我们会在属性名表中有个字段（是否搜索字段）来人工控制哪些属性是搜索属性

2.基本属性是同一个宝贝下面所有SKU都共有的，SKU属性是单个SKU独有的，所以搜索的时候还必须分清楚销售属性（销售属性组成SKU）和基本属性。

3.属性图片的存储我并没有设计，因为我们是做快消品，没有这个需求。但是，如果我做的话我还会是在基本属性值表中加上”是否图片属性，是否使用默认图片，图片URL“3个字段来记录颜色属性。做属性搜索的时候比较方便。

4.产品通过关键字搜索和属性搜索是分开的，两种搜索并不是一种解决方式，比如淘宝，在首页的搜索框是通过分词匹配宝贝标题的关键字，通过关键字的匹配程度，店铺的dsr评分权重来决定搜索结果，而属性搜索的时候则是匹配满足属性条件的宝贝。那属性又分第1点和第2点，所以还是挺麻烦的。

那到了这里产品的存储已经说完了，其它的运费什么的，就懒得说了。

这里你会发现有打包品表，打包品子表，最终商品表，商品变更记录表。这里需要详细说明一下。

首先说一下打包品概念：

打包品：为了各种运营上的需求，很多时候我们会人为的把多个SKU组合成一个商品进行组合销售，我们在淘宝购物的时候，经常会看到这样的情况，A产品+B产品组合销售，AB的组合在淘宝上面表现为一个宝贝，你看看这里或者这里或者这里，这些就是拉。这种销售数据在订单里表现是一个淘宝商品，但是我们要做库存管理，数据分析等需要拆分出来。这是必须考虑的！

PS：有那种出厂打包品，比如一个包装盒里面有香皂，有沐浴露，但是它们本身就是一个SKU，出厂就这样，所以不能和打包品混为一谈。

由于我们运营上的需要，我们可能卖单个SKU，也可能卖多个SKU的组合，那么在我这里把单个SKU和多个SKU组合都看成打包品，单个的SKU打包品它的子项只有它自己，这样做的好处是，系统中只需要一种方式来处理这种关系。在打包品表中通过类型来区分。

这里有一个关键问题要注意，我们在出售商品过程中，价格是可能会随时人工或者系统来干预变化的，比如产品A标题叫B洗发水+C护发素直降20元，但是我们根据实际的流量和转换率价格可以上下浮动，那么我们就要及时的调整价格，所以我们的标题，价格都需要进行更改，这里牵涉2个问题，我们是新建一个打包品或者我们是另外放在最终商品表，我们就需要修改对应的标题和价格，同时呢，在商品变更记录表中记录添加一个上次修改的备份，作为我们对不同价格的转换率的一个分析基础数据。第二个问题就是由于修改了打包品或者创建了新的打包品（SKU子项，SKU数量一样）价格，那么对应的分配到每个具体SKU的价格发生了变化，这里如果是新建了打包品就没问题，但是如果是修改打包品，那么我们对打包品SKU子项的价格就必须通过相应的公式进行计算。比如A+B+C今天是100元，A是30，B是50，C是20,如果价格变成了90或者110，那么对应到具体的子项价格也需要更改，因为很经常的需求就是统计某产品或者某SKU的销售量和销售额。

所以最终是我们网站上是出售打包品还是最终产品，是每次新建打包品还是修改，这要看自己权衡。但是商品的价格变更是一定要记录的。一是留备份，二是分析价格对销售的影响等等。

这样设计遇到的问题

1.起初产品维护人员意见很大，觉得很复杂，工作量很大。因为这种结构需要维护人员维护属性，并且需要他们懂一些专业知识和熟悉整个流程，各种名词搞得他们头晕，后面甚至出现了相当大的负面抵触情绪。这个没办法，因为我们这个不是网站，不是说让你简单的舒服的就能添加一个商品，这个需要掌握分类-产品-属性-打包品之间的业务关系以及这样维护的好处。解决办法：1.慢慢沟通，说明增加的工作量是为了他们在出复杂的报表的时候不需要手动去进行筛选，而且基础数据维护好了，一劳永逸。2.一定要培训好产品维护人员，让他们在有相关业务背景人员指导下能清晰的分清楚属性的意义，以及根据业务规则维护好属性基础表和录入产品等信息。

2.由于一开始数据的关联检查机制没做好，导致后面乱了很多数据，所以在后面又来花时间检验数据和建立起相应的检查机制，浪费了很多时间。

订单模块结构

这里关系很简单，我想着重说明3个问题，

1个就是订单主表中存储地址库ID+买家具体地址组合成购物地址，不是依赖用户收货地址的信息，因为用户的收货地址是可能发生人为的修改的。

2.地址库的城市级别，这是一个统计维度，最好加上

3.在订单子表中，不仅存储了打包品的ID，还会把当时网站上该商品的标题和SKU名字，以及当时的价格存储进来，这是很有必要，不能直接使用关联的打包品或者商品的价格，标题，前面说了，随时可能改变的。

4.促销信息表，这里就是记录所有促销活动信息，一个商品可能对应多个促销活动，比如使用了优惠券+（满200-20）+ 满100包邮+VIP优惠10元+XXX。这样的设计是比较好的。从订单角度来看这个订单应用了多少个活动模型，能准确的抽取某种促销活动的所有订单。

不要把这种东西设置产品表中，或者与产品表进行关联，先不考虑其它原因，首先把业务模型和产品模型混在一起就乱了。

活动模块设计

由于我们的订单表有订单活动促销信息表与其关联，那么实际上我们统计一般的需求只需要关联过来活动模型表就能得到说某个活动或者某类活动的数据情况，这里对于前台商品活动信息是个悲剧，一套活动缓存跟新机制，前台所有商品显示的时候和所有订单提交时检查是否满足所在时间内的活动模型来展示不同的UI。

还会有很多活动模型，这里只是列了几个，另外，必须注意一个问题，只要涉及到包邮的地方就要考虑有的地方不能包邮。也可以单独存储不包邮的城市。这个就要看业务上如何决定这个模型怎么建立。

访问跟踪模块设计和CRM

访问数据这一块我们是结合量子统计和自己跟踪的数据进行合并数据出数，这块我就过掉了，因为这块感觉我们并没有做太深，今年会单独把这块加强。我只想说，这块很重要。这一块是电子商务运营过程中的重中之中，没有他，几乎所有的带有指导性的报表数据你都没办法出。没有他就没有转换率，没有它，你就不知道站外推广的效果如何，没有他，你就不知道网站栏目，活动标题，图片等怎么去改版，甚至商品怎么放置!!!等等等等….

CRM也是一样，我们现在的弱项，我们现在着重统计用户回购率，对品牌忠诚度等一些现在业务上比较关注的面，没有钻深，但是这样光这样说好像有点太那啥，我放点收集的资料吧，这也是我们下一步努力的目标。

建立CRM的最本质目就是获取、保持和增加可获利客户（消费者）。