前言
做了两年多对于淘宝的电子商务数据线下数据平台，越到前面越感到自己还没入门，不管技术上而是业务上，这篇文章既是对自己的累积的一次梳理，更想的是能在和大家朋友交流中，互相进步。
ps:所有字段并不是即将项目所使用字段，请依照自己的业务需求进行酌情查看处理类目属性，商品，订单结构可以参考淘宝API数据接口进行查看具体字段。
商品模块设计
商品模块是支撑整个构架的核心，如果这块没设计好，那么所有前期的复杂的统计需求基本都满足不了。
为什么这么子设计属性看这里和此处，把品牌从类目中剥离下来是为了减少程序对于商品属性这块的复杂度。这里借助淘宝的添加宝贝的操作来表明上面的数据结构怎样满足以下的需求:
PS:虽然要截玉兰油沐浴露的图，结果看到淘宝取消了当时选择毫升*买的多送得多组合SKU的添加商品形式，改成了一个SKU就是一个孩子的编辑方式，呵呵，没办法，只有前面截个帽子的图，下面的数据却是快消品的。淘宝这样做这只是没办法的，这种快消品不同SKU，图片还不能用一样的，而且大个别用户搜索的之后呢，会喜欢直接搜索具体的毫升数,这也给我们提了个醒，不同的类目可能会是不一样的处理方法，就算是服装这种SKU相对标准的类目，也会有说在展现和搜索结果中，会放置一个产品的多个SKU，比如凡客的网站包装设计影响销售量 的数据统计，一件服装的几个形状都会出现在类目搜索结果中，增加曝光度，吸引用户点击购买。
页面属性的编程实现可以参考此处。SKU存放在产品SKU表中，按我们的实际需求降低修改字段，比如我的表中多了和字段，SKU的属性会拆分后存入产品基本属性值表，便于搜索或统计等需求。商品的基本属性全部打横存入商品的基本属性表中，那么SKU表的存储如下：
那么这个item是4013的产品在基本属性值表中的数据存储如下：
此处我是把所有的属性都打成一条一条存储在这个表中，那么能满足我们在日常业务的属性搜索，统计等需求。按属性搜索，这里必需要留意以下几点：
那到了此处产品的存储已经说完了，其它的运费什么的，就没法说了。
此处你会看到有打包品表，打包品子表，最终商品表，商品变更记录表。这里应该具体说明一下。
首先说一下打包品概念：
打包品：为了各式运营上的需求，很多之后我们会人为的把多个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的最本质目就是获得、保持和提高可盈利客户（消费者）。
以下商务合作
